第15届Jolt大奖入闱作品，敏捷运动领军人物，两次Jolt大奖得主Alistair Cockburn向你推荐成功项目的7大体系特征！作者潜心研究了成功的敏捷项目并识别出它们的共同特征。这些特征将引导您的项目迈向成功。本书适合软件开发人员、项目管理人员、软件工程研究人员，以及所有想要了解敏捷开发思想的各界人士参考。

敏捷团队通过将近10年的潜心研究及反复试验，总结得出水晶项目管理体系：一个以人为本的小团队方法体系。它通过明晰而又实用的说明指导您的团队如何成功开发敏捷类型的项目。每一章节都对敏捷项目的某个不同方面进行详尽而又生动地讲解。本书亮点：

关注成功项目中的关键人员和人与人之间的交流。

提供案例研究、实例、原则、策略、方法，以及体系特征指南。

提供实际项目的工作产品样本，而非空洞的模型或虚构的问题。

介绍软件开发团队能按时交付高质量代码的顶级策略。

指导团队详尽引入最棒的工作方法，如闪电式计划、项目360度全面考察以及最根本的反思研讨会。

与作者通过问答的形式，向读者介绍这些建议如何得来，包括它们在哪些方面适应于XP、CMMI、ISO、RUP以及其他方法体系。

一份详细的案例分析，包括ISO评审员分析。

本书为读者提供了成功项目的7大体系特征。作者潜心研究了成功的敏捷项目并识别出它们的共同特征。这些特征将引导您的项目迈向成功。本书适合软件开发人员、项目管理人员、软件工程研究人员，以及所有想要了解敏捷开发思想的各界人士参考。

序言 Crystal Clear—— 小型项目安全开发的重要原则 Ⅰ

第1章 阐释(旁观者之见) 1

第2章 应用(七大体系特征) 21

体系特征一：经常交付 22

体系特征二：反思改进 24

体系特征三：渗透式交流 26

体系特征四：个人安全 31

体系特征五：焦点 34

体系特征六：与专家用户建立方便的联系 36

体系特征七：配有自动测试、配置管理和经常集成功能的技术环境 38

实证：不同机构间的协作 43

对体系特征的反思 44

第3章 实践(策略与方法)  47

策略 47

策略一：360度全方位考察 48

策略二：早期胜利 49

策略三：灵活程序框架 50

策略四：增量重建 52

策略五：信息传播器 55

方法 59

方法一：方法体系建成法 60

方法二：反思研讨会 64

方法三：闪电式计划 67

方法四：利用专门排列技术的特尔菲估计 75

方法五：每日起立会议 77

方法六：实质性交互设计 78

方法七：流程微观模型 89

方法八：肩并肩编程 90

方法九：燃烧图表 92

对策略以及方法的反思 106

第4章 探究(流程)  109

项目周期 115

交付周期 120

迭代周期 123

集成周期 126

工作周与工作日 127

开发部曲 127

关于流程的反思 128

第5章 检验(工作产品) 129

角色以及他们的工作产品 131

角色：主办方、专家用户、总设计师、设计师兼编程员、商务专家、协调者、

测试员、书写人员 132

关于项目样本的一些注释 135

主办方：具有取舍优先的任务综述 136

团队：团队结构和工作惯例 138

团队：反思研讨会成果 141

协调者：项目规划图、发布计划、项目状况、迭代计划和状况、评审进度表、

风险列表 143

协调者：项目规划图 144

协调者：发布计划 145

协调者：项目状况 148

协调者：风险列表 152

协调者：迭代计划→迭代状况 153

协调者：评审进度表 156

商务专家与专家用户：角色目标列表 157

商务专家：需求档案 158

商务专家和专家用户：用例 162

专家用户：用户角色模型 164

设计师兼编程员：屏幕草图、系统架构、源代码、公共领域模型、设计草图

与注解 165

设计师兼编程员：屏幕草图 167

总设计师：系统架构 169

设计师兼编程员：公共领域模型 172

设计师兼编程员：源代码和交付包 174

设计师兼编程员：设计注解 174

设计师兼编程员：测试 177

测试员：漏洞报告 180

书写人员：帮助文本文件、用户手册以及培训手册 181

对工作产品的反思 182

第6章 误解(常见错误) 185

“我们扎根在一个地方并在此进行了为时两个星期的迭代-- 但是为什么我们

还是失败了？” 185

“两名开发人员被一条走廊以及一扇锁上的门给分开了。” 187

“我们用这个大型基础结构进行初次交付。” 188

“我们的第一次交付是关于数据表的一场演示。” 189

“无可用用户，但一名测试工程师下周即将加入我们团队。” 189

“一名开发人员拒绝对他的设计进行讨论或者拒绝向其他成员展示

他的代码。” 190

“用户希望我们一次就能将所有功能都交付到他们桌上……” 190

“我们有一些小于用例的里程碑事件，还有一些大于用例的里程碑事件。” 191

“我们写下了一个基本概念和系统的设计方案。我们都坐到了一起，这样应该

就可以了吧。” 191

“谁拥有这些代码？” 192

“能否让测试工程师编写测试？如何对图形用户界面(GUI)进行回归

测试？” 193

“最佳迭代周期为多长？” 193

第7章 疑问(常见问题) 197

问题1：水晶项目管理体系的基础是什么？ 198

问题2：什么是水晶家族？ 206

问题3：这是一种什么样的方法体系描述？ 209

问题4：水晶项目管理体系的概要表是怎样的？ 213

问题5：为什么要有不同的篇章形式？ 214

问题6：水晶项目管理体系处于方法体系万神殿的哪个位置？ 215

问题7：CMM(I)怎么样？ 223

问题8：什么是UML，什么是结构？ 226

问题9：为什么目的只为安全区域？难道我们就不能做得更好吗？ 227

问题10：分布式的团队怎么样？ 228

问题11：较大型的团队又怎样？ 230

问题12：固定价格以及固定范围的项目怎样？ 231

问题13：我该如何评价我们究竟有多“敏捷”或有多“水晶”？ 232

问题14：我该如何开始？ 234

第8章 测试(案例研究) 235

现场报告 236

审核员报告 258

领域内的反思和审核报告 263

第9章 集萃(精简版) 267

开发人员还表示当他们同时承担两到三个项目时，他们就无法在任何一个项目上取得进展。而人们似乎要花上一个半小时的时间才能从一个项目的思路回到另一项目的工作思路上。

所有我所采访过的资深项目经理都一致认同，一名开发人员最多一次承担一到一个半的项目任务，以保证其工作效率。一旦接管了第三个项目，那么他在这三个项目上都将无所作为。

我们把它与一些经验不丰富、低估了项目转换成本的经理作比较，这些领导人通常给开发人员同时布置3～5个项目。我甚至遇到同时接管7个项目的开发人员!可以想象他根本没有时间在各个项目的会议上对其工作进展作出汇报，而实际上他的工作也没有什么进展。

补救方法很简单的，尽管有时不太合意。主办者必须让每位成员清楚地了解到他们的首要任务是什么，然后再从首要任务之中列出两项首要之首要的任务。

接着，团队应该形成制定“焦点时间”的惯例。所谓“聚焦时间”是指当一名成员将要接管另外一个项目时，团队必须保证安排给这名成员完整的两天时间来做准备。这种做法适用于部分的项目转换，因为这么做能够保证成员有足够的时间在原先的项目上取得进展，而不是把所有的时间都浪费在了解新的项目上。

团队要形成的另一工作惯例是将干扰局部化。经验告诉我当面对一些严格而简捷的规定时，要把干扰控制住往往会变得不切实际。譬如：“仅限于上午”、“仅限于下午l点到3点时段”等规定。偶发性与迫切性是干扰的两大特点。所以团队的工作就是规定一个两小时左右禁止一切干扰的时间段。大多数情况下，将干扰搁置到两个小时后处理完全没有问题。一些团队就将上午10点到正午这段时间作为禁止会议、来电、软件演示干扰工作的时间段。

以前常常被干扰而打乱思路的开发人员自从执行了每天两个小时的焦点时间且两天为一组时间用在同一项目上这样的做法后，他们每个星期就能拥有整整4个小时的时间完全投入某项研发工作。曾有一名开发人员向我们反馈，自从采用了上述措施之后，他在几个星期内所完成的工作量比以前他几个月所完成的工作量还要大。

P35

Crystal Clear

——小型项目安全开发的重要原则

没有足够的资源开发系统？您不想让团队书写冗长的文件，但是成员却常忘记他们本应知的东西。您不喜欢繁杂的软件开发过程，但却又希望团队能够做得更好，而不是随心所欲地做事情。您特别希望能成功地开发出软件。

您考虑静下心来制定一些团队应该进行的基本讨论话题以及必须认真对待的工作产品。曾经问过自己如下的问题：

那些小型的、成功的项目团队究竟都做了些什么？

它们都采用什么样的做法？

这本书可回答上述问题。它是10年来研究成功小型团队的结果。我们从大多数例子中都获得相同的信息：

● 团队成员紧密聚集在一起，进行经常性交流且态度友善；

● 摒弃官僚性，让团员们自主发挥；

● 让实用户直接参与到项目中；

● 配备优良的自动回归测试配套工具；

● 尽早地、经常性地开发可交付的功能。

采取了上述所有措施后，过程的其他细节将会自行健康发展。

本书介绍了一套您可能想寻求的最具效率(指能考虑到人们在一起工作的自然优点和缺点，能使每个人都在这个团体中愉快工作)方法体系—— 水晶项目管理体系(Crystal Clear)。它是一个以人驱动的方法，可以用最简短的话语做如下概括：

总设计师和2～7名开发人员在一个大办公区室或在相邻的办公室内，使用白板和挂图等信息传播器，方便联系到专家用户，干扰已排除，每一个或两个月(最长一个季度)把可运行、已测试以及有用的代码交付给用户，周期性地反思和调整工作惯例。

这些简单的建议是基于实际经验和理论而提出的。软件开发可以看作以经济限制为特征的开发和交流协作竞赛。1团队进行每一开发的方式都会影响到项目的结果和开发出来的软件。水晶项目管理体系直接采用经济协作行开发方法，指出需要注意的问题、简化的程序以及如何使用不同的规则。许多团队与我一起共同分享了—— 读者现在可以通过这本书与我一起分享—— 原则、工作产品，甚至是办公室布局的例子。

由于具有过大的约束性、侵害性和过高的难度，许多所谓“最好的”方法体系被团队拒用。水晶项目管理体系并不敢奢望成为“最好的”方法，但盼望成为“切实可行的”方法，这样您的团队就够按其本来面目制定适合自身的水晶项目管理体系并在开发中予以应用。

本书材料来源

1991年IBM咨询团队(Consulting Group)请我写一本关于目标技术项目(Object -technology Project)方面的书。由于当时不了解做出重要决定的方法，在我老板Kathy Ulisse2的建议下，我开始采访项目团队。他们的回答与我在书本上读到的信息截然不同。特别是他们强调了有关项目管理方法方面的书籍没有涉及的方面，即密切交流、有道德感、拥有终端客户等等。不久前我又采访了许多不成功的项目团队，他们对这些问题的回答与成功团队的回答截然不同。于是我开始将这些问题，而不是设计技术看作项目成功完成的关键。

我在一个拥有45名成员、总价为1.5亿美元，价格固定、范围固定的项目中试验这些想法。这些想法作为公开(在使用过程中有许多创新)的想法，显示了它们作为核心成功因素的重要性。我将项目访谈中得到的体会编写成课程材料并写入《在面向对象的项目中生存》一书(Cockurn，1998)。3

一个特别的三重组合在许多成功项目中重复出现：团队协作、经常交付和方便联系到专家用户。各项目的不同结果是否在使用这三重组合的前提下获得，使用这一做法的频率远远超过了其他做法。这本书就是建立在这一三重组合基础之上的。

在从业生涯中，我参加过的项目通常都有固定的价格和固定的范围。这类项目通常出价都比较低，也就是说团队若要及时交付就必须在整个开发过程中都富有创意。与《敏捷开发宣言》的大多数其他作者不同，我是通过追求效率而不是快速处理变化要求来讨论敏捷原则。

因此，水晶项目管理体系非常适于固定价格项目的情况。这类项目可以使用我所介绍的策划、交流及报告机制，在规定期限内(可能不够现实)实现软件的交付。记住不要在每个迭代周期开始时就对要求进行修改。若您参加的是一个试探性项目，且它的要求不明确或不断变化，这样做也可以，每个迭代周期开始的时候也可以变动要求。

水晶家族中的水晶项目管理体系

水晶项目管理体系是一个具有共同遗传代码(Genetic Code)的方法体系。它强调经常交付、密切交流和反思改进。水晶项目管理体系不特定，不同的项目有不同的水晶项目管理体系。每个项目或机构可以使用遗传代码形成新的方法。

“水晶”这一名称来源于我对项目特征的总结，即其二维、大小和临界点与水晶颜色和硬度相匹配(见图7-1)。

较大型的项目需要更多的协作和交流，在图中用更深的颜色(亮色、黄色、橙色、红色等等)表示。那些可能导致较大损失的系统工程需要在方法体系中增加“硬度”、给予更多的确认和验证规则。只有几个开发成员的计价系统项目适用石英方法体系(Quartz Methodology)。若同样的团队控制核反应中的硼杆运动，则需使用钻石方法体系(Diamond Methodology)—— 钻石方法体系要求对设计和算法执行情况重复进行检查。

根据参加协作人员的数量，我用不同颜色表示不同的水晶方法体系：亮色表示具有8个或更少成员的团队，黄色表示具有10～20个成员的团队，橙色表示具有20～50个成员的团队，红色表示具有50～100个成员的团队，等等，依次类推，从栗色到蓝色、紫色。水晶橙色项目管理体系在《在面向对象的项目中生存》(Cockburn，1998)中已做叙述。而且它的变体—— 水晶橙色/网在《敏捷软件开发》(Cockburn，2002)中也做了介绍。

我发现，除一些生命攸关的项目外，人们可以通过方法建成和调整研讨会在验证活动中进行添加。4 水晶遗传代码包括：

●  经济协作策略模式(Economic-cooperative Game Model)

●  选定优先(Selected Priority)

●  选定特征(Selected Property)

●  选定原则(Selected Principle)

●  选定样本方法(Selected Sample Technique)

● 项目示例(Project Examples)

经济协作策略模式认为软件开发是一系列“策略”(通常资源有限)，这些策略只包括创新和交流。在这一系列策略中，每个策略都有两个相互竞争资源的目标：在本项目中交付软件和制定系列中的下一项目。项目不会重复，因此每个项目的策略都要与前一项目稍不相同。经济协作策略模式可以帮助开发人员以非常明确、集中、有效的方式去思考他们的工作。

水晶项目管理体系中常见的优先项包括：

●  项目结果的安全性

●  开发过程中的效率

●  惯例的可居性(开发人员可以接受)

水晶项目管理体系将项目团队导向7个安全体系特征。其中，前3个是水晶项目管理体系的核心。其余4个可以任意顺利添加入内以提高安全限度。这些体系特征包括：

● 经常交付

● 反思改进

● 渗透式交流

● 个人安全(信任的第一步)

● 焦点

● 易于与专家用户取得联系

● 配有自动测试、配置管理和经常集成功能的技术环境

水晶项目管理体系的原则在《敏捷软件开发》(Cockburn，2002)中做了详细介绍。其中一些中心思想是：

● 需求、设计以及策划文件的细节因项目情况各不相同，特别是一些未检测到的瑕疵可能造成的损失程度和团队成员间的协作频率。

● 抛弃所有中间工作产品和诸如要求、设计文件和项目计划等“期票”文件也许不太可能；但是可以把这些文件减少到一定程度，以保证成员间的简短、丰富、非正式的交流渠道畅通无阻且可用的、已测试软件能够及早、经常地交付。

● 团队可以不断调整工作惯例以适应个别团队成员的性格、现有的本地工作环境和特定任务的特殊性。

还有就是取舍曲线(Trade-off Curve)。取舍曲线突出了不同交流机制、不同项目情况和共同协作开发的不同策略隐含的价格因素。我利用这些原则形成了水晶系项目管理体系，但是在本书中并未分别予以讨论。

水晶成套产品(Crystal Package)包括选定样本方法(Selected Sample Technique)，而这一方法又包括方法体系的建成、策划以及反思改进。水晶项目管理体系不要求项目人员采用某项特定的方法，因此这些方法只是起动器系列(Starter Set)中的一种。

水晶项目管理体系的各个构成部分是在项目启动时根据遗传代码形成的基础方法体系而生成的。鉴于情况随着时间的变化而变化，在项目过程中方法体系会得到重新调整。方法体系的建成和调整必须能获得快速执行，这样才得以把所花费的时间控制在项目时间框架内，促进项目快速前进。

水晶项目管理体系是水晶家族内一种优化的管理方法，它可适用于成员人数在2～8个、共处一室或处于相邻办公室内的团队。密切交流的特征通过渗透式交流获得强化，也就是说团队成员每天都可以不经意地听到成员间有关项目优先、状态、要求设计等方面的讨论。

这种增强了的交流方式使得团队通过隐性交流和小说明进行工作成为可能。

每个公司和项目都各不相同，水晶项目管理体系也未完全指明。采纳水晶项目管理体系的第一步是找出自身机构的强处和弱处，然后依据水晶项目管理体系的推荐进行调整以扬长避短。

对于某些机构来说，这一工作量过大。水晶项目管理体系并不适用那些机构。它只适用于那些希望建立自身的、个人的、强大的、有效的重复交付软件方法的团队。

水晶项目管理体系与极限编程(XP)有一些共同的特征，但一般来说它不如后者要求严格。您可以把它看作是较为松散的替代方法，是极限编程方法无效时的后备方法，又或是在应用极限编程前获取一些敏捷做法的跳板。

（序言摘录）

Alistair告诉我们，通过采用一些基本的软件开发管理方法和建立适当的团队机制，小团队在开发软件时效率可以很高。与那些采用过于集中和规定死板的开发程序的大团队相比，这些小团队具有更高的效率和更高的可预测性。

——Richard Turner 《能力成熟度模型集成精粹》(CMMI Distilied)作者

水晶项目管理超越了敏捷项目管理(Agile)，我个人认为水晶项目管理体系是敏捷项目管理+灵活项目管理(Flexible)+实用项目管理(Practlcal)的总和。本书通过各种实例及富有成效的样本将我们从地狱般的软件开发过程引向了成功开发软件的道路。

——Scott Duncan 美国质量学会软件分会标准委员会主席、美国电气和电子工程师协会敏捷方法工作组主席

本书是所有希望获得”成熟”、可重复以及更短软件开发周期的人的必读物。它将开发人员的注意焦点从方法体系、过程以及测量转向基本的、基础的人类行为以及成功、可信和富有创意的软件开发项目的组织机制中。

——Jim Highsmith 卡特财团(cutter Consortium)敏捷软件开发与项目管理咨询服务中心主任

AIistair再次将其对软件开发团队所面临问题的高度敏感性与其对如何改善软件开发实践的见解和有用的建议结合起来。本书给读者展示的是基本原则、易采用的方法以及基于人力开发高质量软件的案例，从而对客户需求做出反应。我向软件开发人员和学生极力推荐这本书，把这本书当作建立强有力，高效软件开发团队的指南。

——Lars Mathiassen，佐治亚州立大学(Georgia State University)过程改进中心美国政府科学研究机构联合会(GRA)杰出学者