《Scrum捷径:敏捷策略、工具与技巧》读书笔记之Scrum起步

引言


2015年12月17日晚,在线听了敏捷大师 Evelyn Tian 关于敏捷捷径的在线分享。短短1个半小时,感觉收获颇多。大师 Evelyn 的讲解,由浅入深、栩栩如生,于细节处见真知,对于平时大家常问的问题、经常遇到的疑惑,有种豁然开朗、茅塞顿开的感觉。于是,又一次将目光锁定在了书架上的这本敏捷读物。《Scrum捷径:敏捷策略、工具与技巧》是由 Evelyn 和徐远来共同翻译,书中包含了众多敏捷大师的实践经验和思考成果,是众多大师智慧的结晶,真该拿来好好读一读。可惜自买来之后,除了偶尔随手翻阅之外,没怎么仔细阅读和思考过,实在浪费资源。

自从上了 Evelyn 的在线分享课,决定要认真、仔细地读一读这本书。俗话说,“不动笔墨不读书”。为了能认真阅读并不断反思,在阅读的过程中,写下了本文及后续读书笔记。在此系列文章中,我们将以以章节安排为顺序,以作者阐述的Scrum捷径为主线,逐一总结、评述并思考平日所见的敏捷实践问题,期间补充穿插大量Scrum的基础概念和知识。

本文为第一篇,从Scrum起步讲起,介绍最基本的概念和实践。

第一章 Scrum起步


踏上未知旅程的人,对第一步总是充满畏惧。每一个蹒跚起步的Scrum团队,都会经历从懵懂无知到虚心求教的过程。对于开始尝试Scrum的团队来说,有一个良好的开端,何其重要!第一章就从Scrum起步开始。

捷径1:一句话推销Scrum

Scrum是什么?曾有人问我,可我却一时语塞。怎么用最简洁的一句话,总结一下Scrum是什么?这里有必要浓墨重彩地介绍一下,Scrum到底是什么。

Scrum不是什么缩写词,而是借用自英式橄榄球的一个术语。它原本是指,在橄榄球运动中,双方各3个壮汉队员架着胳膊紧紧组成一个阵型,全力冲向对方区域,尽全力达到得分区的一项运动。Scrum敏捷开发的概念就诞生自这种紧密的、自组织的、相互合作的团队精神。最早引用该术语的是享有Scrum教父之称的竹内弘高和野中郁次郎1986年的那篇开创性的论文“新新产品开发游戏”(Takeuchi and Nonaka 1986)[1]。 下图就是最早的Scrum模型。

Scrum之父 Jeff Sutherland 和Ken Schwaber 与1987年开始在软件开发方面进行合作。1993年,Sutherland 读到了两位日本管理教授竹内弘高和野中郁次郎的上面那篇文章,文中介绍的方法的特点是整个流程都由一个高性能、跨功能的团队执行到底。他从这篇论文中获得了灵感,结合自己多年的经验,与Easel公司的 John Scumniotales 和 Jeff McKenna 一起开发了一套方法,并将自己创造的敏捷开发过程命名为 Scrum。两人在一个 IBM 项目合作,并做了更详尽的研究,Scrum诞生了。1995 年 OOPSLA 大会上他们第一次向世人介绍了Scrum [2]。这标志着 Scrum 敏捷开发的正式诞生。

我们都不是装备着全能银弹的狼人杀手,尽管Scrum背后的概念简单直接,但真正要成功使用 Scrum,却并不容易。引用 Scrum 联盟和敏捷联盟创始人之一 Mike Cohn 的话[3]:

Scrum 是一个让我们关注于在最短时间里交付高质量商业价值的敏捷框架。

让我们来看看 Scrum 到底能给我们带来什么具体好处。

Scrum团队

  • 任务切换减少,Sprint 第一。
  • 可持续的开发步伐,团队成员必须以一种可持续的步伐工作。
  • 不再有授权的独裁者,自组织团队有权自行决定工作该如何完成。
  • 不再有“我们和他们”之分,人人都得全力以赴,帮助团队完成共同的承诺。
  • 仆人式的领导者 Scrum Master 使得团队有了专职的保护伞和推土机,团队可以专注于开发最“赞”的软件。

项目发起人

  • 通过增量式交付可运行且高质量的软件功能,Scrum团队会在几周(或几天)为客户提供真正的商业价值并通过快速反馈周期而显著地减轻软件项目的风险。
  • 将透明性作为核心宗旨之一的经验主义流程,通过易于理解的“信息雷达”实现项目状况的可见、透明,使得意外状况更少。
  • 使用作为支柱的“检查和适应”,持续改进。
  • 变化是机遇而非危险、威胁。

好消息和不那么好的消息

  • 好消息是,Scrum 很容易,让人们心动也很容易。
  • 不那么好的消息是,虽然Scrum不难推,但要高效实施Scrum却完全是另外一回事。要想把团队培养得像“Scrum法拉利”那么炫酷,需要耐心开放的心态教训以及像本书一样方面实用的手册

捷径2:脆弱的敏捷

“伪敏捷”[4]的产生,就在于团队并没有真正了解并掌握Scrum的精髓并付诸实践。而在项目注定以失败告终之后,曾被Scrum伪实践坑过的高级项目干系人,很难在相信 Scrum 了。

Scrum是一个框架,而不是一个方法

好吧,那 Scrum 是什么?用一页纸的图来说明,Scrum就是如下图所示的敏捷开发框架[5],而不是一个方法

Scrum Framework
Scrum Framework

Scrum是一套实践框架,有一套清晰定义的游戏规则。要正确实施Scrum,必须严格遵循事先定义好的规则并在实践框架的指导下开展工作。Scrum没有包括多余的规则或实践,要让它发挥作用,不能偷工减料,必须全盘实践。

用Schwaber的话说,

Scrum就像下国际象棋,要么遵守它的游戏规则,要么不遵守。

 资质证书有用吗?

Scrum Master认证当然有帮助,但其作用也却决于具体的个人,认证本身可能并没有太大的意义。如果无法理解 Scrum的精髓,即使获得了认证证书,也成不了合格的Scrum Master。本质上,Scrum Master的素质比证书更为重要。

滥用敏捷宣言

提到敏捷,就不得不提《敏捷宣言》[6]。随着敏捷软件开发的兴起,从事不用敏捷开发方法实践研究的大牛们觉得有必要做些什么,以整合整个敏捷运动。于是,2001年2月11日到13日,17位软件开发领域的领军人物聚集在美国犹他州的滑雪胜地雪鸟(Snowbird)雪场。经过两天的讨论,“敏捷”(Agile)这个词为全体聚会者所接受,用以概括一套全新的软件开发价值观。这套价值观,通过一份简明扼要的《敏捷宣言》,传递给世界,宣告了敏捷开发运动的开始。《敏捷宣言》宣告了4条价值观和12条实践原则。

敏捷软件开发宣言

我们一直在实践中探寻更好的软件开发方法,

身体力行的同时也帮助他人。由此,我们建立了如下价值观:

个体与互动 高于 流程与工具

可工作的软件 高于 详尽的文档

客户合作 高于合同谈判

响应变化 高于 遵循计划

也就是说,尽管右项有其价值,我们更重视左项的价值。

敏捷软件的十二条原则

我们遵循以下原则:

我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意

欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化

经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。

业务人员和开发人员必须相互合作,项目中的每一天都不例外。

激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标

不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈

可工作的软件是进度的首要度量标准。

敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。

以简洁为本,它是极力减少不必要工作量的艺术。

最好的架构、需求和设计出自自组织团队

团队定期地反思如何能提高成效,并依此调整自身的举止表现。

好了,回到我们的讨论。总有人喜欢曲解Scrum的人,有时甚至还用《敏捷宣言》来为自己辩护。那些滥用敏捷宣言的人,要么没有看到最后一行,就是忘记了最后一行,再不就是故意忽略最后一行。

对敏捷宣言而言,左边的东西固然重要,但右边的东西基本上也是不可或缺的,即便是对他们的需求极其有限。

几个Scrum的误用模式

  • 测试Sprint。测试Sprint的两种表现,实质都还是瀑布开发。功能没有经过全面测试,是不完整、不可发布的、存在高风险。没有达到“完成标准”所规定的质量标准,就不能算完成。
  • 没完没了的Sprint 0。Sprint 0不是真正的Sprint,通常描述团队在开始真正的Sprint之前需要做的准备工作。这些准备工作不一定有时间表,也不需要具备实际Sprint的一些要素。有很多不恰当的工作被塞入Sprint 0,使得真正的Sprint被推迟开始。
  • 长短不一的Sprint。规则的Sprint持续期很重要。
  • 单独估算。要求资深开发人员单独估算分析每个任务是有问题的。专家和团队里做具体任务的人是有能力差异的。团队应以集体身份进行估算工作。
  • 依赖于规范。规范只是一个信息存放点或提醒而已。实际需求是通过团队同声唱响的美妙音符以及开发出真正能工作的软件来表现的。
  • 找错Scrum Master

牢记老人言

做事情,就应该一次到位“。

不应该改变Scrum的游戏规则,要么在Scrum的框架直到下工作,要么闭嘴别说自己在做Scrum。

捷径3:有创意的舒适

一个微笑,一声真诚的“你好”会使你感觉如沐春风,身处活泼而高效的框架下。一些微不足道的小事,比如早上一句友好的问候,足以影响整个团队的运作和沟通效果。“有创意的舒适”这条捷径,适用于所有团队环境,确保团队中每个人都觉得上班这件事儿有动力、有兴致,更重要。

可以用一些简单(而且便宜)的方法来保持团队成员的满意度。

向个人表示感谢

团队是有个人组成的,个人仍然追求自我价值的实现并期待有人认可自己的勤勉。

他人发自内心的赞赏会让人备受鼓舞。就算是最简单的赞赏,也是我们有安全感,让我们放手竭尽所能地干好本职工作。而且,他会使我们充满活力。

高度互动的办公环境

Scrum 密切依赖高度互动的办公环境来推动Scrum的开放价值观。下面几个基本要求有利于Scrum的实施。

  • 白板和足够多的墙面空间。
  • 足够好的采光。
  • 每个团队使用一体化桌面空间,只在不同团队之间才有隔断。
  • 宽敞的座位空间。
  • 每个团队供讨论用的小圆桌。
  • 配备投影仪和白板的大会议室。
  • 供团队成员静思的免打扰区。
  • 私人空间。
  • 与组织中的噪音源保持一定距离,免受干扰。

配备办公利器

给开发人员配备最新、最好的技术工具。通过提供合适的工具,不仅可以让开发人员开心,还能提高整体生产率。

身份认同

俗话说,“物以类聚,人以群分。” Scrum强烈鼓励团队成员坐在一起。鼓励Scrum团队取个队名,选个团队颜色,再用海报、徽标和横幅来装饰工作区。成型的团队通常都表现出强烈的身份认同感。

团队对产品的投入也很重要。可让开发人员加入前期的一些用户故事讨论。

开心的人

早晨一个温暖的问候,工作干得漂亮是同伴之间彼此真诚的鼓励和赞赏,属于某个独特团队的归属感,都足以让你乐得眉开眼笑。

总结与归类


万事开头难,本章三个捷径所讨论的战术、工具和技能,着眼于如何帮助你和组织启动Scrum。

一句话推销Scrum,就是一个电梯演讲。而脆弱的敏捷告诉我们如何区分框架和方法,以及一些误用Scrum的模式。有创意的舒适则想方设法提高了团队士气,营造一个温馨舒适的办公环境,确保协作与高效。

译者Evelyn Tian


Evelyn Tian

Evelyn Tian 是 Head of Lean & Agile Program at R&D North East Asia; Lean and Agile Head Coach for Asia Pacific at Ericsson。更多信息,参见Linkedin

图书信息


Scrum捷径:敏捷策略、工具与技巧

本书由清华大学出版社于2014 年9月出版。详情参见:

  • 清华大学出版社: http://www.tup.tsinghua.edu.cn/booksCenter/book_05759701.html
  • 互动出版物:http://product.china-pub.com/4327089
  • 京东商城:http://item.jd.com/11548820.html
  • 亚马逊:http://www.amazon.cn/%E5%9B%BE%E4%B9%A6/dp/B00N9UDSNO

参考文献


[1] Takeuchi, Nonaka, New New Product Development Game, 1986. https://hbr.org/product/new-new-product-development-game/an/86116-PDF-ENG

[2] Jeff Sutherland, Ken Schwaber, OOPSLA 1995年度大会上的论文。

[3] Mike Cohn, Succeeding with Agile: Software Development Using Scrum, 2007. http://www.mountaingoatsoftware.com/books/succeeding-with-agile-software-development-using-scrum

[4] 敏捷 VS 伪敏捷,http://www.51testing.com/html/82/166582-844998.html

[5] Jeff Sutherland, Ken Schwaber, Scrum Guide, http://www.scrumguides.org/

[6] 《敏捷宣言》,http://www.agilemanifesto.org/iso/zhchs/,2001