敏捷-生命周期

前情回顾，上一节咱们了解到，敏捷起源的背景、宣言、原则；也对以上作了初步的梳理。今天咱们开始揭开敏捷神秘面纱的第二层“生命周期”。提到“生命周期”详细大伙必定不陌生，诚然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等要素构建一个跨职能的方案，来指导小组成员，包括冲刺计划、日立会、评审、回顾/复盘的方式进行敏捷项目开发。项目管理的目标是在特定的环境下，采用最好的方式创造最大商业价值。

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

”在我漫长的一辈子中，有多少小小的子弹和霰弹落到了个人身上，不知从哪儿飞来，击中个人心灵，因而给我留下许多弹伤。而当个人生命已近暮年，这些数不尽的伤口，开始愈合了。在那曾经受伤的地方，就生长出思想来。“《思想的诞生》附送语录