开工福利|免费学 2200+ 精品线上课,企业成员人人可得! 了解详情
写点什么

团队是否应该采用分离的工作节奏?

  • 2018-01-02
  • 本文字数:3151 字

    阅读完需:约 10 分钟

最近,Twitter 上掀起了一场有关团队是否应该采取分离工作节奏的讨论,比如,工作计划和学习改进是否可以采用不同的节奏。分离的工作节奏可以让团队找到适合自己的工作方式,具有更大的灵活性和自主性,也会带来更好的产出。

第一条推文来自 Matt Barcomb:

Barcomb:如果你已经有成型的 MVP(最小化可行产品)或者知道如何安排工作优先级,那么就没必要进行 Sprint 计划(或者是制定 Sprint 目标)。

Ron Jeffries 引用 Barcomb 的推文,说:

Jeffries:如果你想提高可预测性、缩短产品生命周期或加强沟通……那么分离的工作节奏或者说计划性的东西才会体现它们的作用……

在后续的讨论中,Barcomb 建议让团队采用分离的工作节奏,而 Jeffries 一直在质疑:

Barcomb:一般来说,我们会推荐计划和改进这两个部分使用同一个节奏。不过,我还是建议要把它们分开来实施。

Jeffries:为什么要分开?定期进行计划,并在同一时间评审完成进度不是很好吗?

Barcomb:让我感到很疑惑的地方,就是当团队需要一个自省通道时,却感觉(或者被告知)他们不能这么做,因为那不是 Scrum。

Jeffries:为什么有人需要不一样的工作节奏?是因为它比 Sprint 慢?到底是为什么?

接下来,John Cutler 加入了讨论。他给出了几个为什么需要分离工作节奏的理由:

Culter:

客户反馈闭环

交付闭环

集成闭环

分解工作

自省闭环

目标设定闭环

如果能够以一种节奏做完这些事情或许会更好,但通常不是这样的。它们有些是即时性的,有些需要长一点时间,有些则短一些。

Matt Heuser 也发了推文,例举了一个采用分离工作节奏的公司的例子:

Heusser:我可以以一家位于印第安纳州的公司为例,他们就成功采用了分离的工作节奏。我可以在下次的 Agile&Beyond 大会上分享。

InfoQ 采访了 Matt Barcomb、John Cutler 和 Matt Heusser,讨论了分离工作节奏以及它会为我们带来哪些好处。

InfoQ:计划和改进采用同一个节奏有哪些优势和不足?

Matt Barcomb:首先要说明的是,问题不在于是否要让计划和改进采用同一个节奏,而在于是否允许团队把它们分开实施。我经常看到团队因为“Scrum”而只采用了一个节奏。

不允许分离节奏的劣势在于,它会降低团队的自主性,导致不好的产出。所以,如果能反其道而行之,它就会变成优势。

在现实当中,我也看到一些例子,因为团队无法实施分离的工作节奏,导致下列情况的发生:

  1. 做了太多的计划,有些只是“Sprint 层面”的任务。
  2. 糟糕的计划和产出。
  3. 没有适当控制好改进速度,团队无法应对所有的变更。
  4. 忘记了改进想法,延误了必要的改进。
  5. 没有考虑周全各种角色和各个级别的改进。

当然,除了上述这些,还有其他的一些因素。而且,即使只采用了一种节奏,我们仍然有办法解决上述的一些问题。不过,分离工作节奏可以让团队有机会找到更适合他们的工作方式,通常情况下,这样会帮助他们达成更好的目标。

John Cutler:团队经常以便利为理由将计划和改进耦合在一起,他们倾向于在一次会议中把所有的事情都做完。另外,自省通常是围绕着“成功”的计划而进行。通过这种节奏的耦合,团队可以确保他们所了解到的内容是“最新”的。

当然,这里也存在一些潜在的不足。比如,团队在这一过程中能够理解到的变更是很有限的。经常性的自省变成了日常的杂务,同时也在消耗着团队的精力,导致他们逐渐失去热情。与此同时,两周一次的计划会降低它的实际作用。“一篮子解决问题”的方式无法让团队更好地满足特定需求。

Matt Heusser:耦合的好处就是简单,而且可以实现实实在在的改进。有太多的公司忙于生产业务,没有太多时间用在计划和改进上。即使有,他们也不会把得出的结论应用到下一个项目当中。我曾经工作过的一个公司沉迷于两义性(ambiguity)的评审风格,项目经理手里拿着一个检查清单,说:“从现在开始,所有的项目都需要进行两义性的评审!”但我从来没见过有哪个团队在使用这种方式。而有了 Sprint 的概念,你就有了明确的开始时间和明确的结束时间,并考虑接下来该做些什么。

Customize Your Agile Approach: Select Your Agile Approach That Fits Your Context 这篇文章中,Johanna Rothman 探讨了如何自定义敏捷方法,并设计出一种集交付、计划和反馈为一体的工作节奏,可以用在实际的产品、项目或团队中:

每个团队都是不一样的,所以每个团队都需要有自己的敏捷方法。有些团队可以使用现成的框架,如 Scrum、XP 或 Kanban。不过,从我的经验来看,大多数团队需要根据实际情况自定义敏捷……或许你所处的环境可能需要集计划、演示和发布为一体的工作节奏。但你的团队可能会发现这样的节奏其实不会奏效。

InfoQ:在什么情况下你们会建议采用分离的工作节奏?

Cutler:我建议在团队遇到信息流瓶颈或感觉到能量不匹配时采用分离的工作节奏。比如,想象一下两周一次的 Sprint 到达尾声的时候,事情已经偏离了正轨,但没有人能确切地说出问题的“根源”是什么,因为有用的信息已经缺失了。而此时,我们的看板已经达到了 EIP(进行中的实验)限制。很多在进行中的持续改进都是有意义的,但我们却还没准备好去完成之前作出的承若。

在这种情况下,我们或许可以尝试进行节奏分离。我们可以缩短 Sprint 时间,也可以看情况进行进行 15 分钟的自省,或者每两周进行一次短时间的自省,每个月进行一次深度自省。

Barcomb:我会建议给团队足够的自由度,让他们自由进行节奏分离。我听到有些人说,刚开始采用敏捷方法的团队应该耦合他们的工作节奏(也就是“进行 Scrum”),因为分离的节奏对于一些新敏捷团队来说是一种无法掌握的“高级”技术。

就个人而言,我觉得不是这样的。在与新的敏捷团队一起工作时,我并不会特意去鼓励或者阻止他们使用耦合的节奏。我觉得我们应该帮助团队去发现适合他们的工作方式以及怎样的工作节奏有助于这些工作方式。我不觉得这是什么神秘的高级技术。有些团队已经在这么做了,然后有人跑过来告诉他们说“那不是敏捷”。说实话,分离节奏不会比小孩的日常杂务难多少。

Heusser:如果改进工作已经在进行中,而且团队擅长设计实验,那么就没有必要与计划保持同样的节奏——它完全可以根据实际需要即时进行。在我看来,实时的决策对技能有更多的要求。所以,我会建议使用多种计划时间窗口,Sprint 只是其中的一种。就像棒球赛那样,我们可以进行单次、一局、一场、一个赛季或一整年的计划。

我的策略是在计划和改进出现混乱时才增加 Sprint,然后在走上正轨或者具备了可预测的交付流程时再把它们去掉。我之前在一个印第安纳州之外的公司工作,在我之前,Matt Barcomb 也在那里。他们获得了长久稳定的成功。我们当时所做的就是即时 (Just In Time)的自省。如果有需要讨论的事情,我们就在看板上放上粉色的卡片,如果集齐五张卡片,我们就进行一次自省。我们放一张红色卡片在粉色卡片的前面,用来安排自省。

InfoQ:分离的工作节奏会给我们带来什么好处?

Heusser:在该做事情的时候就去做,而不是死板地照着某种计划安排来,这样才会带来更好的产出。当然,这也要求更复杂的技能——做出决策总是比遵循指示要困难得多。

Barcomb:分离的工作节奏最终会带来适应性和自主性。如果团队认为耦合的节奏更适合他们,那么就这样去做,没什么问题!如果他们没有其他更好的方式,完全可以试着这么做!但不能强制他们总是使用同一种的方式,因为这种方式在某个时候可能变得毫无意义,他们应该有权利决定以何种方式来达成目标。

Cutler:分离的节奏适用于多元化的认知、团队的工作风格、信息流、处理信息的能力和复杂工作的可变性。认为人类可以在同一种节奏中处理不同类型的工作,这样的想法有点幼稚。不过,如果有人说所有事情都可以即时进行,我也会站出来反对,因为这种观点太过自以为是了。试想一下,如果有些团队成员在周末时紧闭大脑不想进行任何思考,那该怎么办?

查看英文原文 Should Teams Decouple Cadences?

2018-01-02 18:002324
用户头像

发布了 322 篇内容, 共 143.9 次阅读, 收获喜欢 148 次。

关注

评论

发布
暂无评论
发现更多内容

探讨:2023 年 WEB 3 的 5 大趋势

开发微hkkf5566

API 网关 Apache APISIX 3.0 版本正式发布!

API7.ai 技术团队

Apache 开源 APISIX 新版本/特性发布

实践一年之久,vivo 如何基于 APISIX 进行业务基础架构的演进

API7.ai 技术团队

开源 云原生 API网关 APISIX 客户案例

React-Native 开发实用指南

环信

前端 开发 React Native Android;

如何通过Java 在 Word 中更改字体颜色

Geek_249eec

word java;

【11.04-11.11】写作社区优秀技术博文回顾

InfoQ写作社区官方

热门活动

计算机网络:随机访问介质访问控制之CSMA/CA协议

timerring

计算机网络 11月月更 CSMA CSMA/CA

如何使用清源 CleanSource SCA 管理开源风险

安势信息

SCA SBOM 清源CleanSource SCA 开源风险

Centos7 gcc4.8.5升级到版本gcc5.4.0

A-刘晨阳

Linux 运维 11月月更 gcc5.4

还不会日志异常检测?看完这篇文章就够了!

云智慧AIOps社区

人工智能 机器学习 大数据 日志分析 异常日志

TDSQL-C真·秒级启停:连接断了,又没断

腾讯云数据库

数据库 腾讯云 TDSQL-C 腾讯云数据库

久等了,青年技术沙龙北京发车!

小红书技术REDtech

科普|渲染农场与超级计算机有什么不同?

Finovy Cloud

人工智能 深度学习 图像处理 云渲染 渲染农场

性能测试岗位能力模型

老张

性能测试 胜任力模型

Apache ShenYu 集成 RocketMQ 实时采集海量日志的实践

Apache RocketMQ

RocketMQ 消息队列 Apache ShenYu

峰会实录 | 镜舟科技CEO孙文现:基于StarRocks打造企业级极速统一数据分析产品

StarRocks

数据库·

鸿蒙生态汇聚200万+开发者,金山办公、京东分享高效开发新体验

叶落便知秋

大数据中,LED显示屏行业的两大服务和四大功能

Dylan

LED显示屏 户外LED显示屏 led显示屏厂家

面试还不懂JVM调优,看这篇文章就够了!

Java全栈架构师

程序员 性能优化 JVM java面试 jvm调优

Linux中gcc4.8.5升级到gcc5.4.0用已经编译好的安装包升级(重点是不用编译安装,可以更省时)

A-刘晨阳

Linux 运维 GCC 11月月更 gcc5.4

深入理解数组的slice方法

好程序员IT教育

JavaScript 数组 slice

集合管道模式(上)

冰心的小屋

集成管道模式 pipline

用技术为内容注入生命力,华为视频持续升级影音体验

科技汇

华为全联接大会2022丨华为云打造可信认证体系,加速开发者成长

华为云开发者联盟

云计算 后端 华为云 企业号十月 PK 榜

开源的YAPI外还有哪些免费的接口工具?

Liam

开源 YAPI 接口工具 免费

SpringCloudAlibaba 微服务组件 Nacos 之配置中心源码深度解析

程序员小毕

微服务 后端 nacos 架构师 java面试

分布式数据库九大发展趋势|文末附完整报告下载

OceanBase 数据库

双机热备软件哪家好?有哪些功能?咨询电话多少?

行云管家

高可用 热备 双机热备

保定有几家等保测评机构?咨询电话多少?

行云管家

等保测评 等级测评 等保测评机构 保定

【杭州专场】蚂蚁单测自动生成产品体验活动招募开启

TRaaS

Web3.0 中的去中心化身份

开发微hkkf5566

团队是否应该采用分离的工作节奏?_文化 & 方法_Ben Linders_InfoQ精选文章