敏捷项目管理21天学习计划--敏捷生命周期

前情回顾，上一节我们了解到，敏捷起源的背景、宣言、原则；也对以上做了初步的梳理。今天我们开始揭开敏捷神秘面纱的第二层“生命周期”。提到“生命周期”详细大伙一定不陌生，诚然IT语言：C、C++、C#、JAVA等都有一套自己的生命周期，大伙也玩的贼溜。今天呐，不讲开发语言的生命周期，将敏捷的生命周期。

提到敏捷的项目生命周期，要先从传统型的说起。我们是否习惯了先做计划（需求调研)->分析文档->确定需求->设计(原型)->确定->编码->测试->实施交付->诺曼底D日(噩梦的开始)；或者是这样的需求->设计->实施->诺曼底D日重现。

看到这里，别吃惊，为何我重复提到诺曼底D日，在诸多影片中，该行动被塑造成英勇悲壮受世人传颂。但我要说的是，IT界不提倡这种英勇和悲壮。IT不提倡个人独立作战，注重团队合作+和客户合作+灵活的策略=持续有质量的输出。

团队有多种形式，人员形形色色，也有多种实施方式，我们要在一个个成功/失败的项目中总结其特性，形成一种行之有效的团队管理方法。在这里，忍不住说一句：“不要畏惧失败，要正视失败，从中提炼出供团队、成员学习、改变的一些正确的经验和方法。

从上面我们可以看出，我所提的两种方式可以归纳到”预测型生命周期“，何为预测型生命周期？这是一种传统的方法，和ASP一样古老，即提前进行大量的计划工作，然后一次连续执行，直至项目编码终结。在该过程中，不会有任何的商业或功能的交付。这种方法有效，也有弊端。这里只讲弊端，设想一下这么个场景，A集团下分部IT，某天接到A的指示，做一个OA系统。OK，部门负责人开始走”分析->设计->创建->测试->交付“这么一个流程。

逻辑上没有问题，但A只有在IT部交付那一刻，才知道软件的功能。该过程期间A一直在想，这群人在做什么？是不是在偷懒？进度无法得知，那么，奖金、KPI怎么算？IT部负责人在人员气氛不稳时，向A申请经费或时间来活跃气氛，A会同意吗？往往是开始A对IT部门很信任，越往后信任度越低，自然各种福利待遇会逐渐减少。团队成员会觉得被无情压榨，部门负责人也相当委屈，长久以来，效率低、士气低、人员流动性大。上节我们有讲过团队人最重要，人才流失产品质量往往打折扣。最终两个结果，1.负责人引咎辞职；2.产品严重不符合预期，后期不断的修改，人员怨声载道，工期一拖再拖，项目以流产告终…

迭代型生命周期：这种方法允许对未完成的工作进行反馈，从而改变和修改工作的方法，项目复杂度高、变更频繁适用这种方式，自然”瀑布式\预测型生命周期“也适合这种方式。优势在于反馈-更改，进度可控，质量可控。相信很多企业在用这种方式。

基于第一种的方式，我们更改下故事；小A接任上一任负责人，负责项目开发。小A基于以往踩过的坑，决定采用定期向总部交付，那怕软件不完整，也要交付。

我们来看看小A是怎么做的，每次交付时，会在集团区里进行汇报：

1.本周期更新了什么。

2.参与人有哪些。

3.测试人员有哪些。

4.下次预估会交付哪些内容。

收获自然受到集团的好评，集团知道进度可控，对IT部信心增加，那么集团/客户会更放手让团队去施展。笔者一直认为”一个好的领导，做事要有策略、手段。敏锐感知团队、客户的动向，发现异常后及时通过一定的手段进行调整，将利益最大化。而不是，踩着部下向上爬…一味的去迎合客户、上级，会翻车的。“

扯远了，还有个好处是，通过这种方法，项目在开发过程中，方向不会偏离，质量有保证。组员不会因为无休止的修复未预料到的需求，加深组员对产品、对团队、对领导者的信心，逐步像敏捷过度。这种就是增量型生命周期。

再讲一个故事，最后一个。小A通过"增量型生命周"发现，队员已经习惯这种高效的方法来工作且收获颇深。小A决定换一种方法，即采用故事、将故事拆分成一个个章节，通过卡片、时间盒的方式进行研发。

真正做到客户/领导/组员对当下工作清晰明了，每日组员主动领取任务，通过看板、软件等方式进行质量进度管理。Scrum/负责人一定要合理分配时间盒、严格按照约定的时间进行掌控。小A深知人是有惰性的，要怀疑一切，故小A无时无刻在调配组员在工作中需要的各项组员，严格把关，真做到”领导分配->组员领取“到”人人主动拉去任务，领取->反馈“的过度，人人都是团队的小主人，领导负责人即使仆人。正是通过”需求->分析->设计->创建->测试“这种方式基于”迭代的敏捷生命周期方式“，将需求隔离，限制WIP，小A职务获取了更高一步的提升，团队人员收入也进行了一次大的调整，客户/公司利益得到最大化，实现双赢。

当然还有基于流程的敏捷生命周期：从TODO List中提取部分功能开始工作，而不是按照基于迭代的进度计划开始工作。工作流的价值就体现出来了，限制在制WIP数，便于及时发现问题，减少需求的返工，有团队、业务方决定规划、产品评审与回顾。

”需求变更->分析->创建->测试->限制WIP数“流程进行开发，是流程性敏捷生命周期的特点。WIP是丰田最早提出并应用的，关于WIP将会在专门的课程讲，此处不赘述。

方法特性动作交付目标/成果预测型固定整个项目期间执行一次单次管理成本加大迭代型变化重复直到正确为止单次正确、有效增量型变化对给定的增量执行一次频繁部分速度敏捷性变化重复直到正确为止频繁部分将客户利益最大化

迭代和增量型式敏捷生命周期的两个重要概念：

迭代：像素描或临摹，通过每一次的交付，反复求真的过程，使软件/项目的质量越来越清晰，从而提升软件/项目的质量。

增量：像拼图，每次交付多一点，通过功能数的不断累积，使软件/项目的质量越来越清晰，从而提升软件/项目的质量。

相信看到这里，大家可能有疑问，讲了这么多，到底哪个合适，能不能两个都用？恭喜你，你已经步入敏捷的开发模式中了。

混合生命周期：项目并不是使用单一的方法，医生通过”望闻问切“来诊断病人，项目也不例外。需要通过各种组合，根据周期的不同来组建适合团队的敏捷方式。例：”预测、迭代、增量、敏捷：迭代型、增量型“的组合或协调（仆人）式的方法，Scrum、看板、XP等要素构建一个跨职能的方案，来指导小组成员，包括冲刺计划、日立会、评审、回顾/复盘的方式进行敏捷项目开发。项目管理的目标是在特定的环境下，采用最好的方式创造最大商业价值。

最后在啰嗦一句”没有固定的一种模式，只有符合当下的多种组合“，团队的经验水平、客户合作度、项目需要多个团队合作、组员缺少敏捷方法的经验等都应列为考虑的因素。

”在我漫长的一生中，有多少小小的子弹和霰弹落到了我的身上，不知从哪儿飞来，击中我的心灵，于是给我留下许多弹伤。

而当我的生命已近暮年，这些数不尽的伤口，开始愈合了。在那曾经受伤的地方，就生长出思想来。“《思想的诞生》附送语录