1 敏捷转型

周一上班，张大胖收到经理的一封邮件，标题赫然写着：

大胆拥抱变化，努力促进敏捷转型。

旁边的何小痩吐槽说：我们的瀑布模型用得挺好啊，职责明确，按部就班，为啥要转型？折腾人！

喜欢接触新技术的张大胖说：放心吧，敏捷软件开发那一套，Scrum、 TDD、结对编程我早就试验过，我给你说，根本就用不起来。

张大胖的公司之前一直使用瀑布模型进行开发：

软件开发就像接力赛，一棒接一棒，最后交给客户。

但是瀑布模型的缺点也非常明显：

需求在客户的脑子中，没法精确，完整地描述，需求文档看似做完了，进入到设计开发，但很可能是跑偏了！

跑偏的后果就是：错误到了用户验收测试阶段才发现，客户说：这不是我想要的东西。

只好返工，返工相当于再走一遍瀑布，代价太高了。

公司这两年的项目就没有按时完工的，问题主要就出在需求上。

2 迭代开发

很快，经理聘请的教练就进场了。

在动员会议上，张大胖惊奇地发现，教练根本不提敏捷的事儿。

也根本没提TDD，结对编程，Scrum，反而提了一个新词：迭代化开发

张大胖忍不住嘲笑：这迭代化开发，不就是把原来的大瀑布，切分成一个个小瀑布吗？换汤不换药！

教练并没有直接回应张大胖，只是是笑了笑：迭代化开发的关键是：价值驱动和风险驱动。

张大胖：别拽这些没用的词，是骡子是马拉出来溜溜。

教练：我们用一个项目实战一下就明白了。

经理还真是信任这位教练，居然给让他带着大家做一个真实的项目。

张大胖心想：正好，我看看你怎么当众出丑。

3 需求分析

项目实战正式开始。

按照之前的经验，肯定要请业务人员来写需求文档，也就是用例。

但是这一次，教练直接宣布：花两天时间，召开需求分析会议。

张大胖忍不住对何小痩说：两天？两天能把所有的需求理清楚，把所有的需求文档都写完吗？我们之前需求分析阶段都用了两个月！

何小痩也无法理解：谁知道他葫芦里卖什么药，我们去听听。

需求分析会议不但有业务人员，还有架构师，开发人员，甚至测试都来了。

教练说：业务人员已经整理了一个非常粗略的文档，已经发给大家了，大概有20个需求，我们这次先挑选10%-15%进行深入分析，其他的先进行粗略分析。

张大胖立刻问道：10%-15%？怎么选？

教练在白板上写道：

张大胖心中一震：卧槽，这位教练真的有两把刷子啊，这三个原则很厉害，一下子就抓住了关键点！

大家按照这3个原则，饶有兴趣地挑选了3个需求。

两天以后，大家对这3个需求做了详细的分析。剩下的十几个只做了粗略的分析。

教练说：好了，下周我们正式开始迭代开发，每个迭代三周如何？

张大胖心说：好，我看看你的小瀑布怎么搞。

4 第一个迭代

第一个为期三周的迭代正式开始。

周一，教练带着大家开了一个简短的迭代计划会议，把3个需求做了任务分解和工作量估算，从中选取一些任务的子集作为本次迭代的任务。

随后，在架构师的带领下，大家开始进行建模和设计。

让张大胖感到震惊的是，教练居然不让大家写详细的设计文档，而是把架构师和开发人员都赶到白板前去做设计。

每个人都必须参与，发表意见，在白板上画流程图，设计图，UML图，各种图......

张大胖问道：怎么回事？我们不写文档了？这草图能用来开发吗？

教练：你想想看，之前写的文档有多少是真正精确的？有多少随着开发的推进迅速过时了？

张大胖一想确实如此，那些写得漂亮的设计文档几乎没人看，因为和代码严重不一致，就是为了应付验收而已。

教练又说道：我们不需要面面俱到的文档，只需要足够好的文档，你看大家都参与了设计的讨论，达成了共识，回头用手机把这些UML草图拍下来保存就行了。

张大胖还是将信将疑，但是他发现，不写容易过时的文档，确实省了自己不少事。

通过白板讨论，大家对设计都达成了一致。

架构师把一些最关键的决策给记录了下来，这才是最宝贵的文档。

5 迭代出了问题

接下来，每天都是编程、测试，和别人的代码集成。

教练和架构师的要求比较高，单元测试，集成测试，性能测试都得做

两周时间很快过去，第二周的周五，发生了一件让张大胖幸灾乐祸的大事情：计划的需求肯定完成不了了！

张大胖面带愁容，心里却乐开了花：教练，照目前的进度，这个迭代完成不了所有的需求啊！

教练：这很正常，说明我们对自己的工作量估算还不准确，以后会越来越好的。

张大胖：那怎么办？第一个迭代宣告失败？

教练笑了：不不，我们拿掉一些次要的任务，保证这次迭代有可以展示的东西。

很快，时间到了第三周的周四，教练通知大家要冻结代码，该提交的赶紧提交，周四要给客户做演示。

第一个迭代刚刚完成，系统还非常简陋，但是在演示中客户依然提出了几个非常重要的问题：

“你们搞错了，这个地方是角色A才能访问的，角色B访问不了！”

“忘了说了，这个地方的数据来源是Excel，必须得支持Excel的导入”

张大胖非常感慨：幸亏是现在就发现了，要是到最后就惨了。

客户的反馈也被加入到了需求中。

6 继续迭代

在第一个迭代要结束时，教练带着大家召开了第二次需求分析会，又按照之前的3个标准，选取了10%~20%的需求，进行详细分析。

然后就是第二个为期三周的迭代。

经过四五次这样的迭代，80%~90%的需求已经分析完成。

这些需求经过了用户的反馈，质量要远高于瀑布模型中的需求分析文档。

教练总结道：虽然开发还没有完成，但是我们已经完成需求的细化阶段，我们可以比较精确地估算什么时间可以完成项目了。

在后续的迭代中，需求分析活动越来越少，需求也没有显著变化，开发活动则越来越多。

稳定的需求，精确的估算，让大家开发起来信心越来越足。

这一次，项目按时，高质量地交付了！

7 总结

在总结会议上，教练给大家展示了一幅图：

看着图，张大胖非常感慨：迭代化开发，关键是：不要在开发之前，就“冻结”需求和设计，软件开发是有不可避免的变更的特点，必须通过不断地反馈和调整，才能达到目标。

拥抱变化，这才是敏捷的真谛。

但他还是向教练提了一个问题：TDD、结对编程、Code Review这些东西什么时候用？

教练说：咱们的迭代化开发相当于一个筐，这些敏捷实践都可以往里边装啊，只要你的团队能够熟练实施这些实践，就可以在迭代化开发中使用起来啊！