去年在一家公司时我的 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 等工具进行交流，让所有的人都知道你在怎样思考，减少悄悄话。