敏捷开发宣言

谈及敏捷开发不得不提到敏捷开发宣言，主要是四点：

• 个体和交互 胜过 过程和工具
• 可以工作的软件 胜过 面面俱到的文档
• 客户合作 胜过 合同谈判
• 响应变化 胜过 遵循计划
  

敏捷开发宣言中提到的四点就是针对这种现实需求所提出的更好的软件开发方法，是顺应现代发展的一种必然趋势。

个体和交互胜过过程和工具

工具就是为了团队的效率提升而存在的。工具的学习也会占用大量的时间，工具的问题也很重要，不需要太多、太复杂的工具，也不要频繁切换工具。团队成员之间的沟通也极其重要，所谓“三个臭皮匠抵得过一个诸葛亮”。良好的沟通，能够引导团队集思广益，积极碰撞出灵感的火花。

可以工作的软件胜过面面俱到的文档

过多的文档会造成文档维护起来非常麻烦，不能保证文档的版本与软件版本一致。对于团队来说，维护一份短小而且主题突出的文档是至关重要的。
show me your code 代码是唯一没有二义性的信息源，代码真实表达了它所做的事情。

客户合作胜过合同谈判

成功的项目需要有序，频繁的客户反馈。客户最好是和开发团队密切地在一起工作，很多开发中出现的问题能够快速反映出来，另外开发团队也能够清楚验收测试的细节。另外，客户和开发团队之间真诚的合作，也减少了无理的或者不切实际的需求提出。

响应变化胜过遵循计划

初定计划时，不能定得太远，没人能想到后面会发生什么，市场环境在不断变化中，这也会引起需求的变动。
在施行计划时，也不能死板地去根据计划的日期来决定，可能会出现人力的减少，造成项目的延期。
比较好的计划就是：工作任务颗粒度细化到天，特性的开发任务定在一周，迭代版本不要超过一个月，迭代版本二到四周，产品版本最好不要超过三个月，大的基线版本可以半年、一年。

对敏捷常见的误解

误解一： 敏捷开发意味着可以不需要文档、设计和计划； 
误解二： 敏捷只是一些优秀实践，或者是优秀实践的结合； 
误解三： 敏捷只适用于小项目开发； 
误解四： 敏捷只会对研发产生改变； 
误解五： 管理者不需要亲自了解敏捷，只需要管理上支持就可以了； 
误解六： 引入敏捷只需要按照既定的步骤去做就可以了； 
误解七： 敏捷是CMM的替代品，是另一种流程； 
误解八： 敏捷只注重特性的快速交付，在敏捷下架构不重要了；

统一认识：敏捷=理念+优秀实践+具体应用

敏捷的理念的解读

1)聚焦客户价值(Value)，消除浪费

二八定律普遍存在于我们工作与生活的几乎所有场景下。

2)激发团队(Team)潜能，加强协作

团队是价值的真正创造者，应加强团队协作、激发团队潜能；软件开发是一种团队活动，首先应做到提升沟通效率降低交流成本。

3)不断调整以适应(Adapting)变化

不断的根据经验调整，最终交付达到业务目标的产品。

敏捷实践

1、管理实践

1）迭代开发

（1）迭代划分要合理，选择要保证迭代版本可交付，用户可体验；风险大的需求放在最前面验证，确定需求跟不确定需求最好分开迭代

（2）对架构有要求，架构要稳定，如果后面迭代推翻了前面的架构，影响就比较大

3）迭代计划会议

4）迭代验收会议

5）迭代回顾会议

6）可视化管理/看板/燃尽图

项目管理任务进展视图，方便内外部相关人了解项目情况，项目管理的基础工具

7）每日站立会议/晨会

技术实践

1）用户故事

2）产品backlog

3）迭代backlog

4）anatomy系统解剖

5）结对编程/结对Review

6）简单设计

7）TDD测试驱动开发

8）自动化测试

9）自动化构建

10）持续集成

11）持续交付

组织实践

1）完整团队/多功能团队/紧密团队/作战室

2）完成标准

3）团队成员角色

运营实践

1）showcase

2）内测

3）公测