敏捷开发

Posted 2020-11-20 wuxun1997

　　敏捷（Agile）的各种概念满天飞，各大公司都说自己在用敏捷。就说我自己这几年来经历过的项目吧，每个都说自己用的就是敏捷开发，由此可见敏捷有多火。但实际上很多都只是伪敏捷，光有样子，没有里子。而且并非所有项目都需要敏捷，像一些计划性高的传统项目。另外，敏捷更多的是一种思想，不仅仅只是适用于软件行业。

　　为啥敏捷突然就冒出来了呢？存在即合理，以前的项目都偏大，或者预算是死的（比如政府项目），或者需求是确定的（比如科研项目），传统的瀑布模型可以很好的完成任务。后来项目慢慢变小变灵活了，互联网出来后很多需求都是需要快速变化的。比如微信，它一开始就只有很简单的功能，通过市场的反应、用户的反馈，迭代推进，一两个月发布一次，功能慢慢的丰富了。马化腾说的小步快跑，就是敏捷开发模式的核心——迭代。通过迭代发布原型产品，我们可以很快发现这个产品有没有市场，客户可以看到是不是他们想要的产品。这样既可降低的沉没成本，也能快速提升产品的价值。那么究竟啥是敏捷？很多人都是云里雾里的，我也一样。昨天听了一场敏捷开发的讲座，总算开窍了一些，就拿出来分享一下。

　　先从敏捷宣言说起吧，毕竟这是敏捷的源头。这里就不聊哪些人在哪里做了哪些事，就看宣言都有啥：

   　　 Individuals and interactions over processes and tools

    　　个人和交互 重于 过程和工具
    　　Working software over comprehensive documentation

    　　可用的软件 重于 完备的文档
    　　Customer collaboration over contract negotiation

    　　和客户协作重于 合同谈判
    　　Responding to change over following a plan

    　　响应变化 重于 遵循计划

　　很明显，这些都是针对传统瀑布模型的宣战，虽然他们很客气的补充了一句：后者并非没有价值，只是我们更加关注前者。宣言一出，四方响应，很多人心里都觉得这群人说出了我们的心声啊。可是光有宣言也不行啊，得有拿得出手的东西，所以XP、Scrum就来了。

　　XP（Extreme Programming）叫极限编程，它注重的是价值观：沟通、简单、反馈、勇气和谦逊。沟通我们都在做，但往往沟通就是最难的，特别是大公司，部门墙多且厚。开发和测试最容易直接干起来，毕竟天天打交道嘛。至于千里之外的第三方，找不到人或者人家根本不鸟你是很正常的。简单是一种很好的思维方式，画张图能说明白的事，为啥要花上半天去写文档或者吐唾沫呢？几行代码能搞定的事，就别用几百上千行代码去实现，别把自己臆想出来的功能加到需求里。反馈是提升效率的必杀技，有问题了马上反馈，迅速沟通，快速推进，效率自然就上去了。勇气说的是敢于推倒重来，代码写得烂不要紧，就怕明知道烂还不去重构。谦逊是美德，不懂别装懂，懂了别以为啥都懂，总有你不懂的。

　　XP有不少实践可供参考，比如客户参与进需求和测试，团队共同制定计划，随时调整计划，简单设计，寻找满足当前需求的最简单方案，好基友结对编程，持续集成，测试驱动开发（TDD）和验收测试（UAT），及时重构，隐喻，以项目全景图来全局考虑。

　　Scrum是美式足球里开场时的争球，敏捷里用它来比喻大家都打着鸡血朝目标拼命。Sprint指的是迭代。Scrum里有三种角色：PO、SM和ST。具体说明如下：

　　产品负责人（Product Owner）：主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。

　　流程管理员（Scrum Master）：主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。

　　开发团队（Scrum Team）：主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。

　　一个Scrum的开发流程大概是这样的：

　　1.PO把需求扔进需求池PB ( Product Backlog，产品需求列表）；

　　2.PO召开Sprint Planning Meeting（迭代计划会议），根据优先级排序PB，ST从中挑选出一个 Story 作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，再把这个Story进行细化，形成一个SB（Sprint Backlog，迭代需求列表）；

　　3.SB是由ST去完成的，每个成员根据SB再细化成更小的Task任务（细到每个任务的工作量大约在两天内完成）；

　　4.在ST完成SB的过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，提出遇到的问题，每个人发言完成后，要到白板更新自己的 Sprint burn down（Sprint燃尽图）；

　　6.每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；

　　7.当一个Story完成，也就是SB被完成了，要进行 Srpint Review Meeting（迭代演示会议，也称为评审会议），PO和客户都要参加，每一个ST成员都要向他们演示自己完成的软件产品；

　　8.最后就是 Sprint Retrospective Meeting（回顾会议），以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中。

　　作为敏捷开发的不同模式，Scrum较XP稍侧重于过程。在实际应用中，它们两者可以结合起来。不管什么方法论和工具，没有最好的，只有合适的，说到底还得看项目的具体情况。