精益敏捷笔记 - 草稿

让敏捷转型持续方法：

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：为了做这些事的前提假设，可能是成立的，也可能是不成立的

敏捷不是解决所有问题的方法，他只是一面镜子，让你看到问题所在。