Agile Patterns

谈谈敏捷中的那些模式

敏捷中的模式与反模式

本文的内容来自于7月10日我在“艾威网校”的一次分享。
开始先简单自我介绍如下:(欢迎扫码获取ppt)

Bob Jiang自我介绍幻灯片,中国北方第一位CST认证Scrum培训师

本文主要分为四个部分:

  1. 什么是模式语言及反模式语言
  2. 敏捷中的模式语言(Scrum Patterns)
  3. 敏捷中的反模式语言
  4. 回归本质

什么是模式语言和反模式语言

模式语言定义:物体或事件上规律变化与自我重复的样式过程

模式(英语:Pattern,源自法语:patron),在物体或事件上,产生的一种规律变化与自我重复的样式之过程。

在模式之中,某些固定的元素不断以可预测的方式周期性重现。最基本而常见的模式,称为密铺,具备重复性以及周期性两大特征。找寻出固定模式是人类基本的认知功能之一。

– 摘自维基百科

在1977年的《A Pattern Language》一书中,Christopher Alexander提出了模式语言的概念。在豆瓣中的图书介绍如下:

克里斯托弗·亚力山大是美国杰出的建筑理论家。由他领衔撰写的《建筑模式语言》一出版就受到建筑界的广泛重视和高度赞誉,并对建筑业产生了深远的影响。 《建筑模式语言》别出心裁且有根有据地描述了城镇、邻里、住宅、花园和房间等共253个模式,提供了一幅幅设计、规划、施工等方面的崭新蓝图,构思新奇,妙想迭出,不同流俗。 作者写道:“我们深信无疑,本语言要比一本手册、或一位教师、或另一种可能的模式语言略胜一筹。这里的许多模式看来在今天和以后的500年间将成为人性的一部分,成为富有人情味的行动的一部分。”诚如美国《建筑设计》一则评论所说:这也许是20世纪出版的关于建筑设计的最重要的一本书了。 这本书的生命力在于“以人为本”。它是此书的主题思想,像一条鲜艳的红线贯穿始终。各模式的字里行间洋溢着浓浓的人情味和对人的无微不至的关爱,如保护生态环境,如何绿化美化城镇和住宅,反对建筑风格的千篇一律,鼓励人际交往,强调人、社会和自然环境三者的和谐统一,等等。

所以不论是在敏捷转型中,还是软件开发中,亦或是建筑行业或我们身边,都会存在着许许多多的模式。而本文就是要和大家一起来探索一些敏捷转型中的模式(以及反模式)。其中的一些模式摘自于《A Scrum Book》一书,书中提供了94中Scrum的模式,下面我会结合实际工作经验介绍其中的4种。

反模式

反模式(anti-pattern)也是一种模式,最早是在软件工程中提出的,反模式指的是在实践中经常出现但又低效或是有待优化的设计模式,是用来解决问题的带有共同性的不良方法。按照《反模式》一书的作者的说法,可以用至少两个关键因素来把反模式和不良习惯、错误的实践或糟糕的想法区分开来:

  1. 行动、过程和结构中的一些重复出现的乍一看是有益的,但最终得不偿失的模式
  2. 在实践中证明且可重复的清晰记录的重构方案

– 演绎自维基百科

敏捷中的模式语言

敏捷中的四种模式语言:回顾会、小吃神社、障碍清单、Scrum板

下文主要描述四种敏捷中的模式语言:(分为两类 - 产品组织和价值流)

  1. 回顾会(产品组织)
  2. 小吃神社(产品组织)
  3. 障碍清单(价值流)
  4. Scrum板(价值流)

回顾会

回顾会是敏捷中至关重要的一个会议(也是敏捷的本质,在最后的总结中我会再次提出这个重点)。如下图,如果忙于交付而忽视了改进,则从长期来看一定是得不偿失。

回顾会的重要性示意图:忙于交付忽视改进长期得不偿失 回顾会Start-Stop-Continue方法:开始尝试、停止无效、继续良好

对于团队而言,回顾会就是每个迭代结束前团队在一起反思团队中关于人、关系、过程和工具的情况,根据上述情况制定具体的改进计划。上图中采用的方法是: Start, Stop, Continue

  • 开始尝试新的方法
  • 停止无效或低效的方法(或工具)
  • 继续使用良好的工具(或方法)

另外对于个人而言,也是需要不断的回顾总结与反思。这里是我个人的每周总结

小吃神社

团队都很难独立存在的(尤其在大公司中),于是日常工作中团队(或团队成员)总是会受到不同人的干扰与打断。被打断后要再重新开始刚才的工作就需要思路能接上,这是一个很难的事情。所以对于团队需要有一个缓冲地带,就是下图中的“小吃神社”。(这个名字来自于日语)

注:小吃神社不是茶水间,这个区域离团队很近,但不至于影响到团队的其他人工作。

小吃神社模式示意图:团队缓冲地带避免频繁打断工作节奏

这个缓冲地带对于团队来讲非常重要,任何问题都不要直接去打断团队的节奏(除非是生产系统挂了)。而是大家可以在小吃神社这里进行讨论。这个模式的前提是,团队太容易也太频繁被打断了。

障碍清单

障碍清单模式:可视化收集排序团队障碍,指定跟进人解决

工作中每个人都会碰到不同的问题、障碍。敏捷中经常也会提倡在每日站会上提出遇到的问题障碍。然而仅仅提出并不是很好的做法,更好的做法是可以创建一个障碍清单,用于收集并排序团队中的障碍。

这个模式的好处是:

  1. 可视化团队所有的障碍问题
  2. 排序(根据风险评估)后,根据顺序来一次解决障碍
  3. 每个障碍可以注明跟进人

Scrum板

Scrum板如下图,是一个白板,用于可视化团队在迭代内的进度。团队每日站会就围在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视为差事。

提示:告诉/分配/应该这样的词是发生微观管理的警告信号!

最终,所有这些都归结为相同的基本问题:通过施加控制被误导的需求和提供帮助的愿望,通常是基于这样一种想法,即:说的人比做的人更知道如何做得好,[ 2 ]以及更能感受是否可控。

我们都会偶尔做一些这样的事情,不要自责。这是正常的人类行为,但是当它成为您的管理风格中反复出现甚至将其定义为您管理风格的一部分时,就是问题。

微观管理的后果

近几年,一些理解现代工作环境中人类行为的模型逐渐出现。作者及其框架研究如下:

  • Dan Pink –自主,专精和目标[ 3 ]
  • Susan Fowler–自主,亲和力和能力[ 4 ]
  • David Rock–身份确定性,自主,亲和力和公平性[ 5 ]

自主程度是所有研究的核心吗?他们每个人都说人们需要拥有自由和独立性,才能做到最好。我还可以说,自主,参与和自组织也是Scrum的核心,这并非偶然。当允许进行微观管理时,这些方面都会受到破坏。