简明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强调进行小步骤开发,同时检验最终产品和当前实践的功效,然后调整产品目标与过程实践。 周而复始。

继续阅读 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时测试是否会失败?这无需火箭科学就能找到答案,但却是我们大脑的不必要的认知工作。

继续阅读 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。

继续阅读 More

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

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


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

简介

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

继续阅读 More

敏捷整洁之道--Uncle Bob正本清源

如果你知道Bob大叔,如果你对他的整洁之道有所耳闻,你一定能想象这场直播具有的非凡意义。从2001年敏捷宣言的诞生,到2009年《代码整洁之道》的面世,再到之后的《代码整洁之道:程序员的职业素养》、《整洁结构之道》,今年,刚好整整20年,Bob大叔创作的《敏捷整洁之道:回归本源》构成了“整洁三部曲”,其背后的思想和历程值得每一位希望写出整洁代码的程序员挖掘。

鲍勃大叔《Clean Agile》翻译版《敏捷整洁之道》
您还没有拥有吗?扫描上方二维码
只需一张毛爷爷即可获得由敏捷大咖「申健」「熊节」
亲笔签名的『限量版』图书

另外,还有一点难得的是,这场直播请到的嘉宾正是“整洁三部曲”的译者,时隔十年,齐聚一起,为你解码“Bob大叔”关于整洁代码的核心理念和价值。

观点提要:申健老师以“Bob大叔对敏捷清理门户”这样极具话题性的主题,展开讲解了人们对敏捷的误解,批判了大型伪敏捷,最后给出了敏捷在企业落地的建议。

(这篇回放稿总共接近4万字,在这里小编尽量保证不曲解大咖们的原意,将其主要观点和精华浓缩出来,呈现给大家,希望大家有所收获。)

继续阅读 More

敏捷绩效考核与OKR

从“为什么”开始

敏捷的目标是增强组织响应变化的能力,主要通过目标对齐、信息透明一致、尽早反馈和调整、基本功提升、去中心化控制等来达到,因此绩效考核的原则要顺应这些敏捷思想,激发员工动力。我认为敏捷组织转型下,绩效考核(无论是KPI还是OKR)都应关注以下原则:

  1. 更多关注团队表现而非个体表现
  2. 从被动指标分解到自组织的目标管理
  3. 配合短迭代研发周期,缩短考核周期
  4. 从奖金和排名转移到学习与成长

一个可参考的敏捷团队绩效模型:

某国内企业用OKR绩效牵引转型,兼顾成功与成长

  • 个人绩效构成(百分制):
    • 团队(业务)目标实现率 30分
    • 关键举措/行动完成情况 40分
    • 团队协同情况 30分
      • 推进他人帮助自己完成关键工作 10分
      • 帮助他人完成关键举措 10分
      • 部门/团队建设参与和贡献 10分
    • 加分项
      • 或政府事迹表彰 5-20分
      • 关键工作以外的突出贡献 5-20分
    • 其他赏罚调整 5-20分
  • 个人绩效构成(百分制):
    • 团队(业务)目标实现率 30分
    • 关键举措/行动完成情况 40分
    • 团队协同情况 30分
      • 推进他人帮助自己完成关键工作 10分
      • 帮助他人完成关键举措 10分
      • 部门/团队建设参与和贡献 10分
    • 加分项
      • 或政府事迹表彰 5-20分
      • 关键工作以外的突出贡献 5-20分
    • 其他赏罚调整 5-20分

其他一些原则

根据《Scrum Primer》 v0.5,作者根据Yahoo在2008年前后使用Scrum后调研(以1-5打分的方式进行),当时发现主要绩效提升表现在以下方面: 生产效率,团队精神,适应性,责任性,协作能力。那么敏捷转型的整体绩效也应该从以上方面进行考虑作为文化导向,结合我从2007年开始在诺基亚西门子通信的敏捷经历,建议做法如下

  • 减少个人绩效的权重,增加组织或团队层面的权重
  • 绩效打分与奖金分配不完全挂钩
  • 依据360度收集的信息、评价和数据
  • 考虑团队工作内容、需求变化和复杂程度,可结合OKR与KPI的使用
  • 敏捷Scrum中的短迭代计划——由PO指出迭代目标,团队共创出要达成的任务——实际就是一个执行层面的短期OKR。而产品、项目级别的大目标,可认为是战略层面的长期OKR。
  • 设定团队之间互相支持的指标,作为团队绩效评分(Team Performance Evaluation),例如帮助其他团队修Bug,为其他团队做分享都可以互相送分数。

大型规模化敏捷,请和你的大老师远离敏捷

随着敏捷开发的流行,近年来各种大型、规模化敏捷框架、敏捷组织设计、业务敏捷也称为大老师们口中的热词,也带来了很多讨论甚至质疑。本文根据笔者Jacky Shen在2019上海和北京敏捷之旅发表演讲所整理。

笔者认为,敏捷的核心是“小而美”,追求“大而全”非常危险而且也达不到敏捷的目标,即“早+准”,在不确定环境中快速反馈来命中商业愿景,提升竞争力。

本文分为以下三个部分:

  • 从敏捷到”大型敏捷”
  • 骨感现实中的复杂性
  • 变革管理及一些原则

一、从敏捷到规模化”大型敏捷”

1.1 回顾敏捷Agile这个词

2001年17位软件行业先驱在美国雪鸟镇聚会,石破天惊地提出了《敏捷开发宣言》,当时的主要关注点包括:

  • 追求响应力与灵活性,即适应性over预测性 (不是单纯地求快,也不是要压榨产能)
  • 以人为本(一群“艺术”家),而非用流程来管控(流水线工人)
  • 提升客户和团队满意度

然而现实中,人们对”敏捷”还有其他期望:

  • “抄竞品抄得快” — (敏捷不见得能帮你少花时间,只让你知道该干嘛)
  • “明年少招点人” — (敏捷不见得提高产能,只是增加了可管理性)
  • “按时上线” — (敏捷不见得确保时间,只是摧毁不切实际的幻想)

笔者认为,我们平时书本和课程谈的各种敏捷方法论、框架实践集,都在描述一种“理想的未来状态”,但是很难说如何在特定组织中能够达到那种状态,所以与敏捷转型(变革管理)是两码事。

继续阅读 More