• Cams2
  • Cal
  • Training
  • Five
  • Arne-2017q4
  • Jens
  • Jim-banner
  • 2015
  • Innovation-management-workshop
【丹桂飘香 八月】Scrum的本质,您领悟了吗 ?——ShineScrum学员读《Essential Scrum》心得笔记


引言


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

第一章 引子

感想

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不太适合中断驱动型工作。在中断驱动的环境里,最好用看板方法取而代之。具体而言,看板提倡以下原则:

l 把WIP穿过系统的过程可视化

l 限制WIP在每个步骤里的数量,确保不超负荷

l 度量和优化穿过系统的工作流,以持续改进

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

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

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

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