让敏捷转型持续方法：
1. 改变考核机制，在改变的初期调低原有KPI指标，增加对辅助工具（敏捷，精益或其他方法）的使用情况的考核。
2. 在改变过程中，发现对组织有益的流程，要加入到KPI中，变为日常考核的一部分。
3. 给所有好的“动因”以正向的反馈，即使结果看起来没那么炫目。
4. 领导支持
5. 一个人力量有限，要组建转型委员会，把骨干，积极分子拉进来
6. 敏捷教练，深入团队
7. 每季度评估
8. 每周培训
敏捷失败主要原因
1. 领导不相信敏捷的威力
2. 领导对变革没有承诺
3. 企业缺乏清晰明确的生存威胁
4. 人们认为敏捷只是方法，不是从内到外成长过程
5. 人天生不愿意改变
常见需求分析方法
1. FURPS+
Functionality （功能性）
Usability （可用性）
Reliability （可靠性）
Performance （性能相关的）
Supportability （其它对内部研发支持，比如文档、为了可测性、可扩展性等）
“+” （其它更多可能的考虑）
设计上的限制（比如系统以前的架构局限）
实现上得限制（比如语言，人力资源，操作环境等）
接口的需求（外部依赖的接口和服务）
硬件的需求（物理硬件的限制）
“FURPS+”更像一个checklist，它能提醒我们在发散的时候要从这些角度去思考，避免有大块的遗漏。
2. SQA
相对于上面的FURPS+的方法，SQA的方法在我遇到的实际中更加常用和易用。
SQA就是通过大家一起回答目标story的"Questions"，"Scope"，"Assumptions"三个问题来澄清我们的需求。
Question：任何对这个需求不清楚的问题
Scope：team为了完成这个需求到底要做哪些事，不做哪些事情
Assumptions：为了做这些事的前提假设，可能是成立的，也可能是不成立的
敏捷不是解决所有问题的方法，他只是一面镜子，让你看到问题所在。
