一个完整的敏捷开发的流程(熟悉敏捷开发流程)

敏捷转型

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

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

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

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

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

一个完整的敏捷开发的流程(熟悉敏捷开发流程)

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

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

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

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

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

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

迭代开发

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

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

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

一个完整的敏捷开发的流程(熟悉敏捷开发流程)

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

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

一个完整的敏捷开发的流程(熟悉敏捷开发流程)

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

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

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

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

需求分析

项目实战正式开始。

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

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

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

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

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

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

张大胖立刻问道:10%-15%?怎么选?

教练在白板上写道:

一个完整的敏捷开发的流程(熟悉敏捷开发流程)

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

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

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

教练说:好了,下周我们正式开始迭代开发,每个迭代三周如何?

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

第一个迭代

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

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

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

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

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

一个完整的敏捷开发的流程(熟悉敏捷开发流程)

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

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

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

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

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

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

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

迭代出了问题

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

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

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

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

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

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

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

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

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

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

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

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

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

继续迭代

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

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

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

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

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

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

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

这一次,项目按时,高质量地交付了!

总结

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

一个完整的敏捷开发的流程(熟悉敏捷开发流程)

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

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

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

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

本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 sumchina520@foxmail.com 举报,一经查实,本站将立刻删除。
如若转载,请注明出处:https://www.yiheng8.com/158892.html