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