在家上学 Homeschooling 由于新冠疫情我们都在家，你妈妈和我都同意最好我们在家上学。 我想学习造小汽车。我想知道为什么太阳那么炎热。 很棒的建议，但我们先从一些更好的内容开始…… 今天，你们将学习验收标准（Acceptance Criteria）和完成的定义（Definition of Done）之间的区别。 作者评论 如果敏捷、快速试错、精益创业和PDCA循环等主题背后的思想观念（应该基于现代发展的概念）实际上是孩子们在学校学到的东西，那将会有多棒？ 因此，如果您因COVID-19疫情而被迫在家工作，并可以自由安排自己的时间，那么现在是时候让孩子们学习一些实用的知识了！ 除非他们整天都在远程学习，否则现在您就有机会向年轻人灌输您认为他们应该学习的课程。 因此，抓住机会，告诉他们验收标准（AC）是完成的定义（DoD）的一个子集，或者现场（Gemba）的重要性。 如果您需要，我们甚至可以考虑创建供儿童学习敏捷的材料。 译者评论 家庭教育如何应用敏捷，已经有越来越多的伙伴在进行尝试了。 你有尝试吗？ 这里有一个TED视频讲解敏捷家庭，或许对你有启发。 读者评论 对于今天的漫画，你有什么想说的呢？ 参与讨论，请扫码加入”敏捷家”微信群 原文链接

我要提问 这是一个系列博客文章，回答敏捷中常见问题。查看所有常见问题。今天回答的问题是： Scrum Master是否需要懂技术？ Bob的观点 Scrum Master需要懂技术，而且是一定要懂技术。不懂技术的Scrum Master很难成为一名优秀的Scrum Master。如果你想成为敏捷教练，或许不懂技术还行得通，但是Scrum Master不懂技术是不行的。具体还可以参考之前的博客文章，Scrum Master和敏捷教练之间的区别。 原因1： 不懂技术的Scrum Master很难融入团队。 原因2： 不懂技术的Scrum Master很难帮助团队在开发（工程）实践方面发展。 原因3： 不懂技术的Scrum Master很难帮助团队发现技术的潜在风险或障碍。 不懂技术的Scrum Master很难融入团队 开发团队成员之间沟通的时候，多半会使用技术术语，如代码仓库、技术债、重构、vs code等等。如果听不懂团队说的是什么，就很难了解问题或背景，从而很难融入到团队中去。所以作为Scrum Master，至少需要了解： 常用技术术语 软件开发生命周期 常用的技术工具，等等 不需要Scrum Master成为代码管理的专家、重构专家，但一定要知道这是什么。 不懂技术的Scrum Master很难帮助团队在开发（工程）实践方面发展 如果一名Scrum Master不懂技术，那么他也很难了解或掌握软件开发行业的最新工程实践（开发实践）。那么作为Scrum Master，如何帮助开发团队认识到当下行业有哪些最新的提高效率的开发工具、工作实践呢。 Scrum Master的关注度不仅仅是团队、产品负责人，还需要关注组织和开发实践。参考Scrum Master和敏捷教练之间的区别中Scrum Master关注度一节。 不懂技术的Scrum Master很难帮助团队发现技术的潜在风险或障碍 最后，如果Scrum Master不懂技术的话，他也很难有技术的感觉，从而很难敏感地发现团队内的潜在技术风险或障碍（不一定是真的风险，但有时候一句话就可以点醒团队）。 综上所述，作为一名Scrum Master一定需要懂技术，而且需要是懂大量的技术（不一定需要很深入）。 职场泥石流的分享 以下来自职场泥石流分享的总结，感谢小新同学（谢晓强）的努力。 之前在群里参与讨论过Scrum master与技术间关系的一些问题，从群友那里得到不少启发，其后有机会能在前两天连线Ethan黄老师，直接就这个问题展开了一些辩论，又聆听了黄老师对一些相关问题的分析与解答，让我对问题的认识又深了一些，这篇文字是对之前视频的回顾总结，加上一些我自己的思考。如果我对于黄老师的观点有引用错误的地方，或者大家认为我的观点有何不对之处，欢迎批评指正。 视频的最开始其实是关于SM懂技术是利大于弊还是弊大于利的一场小型辩论，不过我想先不记录这个，先记录黄老师后面回答的几个问题，然后再回到最开始的这场辩论，这样理解起来可能会更好。 问：没有技术背景的SM感觉无法融入团队怎么办？ 针对这个问题，黄老师首先指出这种情况非常普遍，感到fear也是正常的，他自己也有过这样的经历。面对这种情况： 第一个是要想到每个人的知识面都是有范畴的，要扬长避短，同时你现在不会技术不代表以后不会，这种fear也是你学习的动力； 第二个是要弄明白，这个fear是不是有可能是不必要的，因为在这个行业里或技术里你没有积累，并不妨碍你成为一名好的SM或教练，你可以通过学习掌握软技巧，如有效倾听与强力提问、还有学习的能力，来发挥自己价值，融入团队。 问：技术能力非常强的人，他来做SM会遇到哪些问题？ 针对这个问题，黄老师回答问题在于他可能忍不住涉入到技术问题中去，反而可能忽视了本来的职责。解决的办法就是要管住手管住嘴。但现实中当你越界时你自己往往是没有知觉的，所以就还有一些实践小技巧，比如你们团队间可以协商出某种方式来提醒你越界的事，如订做一顶大牛帽子，只有当你带上这顶帽子时才能扮演技术专家的角色，如果你不自觉的扮演了技术专家的角色的话，就要予以一些处罚，比如请喝咖啡等等。 总结一下，就是你作为一名SM，如果你很懂技术，你不是不能涉入到技术中去，只是你要有一种边界感，知道什么时候你是在扮演技术专家的角色，什么时候又该回到SM的角色。 记录完这两个问题黄老师的回答后，我想可以回到最开始的小辩论上来了。 “Scrum Master懂技术是利大于弊还是弊大于利” 虽然黄老师是站的正方，但我觉得黄老师其实心里还是向着反方的，哈哈。言归正传，如果做个比喻，我认为这个辩题，其实是类似于贝壳的东西，贝壳本身并不珍贵，珍贵的是贝壳辛苦酝酿出的珍珠，而辩题酝酿出的珍珠，其实就是它延伸出的一系列问题。

作者：曹天宇 Scrum指南读后感 本人从事传统汽车行业，敏捷经验或scrum经验为0，甚至没有软件开发经验，参加本次培训目的是对敏捷开发有个入门的了解，并结合传统汽车行业的开发流程做一定的思考，因为现在汽车上也会涉及到越来越多的软件。 以下是看完Scrum指南后自己归纳的重点（理解还是更多基于理论层面）： Scrum是一个框架 ，用于开发 交付 持续支持复杂产品的，在此框架中人们可以解决复杂的自适应难题，同时也能高效并创造性地交付最高价值的产品。 Scrum 框架由Scrum 团队以及与之相关的角色、事件、工件和规则组成 Scrum的应用：最初是为了管理和开发产品而开发的 Scrum 的精髓在于小团队 Scrum 基于经验过程控制理论 Scrum 采纳一种迭代、增量式的方法来优化对未来的预测和控制风险 三大支柱：透明，检视，适应 4个正式事件： Sprint计划会议 每日Scrum站会 Sprint评审会议(review) Sprint回顾会议(retrospective) Scrum价值观：承诺commitment，勇气courage，专注focus，开放openness，尊重respect Scrum团队：产品负责人 + Scrum master + 开发团队， 跨职能的自组织团队 产品负责人：将开发团队开发的产品价值最大化，产品负责人是负责管理产品待办列表的唯一负责人 产品待办列表的管理包括： 清晰地表述产品待办列表项 对产品待办列表项进行排序，使其最好地实现目标和使命 优化开发团队所执行工作的价值 确保产品待办列表对所有人是可见、透明和清晰的，同时显示 Scrum 团队下一步要做的工作 确保开发团队对产品待办列表项有足够深的了解。 为保证产品负责人的工作取得成功，组织中的所有人员都必须尊重他/她的决定 开发团队：负责在每个 Sprint 结束时交付潜在可发布并且“完成”的产品增量。在 Sprint 评审会议上，一个“完成”增量是必需的。只有开发团队成员才能创建增量。开发团队由组织组建并得到授权，团队自己组织和管理他们的工作， 规模3-9人 特点： 自组织的 跨职能的 不认可开发团队成员的任何头衔，他们都叫开发人员 不认可开发团队中所谓的“子团队“ 开发团队中的每个成员也许有特长和专注的领域，但是责任属于整个开发团队 Scrum Master: 负责根据 Scrum 指南中的定义来促进和支持 Scrum， 服务型领导 服务于产品负责人： 尽可能确保 Scrum 团队中的每个人都能理解目标、范围和产品域； 找到有效管理产品待办列表的技巧； 帮助 Scrum 团队理解为何需要清晰且简明的产品待办列表项； 理解在经验主义的环境中的产品规划； 确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值； 理解并实践敏捷性 按要求或需要引导 Scrum 事件。 服务于开发团队：

我要提问 这是一个系列博客文章，回答敏捷中常见问题。查看所有常见问题。今天回答的问题是： 什么是Scrum Master，什么是敏捷教练，他们之间有什么差别？ 如何转型成为敏捷教练？ 本文将重点描述敏捷教练和 Scrum Master 这两个角色，以及他们之间的关系和对比。 Scrum Master Scrum Master 是一个全新的角色，是在《Scrum指南》中定义的。这个角色（Scrum Master）不是团队领导者，也不是项目经理，更不是经理。请不要把 Scrum Master 与现有的团队（或组织中）的角色进行映射。因为你找不到这种映射。 Scrum Master 在组织中教 Scrum，并可以帮助团队进行 Scrum 落地实践。Scrum Master，顾名思义，精通 Scrum， 对于 Scrum 有深刻理解，能够指导团队成员更好地产出更高价值的产品。 Scrum Master 是反馈环中重要的角色（另外一个反馈环是 Scrum 中的事件），他是一个支持角色，更像是团队的一面镜子，帮助团队识别出现在的问题，从而能够走向“完美”的目标。 想要对 Scrum Master 这个角色有更加深入的学习，可以看一下我讲的 Certified Scrum Master (CSM) 课程，这个课程是 Scrum 联盟的认证课程，可以为你的职业带来突破。 Scrum Master 角色的描述 – 以下摘自《Scrum指南》 什么是Scrum Master Scrum Master 负责根据 Scrum 指南中的定义来促进和支持 Scrum。Scrum Master 通过帮助每个人理解 Scrum 理论、实践、规则和价值来做到这一点。 Scrum Master 对 Scrum 团队而言，他/她是一位服务型领导。Scrum Master 帮助 Scrum 团队之外的人了解他/她如何与 Scrum 团队交互是有益的，通过改变他/她们与 Scrum 团队的互动方式来最大化 Scrum 团队所创造的价值。

敏捷中的模式与反模式 本文的内容来自于7月10日我在“艾威网校”的一次分享。 开始先简单自我介绍如下：（欢迎扫码获取ppt） 本文主要分为四个部分： 什么是模式语言及反模式语言 敏捷中的模式语言（Scrum Patterns） 敏捷中的反模式语言 回归本质 什么是模式语言和反模式语言 模式（英语：Pattern，源自法语：patron），在物体或事件上，产生的一种规律变化与自我重复的样式之过程。 在模式之中，某些固定的元素不断以可预测的方式周期性重现。最基本而常见的模式，称为密铺，具备重复性以及周期性两大特征。找寻出固定模式是人类基本的认知功能之一。 – 摘自维基百科 在1977年的《A Pattern Language》一书中，Christopher Alexander提出了模式语言的概念。在豆瓣中的图书介绍如下： 克里斯托弗·亚力山大是美国杰出的建筑理论家。由他领衔撰写的《建筑模式语言》一出版就受到建筑界的广泛重视和高度赞誉，并对建筑业产生了深远的影响。 《建筑模式语言》别出心裁且有根有据地描述了城镇、邻里、住宅、花园和房间等共253个模式，提供了一幅幅设计、规划、施工等方面的崭新蓝图，构思新奇，妙想迭出，不同流俗。 作者写道：“我们深信无疑，本语言要比一本手册、或一位教师、或另一种可能的模式语言略胜一筹。这里的许多模式看来在今天和以后的500年间将成为人性的一部分，成为富有人情味的行动的一部分。”诚如美国《建筑设计》一则评论所说：这也许是20世纪出版的关于建筑设计的最重要的一本书了。 这本书的生命力在于“以人为本”。它是此书的主题思想，像一条鲜艳的红线贯穿始终。各模式的字里行间洋溢着浓浓的人情味和对人的无微不至的关爱，如保护生态环境，如何绿化美化城镇和住宅，反对建筑风格的千篇一律，鼓励人际交往，强调人、社会和自然环境三者的和谐统一，等等。 所以不论是在敏捷转型中，还是软件开发中，亦或是建筑行业或我们身边，都会存在着许许多多的模式。而本文就是要和大家一起来探索一些敏捷转型中的模式（以及反模式）。其中的一些模式摘自于《A Scrum Book》一书，书中提供了94中Scrum的模式，下面我会结合实际工作经验介绍其中的4种。 反模式 反模式（anti-pattern）也是一种模式，最早是在软件工程中提出的，反模式指的是在实践中经常出现但又低效或是有待优化的设计模式，是用来解决问题的带有共同性的不良方法。按照《反模式》一书的作者的说法，可以用至少两个关键因素来把反模式和不良习惯、错误的实践或糟糕的想法区分开来： 行动、过程和结构中的一些重复出现的乍一看是有益的，但最终得不偿失的模式 在实践中证明且可重复的清晰记录的重构方案 – 演绎自维基百科 敏捷中的模式语言 下文主要描述四种敏捷中的模式语言：（分为两类 - 产品组织和价值流） 回顾会（产品组织） 小吃神社（产品组织） 障碍清单（价值流） Scrum板（价值流） 回顾会 回顾会是敏捷中至关重要的一个会议（也是敏捷的本质，在最后的总结中我会再次提出这个重点）。如下图，如果忙于交付而忽视了改进，则从长期来看一定是得不偿失。 对于团队而言，回顾会就是每个迭代结束前团队在一起反思团队中关于人、关系、过程和工具的情况，根据上述情况制定具体的改进计划。上图中采用的方法是： Start, Stop, Continue 开始尝试新的方法 停止无效或低效的方法（或工具） 继续使用良好的工具（或方法） 另外对于个人而言，也是需要不断的回顾总结与反思。这里是我个人的每周总结。 小吃神社 团队都很难独立存在的（尤其在大公司中），于是日常工作中团队（或团队成员）总是会受到不同人的干扰与打断。被打断后要再重新开始刚才的工作就需要思路能接上，这是一个很难的事情。所以对于团队需要有一个缓冲地带，就是下图中的“小吃神社”。（这个名字来自于日语） 注：小吃神社不是茶水间，这个区域离团队很近，但不至于影响到团队的其他人工作。 这个缓冲地带对于团队来讲非常重要，任何问题都不要直接去打断团队的节奏（除非是生产系统挂了）。而是大家可以在小吃神社这里进行讨论。这个模式的前提是，团队太容易也太频繁被打断了。 障碍清单 工作中每个人都会碰到不同的问题、障碍。敏捷中经常也会提倡在每日站会上提出遇到的问题障碍。然而仅仅提出并不是很好的做法，更好的做法是可以创建一个障碍清单，用于收集并排序团队中的障碍。 这个模式的好处是： 可视化团队所有的障碍问题 排序（根据风险评估）后，根据顺序来一次解决障碍 每个障碍可以注明跟进人 Scrum板 Scrum板如下图，是一个白板，用于可视化团队在迭代内的进度。团队每日站会就围在Scrum板的前面，每个人回答三个问题。

译者：Fish 审校：Bob 原文链接 设计模式是对重复出现的问题的解决方案的描述，概述了解决挑战所必需的要素，且不提示读者以特定方式解决该问题。 不幸的是，我们还是会经常看到无效行为的反复出现，这些被称为反模式。 以下是对最常见的一种反模式的探讨：微观管理。 反模式[ 1 ]名称：微观管理 别名：过度控制；监督 规模：单团队或多团队 相关反模式：冲刺燃尽图，速度很重要，时间跟踪，个人激励 潜在解决方案： 服务型领导或仆人型领导 冲刺黑匣子 关注成效而不是产出 领导层专注于战略和创造有效的工作环境 为什么会发生微观管理 刚接触Scrum的人通常很难把握有效管理者、ScrumMaster和产品负责人之间的控制界限。这是一个至关重要的考虑因素，因为敏捷的核心是试图去帮助一群人成长为一个有韧性，高效能的团队。这些角色不仅能够促进这种成长，也能阻碍这种成长。允许团队自组织进而蓬勃发展是一个关键因素。 无论您是ScrumMaster还是经理，一旦发现某事可能要出问题，就会想要提供帮助。这可以理解：您是出于好意。但您没意识到这是正在进行微观管理；您觉得这只是给些建议，提供些帮助、点子，使其避免风险。然而，微管理有多种形式：管理层给出建议或直接向团队成员下达命令；利益干系人指导产品负责人用户故事；经理们坚持以某种方式做事，因为他们以前已经做过很多次；还有很多……这些行为都有一个共同的特征：那些并不直接做事的人在试图影响真正做事的人该如何做事。 微观管理在Scrum环境中有很多存在方式。接下来，按角色概述常见的几种。 ScrumMaster的微观管理： 将工作分配给团队成员，而不是鼓励他们进行自组织。当ScrumMaster被赋予ScrumMaster和Project Manager的双重角色时，这种可能性更大。 运作每日Scrum，而不是引导团队开展会议。 将Daily Scrum变成状态报告，而不是团队协作的契机。 将自己的想法和观点注入回顾会中。 告诉团队成员如何工作。 告诉团队成员如何解决问题，这样会损害团队自己解决问题的能力。 告诉团队成员问题出在哪里，而不是帮助他们自己发现问题。 产品负责人的微观管理： 在Sprint中添加新工作，并要求立即完成。管理层有时也会这样做。 参加Daily Scrum以获得状态更新。（Daily Scrum用来帮助团队在一天中进行协作和集中精力。如果团队邀请产品负责人，则产品负责人必须记住这一点，并且不得干涉。） 将Daily Scrum用作向团队询问其工作的机会。 监督团队，检查所有的细节。（一个好的产品负责人应该赋能团队，小事团队可以自己决定。） 管理层和其他干系人的微观管理： 参加Daily Scrum并注入自己的想法，称其为”建议”。（管理层的大多数建议会被自动视为命令。） Daily Scrum中有管理人员出席，也会使人们将事件转变为状态报告事件。团队成员会不自觉经常去看管理者，而不是看同伴。届时，Daily Scrum便成了以管理者为中心而非团队。 管理者，特别是高管的建议通常被当做命令，因为这些人控制团队成员的绩效评估，薪水增加和长期雇佣状态。团队成员自然会去取悦那些拥有权力的人。 要求ScrumMaster在Sprint中频繁更新进度。 使用Sprint Burndown图监察Sprint期间团队的进度。 将Burndown / Burnup /累积流图视为进度的度量标准，而不是将其用作预测工具来查看Product Backlog中的哪些项目将完成。 要求更高的速度或要求团队更快。（团队最终会更快，但只能专注在提高技能和工作质量。） 告诉团队如何工作。 告诉产品负责人如何写用户故事。 将ScrumMaster视为差事。 提示：告诉/分配/应该这样的词是发生微观管理的警告信号！

经理与冲刺列表 Manager vs. Sprint Backlog 我们的冲刺列表不仅包含来自产品待办列表中的用户故事，还包含缺陷、风险、和改进项。 所以任何事情都可以加到冲刺列表中吗？是的，如果团队同意的话，但是…… 那么，请新增：作为经理，我想要你们用小时来计算迭代速率，这样我就可以把团队效率汇报给高管（executives） 作者评论 Scrum指南指出：“Sprint列表是为Sprint选择的产品待办列表条目的集合，以及交付产品增量和实现Sprint目标的计划”。我们还看到，冲刺列表包含缺陷、减轻风险的措施以及根据先前的回顾改进Scrum团队工作方式的活动。 在上述经理的命令中，我们看到了几种反模式；使用组织层次结构告诉团队将某个条目包括在冲刺列表中，该条目的内容（可能）既无助于团队的Sprint目标也不是回顾会的结果，并且请求的动机在于衡量和报告团队的“效率”。至少，经理正确传达了用户故事的声音…… 译者评论 这里主要提到了一个反模式，即经理的副作用。那么这里并不是说经理（或管理层）不重要，而是在敏捷转型中，他们不用进行微观管理。那么对于经理（或管理层）需要做哪些事情呢？ 在《Scrum精髓》一书中有提到，对于敏捷转型中的经理，最主要的工作有： 塑造团队 培育团队 调整并改造环境 管理价值流 塑造团队 塑造团队中有如下几个关键点： 定义边界 提供清晰且鼓舞人心的目标 组建团队 改变团队的人员组成 授权团队 培育团队 培育团队包括： 激励团队 发展团队能力 建立领导力 保持团队的完整性 调整并改造环境 调整并改造环境会包含以下内容： 传播敏捷价值观 移除组织层面的障碍 内部的多个团队保持一致 与合作伙伴（如上下游）保持一致 管理价值流 管理价值流包括： 立足于系统的角度思考问题 管理经济情况（大白话及是否划算） 度量与汇报 所以管理者们，请不要进行微观管理，有大量你应该做的事情。 读者评论 对于今天的漫画，你有什么想说的呢？ 参与讨论，请扫码加入”敏捷家”微信群 原文链接

社交隔离 social distancing 明天起，我们彼此不能离得很近。必须通过社交隔离（social distancing）来阻止COV-19的传播。 好像产品负责人已经尝试让曲线变平。现在接下来的几个迭代将找不到他了。 作者评论 我们所有人都必须竭尽所能，通过社会隔离、在家工作和支持那些冒着生命危险保护我们社会中最弱势群体的人，来防止COVID-19传播。 我们经常看到产品负责人与开发团队之间的距离似乎很遥远，最糟糕的是甚至完全无法找到产品负责人。在此之前，作为敏捷教练和Scrum Master，我们必须帮助PO在进行面向外部的活动（例如与最终用户和客户进行需求研讨会），以及进行面向内部的活动（如与团队进行产品待办列表梳理）之间找到微妙的平衡。 如果产品负责人与团队没有在一起，则确保可以找到产品负责人的一种方法是，每天产品负责人有几个小时的时间窗是团队可以随时能找到的（如打电话的空闲时间）。 译者评论 这个漫画除了描述 COV-19 期间的社交隔离，更重要的描述了产品负责人与开发团队之间的协作问题。 一般情况下，产品负责人在开发团队想要找他的时候很难出现，（就像现在的社交隔离一样）而实际中产品负责人不仅仅对外合作（收集客户需求，与客户互动），还要与开发团队紧密协作（澄清开发团队遇到的问题）。 产品负责人，请不要“消失”…… 读者评论 对于今天的漫画，你有什么想说的呢？ 参与讨论，请扫码加入”敏捷家”微信群 原文链接