目录
好像现在开发软件都流行敏捷模式，项目经理要是不懂得敏捷开发流程感觉就像是过时了一样。但是敏捷优劣并存，用不好的话就会适得其反。其实，我认为敏捷流程更有点极限压榨程序员的意味。
6.1 敏捷的流程简介
敏捷的流程简介.png
-
现有做法vs敏捷的做法
敏捷的做法更像是随意一点，开心就好。
现有做法vs敏捷的做法
-
敏捷的开发原则
- 尽早并持续地交付有价值的软件以满足顾客需求
- 敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势
- 经常发布可用的软件，发布间隔可以从几周到几个月，能短则短
- 业务人员和开发人员在项目开发过程中应该每天共同工作
- 以有进取心的人为项目核心，充分支持信任他们
- 无论团队内外，面对面的交流始终是最有效的沟通方式
- 可用的软件是衡量项目进展的主要指标
- 敏捷流程应能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去
- 只有不断关注技术和设计，才能越来越敏捷
- 保持简明—尽可能简化工作量的技艺—极为重要
- 只有能自我管理的团队才能创造优秀的架构、需求和设计
- 时时总结如何提高团队效率，并付诸行动
-
敏捷的步骤
敏捷的步骤
第一步：找出完成产品需要做的事情—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），在多次迭代中不断总结，改进团队的流程和产品功能。
- 敏捷流程的经验教训
这里有一些实践者的经验教训：
- 敏捷宣言表明的是一些优先级，不必当作圣旨或者教条来争论。
- Scrum Master不是一个官，而是一个没有行政权力的沟通者，就像微软的PM那样。他/她同时还要在团队中做具体的工作。直接把原来的“经理”变成Scrum Master，大多行不通。
- 一些项目需要很多暗箱操作和政治角力才能搞定，Scrum会把这些矛盾都摆到明处。这有好处，也有风险。
- 在复杂的项目里，要让一线团队成员做决定。
- 创业公司的团队其实经常是运行在Scrum 的模式中（只不过大家太忙，没工夫论证自己到底有多么Scrum）。
- 在Scrum计划阶段的估计不是一个“合同”，领导们不要把它当成一个合同。估计总是不准的。坚持短期的Sprint，这样即使不准的估计也不会有大的损害。
- 不要和管理层谈“流程”，他们只关心“结果”。
- 在大型团队、跨地区的团队，或者复杂项目中，Scrum并没有非常完美的答案，Scrum的创始人也承认这一点。
6.5 敏捷的一些相关问答
敏捷不是说开发就不用搞计划、搞文档、上来就写代码等等
——鲁迅没说过
-
敏捷的适用范围
适用范围
-
什么时候适合选择敏捷
什么时候适合选择敏捷
网友评论