XP极限编程---我的敏捷开发之路

传统开发流程中的苦恼 ¶

相信经历过派生开发流程(也就是V字开发流程)的同事一定会有这样的苦恼，
 当需要写太多的设计测试文档，CheckList，各种Review票等等使你被"文档"压的喘不过气来的时候
 当修改一个Bug的时候，又发生了一些新的BUG的时候
 当客户没有时间及时确认成果物，你的进度只有处于等待中的时候。
 当客户的要件定义比较暧昧，对一个要件无从下手的时候。
 当没有或者不能再试验机，开发基板上测试，于是就只有空空等待的时候
 当有一个要件，无法短时间对应完了，只有和客户讨价还价的时候
 当单体测试环节无法发现BUG却无法说明代码品质的时候
 当你还在为了修正一大推BUG而抱怨活干部完，需要整天加班的时候。
 派生开发一个新的功能，看了既存代码后，觉得代码太恶心无从下手，甚至想全部推倒重新写的时候。
 尽管做了WBS，品质账票，却还是无法准确把握项目进度和品质的时候。

如果你在项目中也有这样的烦恼的话，也许你该考虑考虑用敏捷开发的方法给自己还有团队中的伙伴们减减负了。

■什么是敏捷开发（极限编程）¶

敏捷开发（Extreme Programming：极限编程）是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式，
  用来替代以文件驱动开发的瀑布开发模式。目标是提高开发效率和响应能力。
  除了原则和实践，模式也是很重要的，多研究模式及其应用可以使你更深层次的理解敏捷开发。
  极限编程的思想体现了适应客户需求的快速变化，激发开发者的热情，也是目前敏捷开发思维的重要支持者。

■敏捷开发实践¶

迭代开发,故事卡/故事墙，重构，测试驱动开发，结对编程，持续集成，快速反馈，没有加班，充分沟通
 能够用上这些普普通通的实践在你的项目中，就可以打破传统，有效地改善开发的流程。

■迭代开发Iteration ¶

可以工作的软件胜过面面俱到的文档。
 敏捷开发提倡将一个完整的软件版本划分为多个迭代，每个迭代实现不同的特性。
 重大的、优先级高的特性优先实现，风险高的特性优先实现。
 在项目的早期就将软件的原型开发出来，并基于这个原型在后续的迭代不断追加机能。
 迭代开发的好处是：尽早编码，尽早暴露项目的技术风险。尽早使客户见到可运行的软件，并提出优化意见。
 可以分阶段提早向不同的客户交付可用的版本。
 尤其是需求不是很明确的时候，通过每一次的迭代，去深寻客户的式样。

■故事卡/故事墙 ¶

在每个迭代中，架构师负责将所有的特性分解成多个Story Card。每个Story可以视为一个独立的特性。
 每个Story应该可以在最多1个星期内完成开发，交付提前测试（Pre-Test）。
 当一个迭代中的所有Story开发完毕以后，测试组再进行完整的测试。
 在整个测试过程中（pre-test，test），基于Daily build，
 测试组永远都是每天从配置库上取下最新编译的版本进行测试，
 开发人员也随时修改测试人员提交的问题单，并合入配置库。
 敏捷开发的一个特点是开放式办公，充分沟通，包括测试人员也和开发人员一起办公。
 基于Story Card的开发方式，团队会在开放式办公区域放置一块白板，上面粘贴着所有的Story Card，
 按当前的开发状态贴在4个区域中，分别是：未开发，开发中，预测试中，测试中。
 Story Card的开发人员和测试人员根据开发进度在Story Wall上移动Story Card，更新Story Card的状态。
 这种方式可以对项目开发进度有一个非常直观的了解。
 在开发人员开始开发一个Story时，可以用DR的形式向关联的人员说明自己的Story功能，
 以便和关联人员有一致的理解，同时开始自动化系统测试脚本的开发。

■快速反馈 ¶

总结和反思。每个迭代结束以后，项目组成员召开总结会议，总结好的实践和教训，并落实到后续的开发中。

■展示成果 ¶

每个Story开发完成以后，开发人员叫上测试人员，演示软件功能，以便测试人员充分理解软件功能。

■重构 ¶

因为迭代开发模式在项目早期就开发出可运行的软件原型，
 一开始开发出来的代码和架构不可能是最优的、面面俱到的，因此在后续的Story开发中，
 需要对代码和架构进行持续的重构。迭代开发对架构师要求很高。
 因为架构师要将一个完整的版本拆分成多个迭代，
 每个跌倒由拆分成很多Story，从架构的角度看，这些Story必须在是有很强的继承性，是可以不断叠加的，
 不至于后续开发的Story完全推翻了早期开发的代码和架构，同时也不可避免的需要对代码进行不断完善，不断重构。

■TDD测试驱动开发 ¶

正如上面讲的，迭代开发的特点是频繁合入代码，频繁发布版本。
 测试驱动开发是保证合入代码正常运行且不会在后期被破坏的重要手段。
 这里的测试主要指单元测试。

■结对编程 ¶

结对编程技术是指两位程序员肩并肩地坐在同一台电脑前合作完成同一个设计、
  同一个算法、同一段代码或同一组测试。与两位程序员各自独立工作相比，
  结对编程往往只需花费大约一半的时间就能编写出质量更高的代码。

■对于敏捷开发的思考 ¶

1.敏捷开发中可以工作的软件胜过面面俱到的文档。那么文档是不是就不要了呢？
   其实不然。我的理解是Code is Design。当代码结构简单易懂的时候，你的设计文档也将大大的减少。
   当出现变更的时候，简化后的设计文档也将大大缩短修正响应时间，从而实现快速反馈。

2.如何实现快速反馈和成果展示？
   客户买单的是你的程序，是代码。相比文档，任何客户都愿意先看到能跑的代码，
   哪怕这个程序和他们想象的是不一样的。成果展示需要每天做出可以跑的程序来，
   尤其是在开发的早期，但是在嵌入式开发中，每天都有ROM发行邮件的时候，
   你会是一个什么感觉呢。能够每天集成固然挺好，但是我觉得没有必要要完全按照课本上的流程，
   天天去集成一次。

3.结对编程以后，是不是程序的Review就不要了呢？
   我对于这个问题答案既同意也不同意。首先Review是对于开发过程中某个成果物的一次确认过程。
   如果结对编程后，自然而然也就不用特别再去review了。所以我同意这个观点。
   为什么不同意呢，敏捷开发对开发人员提出了比以往更高的要求，即需要开发人员不断地重构出合理的设计。
   敏捷开发中需要有Code Review去承担一部分“结对设计”和“设计把关”的职责。
   所以没有Review是很难把握品质的。而这些Review恰恰就体现在了日常的沟通以及结对的沟通中。
   在瀑布模型中，Review是通过会议的形式体现的，而在敏捷模型中，Review已经贯彻到了日常开发中去了。
   敏捷开发不光对技术有很高的要求，对于高效地沟通效率也相当的看重。
   Review会议还有一个目的就是知识的共享，在敏捷开发中这个也需要体现在每天的开发中。
   敏捷开发中Review会议应该重知识共享，重团队成员的交流。
   如果一味强调指摘CheckList和指摘率等，将会使Review流于形式，也会降低团队敏捷性和积极性。

4.重构与TDD的理解，TDD真的可行吗？等写好了所有测试代码再写代码吗？
   按照我的理解，并不是写好所有的测试代码再去写实现代码。测试代码的作成应该是一个迭代的过程，
   测试代码的作成应该是一个迭代的过程也是一个持续集成的过程。
   对于一个函数的测试，根本不可能在写之前考虑的面面俱到。
   对于测试代码先行，我觉得只要大致有了代码实现的方向，也不难实现。当然也没有必要一定遵守测试先行。
   而是要对于代码设计要充分的思考后，再动手编程。良好的设计是通过测试驱动出来的。良好的设计一定能写出让人简单易懂的测试代码。
   产品的代码需要重构，测试用例的代码也是需要重构的。

5.敏捷开发提倡不加班，但是实际推进中，该加班还是要加班，和敏捷开发没有直接的关系。
   不过敏捷开发提倡高效率，而加班是增加时间却减低效率的一种方式，
   不提倡加班自然也就不难理解了。一天八个小时的高效率工作比一个疲惫不堪的工作十多个小时的人效率更高。

6.敏捷开发对团队中架构师，项目主管，开发及测试成员有相当高的技术能力和沟通能力的要求
   团队中成员的能力将直接影响到敏捷的速度和成果。

7.敏捷开发只能适用于小规模团队的开发，试想想如果是一个几十人甚至几百人的团队，
   那么每个人沟通成本又是多少呢。人数越多，就越需要文档来规范化一些东西了。也就不太敏捷了。

■对于敏捷开发的困惑 ¶

1.如何有效地作出一个个Story，Story的粒度，Story之间的关键路径如何把控
     如何在快速得到客户的反馈后，作出行之有效的计划。
   2.如何保证敏捷团队中沟通充分的前提下，各个成员都有自己独自思考的时间。
   3.敏捷开发只能做出下一次迭代的计划，那么在一次次的迭代中，
     如何去判断项目整体的工作量和进度呢。如果是100人以上的团队，又如何敏捷起来呢。
   4.TDD真的能够100%运用于所有的代码吗？重构完了的基准和触发的必要条件又是什么？
     会不会陷入重构的泥潭呢。
   5.敏捷开发认为沟通重于过程和工具，用工具难道不是提高效率的方法吗？

这些困惑我想只有在实践中才能找到合适的答案吧。

■敏捷开发宣言 ¶

在最后，我们回顾一下教科书上对于敏捷开发的诠释。
   个体和交互 胜过 过程和工具
   可以工作的软件 胜过 面面俱到的文档
   客户合作 胜过 合同谈判
   响应变化 胜过 遵循计划
   虽然右项也有价值，但是我们认为左项具有更大的价值。