一、超越传统开发方式

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

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

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临界值的判断。

旧版

（摘要）

[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

背景

德国的敏捷专家 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

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

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

简介

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

继续阅读 More

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

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

敏捷性获得的因素

继续阅读 More

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

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

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

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

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

继续阅读 More

从“为什么”开始

敏捷的目标是增强组织响应变化的能力，主要通过目标对齐、信息透明一致、尽早反馈和调整、基本功提升、去中心化控制等来达到，因此绩效考核的原则要顺应这些敏捷思想，激发员工动力。我认为敏捷组织转型下，绩效考核（无论是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