敏捷开发 之 理论概述篇

1、 敏捷实践

　　1. 敏捷宣言

　　　　个体与交互　　　　赛过　　过程和工具

　　　　能够工做的软件　　赛过　　面面俱到的文档

　　　　客户合做　　　　   赛过　　合同谈判

　　　　响应变化　　　　   赛过　　遵循计划

　　　　1.1 个体与交互赛过过程和工具

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

　　　　　　工具要选用合适的，不要一开始就盲目选择所谓强大的。要从小工具开始尝试，直到没法适用再去更换。

　　　　1.2 能够工做的软件赛过面面俱到的文档

　　　　　　面面俱到的文档须要花费大量的时间成原本编写和维护。过期的文档比没有文档更具危害性。

　　　　　　Martin文档第必定律：直到迫切须要而且意义重大时，才来编制文档。

　　　　1.3 客户合做赛过合同谈判

　　　　　　一个指明了需求、进度以及项目成本的合同存在根本上的缺陷。大多数状况下，合同中指明的条款远在项目完成以前就会变得没有意义。

　　　　　　那些为开发团队和客户的协同工做方式提供指导的合同才是最好的合同。

　　　　1.4 响应变化赛过遵循计划

　　　　　　需求永远不会绝对稳定，响应变化的能力经常决定着一个软件项目的成败。

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

　　2. 原则

　　　　从上述价值观中引出的12条原则，它们是敏捷实践区别于重型过程的特征所在。

　　　　2.1  咱们最优先要作的是经过尽早的、持续的交付有价值的软件来使客户满意。

　　　　2.2  即便到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优点。

　　　　2.3  常常性的交付能够工做的软件，交付的间隔能够从几周到几个月，交付的时间间隔越短越好。

　　　　2.4  在整个项目开发期间，业务人员和开发人员必须每天都在一块儿工做。

　　　　2.5  围绕被激励起来的我的开构建项目。给他们提供所须要的环境和支持，而且信任他们可以完成工做。

　　　　2.6  在团队内部，最具备效果而且富有效率的传递信息的方法，就是面对面的交谈。

　　　　2.7  工做的软件是首要的进度度量标准。

　　　　2.8  敏捷过程提供可持续的开发速度。责任人、开发者和用户应该可以保持一个长期的、恒定的开发速度。

　　　　2.9  不断的关注优秀的技能和好的设计会加强敏捷能力。

　　　　2.10 简单--使未完成的工做最大化的技术--是根本的。

　　　　2.11 最好的架构、需求和设计出自于自组织的团队。

　　　　2.12 每隔一段时间，团队会在如何才能更有效的工做方面进行检讨，而后相应的对本身的行为进行调整。

2、 极限编程

　　1. 极限编程实践

　　　　1.1  客户做为团队成员

　　　　1.2  用户素材(user stories)

　　　　　　 用户素材(user stories)，也可叫作 用户故事，就是正在进行的关于需求谈话的助记符。

　　　　　　 它是一个计划工具，客户可使用它并根据它的优先级和估算代价来安排实现该需求的时间。

　　　　1.3  短交付周期

　　　　　　 1.3.1 迭代计划

　　　　　　　　每次迭代一般耗时两周。这是一次较小的交付。

　　　　　　　　开发人员经过度量在之前的迭代中所完成的工做量来为本次迭代设定预算。

　　　　　　 1.3.2 发布计划

　　　　　　　　XP团队一般会建立一个计划来规划随后大约6次迭代的内容，这就是所谓的发布计划。它表示了一次较大的交付。

　　　　1.4  验收测试

　　　　　　 用户素材的验收测试须要在实现素材钱或者实现素材的过程当中完成。

　　　　　　 验收测试使用可以让它们自动而且反复运行的某种脚本语言编写。

　　　　1.5  结对编程

　　　　1.6  测试驱动的开发方法

　　　　　　 编写全部产品代码的目的都是为了使失败的单元测试可以经过。

　　　　　　 测试用例按部就班的对代码的编写进行指导。

　　　　　　 编写测试用例的好处是 能够用来验证修改过的代码，有利于重构；促使你编写可测试的代码，可有效的对代码解耦。

　　　　1.7  集体全部权

　　　　1.8  持续集成

　　　　　　 每次签入代码时，须要跟其余的签入合并。为了不合并的时间过长，团队的成员会很是频繁的签入他们的模块。

　　　　1.9  可持续的开发速度

　　　　1.10 开放的工做空间

　　　　1.11 计划游戏

　　　　　　计划游戏的本质是划分业务人员和开发人员之间的职责。业务人员决定特性的重要性，开发人员决定实现一个特性所花费的代价。

　　　　　　在每次发布和每次迭代的开始，开发人员给予上一次中他们所完成的工做量来为客户提供一个预算。客户在这个预算内选择用户素材。

　　　　1.12 简单的设计

　　　　　　a 考虑可以工做的最简单的事情

　　　　　　b 你将不须要它：不要对将来考虑的过多。

　　　　　　c  一次，而且只有一次：不要容忍重复的代码，使用抽象来消除重复。

　　　　1.13 重构

　　　　　　代码每每会腐化。重构就是在不改变代码行为的前提下，对其进行一系列小的改造，旨在改进系统结构的实践活动。

　　　　　　每次改造以后，要运行单元测试以确保改造没有形成任何破坏。

　　　　1.14 隐喻

　　　　　　隐喻是将整个系统联系在一块儿的全局试图。

后记

　　本篇介绍了敏捷开发的一些基本原则，下一篇将针对原则中的 计划、测试、重构 作详细的介绍。