敏捷是一种很“年轻态”的思路/策略，是以“万事万物都在不停地发展变化”为指导去组织软件工程的需求分析、内部的调和、代码编写甚至维护，所以我读起来会觉得很有共鸣。然而并不是所有的地方都适合让“敏捷”去闯一闯。

1.敏捷开发原则

【适应瞬息万变的形式，力求在大潮中可持续发展；年轻态】

【个人进行了分析组合】 1. 可用的、尽早交付的软件是项目进展的主要指标 2. 保持可持续的发展，以需求作为发展优势 3. 自我管理。无论是交流还是信任还是共同工作

2.敏捷流程

1. 找出product backlog【与之前的需求分析不同，这里的backlog不是很“厚”】
2. 决定当前的sprint即sprint backlog【分解为16小时以下的backlog，团队成员根据任务量和自身条件认领backlog】
3. sprint【每日一例会，各自汇报做了什么，有什么困难，下一步计划】

另外，如何让敏捷流程不流于形式？

• 定义好任务量。特别是“还剩多长时间”
• sprint的时候团队保持高度运转，不以外力作用而（暂时）停工或者受到其他影响
• sprint之后如果发现大问题，还要DCR（design change request）
• 任务都完成了不等于可以高枕无忧了。至少（往往）20%的测试任务要花掉80%的时间

3.关于敏捷的另外几条神来之笔

1. 敏捷的团队非常“自我”——自我管理、自我组织，好像非常易于变型的填充物，很多成员都可以有很多“功能”；
2. 不要和管理层谈“过程”，他们只要结果【见人下菜】
3. 大多数被测试、被研究的新东西都很有效果。
   • 参考http://baike.baidu.com/link?url=beVwHx-Synb517sWsjPQ2bsHuzc5qCCX0QrSZ8Ow91TvoPEEEhES7R43SUI_ylpAKv0O5hBoWNwwePhGntQ05lTlqJtpZ7bdIBhSatWAXo-aZcVU8UM0qGoD1n3NruSxt-oMS41qOn9lQWSQBvhK
   • 很有意思的心理学实验结论；似乎做表面文章的时候经常会和这个结论打交道。然而“任何刺激因素（如薪水）都不是非常有效的，因为它总有效用饱和的那一刻”
4. 我们需要敏捷（agile）的开发流程，而不是匆忙（rushed）或者忙乱（chaotic）的流程
5. 敏捷不是万能，它只是能够帮助你更早知道自己能否如期完成任务【因为产品会很早就迎来用户“检查”】

构建之法 第六章 敏捷流程