目录

好像现在开发软件都流行敏捷模式，项目经理要是不懂得敏捷开发流程感觉就像是过时了一样。但是敏捷优劣并存，用不好的话就会适得其反。其实，我认为敏捷流程更有点极限压榨程序员的意味。

6.1 敏捷的流程简介

敏捷的流程简介.png

• 现有做法vs敏捷的做法
  敏捷的做法更像是随意一点，开心就好。
  

  现有做法vs敏捷的做法

• 敏捷的开发原则

1. 尽早并持续地交付有价值的软件以满足顾客需求
2. 敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势
3. 经常发布可用的软件，发布间隔可以从几周到几个月，能短则短
4. 业务人员和开发人员在项目开发过程中应该每天共同工作
5. 以有进取心的人为项目核心，充分支持信任他们
6. 无论团队内外，面对面的交流始终是最有效的沟通方式
7. 可用的软件是衡量项目进展的主要指标
8. 敏捷流程应能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去
9. 只有不断关注技术和设计，才能越来越敏捷
10. 保持简明—尽可能简化工作量的技艺—极为重要
11. 只有能自我管理的团队才能创造优秀的架构、需求和设计
12. 时时总结如何提高团队效率，并付诸行动

• 敏捷的步骤
  
  敏捷的步骤

第一步：找出完成产品需要做的事情—Product Backlog。
第二步：决定当前的冲刺（Sprint）需要解决的事情—Sprint Backlog
第三步：冲刺（Sprint）
第四步：得到软件的一个增量版本，发布给用户

6.2　敏捷流程的问题和解法

敏捷流程的问题和解法

说一下第三点：每日例会。基本上敏捷开发需要经常开例会讨论进度，汇总信息，例如：

我昨天做了啥
我今天要做啥
我碰到了哪些问题

但是每日例会经常会出现一些效率不高的发言。例如：

我昨天掰棒子
我今天继续掰棒子
我没碰到困难

这样的发言毫无疑问是没有意义的。所以就需要定义任务究竟是什么？

每个人的任务必须是明确定义的，狗熊们不能笼统地说“我在掰棒子”，而是要说明标号为123的棒子现在是什么状态，你做好之后交给谁了。

同时，在每一个任务上记录完成这个任务还需要多长时间？

已经花了多少时间虽然重要，但那不是关键（那是沉没成本），关键是要看我们离最后目标有多远。就像某部门展览“反腐成果”给群众看—“已经抓出来N个腐败分子”固然解恨，但关键是“还剩多少在台上”，这个问题不说明，再抓多少个都不解决问题。

最后说一下燃尽图，下面是一个实际项目的燃尽图，有三个每天跟踪的时间值：

实际剩余时间（Remaining Hour）：每个团队成员所有任务的剩余时间的总和。
预估剩余时间（Projected Remaining Hour）：根据每个人每天的理论进度推算的剩余时间。
实际花费时间（Completed Hour）：实际花费的时间。

实际项目燃尽图

6.3 敏捷的团队

敏捷的团队

敏捷看起来很舒服，管理也方便，但是一个强势的Scrum Master是敏捷能否实施成功的关键。这个角色绝不是招呼大家开开会，记录每个人的进度而已。

6.4 敏捷总结

敏捷总结

• 敏捷不特别

Sprint/Scrum对项目的众多需求采取分而治之的办法，能让相关人员集中精力，在一定期限内解决部分问题。它强调短时间的迭代（Iteration、Time-box），在多次迭代中不断总结，改进团队的流程和产品功能。

• 敏捷流程的经验教训

这里有一些实践者的经验教训：

1. 敏捷宣言表明的是一些优先级，不必当作圣旨或者教条来争论。
2. Scrum Master不是一个官，而是一个没有行政权力的沟通者，就像微软的PM那样。他/她同时还要在团队中做具体的工作。直接把原来的“经理”变成Scrum Master，大多行不通。
3. 一些项目需要很多暗箱操作和政治角力才能搞定，Scrum会把这些矛盾都摆到明处。这有好处，也有风险。
4. 在复杂的项目里，要让一线团队成员做决定。
5. 创业公司的团队其实经常是运行在Scrum 的模式中（只不过大家太忙，没工夫论证自己到底有多么Scrum）。
6. 在Scrum计划阶段的估计不是一个“合同”，领导们不要把它当成一个合同。估计总是不准的。坚持短期的Sprint，这样即使不准的估计也不会有大的损害。
7. 不要和管理层谈“流程”，他们只关心“结果”。
8. 在大型团队、跨地区的团队，或者复杂项目中，Scrum并没有非常完美的答案，Scrum的创始人也承认这一点。

6.5 敏捷的一些相关问答

敏捷不是说开发就不用搞计划、搞文档、上来就写代码等等
——鲁迅没说过

• 敏捷的适用范围
  

  适用范围

• 什么时候适合选择敏捷
  

  什么时候适合选择敏捷