ASD Practices敏捷开发实践

敏捷软件开发宣言

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

合作、沟通以及交互能力要比单纯的编程能力更为重要。

应该首先致力于构建团队。

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

对于团队来说，编写并维护一份系统原理和结构方面的文档将是一个好主意，但是那份文档应该是短小的（short）并且是主体突出的（salient）。

直到迫切需要并且意义重大时，才来编制文档。

3.客户合作 胜过 合作谈判

告诉开发团队想要的东西，希望他们消失一段时间就能得到一个满足需要的系统来，这对于公司的管理者来说是具有诱惑力的。然而，这种操作模式讲导致低劣的质量和失败。

那些为开发团队和客户的协同方式提供直到的合同才是最好的合同。

4.响应变化 胜过 遵循计划

对于一个缺乏经验的管理着来说，创建一张优美的Gantt图并吧他们贴到墙上是很有诱惑力的。然而时计商计划将会遭受形态（shape）上的改变，而不仅仅是日期上的改变。

较好的做计划的策略是：为下两周做详细的计划，为下三个月做粗略的计划，再以后就做极为粗糙的计划。

 

敏捷开发原则

以下原则是敏捷实践区别于重型过程的特征所在。

1.尽早的，经常性的进行交付。努力在项目刚开始的几周内交付一个具有基本功能的系统，然后努力坚持每两周就交付一个功能渐增的系统。

2.团队努力保持软件结构的灵活性。这样能够欢迎需求的变化（变化可以为客户创造竞争优势）。因此要学习面向对象设计的原则和模式，这会帮助我们维持这种灵活行。

3.要经常性交付软件，并且是可以工作的软件。周期越短越好。不赞成交付大量文档。

4.业务人员和开发人员要进行频繁的交互，天天一起工作。

5.围绕被激励起来的个人来构建项目，改变对团队工作的阻碍的过程步骤。

6.在团队内部，最有效果并且富有效率的传递信息的方法，就是面对面的交谈，而非文档。

7.工作的软件是首要的进度度量标准，而不是那些基础结构或者文档。

8.保持一个长期和恒定的开发速度。尽量不要拖延和加班，要善于调整速度完成高质量的标准。

9.关注好的设计和技能，编写高质量的代码。如果今天制造了混乱，不要拖到明天去清理。

10.简单。不要预测明天的问题。高质量完成今天的工作，深信如果明天发生了问题，也会狠容易的处理。

11.每一个成员都具有项目中所有方面的参与劝。最好的构架、需求和实际来自于自组织的团队。

12.每个一段时间，团队会在如何才能更有效的工作方面进行反省，然后对自己的行为进行调整。

极限编程实践

极限编程是敏捷方法中最著名的一个。

1.客户作为团队成员。一个房间。

2.用户素材：和用户讨论的，我们认可的需求谈话的助记符。小的功能项。

3.短周期交付。每两周迭代一次。发布计划为随后的6次迭代内容，即3个月。

4.验收测试。在实现素材之前或实现的同时进行编写，由OA负责。每天运行，脚本化，自动化。

5.结对编程。两个人一台电脑。

6.测试驱动的开发方法。测试优先，编写代码的目的是使失败的单元测试通过。能分离耦合性。

7.集体代码所有权。任何人都有checkout任何模块代码和修改的权利。

8.持续集成。使用非阻塞的源代码控制工具。check in时要确保所有测试都能通过，必要时和其他人协商。

9.可持续的开发速度。保持旺盛精力。不允许加班，除了版本发布前的一个星期。

10.开发的工作空间。充满积极讨论的环境下生产率不会下降，会成倍的提高。

11.计划游戏。开发人员给出预算，客户给出素材。

12.简单的设计。考虑能实现当前素材的最简单的设计，不要先用数据库，中间件等，非要不可时，再引入它。不能容忍重复代码。

13.随时重构。

14.隐喻。系统的整体实现后的场景，或者框架场景，用比喻的方法，在脑海里的具体呈献。

重要的实践

1.计划游戏

2.测试驱动

3.不断重构