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这些东西什么时候用？
教练说：咱们的迭代化开发相当于一个筐，这些敏捷实践都可以往里边装啊，只要你的团队能够熟练实施这些实践，就可以在迭代化开发中使用起来啊！
后记：
本文来自网友@lxb的投稿，我做了故事化的“大改造”，本文讲述的是敏捷最基本的一个实践：迭代化开发，熟悉RUP的同学会看出来，文中的介绍其实是RUP的一个裁剪。
欢迎各位小伙伴投稿，讲述你的职场故事，技术人生，稿费700元（需要能标记原创），我的微信: onlyliuxin97
非技术方面：学习经历、职场经历和职场感悟、吐槽都可以。
技术方面：希望能通俗易懂地讲一个相对通用的技术，不要太狭窄，能用故事讲最好（稿费1000元），或者某个技术的演变历史。
泛技术类的：科技公司、科技人物、科技事件、能给大家带来感悟，感到有收获的都行。
（完）
点击下方图片，查看更多精彩
4277
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
