标题：CrystalClear:小团队的敏捷开发方法
图书信息
出版社: 清华大学出版社; 第1版 (2006年9月1日)
平装: 268页
开本: 16开
ISBN: 7302133808
条形码: 9787302133803
尺寸: 23 x 18.5 x 1.1 cm
重量: 422 g
作者简介
作者：(美)科克伯恩 译者：马振晗 罗海花
一名著名的软件专家，也是一名优秀的讲师，于2001年和2002年两次获得、Jolt生产力奖。他分别向应用敏捷方法体系的新手及专家谨慎地提出各种建议。新手在此书中将找到对这些敏捷方法进行选择的独家指导。专家则会在此书中发现一些全新的、可尝试的策略及方法，以及他们用以做出提前决定的前后信息。
内容简介
《Crystal Clear:小团队的敏捷开发方法》为读者提供了成功项目的7大体系特征。作者潜心研究了成功的敏捷项目并识别出它们的共同特征。这些特征将引导您的项目迈向成功。敏捷团队通过将近10年的潜心研究及反复试验，总结得出水晶项目管理体系：一个以人为本的小团队方法体系。它通过明晰而又实用的说明指导您的团队如何成功开发敏捷类型的项目。每一章节都对敏捷项目的某个不同方面进行详尽而又生动地讲解。
[精彩试读一]   
[精彩试读二]    
作者潜心研究了成功的敏捷项目并识别出它们的共同特征。这些特征将引导您的项目迈向成功。《Crystal Clear:小团队的敏捷开发方法》适合软件开发人员、项目管理人员、软件工程研究人员，以及所有想要了解敏捷开发思想的各界人士参考。
《Crystal Clear:小团队的敏捷开发方法》亮点：
关注成功项目中的关键人员和人与人之间的交流。
提供案例研究、实例、原则、策略、方法，以及体系特征指南。
提供实际项目的工作产品样本，而非空洞的模型或虚构的问题。
介绍软件开发团队能按时交付高质量代码的顶级策略。
指导团队详尽引入最棒的工作方法，如闪电式计划、项目360度全面考察以及最根本的反思研讨会。
与作者通过问答的形式，向读者介绍这些建议如何得来，包括它们在哪些方面适应于XP、CMMI、ISO、RUP以及其他方法体系。
一份详细的案例分析，包括ISO评审员分析。
媒体评论
书评
Alistair告诉我们，通过采用一些基本的软件开发管理方法和建立适当的团队机制，小团队在开发软件时效率可以很高。与那些采用过于集中和规定死板的开发程序的大团队相比，这些小团队具有更高的效率和更高的可预测性。
——Richard Turner 《能力成熟度模型集成精粹》(CMMI Distilied)
作者
水晶项目管理超越了敏捷项目管理(Agile)，我个人认为水晶项目管理体系是敏捷项目管理+灵活项目管理(Flexible)+实用项目管理(Practlcal)的总和。本书通过各种实例及富有成效的样本将我们从地狱般的软件开发过程引向了成功开发软件的道路。
——Scott Duncan 美国质量学会软件分会标准委员会主席、美国电气和电子工程师协会敏捷方法工作组主席
本书是所有希望获得”成熟”、可重复以及更短软件开发周期的人的必读物。它将开发人员的注意焦点从方法体系、过程以及测量转向基本的、基础的人类行为以及成功、可信和富有创意的软件开发项目的组织机制中。
——Jim Highsmith 卡特财团(cutter Consortium)敏捷软件开发与项目管理咨询服务中心主任
AIistair再次将其对软件开发团队所面临问题的高度敏感性与其对如何改善软件开发实践的见解和有用的建议结合起来。本书给读者展示的是基本原则、易采用的方法以及基于人力开发高质量软件的案例，从而对客户需求做出反应。我向软件开发人员和学生极力推荐这本书，把这本书当作建立强有力，高效软件开发团队的指南。
——Lars Mathiassen，佐治亚州立大学(Georgia State University)过程改进中心美国政府科学研究机构联合会(GRA)杰出学者
目录
序言  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