`

跌跌撞撞地敏捷之路——第一次敏捷开发

阅读更多

日期:2009.02.16——2009.03.06

      这个项目将尝试采用敏捷开发。

      敏捷是什么,现在回想起来,当时项目组成员对这方面的了解几乎就是空白,十足的敏捷白痴(现在这样讲,其实也是在五十步笑一百步,惭愧),只知道这是时下比较时髦的名词,还有几个相关的名词:迭代、结对编程、极限编程、scrum、story、燃尽图,对所有这些名词的了解也顶多停留在非常肤浅的认知上。对于我自己来说,也是人云亦云,外加上很久很久以前走马观花地瞟了几眼《硝烟中的Scrum和XP》,也多亏这几眼,我才知道敏捷里还有scrum、story、燃尽图这几个名词,汗颜。

      项目启动前走的流程还是沿用了CMM的老一套,产品SE下规格,然后规格评审,为初步估了代码量,最后就开始准备立项开发了,这时到岗的开发人员有三个:PL(CMM中的称谓)、我和另一个同事,根据估出来的代码量,需要再协调两个人开发人员,其中一个在项目启动前就到位了,另一个还暂时定在南京异地开发(我们在深圳),这与敏捷开发原则是相违背的——团队成员最好能做到同地紧密协作,而且能够做到每日面对面交流。后来我们在这一点确实尝到了苦头。

      由于项目组成员对敏捷开发都不熟悉,项目启动前申请了一个培训,但由于培训老师本身并没有参与过敏捷项目,培训过程也差不多就是照本宣科外加讨论,所以这个培训其实也没有起到多大的作用,我并不是在说培训老师能力差,其实换任何一个没有具体参与过敏捷项目的人来给人培训,都不会有什么成效。敏捷不是光靠看书、靠参加就能学会的,只有参与过敏捷项目的人,才能在操作过程中遇到实际的问题,才能针对问题去解决问题,在这里只有理论是不行的。

      立项之前,PL(CMM中的称谓)根据初步估计出来的代码量,以及交付时间点,将真个项目划分为4个迭代,迭代周期为3周,然后和我这对个挂名的版本SE两个人再细分了下需求点,按自己的的感觉(有点类似优先级)细分结果划分到各个迭代中去实施,并写在一个excel文档中,内容大概就是这样的:

 

迭代一:

功能点      代码量(行)

*****功能   1200

*****功能   850

…………………

迭代二:

功能点      代码量(行)

*****功能   1200

*****功能   850

…………………

 

假如硬要往scrum中靠的话,这个应该算是产品的backlog了,每个功能就是一个story,但这里写的内容与真正意义上的story内容少多了(当时还不知道如何写story呢,哈哈),其实在scrum中,产品blacklog应该是product owner来写的,这个角色应该就是我上面说的产品SE了,这个职责是不能由其它人顶替的。后面就开了个项目开工会了。到这里为止,一切好象还是和CMM的没有什么差别。

      接着,第一个迭代开始了。迭代的第一天,我们开了个会,与会人:5个开发(一个在南京用电话会议接入),2个测试,1个资料以及QA。我拿着之前我和PL整理出来的那个“story”excel,为项目组成员讲解了下这个迭代我们要完成的功能,然后就让各个成员根据自己的意愿去挑想要做的功能了,并要求各个开发人员在会后将功能点细分成“story”(呵呵,搞笑吧,在scrum中这应该是任务了才对),并把每个story的描述以及相应的代码量写到贴纸上。下午,把大家的“story”卡片收集起来,统计了总的代码量,然后就准备开始画燃尽图了。这燃尽图怎么画呢?没什么讲的,横轴肯定是日期了,单位是天。纵轴呢?我们讨论后,就是将总的代码量,然后除以一个适当的值,将这个值做为纵轴的单位,这样子才好画点,否则4000行代码量(实际4000后面还有零头的),以一行为单位,那纵轴就得画4000个点,画死人了,最终我们决定以200行为单位。就这样我们得到了我们的燃尽图了。

      然后迭代正式的开发期了。果然,团队人员不在一起办公的缺点在头几天就立马暴露出来了。首先,每天早上的站立会议,南京的兄弟通过电话接入,由于没有会议终端,深圳这边的讨论他那边听不清楚,只好深圳轮到谁讲了就拿起话筒讲,结果如果南京的兄弟有疑问了,还得把话筒再放回去,使深圳的每个人都能听到他在讲什么;其次,开发过程中讨论不方便,深圳这边有什么结论,那边不能实时知道;最后,就是南京那边的进度不能很好的控制。所以没过几天,我们就强烈申请南京的兄弟过来深圳办公。

      由于当时决定的燃尽图画法,画上去之前得先将昨天完成的工作量汇总,然后再除以200,才换算出燃尽图上的进度,相当麻烦,而且这个除,很多时候除出来的结果并不是整数,或者半数(**.5),所以画的时候更痛苦了。

知道我们怎么统计昨天完成的工作量的吗?我们只算昨天实际写的代码行数,对于UT的工作量不进行统计。而我们的燃尽图上体现的迭代要完成的代码量呢?则是包括了编码、测试的工作量的。结果,我们在迭代进行到一半的时候,就发现了我们很可能到迭代完成的时候,即使代码完全写完了,燃尽图上的曲线“燃”不到底了,就是不能和横轴相接。果然,到了迭代结束的时候,我们的燃尽图上的曲线就挂在半空了,但实际上代码都已经写完,测试也完成了。呵呵,好笑。

      就这样,我们的第一个敏捷的迭代完成了。好笑。


                                                                                                                                           (待续...)

 

10
1
分享到:
评论
5 楼 seemoon 2009-03-27  
很好的实录.
感觉老兄一个劲儿的光讲燃尽(burndown)图了,敏捷很多点还没有提到,比如,客户在哪里?有没有tdd提高质量?怎么处理文档,如何进行团队沟通?
期待你的下一次精彩的记录.
4 楼 ayaga 2009-03-25  
兄台莫非华为的?
3 楼 flyfan 2009-03-25  
我也想敏捷
2 楼 Hotpepper 2009-03-24  
呵呵,确实称不上敏捷。
现在正在实施敏捷,在这个过程中我突然萌发了写点“敏捷日志”的念头,打算将项目过程中我们遇到的问题,以及解决的措施,感受写下来。通过这种方式,一方面加深在写的过程中可以进行总结、反思,加深对敏捷的理解,另一方面,这些实践可以得以积累下来,成为一笔小小的财富,可以在后面做为给其它公司中的其它项目组做敏捷培训的资料,我想这些东西比大段大段的理论来得使用。
正象我一开始说的,我们几乎是“十足的敏捷白痴”,所以第一个迭代走成这个不伦不类的样子,但我们也从中学到了不少,例如燃尽图为什么会燃不完。^_^
1 楼 seekgirl 2009-03-24  
这也叫敏捷?

相关推荐

Global site tag (gtag.js) - Google Analytics