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

日期：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的工作量不进行统计。而我们的燃尽图上体现的迭代要完成的代码量呢？则是包括了编码、测试的工作量的。结果，我们在迭代进行到一半的时候，就发现了我们很可能到迭代完成的时候，即使代码完全写完了，燃尽图上的曲线“燃”不到底了，就是不能和横轴相接。果然，到了迭代结束的时候，我们的燃尽图上的曲线就挂在半空了，但实际上代码都已经写完，测试也完成了。呵呵，好笑。

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

• 跌跌撞撞地敏捷之路——Story重要程度的作用
• 跌跌撞撞地敏捷之路——及时记录经验教训
• 跌跌撞撞地敏捷之路——为什么进度那么慢

                                                                                                                                           （待续...）