构建之法学习（第六章 敏捷流程）

第6章  敏捷流程

 

本章主要介绍了敏捷流程及其原则，Backlog、Burn-down、Sprint、Scrum方法论。以及什么时候选择敏捷的开发方法，什么时候选择其他方法。

 

1.敏捷的流程

         定义：“敏捷流程”是一系列价值观和方法论的集合。

现有的做法	敏捷的做法
流程和工具	个人和交流
完备的文档	可用的软件
为合同谈判	与客户合作
执行原定计划	响应变化

 

2.敏捷开发原则

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

 

3.敏捷的步骤

　　1.找出完成产品需要做的事情—Product Backlog

　　2.决定当前的冲刺需要解决的事情—Sprint Backlog

　　3.冲刺

　　4.得到软件的一个增量版本，发布给用户

 

4.如何成为敏捷的团队？

　　1. 自主管理：以前领导布置了任务，我们实现就可以了，现在要自己挑选任务；每次Sprint结束之后，还要总结不足，提出改进，并且自己要实施这些改进。“自主管理”不等于“没有管理”。

　　2. 自我组织：以前做好自己的事情就好了，安心下班。现在每个人要联合起来对项目负责，有人工作落后了还要帮助他改进，项目缺少某类资源还要自己顶上去。

　　3. 多功能型：以前规格说明书由PM来写，测试由测试人员来做，现在每个人都全面负责，自己搞定规格说明书，和别人沟通，同时自己搞定测试。

 

5.敏捷流程的经验教训

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

 

6.敏捷的试用范围

客观因素/      最适用方式	敏捷(Agile)	计划驱动(Plan-driven)	形式化的开发方法(Formal   Method)
产品可靠性要求	不高，容忍经常出错	必须有较高可靠性	有极高的可靠性和质量要求
需要变化	经常变化	不经常变化	固定的需求没需求可以建模
团队人员数量	不多	较多	不多
人员经验	有资深程序员带队	以中层技术人员为主	资深专家
公司文化	鼓励变化，行业充满变数	崇尚秩序，按时交付	精益求精
实际例子	写一个微博网站	开发下一版本的办公软件；给商业用户开发软件	开发底层正则表达式解析模块；科学计算；复杂系统的核心组件
用错方式的后果	用敏捷的方法开发登月火箭控制程序，前N批宇航员都挂了	用敏捷方法，商业用户未必受得了两周一次更新的频率	敏捷方法的大部分招数都和这类用户无关，用户关心的是：把可靠性提高到99.999%   ,不要让微笑的错误把系统搞崩溃