敏捷开发的一些体会

现在在网上看文章，貌似不敏捷就落伍了。公司内部各team在show off的时候也是大谈如何从瀑布走向敏捷，貌似一敏捷就药到病除。最近在coolshell的blog上看到一篇老文“再谈敏捷和ThoughtWorks中国咨询师”，顿感心有戚戚焉。现在就结合我这里的具体项目谈谈什么样的项目适合做敏捷以及如何做好敏捷开发。

PS: 哥虽然有Scrum Master的证书但还是反对什么都往敏捷头上套。

公司之所以选择这个项目进行Scrum试点有如下几个原因：

1. 上一个版本原计划半年结果做了1年，公司近三分之一的开发和测试资源砸了上去。
2. 需求频繁变化，产品经理和开发测试人员相互扯皮。
3. 产品仓促上线，大量功能未经充分测试。
4. 新上任的工程总监是敏捷开发爱好者，正好拿此项目开刀。

现在Scrum正式开始了，但是我在这里要问一句我们开发软件的目的是什么？这个还要问吗？不就是为了发行后赚钱吗！带着这个问题，我们美国的项目经理我们准备什么时候发行？哥承认被shock了，那位大哥的回答是：我们现在开始敏捷了，一个sprint接一个sprint做，啥时干完啥时发行。好吧，幸亏这个项目的测试不是哥直接负责，你爱咋地咋地。(其实哥是对自己手下的兄弟有信心，真要做砸了我们估计还能成为仅有的亮点。)

带着同志们的祝福，项目开始了。每个sprint不管3721只要产品经理脑袋一拍，一堆需求就塞进来了。开发看着只有一句话描述的需求面对的回复是：现在是敏捷开发了，要多沟通少文档。沟你妹啊！一个在中国，一个在美国，邮件沟通一来一去一天就没有了。电话？是你熬夜呢还是我黎明即起？3周一个sprint，光把需求搞明白就一周去掉了，然后做啊做啊，还有2天sprint就要结束了，可是突然一看任务列表，50个只完成了30个，怎么办？根据Scrum的教条，sprint是不能延期的，那么做不完的就踢到下一个sprint去好了，反正没有发行日期，慢慢做好了。嗯，很好，这个sprint我们顺利完成了35个任务！做啊做啊，3个月过去了，产品经理看看几个大功能也有模有样了，很好，我们宣布某某新版本顺利发行！！！(先开枪再画圈，很好很强大！)

显然这样的敏捷开发是不能让高层满意的，大家坐下来总结经验教训，推出了2.0版，更新如下：

1. 大老板希望更快的看到成果汇报，sprint周期由三周缩短为两周。
2. 中美各成立一个Scrum小组，本地测试支持本地开发，每个sprint的任务按比例分配。
3. 产品经理必须提供更完善的设计文档。
4. 加强沟通，每周双方召开例会。
5. 除去在美国的主产品负责人和Scrum master，在上海增设本地的产品负责人和Scrum master，部分决策可以就地做出，不必请示美国。
6. 开发必须写单元测试。

这些改动，3456点都是对项目整体有利的。第1点带来的问题是如果开发工作稍有延误，留给测试的空间就十分有限了。第2点则喜忧参半，好处是上海团队有了更大的自主权，坏处是测试开发比严重不足。因为上海的测试leader要兼任Scrum master，所以测试和开发是2.5比7，而美国的测试和开发则是4比6。不过考虑到本地测试生产率高于美国，而且开发也愿意挤出时间来帮助测试执行测试用例，在2个sprint之后，上海团队表现良好，而美国团队依然落后于进度。

虽然2.0版的Scrum比起1.0版大有进步，但是依然存在以下几个问题：

1. 周期太短，开发完成工作后留给测试的时间太少。
2. 上海的测试长期超负荷工作。
3. 因为周期太短，所以没有时间做测试自动化，这样导致在无法做自动化的回归测试，只能依赖手工测试选取几个关键测试用例保证之前的功能正常工作。

虽然还是有种种问题，但好歹是稳步前进了。周期恢复到三个星期，人手不够开始招实习生，自动化测试没时间做那么就上线后集中拉一段时间补课。

通过近半年的Scrum实践，我总结了一些经验和大家分享一下：

1. 一定要有一个release目标，要根据这个目标倒过来排计划。
2. PO和Scrum master必须有丰富的传统开发模式经验，不然项目很容易失控。
3. 每天的例会后Scrum master要迅速跟进，重大问题要立刻解决，什么工作生活平衡全是扯淡，执行力必须是第一位。
4. 虽说搞Scrum要求每个员工都积极主动，但是开发和测试leader还是要花很多时间分配任务，调整优先级。开发必须为测试和修复bug留出足够时间。
5. 自动化测试非常重要，早做晚做一定要做。
6. 员工之间的知识共享非常重要，谁都有个头疼脑热，不能因为一个人暂时离开就影响项目进度。
7. 单元测试帮助很大，一是避免了很多基础的业务逻辑错误，二是可以让开发更清楚业务逻辑