引言

我喜欢读书，书是我最忠实的朋友。当我想找他聊天时，他总是有时间陪伴我，随便聊多长时间。当我厌倦他时，他从不打扰我，直到有一天我开始想念他。我喜欢读书，书是我最博学的老师。当我百思不得其解时，他来给我点拨，引领着我，或许横跨整个太平洋，或许穿越回上个世纪。写些读书心得，算作对朋友的回赠，对老师的敬意。

第一章 引子

 感 想 

Scrum的项目管理策略是“好钢用在刀刃上”

在《Essential Scrum》书的一开头，Ken Rubin用他小儿子的诞生比喻一个项目，指出一个成功项目应具备的特点：准时、高质量、干系人满意。项目管理有几个基本维度：时间、范围、成本和质量。这些维度相互制约，似乎达成一些要求，就必须对另一些要求妥协。

怎样平衡这些维度？项目管理策略需要回答这个问题。

实践中，开发团队往往面对所有维度的要求都固定，无权妥协的困境。他们不得不通过暗中损失“质量”这个隐性维度，来换取在时间、范围、成本这些显性维度达到要求。然而，质量问题早晚会浮出水面，影响客户满意度，给维系和发展长期客户关系带来负面影响。

Scrum采用的是满足时间、成本和质量要求，灵活调节范围的策略。在时间方面，Scrum的每个Sprint都要开发出潜在可发布的软件，满足正式发布截止时间的风险比传统开发方法小。在成本方面，软件开发的主要成本来自开发者的人力成本。Scrum开发团队成员应当基本稳定。以团队为核心开展工作，这既是对人类社会性需求的满足，也是Scrum的核心精神。所以成本主要受时间的影响。时间不延迟，成本就不会超预算。在质量方面，通过制定和履行严格的完成的定义（DoD），保证发布的特性具备应有的质量水平。在范围方面，Scrum采用将产品待办项按照优先级排序的策略，在时间紧，人力有限的条件下，优先开发对用户最有价值的特性。

俗话说的好，好钢用在刀刃上。Scrum用有限的时间和成本做最有价值的事，让客户满意。这符合20-80 定律，是价值驱动代替计划驱动的原则在实践层面上的体现。

Genomica取得的成果

 感 想 

怎样评价Scrum使用成功与否？

Ken Rubin在Genomica担任VP期间，先后采用瀑布开发方法和Scrum开发方法开发一款创新型产品。基于这款产品开发的实际情况，他用一张表格对比瀑布和Scrum的使用效果。值得注意，他对比了三个指标：工作量、速度和客户满意度。工作量指人*月数；速度指单位时间开发出的有价值的特性个数；客户满意度指与客户形成长期合作关系。

为什么选取这样三个指标？他们具有怎样的普遍意义呢？

第一、 工作量

为什么比较工作量而不比较开发成本呢？软件开发的成本主要来自开发者的工资，外加其他费用，如出差、加班、团队建设。工资是保密信息，并且不同地区差距较大，不容易获得准确数据，不方便拿来比较。而用工作量（人*月）就简单的多。人*月数与开发成本具有很强的正向相关性，人*月数大，开发成本必然高，降低成本也主要通过降低人*月数来达到目标。所以通过比较人*月数的方法来比较开发成本，是简单有效的好方法。

第二、 速率

为什么比较速率而不分别比较范围和时间呢？开发范围大小不同的项目，比较时间没有意义。开发时间长短不同的项目，比较开发范围也没有意义。通过用特性个数除以时间计算速率，得到单位时间内开发的特性个数，两个项目、两种开发方法才具备可比性。

需要注意，这里用作分子的特性个数指“有价值”的特性个数。在变更为常态的革新型产品的开发过程中，Scrum频繁获取客户反馈，围绕客户价值排列新特性的优先级，优先实现它们。而瀑布开发方法根据计划阶段确定的需求进行开发，到项目结束时，当初确定的部分需求失去了其价值。这就导致采用Scrum方法开发出的“有价值”的特性个数就比采用瀑布方法开发出的多。

其一，单位时间开发的新特性多，未必代表做的好，这里速率强调有价值的特性。其二，开发同样有价值的新特性，用更短的时间，越早交付越好。

第三、 客户满意度

评估软件质量，可以考虑客户满意度、缺陷数据、可维护性（圈复杂度）等多个度量。其中最终要的，也是比较容易获得的度量是客户满意度。怎样度量客户满意度呢？像银行柜台那样安装一个用户反馈终端，邀请客户点“非常满意/满意/不满意”的按钮吗？或者像教育咨询机构的客服那样打电话给客户，邀请评分吗？你一定遇到过这样的现象：有的客户很友好，按了“非常满意”或打了10分，但就是不再继续购买你的产品或服务了；而有的客户很挑剔，提出各种抱怨，但继续购买你的产品或服务。于是我们感到客户反馈不客观，无法准确度量。Ken Rubin在这个问题上给出一个睿智的答案：用“维系和发展与客户之间的业务关系”度量客户满意度。

Scrum能给你带来帮助吗？

 感 想 1 

什么时候适合用Scrum？什么时候不适合？

Scrum并非银弹。按照Cynefin框架，Scrum最适合应用在复杂（complex）场景中，用于开发创新型产品和特性。Scrum需要客户的配合，客户需要能够接受在Sprint期间不轻易改变已经处于进行中的工作项。客户需要参加Sprint评审会，并对展示的产品特性给出反馈意见。如果你的客户习惯于强势沟通，并且朝令夕改，总是有更重要的事打断你目前正在进行的工作，不能接受有计划、有节奏的长期合作，那么你感觉你是否经常处于中断驱动（interrupt-driven）的工作场景中呢？如果真是这样，看板方法比Scrum对您更有帮助。

 感 想 2 

怎样用看板

Scrum不太适合中断驱动型工作。在中断驱动的环境里，最好用看板方法取而代之。具体而言，看板提倡以下原则：

• 把WIP穿过系统的过程可视化
• 限制WIP在每个步骤里的数量，确保不超负荷
• 度量和优化穿过系统的工作流，以持续改进

想起两个违背第二条原则的案例。

案例一、某产品集成阶段出现大量缺陷，管理层施加压力，要求当天指派的缺陷当天解决。开发团队每人每天解上百个bug，每人每月加班超过100小时。然后出现什么问题呢？有些缺陷其实没有解决，但是已经是午夜零点，开发者直接在缺陷管理系统上把缺陷状态改成解决，第二天这个缺陷再被测试者拒绝，并遭到On Shore团队投诉。

案例二、某产品由于软件架构不合理，导致一个模块与其他模块高耦合在一起。当其他模块开发时，这个模块的开发团队就为解bug疲于奔命。后来实在解不完了，干脆慢慢解。所谓虱子多了不咬，债多了不愁。过了几个月，对这个产品的软件架构重新调整，才解决这个问题。

所以在使用看板时，确保不做超过自己能力的工作是一条重要的原则。超出了自己能力的最大限度，就会导致工作质量急剧下降，或者工作效率急剧下降。如果的确有那么多工作需要完成，首先应该秉承按照优先级排序的原则，用有限的时间和资源，优先做最有价值的工作。然后再运用第一条和第三条原则，可视化问题，从根本上解决问题。比如案例二提到的软件架构调整。

本文作者王子君，由ShineScrum Jim Wang审核，转载请注明