《设计已死》

XP 的主要设计者之一 Martin Fowler 在《设计已死》
http://martinfowler.com/articles/designDead.html
http://www.agilechina.org/MartinFowler/isdesigndead.htm
中说：
"Don't worry about design, if you listen to your code a good design will appear."
“别担心，仔细注意你的程序代码，你就会看到好的 design 浮现出来。”
这句话被很多断章取义者大加嘲讽，认为它使得软件开发回到了 "code and fix" 的原始状态。（包括去年我面试的一家公司的 CTO，他在得知我的上一家公司以 XP 方式管理项目后给我好好地上了一堂软件工程课，使我开始注意到框架和体系结构对于软件开发的重要性。）
这句话其实是我看到过的一条关于软件开发的真理。它强调了关注代码的重要性。不关注代码的人是不可能做出最佳（最实用）的设计的。设计与开发完全脱离很有可能会造就一些徒有美学价值却不实用的“完美设计”，Sun 的 PetStore 就是这样的代表。
有人认为 XP 完全不注重设计，这其实是一个误解。XP 只是不同意 planned design（计划式设计）而提倡用另外一种 evolutionary design（演进式设计）。在读完《设计已死》这篇文章后你会对这两种设计方法的区别有一个清晰的了解。

http://www.agilechina.org/MartinFowler/isdesigndead.htm
中文版

没有比XP还会重视设计的方法，在XP中TDD和REFACTOR都是设计，PP其实也是一种设计，代码共享也是设计。XP是一种从开始一直要持续到结束的设计。

是啊，真正想把事情做简单反而不简单。
现在我也做 PM 了，才发现真正实施 XP 并不简单。TDD 要实施也是困难重重。最主要的是测试代码写多少才合适？写测试代码对开发人员的要求非常高，要求严格了影响项目进度，要求松了又容易流于形式。
这是我至今没有完全想清楚的问题，但是不做单元测试，就完全不是 XP 了。
可能真要完全按照 XP 的做法来，还是要等我们更加壮大了再说。我来总结一下：
5 人以下的小团队：沟通量很小，不需要过程也可以完成项目，
5-10 人的团队：按照 XP 方式管理。
10-50 人的团队，可以划分成多个 5-10 人的 team 按照 XP 方式管理。
50 人以上的团队，按照 RUP 方式管理。

去年在一家公司时我的 CTO keys 写的 XP 项目管理方法，对 XP 感兴趣的朋友可以参考一下。

采用 XP 方法进行项目管理

-------------------------
核心价值
-------------------------

1、沟通
   缺乏沟通，是几乎所有软件问题的根源。通过直接，及时地与客户沟通，就可以消除大多数的问题。

2、简单
   保持设计的简单，为今天设计，永远不要为明天设计。
   不要将注意力放在软件的最复杂难解的功能上。今天做简单的工作，明天花点代价修改它要比今天做可能永远用不到的复杂工作好的多。

3、反馈
   更早和经常来自客户，团队和实际最终用户的具体反馈意见将为项目提供更多的机会来把握住正确的方向，少走弯路。
   通过自动化的单元测试来获得系统的反馈，通过反馈告诉我们工作做得怎么样。

4、勇气
   要有勇气尝试新得的，不同的东西来大幅度减少项目时间。要有勇气在即使面对巨额预算和截止期限压力时仍能坚持做正确的事情。


-------------------------
规则和实践
-------------------------

计划
---------

1、编写 User Story
   通过 User Story 来描述系统需要为用户做些什么。一个 User Story 一般三句话左右，是客户以他们自己的术语写成的。

2、通过发布计划制订时间表
   对每个用户素材进行估计，选出一些用户素材在第一个发布中实现，再分别选出随后几个发布中应实现的用户素材，形成发布计划。

3、频繁发布小版本
   经常将迭代生成的版本发布给客户。这样客户就能及早得到并使用这些功能。这对及时地收到有价值的反馈并作用到以后的开发中去是非常关键的。

4、将项目划分为迭代
   每个迭代一到三周。

5、每次迭代开始前制订迭代计划
   按照 User Story 对客户价值的高低顺序，从发布计划中选取出来的。User Story 和上次迭代测试失败的部分都会转化为开发任务，每个任务应该持续一到三个开发日。

6、Move people around
   在每次迭代中，鼓励每个人去尝试接手系统中新的部分。结对编程能够在不降低生产力并能保证思维连续性的前提下使之成为可能。人员的组合可适时进行调整。避免形成知识孤岛。

7、每天上班后召开 stand-up meeting
   站着开会的目的就是整个组内的交流沟通。在这个每天举行的会上，交流所遇到的问题，一些解决方案和项目的焦点所在。大家围成一个圈站着开会可以避免长时间的讨论。

8、遇到问题时修改 XP
   XP 规则是应该遵循的，但对不能良好运做的部分应毫不犹豫地加以修改。

设计
---------

1、简单
   尽量用最简单的方法去达到目的。在为一段复杂代码浪费许多时间前，先找出简单的方法肯定费时更少开销也更低。尽可能地保持简单，尽可能晚地增加功能。

2、在设计期间使用 CRC 卡
   CRC 卡的目的是让程序员脱离过程模型的束缚，而以面向对象的方法来考虑问题和交流思想。

3、尽可能地重构
   尝试更改现有代码是否可以让新特性的开发更容易。查看刚刚写好的代码，看是否有方法可以对它进行简化。

编码
---------

1、客户随时在场
   需要在现场有一位客户来明确素材，并做出重要的企业决策。开发人员是不允许单独做这些事情的。让客户随时在场可以消除开发人员等待决策出现的瓶颈。

2、代码必需符合相应的标准
   通过编码标准防止团队被一些无关紧要的愚蠢争论搞的不知所措。目标应该是团队中没有人辨认得出是谁写的哪一部分代码。以团队为单位对某一标准达成协议，然后遵守这一标准。

3、首先做单元测试
   开发人员在编写代码前先编写单元测试。单元测试及时告诉开发人员系统在某一点上是否工作。

4、实行结对编程
   开发人员结对进行开发。

5、经常集成
   经常进行代码集成可以避免集成梦魇。

6、实行集体代码所有权
   小组中的任何人都有权对代码进行更改来改进它。每个人都拥有全部代码，这意味着每个人都对它负责。

7、将优化工作留到最后。

8、不要超时工作
   长时间地持续工作会扼杀工作绩效。疲劳的开发人员会犯更多错误。让开发人员每天早晨都感到有活力有激情，每天晚上都感到疲惫而满足。

测试
--------

1、所有的代码必需有单元测试。

2、所有的代码发布前必需 100% 通过单元测试。

3、当发现了一个 bug，必须要增加相应的测试。

4、经常运行单元测试并公布其结果。


-------------------------
项目开发过程
-------------------------

项目开发过程分为 3 个阶段：调研，承诺，迭代

调研阶段
----------

1、编写 User Story，写入项目主目录的 doc/TODO.txt 文件中，例如：

* 仓库管理
  对仓库信息进行维护
  对仓库进行分类，例如自有仓库、中转仓、虚拟仓、售后仓等。

2、由开发人员评估 User Story。对于不能评估的 User Story，由需求人员对 User Story 进行拆分，拆分后再由开发人员进行评估。每个 User Story 上的开发时间为一周、两周或三周。

承诺阶段
---------

1、对 User Story 按用户价值、风险和开发速度排序，写入项目主目录的 doc/TODO.txt 文件中，例如：

story               value   risk        velocity
-----------------------------------------------------
user                高      低          15人天
customer            高      低          15人天
role_security       高      中          15人天
sales_order         高      低          6人天
data_encryption     中      中          12人天
data_exchange       中      高          15人天
data_backup         低      低          12人天

2、制订发布计划，写入项目主目录的 doc/TODO.txt 文件中，例如：

* version 0.1 : 90人天，2002.7.5 发布
  user，customer，role_security
  仓库，report，sales_order，进销存分析

* version 0.2 : 97人天
  客户退货，编码对照，仓库调拨，经营管理
  数据同步，数据采集，data_encryption，data_exchange，data_backup


迭代阶段
----------
1、制订迭代计划，每个迭代一般持续一至三周。迭代计划尽量细分到每天。

  迭代计划写入项目主目录的 doc/TODO.txt 文件中，例如：

* Disability Plan Redesign
  Richard: 0.5 days: 45 Transaction input
  Brain: 1.0 days: DAP Counter corrections

* Supplemental Unemployment Benefit
  Ralph: 1.0 days: Take deduction bases on catalog
  Ann: 0.5 days: Load UPGUA history tables

2、用 CRC 卡进行设计
   CRC 设计文档规范见 $CVSROOT/knowledge/management/CRCConventions.txt

3、编写单元测试代码
   在编写程序前，首先编写验证该程序的单元测试代码。测试代码放在项目主目录下面的 test 目录中。

4、按照代码规范进行编码
   Java 代码规范见：$CVSROOT/knowledge/management/CodeConventions.pdf


-------------------------
Team 构成
-------------------------

1、由 2-3 个程序员组成 pair，pair 为 team 安排工作和进行工作考核的最小单位。

2、由 2-3 个 pair 组成 group，并制定一位 group leader

3、由 2-3 个 group 组成 team，并制定一位 team leader

group leader 的职责
--------------------

1、每天上午上班后组织 group 成员召开 stand-up meeting 进行组内交流。

2、指导 group 使其按照项目管理的要求进行工作，在技术上和业务上对 group 成员进行帮助。

3、检查 group 成员的提交到 CVS 中的代码，每天下班前将发现的问题写到 $CVSROOT/knowledge/management/GroupReport.txt 中。

4、需求分析和系统设计。

5、可接收性测试。

team leader 的职责
-------------------

1、在项目管理，技术和业务上对 team 的工作进行指导。

2、检查各 group 的工作，每天下班前将发现的问题写到 $CVSROOT/knowledge/management/TeamReport.txt 中。

3、需求分析和系统设计。

4、可接收性测试。

项目管理部的职责
-------------------

1、检查所有的 team 是否按照项目管理的要求在工作。

2、检查所有的 team 的迭代计划。

3、每天将检查的结果形成项目管理报告（$CVSROOT/knowledge/management/PMReport.txt）

4、可接收性测试。


其他注意事项

1、源代码就是文档
   在整个开发过程中的 User Story 是临时的文档，不会被长期保留，CRC 文档和源代码才是最终的开发文档，将被长期保留。

2、不说悄悄话
   通过 IRC 等工具进行交流，让所有的人都知道你在怎样思考，减少悄悄话。

TDD绝对不是先写单元测试那么简单。其实它的思想内核在于，你要首先确定你要作什么，并且你要找到当你做了一些事情以后，可以验证你做的这些事情是不是你要要做的那些事情的方法。
当然最为程序员感受最深的还是先写单元测试。究竟要写多少测试呢？KENT告诉我们要做足够的测试，还有人说不要对有把握的东西测试。但是这些都是模糊的说法（XP中很多方法都是很模糊的），需要你针对性的去按照自己的组织确定一个实际的标准，确定一个纪律。
说到纪律，这个可能是XP中要求最为严格的东西。我对于讨论的要求是按照5分钟为计时单位的。而重构中的味道，也是在集体讨论后决定的，是有具体的要求。测试也是有具体的要求的（但是这个标准和你所在的环境很有关系，不应该把一个组织的标准用在另一个组织中）。
而遵守纪律意味着你承认你是这个组织中的一个成员，你可以使用这个组织的资源，得到其他人的帮助。不遵守是被允许的，但是这时要求你不能使用别人的资源，也不能寻求别人的帮助，而且你必须完成你的任务。
其实我想XP中很多手段都是可以单独实施的，我们不需要上来就实施XP的所有的方法，一个一个逐步实施会好的多。而对于使用CRC习惯的人来说，使用使用FDD方法会好些。
同时提醒一下大家，上面dlee提供的XP实施方法有些问题。最重要的一点是，他的usestory的粒度都很大，这说明他们可能还使用任务卡来做任务分配。同时他们的usestory命名似乎是随意的，应该有具体的规则，即使是客户也要遵守这样的规则。同时迭代周期应该是在开始的时候就固定下来，并且维持不变的。同时我们是不断提交可以工作的软件，而不是不断发布小的版本。这一点有很大的不同，请务必深刻体会。

对的，XP 对于纪律的要求是非常严格的。中国的很多程序员纪律性并不好，尤其是那些编程高手（我也并不喜欢这样所谓的高手）。还有一个问题是制度（由 CTO、PM 制订）如果制订得不合理（例如：对于进度的设置出于主观臆断，没有按照 XP 的要求基于长期积累的数据进行科学度量），会引发强烈的抵触情绪。XP 最强调的是沟通，要让所有成员完全理解 XP 的意图，自觉地遵守制订的制度，而不是强制性地进行半军事化管理，我想所有程序员最反感的就是这样。程序员如果没有较高的开发技能和个人素质（注重团队合作而不是搞个人主义），完全无法适应 XP 的快节奏和纪律。
我去年所在的那个团队有一个很大的问题是沟通不够，对 XP 有足够理解的只有管理层的两三个人（很难说他们是真正理解了 XP，但是形式上做的还是很足的），底下的程序员只是肤浅地知道了一些 XP 术语，却不理解 XP 为何要这样做：为何要测试优先，为何要结队编程，为何每天早上要开 Standup Meeting。最后项目进度压的大家怨声载道，好象 XP 只是一个资方更多压榨程序员剩余价值的工具，结果并没有取得理想的效果（很多好的程序员跑掉了，你说效果理想吗？）。

我现在更倾向于一种折中的方式，即结合 XP 和 RUP 的优点，使程序员有足够发展空间，能够逐步成长起来，而不是象某些人所做的那样揠苗助长地强迫他们除了完成大量开发任务外还要完全达到 XP 的要求。中国现在真正符合 XP 要求的程序员（至少要非常熟悉 Java API 和设计模式）是很少的，我们无法改变这个大环境，所以我们还是立足于自己培养人才。

XP 并不是万能的。对于研发性质的开发，如果需要很复杂的技术，请不要采用 XP 方式管理。只有那些技术非常成熟（程序员对于技术和工具已经充分掌握）的项目才应该采用 XP 管理。XP 最适合那些以外包为主不需要很高技术含量（使用成熟的框架，程序员已经掌握得非常熟练）的软件企业。XP 对于这些企业达到 CMM2 “可重复级”的目标是非常有帮助的。这是由 XP 的本质所决定的，也是我在反复读过几本 XP 经典教材后得出的结论。XP 成功实施的前提是一个复杂问题可以分解为多个小的简单问题，所以可以采用迭代的方式逐步去解决。但是仍然有一些非常复杂的问题甚至很难进行分解。比如 OLAP 应用，如果没有一个实现良好的 Cube 核心，是很难展开下一步的开发工作的。这时候整个任务的瓶颈都卡在这个最复杂的技术难题之上。这些复杂的问题由于其技术的尖端性，是无论你用多少教科书上的设计模式都无法解决的（只是打个比方，设计模式也不应该用在这种场合）。在这种场合，你也别奢望 XP 能够成为你的救命稻草。

XP 中强调简单，使有些人（还是一些断章取义者）误以为设计模式、UML 是过时的东西，这是一个危险的倾向，千万别这样想。设计模式、UML 仍然是非常有价值的东西。有些真正复杂的问题，不是你想要简单就能简单的（只能相对简化），所以未雨绸缪的事情还是该做一些的。

XP 的逻辑是严密的（并不是象有些人认为的满是漏洞），但是严密的逻辑未必一定是可行的，因为这里要面对的是人。人是可以量化的吗（又回到把程序员简单抽象为“编程单位”的恶劣回忆中）？程序员张三和李四是完全一样的吗？你还是要因人而异进行管理吧。人是最宝贵的财富，你不尊重人，不注重人的培养，最后人离你而去，这就是“人”这类对象对外所表现出的规律和接口。所以我认为 XP 的核心是“以人为本”而不是纪律。如果我来负责实施 XP，我更倾向于稍微放松纪律方面的要求，而通过更好的沟通使程序员自觉地按照 XP 的要求来做事（是“我要做”，而不是“那个混蛋 PM 要我做”）。实施 XP 是一个循序渐进的过程，我很反对那种大跃进式的做事方式。

ozzzzzz 其它的观点我基本上同意。我们目前采取的方式与 FDD 比较接近。没有采用 TDD 方式主要是出于成本和项目进度方面的考虑。不管是 FDD 还是 TDD，这些方法只要认真做好了，都能取得较大的收效。

XP 只是诸多敏捷开发方法中的一种，对于 XP 目前还存在很多争议，但是随着时间的推移 XP 肯定会越来越成熟的。
XP 与 RUP 的相同之处在于：
1、同样是用例驱动的开发方式。
2、同样是以体系结构为中心。
3、同样以迭代和里程碑的方式进行开发。强调开发过程中反复的重要性。

不要太迷信过程，任何过程都不是万能的。过程不象技术，好就是好，有一个较为客观的评判标准。过程是更加柔性的东西，很难有一个定论，比如有人认为 CMM 就是终极真理，而我认为那只是一堆大而无当的垃圾。过程只是在你已经知道该做什么和如何做后帮助你更好地完成工作。但是有些时候你首先搞清楚需要做什么和如何做才是最重要的。这是我看了《人月神话》之后的感受，这些年有很多新技术让我误以为出现了银弹，但是仔细考察之后还是感觉到失望，XP 同样也不是我所期望的银弹。

因为没有采用过xp，只是看过很多关于xp的介绍文章，自己体会，除了上面提到的纪律性，对于队员的要求很高，它的很多实践都依赖于程序员的能力，尤其是没有核心队员（指水平，无它意），采用xp死的多，如果不死，就像dlee说得，这类项目不用过程也能ok，甚至更快，更好。
我觉得xp相对于rup最重要的区别是关于人的价值，这一点不仅指尊重程序员的价值，程序员还要有价值才行。
因此，除了人数，规模，大家是否接受xp这些因素以外，对于希望采用xp的团队，应该还有什么样的素质要求。
我自己提一些，抛砖引玉
1，在开发项目中所涉及的所有技术都要有相应的人员能够掌握
2，都能写出一定水准的代码（至少是基本合格，能够被重构的吧）
3，对于模式，uml，用例......都要有一定了解
4，在开发总时间里，学习占用时间不能太高（业余时间除外）
5，所有人都要有全局概念，无论是技术上的，还是业务上的，（我觉得挺难）。

首先我还是会强调在XP中纪律的重要性，但是这个纪律是开发者之间达成的协议，而不是自上而下的一种约束。明白这种纪律的产生的原因会让你更加理解为什么会强调交流，以及怎么强调交流。
其实XP并没有说就不存在核心设计人员，那只是一种误解。同时你也可以引入你觉得XP缺乏的任何的东西，只要你相信那些东西有用，并且其他人也和你一样认为有用。不要去考虑是不是在XP了，你应该考虑是不是这样做有效了。
XP也没有要求必须只有技术能手才可以使用，新手一样可以从中得到很多。而且大家这么评论XP的时候，似乎隐含着新手在一个什么别的方法指引下实施项目就会没有问题的观点。这显然是一种对XP的强词夺理，按照这样的观点新手就没有什么方法可以去实施项目了。
对于UML和用例这些东西XP也没有强求，而且应该明白XP没有要求你去使用USECASE，也没有要求你必须去UML。其实KENT很反对使用UML。但是我不觉得UML有什么不好，我还是会使用它。但是你也可以看到UML并不是被强制实施的。
写一定水准的编码是受PP和编码标准支持的，并不是什么困难的事情。而且不管你在哪，大不到水准的编码都会成为问题。
学习这个是在XP进行中不断被强化的，PP的时候学习同伴的技术，交换任务会让你接触到不同的技术，集体设计共享代码让你可以学习所有人的技巧。
说到全局观念，不是说要求你有，而是在不断的交换任务的操作中自然达到对项目整体状态的把握的。
其实说实际的，在国外真正喜欢XP是商人和用户，而不是开发者。XP使客户第一次感到他们在控制一些东西，在参与自己软件的实际设计，并且在不断的监督软件的实际开发过程。而不是只能从一些似是而非的文档，和不知所云的评审中才能得到项目的蛛丝马迹。
说了这么多XP的好话，可是我还是建议大家去实施FDD。那才是我最喜欢的，而且我还喜欢COLOR UML。color UML大家最好都去研究一下，真的很牛的一种方法。

和 ozzzzzz 讨论真的是受益非浅，我会持续关注 FDD 的。这些过程如果不亲自实践体会是不会很深的，FDD 恰好是马上就可以实践的过程。