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.不断重构

 

你可能感兴趣的:(程序设计)