前情回顾，上一节我们了解到，敏捷起源的背景、宣言、原则；也对以上做了初步的梳理。今天我们开始揭开敏捷神秘面纱的第二层“生命周期”。提到“生命周期”详细大伙一定不陌生，诚然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等要素构建一个跨职能的方案，来指导小组成员，包括冲刺计划、日立会、评审、回顾/复盘的方式进行敏捷项目开发。项目管理的目标是在特定的环境下，采用最好的方式创造最大商业价值。
最后在啰嗦一句”没有固定的一种模式，只有符合当下的多种组合“，团队的经验水平、客户合作度、项目需要多个团队合作、组员缺少敏捷方法的经验等都应列为考虑的因素。
”在我漫长的一生中，有多少小小的子弹和霰弹落到了我的身上，不知从哪儿飞来，击中我的心灵，于是给我留下许多弹伤。
而当我的生命已近暮年，这些数不尽的伤口，开始愈合了。
在那曾经受伤的地方，就生长出思想来。“《思想的诞生》附送语录