前两天给头提的新开发方式

前些日子头说要新的ABL小组探索一些新的开发方式，我满心欢喜，提出了一个结合公司实际的方案。 可惜，在现实的压力面前他们退缩了，回到了老路。 心有不甘，记录在此，凭吊之~~~~

[quote]

ABL工作流程和方式
      （草稿）
    
业务：
  1、请一位测试组成员加入ABL小组，为ABL小组业务负责人。
  2、所有的业务需求的收集、变化、确认，都集中于此业务人员。
    技术人员在业务上的精力可以适量减少。
  3、开发人员有业务问题需要首先咨询业务人员。在业务人员依然不清楚地情况下，可以由业务人员发起同美国同事的讨论。
  4、所有的需求变化和确认状况需要通知全组人员。
  
技术：
  
  开发原则  
   A：进行单元测试。
      后台主要测试BO和DAO，测试工具为JUnit（DBUnit）工具；
      前台主要使用Selenium测试。
      单元测试没有通过的代码不可以提交到CVS。
   B：每完成一小步就集成测试，间隔时间尽量缩短。具体时间可以根据实际开发状况调整。
     集成测试自动化。
   C：在完成任务后，可以到组长处领取新任务或者帮助他人完成任务，可以自己选择。
   D：如果在指定时间内某人没有完成任务，责任不仅仅是任务领取人个人的，也是大家的。
   E：每天上午9:30，在会议室召开例会（立会）。所有人站立开会，每次时间控制在15分钟左右。
     每个人回答四个问题：
      1〉昨天开会之后作了什么？
      2〉今天要做什么？
      3〉碰到了什么障碍？
      4〉有什么要同大家共享的？
     会上提出问题，会后解决问题。
     
  开发步骤：
    step 1: 所有人员阅读所有文档，需要熟悉理解所有业务需求。
    step 2: 前台与后台分开走。
        两人负责前台delegate之前；两人负责后台从delegate到DAO。
        delegate接口双方共同协商。
        后台是模拟实现，前台是全部实现。
    step 3：集成测试，跑通流程，业务人员确认主流程正确。
    step 4：实现业务逻辑（单元测试）
    step 5：集成测试（频密）
    step 6：将step4与step5循环，一直到项目结束。

[/quote]

评论

19 楼 steven_xu 2007-04-09  

1.关于测试人员加入到项目中的问题：一两年前和dreamhead一起做过一个项目，虽然项目的类型和你的项目不同，那个时候有个测试强人在项目启动阶段就加入到我们组，从需求开始做，一样的做需求的分析，做用例，做架构，做设计。。。都是从测试人员的角度出发的，当时这种方式给我们冲击很大，在开发中不断感觉到测试人员眼中的项目开发，能感觉很多时候测试对于项目的开发有很大的推动力量。一直给人留下深刻影响。如果有机会，建议尝试，很不错的。<br/>
2.我们项目一直在用wiki作为共享的平台，每个开发人员或者测试人员都可以写很多东西，开会的小结，个人的想法，共享出来的文档，小的设计，大的架构，各个阶段的经验，业务的模型，还有大家经常可以写一些鼓舞士气的话，很不错。现在正在推广到项目组以外呢。搭建一个wiki平台很容易，当然你要带头写很多东西，慢慢积累了大家觉得都不错，都开始写了，而且可以搜索，可以分享，甚至开发人员离去了，但是他／她曾经的想法还在那儿呢。<br/>
3.我们项目组的想法一直就是迭代迭代，事情一步一步的做，慢慢的积累，一两年下来发现已经形成了很多好的习惯。

18 楼 bdv32mfe 2007-04-02  

没有什么实际经验，怎么能照搬书上的东西呢.
如果目前的开发方式有问题的话，尽量完善目前的开发方式，而不是另搞一套。
说话比较直率，请谅解.

17 楼 basicbest 2007-03-30  

adamzhao 写道

虽然我确实在公司的内部技术交流中专门介绍过敏捷，但是本次提出方案我没有打着敏捷的旗号。只是想针对公司目前存在的问题，从敏捷思想中借鉴一点东西，提出一些新的方式，希望能够解决目前的一些问题。自然这个方案非常幼稚，呵呵，或许正是这种幼稚遭到“长老”们的“反感”。

像我这样只是汲取了敏捷一点点东西，就很难展开了。所以我认为敏捷推广“任重而道远”。

呵呵，敢于实践就是值得鼓励的，人类发展的过程就是一部战争史，个人也是一样，每个人的发展其实也是一个不断犯错的过程。大家一同讨论，然后进行修正。

adamzhao 写道

小组一共三个半人，那半个是一名组员只被头分配了50%的时间和精力。
之前小组内部分配任务，一人分配一个或几个模块，从前台一直做到后台（JSP > Action > delegate > accessor > EJB > Bo > Dao）。存在很强的封闭型，这样的代码拿给别的人是很难理解。可能我在那个草稿中的说法不清楚。我想体现的是，第一：代码共享；第二：配对编程。PP非常难以实现，但是代码共享还是可以做到的。所以提出了这样的想法。希望大家互相关注，团结一致。

这个小组规模非常小，流程只会降低效率，但是定义基本的策略还是有必要性的，这是为了消减人力上的风险。比如人员退出（离职，生病，乃至死亡），新进人员等等。
这个策略是把你们团队的价值观进行强化。

adamzhao 写道

这个提法是想解决两个问题：
第一，掌握项目进度，控制节奏。以往公司都是要求大家填写project，但是这个东西是静态的，只会写上完成的百分比，无法体现项目和小组成员的真实状况。项目经理只要看到大家完成的百分比，然后就催促进度。

第二：加强沟通。譬如：碰到了什么问题？有什么成功经验？有什么想要告诉大家的？ 现在小组成员之间根本就没有太多交流，每天闷头干活，只不过大家碰巧都在做一个模块里的东西而已。简单几个问题，就能知道大家的状况，更多的交流会后就会在成员之间展开。

第三：说到浪费时间，那我们也来算一算。例会每天召开，每次都控制在15分钟之内。这样每周五天，最多就是75分钟。而目前的例会是每周五召开，每次都是拖拖拉拉，至少要一个半小时才能开完。那么75分钟和90分钟那个更加浪费时间就很明显了。

我说说我的做法，每天下午17：00（17：30下班）有1-5分钟的例会，用于解决项目共性的问题，上次进度的总结，以及决定及决策。
项目个人的问题，开始时每天会例行巡查，了解项目问题，待成员养成习惯后，鼓励员工主动汇报，然后再辅以随机巡查。
每周末，或者相对重要的日子，比如迭代检核点，有例会，这个时候是要一起讨论解决问题，花费时间长些，但是由于绝大部分问题都在平时解决掉，这个例会就很轻松，倒有点像是供大家偷懒用的。
之所以不在日会议上让每个人都发言，是因为，我们国家是有开会陋习的，而且，过程中绝大部分问题都不是非常复杂，但是大家一讨论就会越来越复杂，所以，把解决问题放在会议以外，这样也能为团队的高效协作创造机会。

adamzhao 写道

前边我回答过这个问题。呵呵，实际上我们现在只有几个文档，量很小。而且正处于需求收集阶段，在这个阶段要求大家熟悉理解所有的业务（也只是概要的），不过分吧？否则怎么实现代码共享？怎么能够知道别人在做什么？

这点我的看法是，如果不知道为什么要共享代码，那么就不去共享。知道别人做什么不那么重要，解决开发中的问题是重要的。当然，因为你们的团队较小，所以如果是另外一个原因，就是因为没有架构师，所以，要求大家了解业务也是有可以的。虽然说架构师不是要了解所有业务，但是业务是影响你们使用的技术的，在没有架构师来全局考察技术架构的情况下，使大家都了解业务从而能够交流设计，这也是解决的方法。

adamzhao 写道

javaeye上我最关注的就是项目管理和敏捷了，o6z应该是实干者和理论者，我非常佩服。白衣的很多东西更接近我的状况。顺便说一句，他在springside上提的对service的单元测试可真的不算是纯正的单元测试了。  

呵呵，一起学习

16 楼 rainlife 2007-03-30  

基本上每一个公司都有自己公司一套的,主要就是看头了,原来的PM蛮推崇域建模及XP的,基本都是从一个一个的user story开始,但后来的PM就不喜欢了,还是走原来的老路,整个team又回到了从前。

15 楼 gigix 2007-03-30  

http://www.iteye.com/topic/66559

14 楼 adamzhao 2007-03-30  

呵呵，很高兴与你交流这个问题。
首先声明，我没有敏捷的实践经验，知道的那点东西都是书本和网络上的。

basicbest 写道

敏捷只是一种思想，如果咋们非要打着敏捷的旗号，相信成功的可能性不大。我在项目中推行流程和方法都是根据喜好，如果老板喜欢RUP，我就说这个是RUP，其实他怎么知道RUP是什么？如果你说自己在敏捷，如果站在“长老”们的角度，相信我也会反感你的。

虽然我确实在公司的内部技术交流中专门介绍过敏捷，但是本次提出方案我没有打着敏捷的旗号。只是想针对公司目前存在的问题，从敏捷思想中借鉴一点东西，提出一些新的方式，希望能够解决目前的一些问题。自然这个方案非常幼稚，呵呵，或许正是这种幼稚遭到“长老”们的“反感”。

像我这样只是汲取了敏捷一点点东西，就很难展开了。所以我认为敏捷推广“任重而道远”。

basicbest 写道

我不知道你们的团队大小，但是可以发现的是，这个流程本身并不能体现敏捷。有些可能犯了基本的管理上的失误。
比如：
D：如果在指定时间内某人没有完成任务，责任不仅仅是任务领取人个人的，也是大家的
这样职责不明，队伍稍大些，就会出现一只老鼠坏锅汤的问题。

小组一共三个半人，那半个是一名组员只被头分配了50%的时间和精力。
之前小组内部分配任务，一人分配一个或几个模块，从前台一直做到后台（JSP > Action > delegate > accessor > EJB > Bo > Dao）。存在很强的封闭型，这样的代码拿给别的人是很难理解。可能我在那个草稿中的说法不清楚。我想体现的是，第一：代码共享；第二：配对编程。PP非常难以实现，但是代码共享还是可以做到的。所以提出了这样的想法。希望大家互相关注，团结一致。

basicbest 写道

E：每天上午9:30，在会议室召开例会（立会）。所有人站立开会，每次时间控制在15分钟左右。
如果有项目经理这样定义，我的第一个想法就是：离开这家公司，至少离开这个项目组。
“所有人站立开会”这个非常诡异。如果我是瘸子，你叫我咋办？
召开例会是没有问题的，但是把“站立开会”写在书面文件中是非常奇怪的事情。
另外，每个人都回答四个问题的做法，即使在一个很小的团队都是很浪费时间的。而且，这种方法应当算是被动式的管理方式。

这个提法是想解决两个问题：
第一，掌握项目进度，控制节奏。以往公司都是要求大家填写project，但是这个东西是静态的，只会写上完成的百分比，无法体现项目和小组成员的真实状况。项目经理只要看到大家完成的百分比，然后就催促进度。

第二：加强沟通。譬如：碰到了什么问题？有什么成功经验？有什么想要告诉大家的？ 现在小组成员之间根本就没有太多交流，每天闷头干活，只不过大家碰巧都在做一个模块里的东西而已。简单几个问题，就能知道大家的状况，更多的交流会后就会在成员之间展开。

第三：说到浪费时间，那我们也来算一算。例会每天召开，每次都控制在15分钟之内。这样每周五天，最多就是75分钟。而目前的例会是每周五召开，每次都是拖拖拉拉，至少要一个半小时才能开完。那么75分钟和90分钟那个更加浪费时间就很明显了。

basicbest 写道

step 1: 所有人员阅读所有文档，需要熟悉理解所有业务需求。
这个也是很奇怪的做法，实在不知道这样做的意义。

前边我回答过这个问题。呵呵，实际上我们现在只有几个文档，量很小。而且正处于需求收集阶段，在这个阶段要求大家熟悉理解所有的业务（也只是概要的），不过分吧？否则怎么实现代码共享？怎么能够知道别人在做什么？

basicbest 写道

有些东西流行并不是因为它确实合适，而只是因为它迎合了某些人的心理需要。但是心理需要归心理需要，赚钱还是最重要的。有市场的且能够带来盈利的才是最好的。
建议楼主研究一下UP，以及其他的Agile方法，比如FDD，Scrum，水晶等等。江南布衣的观点相对比较中肯，我觉得可以参考。o6z的观点有些超前，可以在深入以后再去理解。其他还有很多有真正的具体经验的朋友意见都不错。当然，这些只是我的看法。不管怎样，千万不可听信一家之言。

javaeye上我最关注的就是项目管理和敏捷了，o6z应该是实干者和理论者，我非常佩服。白衣的很多东西更接近我的状况。顺便说一句，他在springside上提的对service的单元测试可真的不算是纯正的单元测试了。  

13 楼 gigix 2007-03-30  

basicbest 写道

gigix 写道

adamzhao 写道

不过我现在面对的问题是：我向大家展示了自己的想法之后，年轻的普通的开发者表示赞同的比较多，年长的开发者和头却不是特别认同。
也就是说抵触情绪来自于上层。

我在敏捷方面目前只是个爱好者，没有实践经验，资历浅薄。为了推动公司的能够接受敏捷，年前我甚至请来了TW的马X给我们头讲解。 呵呵，高级咨询师呀，照样没撼动。

一句话：推动敏捷，任重而道远啊~~

对于上层，你需要告诉他们：这样做了以后能带来哪些价值。让他们清楚看到做这些事情的利益所在，他们会比较容易接受。
有机会的话，可以找我们再去帮你撼一撼。

你们撼成功了哪些案例？？

http://www.thoughtworks.com.cn/case-studies.html

12 楼 basicbest 2007-03-29  

gigix 写道

adamzhao 写道

不过我现在面对的问题是：我向大家展示了自己的想法之后，年轻的普通的开发者表示赞同的比较多，年长的开发者和头却不是特别认同。
也就是说抵触情绪来自于上层。

我在敏捷方面目前只是个爱好者，没有实践经验，资历浅薄。为了推动公司的能够接受敏捷，年前我甚至请来了TW的马X给我们头讲解。 呵呵，高级咨询师呀，照样没撼动。

一句话：推动敏捷，任重而道远啊~~

对于上层，你需要告诉他们：这样做了以后能带来哪些价值。让他们清楚看到做这些事情的利益所在，他们会比较容易接受。
有机会的话，可以找我们再去帮你撼一撼。

你们撼成功了哪些案例？？

11 楼 basicbest 2007-03-29  

敏捷只是一种思想，如果咋们非要打着敏捷的旗号，相信成功的可能性不大。我在项目中推行流程和方法都是根据喜好，如果老板喜欢RUP，我就说这个是RUP，其实他怎么知道RUP是什么？如果你说自己在敏捷，如果站在“长老”们的角度，相信我也会反感你的。
我不知道你们的团队大小，但是可以发现的是，这个流程本身并不能体现敏捷。有些可能犯了基本的管理上的失误。
比如：
D：如果在指定时间内某人没有完成任务，责任不仅仅是任务领取人个人的，也是大家的
这样职责不明，队伍稍大些，就会出现一只老鼠坏锅汤的问题。

E：每天上午9:30，在会议室召开例会（立会）。所有人站立开会，每次时间控制在15分钟左右。
如果有项目经理这样定义，我的第一个想法就是：离开这家公司，至少离开这个项目组。
“所有人站立开会”这个非常诡异。如果我是瘸子，你叫我咋办？
召开例会是没有问题的，但是把“站立开会”写在书面文件中是非常奇怪的事情。
另外，每个人都回答四个问题的做法，即使在一个很小的团队都是很浪费时间的。而且，这种方法应当算是被动式的管理方式。

step 1: 所有人员阅读所有文档，需要熟悉理解所有业务需求。
这个也是很奇怪的做法，实在不知道这样做的意义。

有些东西流行并不是因为它确实合适，而只是因为它迎合了某些人的心理需要。但是心理需要归心理需要，赚钱还是最重要的。有市场的且能够带来盈利的才是最好的。
建议楼主研究一下UP，以及其他的Agile方法，比如FDD，Scrum，水晶等等。江南布衣的观点相对比较中肯，我觉得可以参考。o6z的观点有些超前，可以在深入以后再去理解。其他还有很多有真正的具体经验的朋友意见都不错。当然，这些只是我的看法。不管怎样，千万不可听信一家之言。

10 楼 温柔一刀 2007-03-28  

gigix 写道

adamzhao 写道

不过我现在面对的问题是：我向大家展示了自己的想法之后，年轻的普通的开发者表示赞同的比较多，年长的开发者和头却不是特别认同。
也就是说抵触情绪来自于上层。

我在敏捷方面目前只是个爱好者，没有实践经验，资历浅薄。为了推动公司的能够接受敏捷，年前我甚至请来了TW的马X给我们头讲解。 呵呵，高级咨询师呀，照样没撼动。

一句话：推动敏捷，任重而道远啊~~

对于上层，你需要告诉他们：这样做了以后能带来哪些价值。让他们清楚看到做这些事情的利益所在，他们会比较容易接受。
有机会的话，可以找我们再去帮你撼一撼。

这个实在，最重要的是要得到头的支持

ps：gigix貌似在乘机揽业务

9 楼 adamzhao 2007-03-28  

gigix 写道

对于上层，你需要告诉他们：这样做了以后能带来哪些价值。让他们清楚看到做这些事情的利益所在，他们会比较容易接受。
有机会的话，可以找我们再去帮你撼一撼。

好，合适的时候一定请你们再帮忙撼一撼！

8 楼 adamzhao 2007-03-28  

<br/>
<strong>ahuaxuan 写道：</strong><br/>
<div class='quote_div'>
<p><font>

<strong>adamzhao</strong> 写道

</font></p>
<p><font>     <br/>
  开发步骤：<br/>
    step 1: 所有人员阅读所有文档，需要熟悉理解所有业务需求。<br/>
    </font></p>
<p><font>

</font></p>
<p>这在我们项目组里是不可能的，不可能有那么多时间来让所有人阅读所有文档，自己负责的那块肯定要仔细阅读，其他部分只需了解，另外的不足靠teammates之间的面对面的直接沟通，这样效率比较高</p>
</div>
<p> </p>
<p>可能我们的情况不太一样吧</p>
<p>我们做的东西都是从美国总部那边拿过来了，初始时只有一个概念化的文档，告诉你要做一件什么事情。</p>
<p>然后需要北京这边与美国那边不断的研究和讨论。逐渐逐渐理清楚、想明白，形成一个完善的需求文档。（这里没有敏捷中的现场业务人员引领）</p>
<p>然后再到概要设计，详细设计。等到详细设计和开发的时候才会各自管各自的模块。</p>
<p> </p>
<p>基于这样的现实，我提出了要在测试人员中抽取一个人作为ABL组的业务人员，先于我们了解需求；但是所有的组员应该整体了解才行，否则的话如何对别人做的事情也有概念？</p>

7 楼 gigix 2007-03-28  

adamzhao 写道

不过我现在面对的问题是：我向大家展示了自己的想法之后，年轻的普通的开发者表示赞同的比较多，年长的开发者和头却不是特别认同。
也就是说抵触情绪来自于上层。

我在敏捷方面目前只是个爱好者，没有实践经验，资历浅薄。为了推动公司的能够接受敏捷，年前我甚至请来了TW的马X给我们头讲解。 呵呵，高级咨询师呀，照样没撼动。

一句话：推动敏捷，任重而道远啊~~

对于上层，你需要告诉他们：这样做了以后能带来哪些价值。让他们清楚看到做这些事情的利益所在，他们会比较容易接受。
有机会的话，可以找我们再去帮你撼一撼。

6 楼 ahuaxuan 2007-03-28  

<div class='quote_div'>
<p><font>

<strong>adamzhao</strong> 写道

</font></p>
<p><font>     <br/>
  开发步骤：<br/>
    step 1: 所有人员阅读所有文档，需要熟悉理解所有业务需求。<br/>
    </font></p>
<p><font>

</font></p>
<p>这在我们项目组里是不可能的，不可能有那么多时间来让所有人阅读所有文档，自己负责的那块肯定要仔细阅读，其他部分只需了解，另外的不足靠teammates之间的面对面的直接沟通，这样效率比较高</p>
</div>
<br/>
<br/>
<br/>
<br/>

5 楼 adamzhao 2007-03-28  

tuti 写道

首先要集体总结过去.
哪些是好的,要保持.
哪些是不好的,要改正.

只有大家都觉得有些东西是问题以后,
再讨论出针对这些问题的一些处理方式.

如果是你个人提出,容易出抵触情绪.

低调,低调.

有道理！

不过我现在面对的问题是：我向大家展示了自己的想法之后，年轻的普通的开发者表示赞同的比较多，年长的开发者和头却不是特别认同。
也就是说抵触情绪来自于上层。

我在敏捷方面目前只是个爱好者，没有实践经验，资历浅薄。为了推动公司的能够接受敏捷，年前我甚至请来了TW的马X给我们头讲解。 呵呵，高级咨询师呀，照样没撼动。

一句话：推动敏捷，任重而道远啊~~

4 楼 tuti 2007-03-28  

首先要集体总结过去.
哪些是好的,要保持.
哪些是不好的,要改正.

只有大家都觉得有些东西是问题以后,
再讨论出针对这些问题的一些处理方式.

如果是你个人提出,容易出抵触情绪.

低调,低调.

3 楼 giscat 2007-03-28  

流程不要太复杂，尽量简单
尽量常规时间结束战斗，
  少加班，多拿钱是正道

2 楼 adamzhao 2007-03-28  

dada说的对，这确实不是一个很好的方案。是我写的一个初稿，很多东西考虑的确实不全面。 对于敏捷我只有书上和论坛上的知识，具体的实践确实没有，所以也一直渴望能实践一把。但在一个早就习惯了瀑布式的环境中推动敏捷必须一步一步走，所谓摸着石头过河。

提出一个实践草稿，然后逐渐在实际中验证和寻找更佳的解决方式，我想最重要的就是要“开始”。

1 楼 dada 2007-03-28  

说实话，我不觉得这是一个特别好的方案。
姑且不论这样的测试和开发方式是否会带来一个高效的项目，我看到的最大问题是项目里面充满了责任，但是缺少机制让人去履行责任。