简明Scrum入门教程 (Scrum Primer v2.0版)

一、超越传统开发方式

传统的开发方式由单一专业职能团体组成,反馈环延迟甚至薄弱,使用预言性质的计划和从分析到测试流程,这在变化无常的当今世界中成效甚微。由于直到开发后期才会有真正可工作的软件,这种方式会延迟反馈、学习,以及潜在投资回报。从而导致透明度不足、改进能力缺失、灵活度减少、商业和技术风险增加。

取而代之的是跨专业职能团队与迭代开发,这种方式也存在了几十年,但并不如传统模式那样被广为使用。

Scrum把已被证实的产品开发概念打包到简单的框架中,包括:真正的团队、跨职能团队、自管理团队、短迭代全周期反馈环、降低变动成本。这些概念提升了敏捷性与反馈、使提早实现投资回报成为可能并降低风险。

二、概述

Scrum是跨职能团队以迭代、增量的方式开发产品或项目的一种开发框架。它把开发组织成被称为Sprint的工作周期。这些迭代每个都不超过4周(最常见的是两周),并且无间歇地相继进行。 Sprint是受时间盒限制的,无论工作完成与否它们都会在特定日期结束,并且从不延长。通常由 Scrum团队来选定一个Sprint的时长,并且对于他们所有的Sprint都使用这一时长,直到这个团队能力提高,可以使用较短周期。在每个Sprint的初始,跨职能团队(大约7名成员)从排好优先级的列表中选择事项(客户需求)。团队对于在Sprint结尾他们相信自己可以交付哪些目标集合达成一致意见,这些交付应该是有形的并且能被真正“完成”的。在Sprint过程中不可以增加新事项,Scrum在下 一Sprint时才接受变化,当前这么短的一个Sprint周期里只注重于短小、清晰、相对固定的目标。团 队每天都进行简短会面来检验工作进程,并调整后续步骤以确保完成剩余工作。在Sprint结尾,团队与利益关系人一起回顾这个Sprint,并演示所构建的产品。团队成员从中获取可以结合到下一Sprint 中的反馈。Scrum强调在Sprint结尾产生真正“完成”了的可工作产品。在软件领域是指已经集成的、 完全测试过的、已经为最终用户生成文档的、潜在可交付的系统。其中的主要角色、工件和事件如 图表1所总结。

1 Scrum概述

Scrum中的一大主题就是“检视并调整”。因为开发工作不可避免地包含学习、创新和意外事件, Scrum强调进行小步骤开发,同时检验最终产品和当前实践的功效,然后调整产品目标与过程实践。 周而复始。

Read More

基于风险投入比的敏捷性(灵活适应)获得策略

大家都讲敏捷(Agile),这个词的不等于单纯的快,而是灵活适应,快速响应变化的意思。

那么,哪些因素可以提高组织敏捷性呢?这里提出一个基于风险ROI的模型,讲各种因素统一融合起来。

$$
ROI=\frac{Impact*p%}{Cost}
$$

(p%=概率或确定性,Impact=影响程度或收益程度,Cost=成本)

ROI高 <———> ROI临界值 <———> ROI低
全面标准化 增多可能性 (受心理风险偏好影响而得到补偿) 降低沉默成本 延迟决策
例:信息透明对齐、结构清晰、动作一致、防呆机制、排队 例:拆分、模块化、Plan B、冗余、备份、去中心化小团队 | 例:试错、尽早迭代、能力储备建设(仅长期效应) 例:极简、断舍离
(广度优先?) (深度优先?)

风险偏好心理补偿作用:对不确定和犯错的容忍

由于心理对变化和不确定性的恐惧,而影响到ROI临界值的判断。


旧版

有效的单元测试之一--代码坏味道(读书笔记精华带源码)

(摘要)


[TOC]

自动化测试的价值

开发者应该编写自动化测试,以便当发现回归问题时就使构建失败。而且,测试先行的编程风格已有大量的专业研究,使用自动化测试不仅是保护回归,而且是帮助设计,在编写代码之前就指出代码的期望行为,从而在验证实现之前先验证设计。

来认识一下小马。小马是著名的编程奇才,两年前刚毕业,然后加入了本地一家投行的IT部门,为银行开发用于在线自助服务的web应用程序。作为团队中最年轻的成员,起初他保持低调,集中精力学习银行的领域知识,熟悉“这里做事的方式”。

几个月后,小马注意到团队的工作很多都是返工:修复程序员的错误。他开始关注团队修复错误的类型,发现单元测试可以轻易地捕获到其中大多数。当他感觉到哪里存在特别容易出错的代码时,小马就对其编写单元测试。

测试帮助我们捕获错误。

一段时间以后,团队其他人也开始到处编写单元测试。Marcus已被测试感染 (test-infected) 了,他碰过的代码几乎都具有相当高的自动化测试覆盖率。除了在第一次时犯错,他们不会再花费时间修复过去的错误,待修复缺陷的总数在下降。测试开始清晰可见地影响着团队工作的质量。

自从小马编写第一个测试,已经过去近一年了。团队的测试覆盖率在近几个月快速提高,达到了98%的分支覆盖率。小马曾认为他们应该推动那个数字直到100%。但过去几周,他打定了主意——那些缺失的测试不会给他们带来更多价值,花费更多精力来编写测试不会带来额外的收益。许多没有测试覆盖的代码,只因所用的API要求实现某些接口,但小马的团队并未用到它们,那么何必测试那些空方法桩呢?

100%测试覆盖率不是目标

100%的覆盖率并不能够确保没有缺陷——它只能保证你所有的代码都执行了,不论程序的行为是否满足要求。与其追求代码覆盖率,不如将重点关注在确保写出有意义的测试。

后来,高级软件架构师老赛加入了自助服务团队,并快速地成为了低级成员的导师,包括小马在内。小马习惯于先写代码,在提交到版本控制系统之前再补充单元测试。但老赛的风格是先写一个会失败(很明显是这样)的测试,再写足够使测试通过的代码,然后写另一个失败的测试。他重复这个循环直到完成任务。

与老赛共事,小马意识到自己的编程风格开始转变。他的对象结构不同了,代码看起来稍微不同了,只是因为他开始从调用者的角度来审视代码的设计和行为了。

测试帮助我们针对实际使用来塑造设计。

想到这些,小马觉得好像明白了一些道理。当他试图用语言表达出他的编程风格是如何改变的,以及收到了哪些效果时,小马明白了他写的测试不仅仅是质量保证的工具,或是对错误及回归的保护。测试作为一种设计代码的方式,提供了具体的目的。编写使失败测试通过的代码比以前的方式简单多了,而且该做的也都做了。

通过明确地指出所需的行为,测试帮助我们避免镀金。

主人公小马的经历正如许多爱好测试的编程人员一样,在不断地认识和理解测试。我们经常因为相信单元测试有助于避免尴尬、耗时的错误而开始编写它们。随后我们会学到,将测试作为安全网只是等式的一部分,而另一部分——或许是更大部分——其好处是我们将测试表达为代码的思考过程。

大多数人同意说编写一些测试是不费脑筋的。但随着我们接近完全的代码覆盖率,我们不那么确定了——我们差不多已经为一切都编写了测试,而剩下的没有测试的代码是微不足道,几乎不会破坏。这就是某些人所谓的收益递减。因此,

编写测试的最大价值不在于结果,而在于编写过程中的学习。

(略,请阅读正版原书)

何为优秀与代码坏味道

可读性、可维护性、可信赖性…

单元测试代码的可读性

原始类型断言

断言应该表达某种假设或意图。它们应该声明代码的行为。基本断言的问题在于它们缺乏意义,因为断言的基本原理和意图隐藏在看上去无意义的单词和数字背后,造成它们难以理解,并且难以验证断言的正确性。

下面例子展示了一个**全局正则搜索(grep)**程序的测试。grep程序其实就是逐行处理某种文本输入,在处理时可以包括或排除掉含有特定子串或模式的文本行。测试应当是你的对象所提供功能的具体例子,那么我们来看一看这个测试是否说清楚了grep程序该做的事情。但愿这个测试没有受到原始类型断言的折磨!

1
2
3
4
5
6
7
@Test
public void outputHasLineNumbers() {
String content = "1st match on #1\nand\n2nd match on #3";
String out = grep.grep("match", "test.txt", content);
assertTrue(out.indexOf("test.txt:1 1st match") != -1);
assertTrue(out.indexOf("test.txt:3 2nd match") != -1);
}

这个测试在干什么?首先,我们定义了文本字符串content来表示一段输入,然后调用grep程序,然后对grep结果输出中的某些东西进行断言。这些东西就是问题所在。断言的目标并不清楚,因为断言过于基本——它与测试的其他部分说着不同的语言。

具体来说,我们在这个断言中是要计算输出结果中的另一个文本字符串的索引,并将其与-1进行比较;如果索引为-1,那么测试失败。测试的名字叫做outputHasLineNumbers,显然,对于在代码中grep()的具体调用,输出结果应当包含正在进行逐行查找的文件名,后面加上行号。

不幸的是,我们不得不经过这个思考过程才能理解为什么我们要计算索引,为什么查找test.txt:1而不是其它东西,为什么与-1进行比较,当索引是-1或不是-1时测试是否会失败?这无需火箭科学就能找到答案,但却是我们大脑的不必要的认知工作。

Read More

企业组织购买敏捷教练的价值是什么

你可能没有意识到,但是当你购买敏捷教练(特别是企业级教练)时,你所购买的是他们带来自己方式、他们的理智、他们的自制、他们的意义建构、以及他们的人性。正是由于很少人能带来那些东西,所以你值得付出—————金钱,以及(暂时性)的迷失方向和一定程度的不舒适,而这些将最终转化为舒适。你购买的是种子,这些种子会为你的组织赋予人性。

“You may not realize this, but when you pay an agile coach (especially an enterprise coach), you’re paying for the way they bring themselves, their consciousness, their self-mastery, their sense-making, and their humanity to your organization. And because it is so rare for people to bring these things, it’s going to cost you - both in terms of money, and in terms of (temporary) disorientation and a certain discomfort, which will eventually turn to comfort. You’re paying for the seed to humanize your organization.” - Posted on LinkedIn by Oluf Nissen

全球敏捷业界呼吁从 SAFe 中删除对 Scrum 的引用!

背景

德国的敏捷专家 Den Sunny 在2020年发起了一个全球性的签名运动,网站 http://remove-scrum-from-safe.tilda.ws/

我们喜欢 Scrum。我们反对 SAFe(规模化敏捷框架)创建和推广的对 Scrum 的误解

理由主要在在于规模化敏捷SAFe官网对Scrum、Scrum Master等概念的描述与Jeff Sutherland 和 Ken Schwaber 制定的《Scrum指南》有多处出入,造成误解和误用。

…像 SAFe 这样的框架 … 与 Scrum 指南不一致,并且编纂了可能削弱团队多年的功能障碍。

– 杰夫·萨瑟兰(Jeff Sutherland), Co-creator of Scrum

呼吁和诉求

我们呼吁 SAFe 的所有者尊重个人和组织,停止承诺可以在 SAFe 中使用 Scrum 和 Scrum Master 角色!

许多组织相应地实施规模化敏捷 SAFe,并具有各自的角色和流程。由于当前 SAFe 描述中的陈述,他们可以合理地期望能够在此结构中使用 Scrum。相反,SAFe 角色和流程迫使他们使用****大量 Scrum 反模式并造成严重的功能障碍

然而,这些组织认为这正是 Scrum 框架,他们在此基础上了解 Scrum。它引入了对 Scrum完全错误的理解,并剥夺了组织实现目标的机会

此外,对于决定在 SAFe 中培养 Scrum Master 技能的人来说,这会导致重大的职业损失. 他们学习了错误的理论并采取了功能失调的行为。之后,他们很难理解真正的区别,以便能够有效地帮助组织正确采用 Scrum。

Read More

银河竞逐RFTG第一扩展:风雨欲来 桌游中文规则

(原文由博主mebusw于2009年发表于现已不在的桌游论坛BGC。”Race For The Galaxy” 策略类卡片桌游是一种很好地团建方式,节奏快,时间段,易上手,寓教于乐,特别适合于敏捷团队,笔者于2007年开始尝试这种方式带团队,收到很好的效果。今日偶然翻到这篇旧文,忆往昔DIY的日子,唏嘘不已。)


随着空间跃迁知识的传播,一个古代种族开始蠢蠢欲动,而另一个种族需要逃离行将灭亡的恒星。银河帝国的力量不断增长,导致了更加严重的叛乱和佣兵的出现。在这个面临战争的银河系里,你能建立起最为繁荣强大的国家么?

简介

本扩展里加入了新的起始星球和新的游戏卡牌,为第五玩家准备的行动卡牌和VP筹码,以及银河竞逐的目标卡。此外这里还提供了一个独立的单人游戏,一种轮抽玩法以及一些空白卡牌,以便玩家自己设计星球和开发设施牌。

Read More

敏捷教练Scrum Master要做些啥?像甘道夫一样。

gandalf

本文是之前为Scrum Gathering 2013敏捷大会准备话题时总结的一些想法,又在台北RSG2022大会进行了重制。更多是从内部做ScrumMaster和敏捷教练时的体会。重点是:对齐目标 收服人心,用魔戒甘道夫作比喻,借假修真地阐述敏捷教练打造敏捷团队的秘诀,最主要的能力就是”填坑”(Fill the Gap)。

点击观看幻灯片演讲实录:

对齐目标 收服人心——魔戒甘道夫用“血泪”填坑 | 打造敏捷团队的秘诀 敏捷教练借假修真

(关于Scrum Master与Agile Coach的区别,笔者认为不大,SM也不只是懂Scrum就够了。其实可以从团队级和组织级来区别工作范围,而不是纠结名字)

SM是新的角色,很多时候定位不是那么清楚。The Scrum Master is primarily responsible for “How” - using Scrum the right way.

Read More

敏捷性(灵活适应性)的来源

大家都讲敏捷(Agile),这个词的不等于单纯的快,而是灵活适应,快速响应变化的意思。

那么,哪些因素可以提高敏捷性呢?这里不讲各种方法论实践,而是试图从“法”的角度来列举一些来源。

敏捷性获得的因素

Read More

在敏捷回顾会议中运用ORID引导技术

作为一个合格的敏捷教练,既要理解领域知识,又要懂得过程的重要性,是各种综合能力的体现。

[

对于《敏捷回顾》这本书,大家一定不陌生了,很多敏捷教练都会到其中的5步法来引导回顾会议。

最近学习了杰拉德老师讲的ToP的引导技术,发现ORID可以作为一种新的引导方式,而且问题的设计更加结构化。那么究竟如何来设计这个过程呢?

Read More

Scrum检查清单中文版

Henrik Kniberg版的Scrum检查清单,是一个简单的讨论工具,可以帮助你启动Scrum,或评估当前的Scrum实施状况,已经由@申导 和 @hanzhi窦  于2013年联手翻译成简体中文版,点击这里下载(Download)

这是什么? 给谁用?

Scrum检查清单是一个简单的工具,帮助你启动Scrum,或评估 当前的Scrum实施状况。

注意这不是规则。它们是指导方针。两个人的团队可能决定不 举行每日站会,因为他们整天结对编程而无需一个单独的会议 去同步。好吧。他们故意地略过了一项Scrum实践,但确保了 Scrum实践的根本目的以另一种形式得到了满足。这是最重要 的!

如果你在实施Scrum,在回顾会议中让团队来逐条检查这份清 单可能会很有意思。作为一个讨论工具,而不是评估工具。

我该如何使用?

  • 小周: “这次回顾会议,我带来一个有用的小清单。有哪些 事情我们没做到吗?”
  • 小丽: “嗯,咱们来看看。哦,我们肯定漏掉了DoD,我们也 没有度量速率。”
  • 小周: “哦,’DoD’列在’Scrum核心’之内,看起来非常重要。’ 速率’列在’推荐但不完全是必须的’之内,那就让我们等一下, 先开始核心的事情。”
  • 小丽: “看,我们还漏掉了’每个迭代(4周以内)交付测试过且 可工作的软件’。它列在’基本项目’之内!有道理,因为市场 部总是在抱怨这件事!”
  • 小周: “或许’DoD’的概念能帮助我们在每个迭代都完成一小 部分,并且更频繁地交付?”
  • 小丽: “好主意,让我们试一试。”

什么情况下不该使用?

  • 大老板: “好了团队,该看看我们的Scrum实施得怎么样了? 请填一下这份检查清单。”
  • 小周: “老板,我很高兴向你汇报我们所有事情都在做。好 吧,除了迭代燃尽图这一项。”
  • 大老板: “烂,烂团队!这上面说你们应该做那些…呃…迭代 燃尽什么的!我想要它们!”
  • 小丽: “但我们运行两周长度的迭代,而且几乎总能交付我 们所承诺的,客户也挺满意。迭代燃尽图目前不会增加什么价值。”
  • 大老板: “可这上面说你们应该做,别让我再逮到你们耍花招,否则我会找些Scrum警察过来。”

这是官方的检查清单吗?

不是。它反映了我个人对Scrum重要事物的主观看法。我花了 好几年来帮助许多公司启动Scrum,并会见了数百位实践者、 培训师和教练;我发现如果使用得当,像这样的清单是有益的