远程团队中的敏捷开发是什么样子的

适应scrum,而不需要每日站立会议、结对编程或面对面会议

敏捷开发远程团队标语
插图的韦森特尼罗

没有一种方法Doist“发展”。我们完全远程的工程团队总是有独立的工作流程。

在公司层面,我们每月定义工作和设定高层优先级Doist目标(DOs)。然而,每个开发团队(游戏邦注:如前端、后端、Android、苹果、Windows、集成)都可以使用他们喜欢的任何进程来执行。这种独立性使我们能够在没有繁文缛节的情况下尝试新的工作方式。在远程团队中使用敏捷开发就是这些实验之一。

我2015年入职时,Doist的Windows团队刚开始只有一个人。就像大多数单人团队一样,没有流程。但在增加了一些人之后,我们开始经历成长的烦恼:

  • 我们团队的要求来自许多方面。确定这些请求的优先级和设定预期的交付日期纯粹是猜测。
  • 我们在很长一段时间里都是独自工作,而不是一个团队,这让我们无法理解在需要的时候我们可以在哪里疏通我们的队友。通常情况下,人们会在一项任务上僵持好几天,然后才主动伸出援手,因为团队成员缺乏可见性。

很明显,我们需要一种更有组织的方式来协作和管理我们的小但不断增长的团队的所有需求。

我们中的大多数人在之前的工作中都有过敏捷开发的经验,所以我们的第一反应就是scrum。但是在完全远程的环境中复制scrum方法并不容易。禅修文化,异步通信——与跨越时区的团队成员所面临的无时无刻不在的日程安排和连通性挑战相结合——使得诸如每日签到、快速反馈循环和结对编程等技术成为不可能。

我们想利用我们完全远程最大限度地,让人们自由地安排他们的日子,最大限度地提高他们最有效率的时间。对我们团队来说,这意味着封锁几天深入的工作没有干扰。工程工作需要高度的专注。断开连接和集中注意力的能力是我们不想放弃的优势。

与此同时,我们仍然在寻找一个过程来激励团队协作,进行基于事实的时间估算,并按时交付高质量的结果。

这些需求意味着我们必须在敏捷的快节奏和长时间埋头专注的工作之间找到适当的平衡。这种平衡总是一个移动的目标——我们不断迭代我们的过程,它从来都不是完美的。流程应该与团队的实际情况一起演进。随着时间的推移,当我们发现新的需求时,我们会添加到这个过程中,当我们不再需要它们时,我们会删除它们。

本文将回顾我们已经成功实践了好几年的基本元素,这些元素对我们来说非常有效。它代表了我们的集体经验,以及从一些伟大的书籍中学到的东西,特别是:

我们的过程的主要要素是:

  1. 积压
  2. 会议
  3. 冲刺

(1)积压

在Doist,我们有很多工程团队需要关注的工作资源。

  • 支持告诉我们我们的用户正在经历的问题,以及他们的改进想法。
  • 设计要求我们在应用的各个地方添加润色。
  • 做班(临时的,跨学科的,基于项目的团队)设置高优先级的项目并驱动我们的大部分工作。
  • 在内部,我们的团队一直在观察遥测数据中的bug,并对重构和新特性有很多想法。

积压

将这些需求聚合在一起,我们就可以在内部创建一个团队backlogAzure董事会,商店所有我们的工作。除了一些小的例外,如果它不在待办事项列表中,我们就不会去处理它。这个需求帮助我们建立规程来一致地使用它,并创建它代表现实的信心。

scrum开发积压
待办事项列表代表了Windows团队在任何给定的sprint中可能完成的所有任务。除了少数例外,如果它不在待办事项列表中,我们就不去处理它。

当整个团队都在为待办事项做贡献时,有两个角色与之互动最多:

  1. 团队领导(我)拥有待办事项列表。团队领导管理待办事项,与团队成员一起确保它反映了所有未来的工作,并使用它来提出冲刺工作量。
  2. 每月英雄在我们的团队集中沟通和其他团队,主要是支援,在扭转线程,澄清用户的bug报告和改进思路。然后英雄把这些线变成可操作的待办事项列表中的工作项。这个角色每月轮换一次,所以每个人都有机会与用户的反馈密切合作,并做更多的埋头项目工作。

积压项目描述
待办事项列表中的每一项都被简要描述,并附有一个指向关于bug或特性的原始线程的链接

构建和维护积压是一项繁重的工作。但是随着团队压力的增长,了解团队应该优先考虑什么,发现工作项之间隐藏的依赖关系,以及计划sprint是非常必要的。

有了定义良好的工作负载,团队就可以开始计划我们的sprint了。

(2)会议

在我们的团队中,一个sprint会持续两周。我们也尝试过每周冲刺,但它们并不适合我们的远程设置。异步通信允许我们做更深入的工作,但它也减慢了通信。如果需要大量的沟通,那么在一周内完成某些任务是不现实的。

在每个sprint的开始,我们有一个会议。这是一个漫长而疲惫的会议,大约两个小时,但这也是两周内我们作为一个团队参加的唯一一次会议。会议的主要目标是评估即将到来的工作,识别不确定性和风险,并锁定即将到来的sprint的范围。

会议有固定的形式:

  1. 得分。一项一项地检查自上次会议以来待办事项列表中的新项目,理解它们的复杂性,并给它们分配一个数值分数。
  2. 范围锁定。就即将到来的sprint达成团队承诺,并将无法进入范围的工作转移到未来的sprint中。
  3. 改善。根据我们最近的经验,讨论流程改进的想法。

让我们详细看看每一个:

得分

会议中最耗时的活动是通过我们在过去两周中积累的新工作项。对于每一个,我们将讨论实现路径和所需的工作。此讨论可以帮助捕获定义不好的工作项或附加了太多不确定性的工作项。我们拒绝对这些内容进行评分,在它们得到更好的定义之前,我们将暂停它们的执行。

我们通过使用规划扑克技术分配故事点来正式确定所需的工作。所得到的分数允许我们查看工作项相对于待办事项中的其他项的成本。

哇喔哇。举起。什么是“故事点”,规划什么是“扑克技巧”?

故事点

故事点度量相对于其他作品实现一个作品的预期难度。与基于小时的预测不同,它不表示执行所需的时间量。相反,它试图回答这样一个问题:A或B,哪个更具有挑战性?它的挑战性会有多大?

故事点通常被限制在数字之外斐波那契序列(如0、1、1、2、3、5、8、13、21、34、55、89、144…)通过使用斐波那契数列,团队承认,随着任务变得越来越复杂,团队对任务的评估能力也会变得更差,这反过来增加了无法实现事先约定的承诺的风险。它还激励团队将任务分解成更小的块,因为团队会认为有很多故事点的任务太不确定,无法以当前的形式执行。

故事点规模

故事点也是针对团队的。当Windows团队采用故事点,我们经历了旧的任务已经执行和达成一致的作品代表1故事点(对我们来说,一个明确的错误,看起来容易修复)或13个故事点(对于我们来说,一些未知和依赖于其他球队,这通常需要一个星期或更多来实现)。

下一个与故事点相关的概念是团队速度。团队速度告诉我们,在过去的几个sprint中,我们作为团队平均能够执行多少故事点。有了这些知识,我们就可以理解每个冲刺阶段可以做什么,并据此制定计划。

如果你仍然不相信故事点的效用,那就说出来这篇博文来自scrum.org一试。

最后,我们需要一种为任务分配故事点的方法。我们通过计划扑克来做到这一点……

规划扑克

规划扑克看起来像什么
我们玩“计划扑克”,分别给一件作品打分,然后公布分数,并讨论任何差异,然后商定一个数字。

规划扑克游戏是将故事点分配给任务的过程最小化群体思维和激励的讨论。

扑克计划有很多变体,但我们的是这样的:

  1. 即将到来的任务的创造者会简单地呈现它,并给出我们想要实现的目标以及我们可能面临的障碍的背景。
  2. 团队要求澄清关于任务的问题。
  3. 基于这些信息,每个人都从斐波那契数列中挑选一个他们认为代表任务难度的数字,而不告诉其他人。
  4. 每个人都在同一时间显示自己的号码。
  5. 如果斐波那契数列中显示的最高和最低的数字相差不超过一步,我们将它们平均,这就成为任务分配的故事点数字。
  6. 如果斐波那契数列中显示的最高和最低数字相差超过一步,持有最高和最低数字的人会概述他们的推理,然后进行简短的讨论。
  7. 根据新的信息,每个人都选择一个新的数字,然后我们再次在同一时间公布它们。
  8. 我们将我们的数字平均,这就成为任务的故事点计数。

扑克计划可能很费时间,但通过练习会变得更快。通过这个过程,我们了解不同的人如何思考问题和评估不确定性,使我们作为一个团队更加紧密。

范围锁定

评分完成后,我们将继续讨论在下一个sprint中包含哪些任务。通过查看我们在之前的sprint中交付的故事点的数量,我们大致知道我们可以执行多少。

Scrum故事点
我们根据我们在过去的sprint中完成的故事点的平均数量来估算每个sprint的团队能力。

在工作上达成一致是一种基于数据的联合演习,但取决于人们之间基于直觉的共识——我们不使用任何正式的优先级方法。与此同时,我们需要始终考虑我们对跨公司计划(我们的DOs)的承诺,并确保它们是优先级的。

改善

在最后一部分,我们简要讨论了之前的2周周期,并确定了我们可以采取的步骤,以成为一个更好的团队。

改善的理念(改善)最早于1950年在丰田汽车公司(Toyota Motor Corporation)实施。这个术语指的是不断地发现微小的、渐进的改进,并立即应用它们。这个想法与诸如10倍的思考该公司专注于革命性但不频繁的创新。这两种心态总是需要在任何团队或组织中共存。虽然改善是达到局部最大化的可靠工具,但要突破到另一个层次,还需要更彻底的改变。

改善vs 10x思考

(3)冲刺

会议结束后,我们有两个星期的时间来执行。在sprint期间,我们的目标是一个单独的工作组合,它发挥了开发人员的优势,并包括一些更容易的任务,以从更大、更复杂的任务中恢复过来。

虽然scrum建议每日站立,但这在远程团队中是不切实际的。在一个一致的时间段上达成一致是困难的,并且破坏了远程工作的最大优势之一——灵活性。乐动捕鱼达人

相反,我们在任务板上观察工作项的流,并确保我们首先解决最关键的任务。对于相对优先级的共同理解来自于黑板上的项目顺序,加上在过程中分享的上下文会议

在整个sprint中,我们异步地交流扭曲的线程以及需要的信息。如果一个项目的进展在董事会上停滞,我们会讨论谁需要帮助,谁有时间提供帮助。

团队领导负责确保人们不会陷入困境,并试图通过与其他团队的沟通和做一些事情来帮助他们rubber-ducking,并在需要时提供有关代码库的历史上下文。


从表面上看,敏捷似乎与偏远的环境格格不入。该方法最初被认为是一种供位于同一地点的开发团队迭代和快速响应更改的方法。如上所述的敏捷软件的12条原则在开发团队中传递信息的最有效的方法是面对面的交流。

但是敏捷的四大支柱之一是“响应变化而不是遵循计划”。在一个完全远程的公司工作,最令人兴奋的事情之一是有机会尝试新的合作方式——有时我们调整那些对位于同一地点的团队有效的方法,有时我们拒绝它,有时我们开发全新的方法。任何敏捷工作流都需要服务于团队的需求,而不是相反。任何东西都不应该被视为神圣或静止的。

正如本文开头所提到的,我们的流程是在特定上下文中为我们工作的时间快照。随着团队和用户需求的变化,我们将继续迭代。敏捷提供了一个广泛的工具箱,我们可以从中挑选,以便继续为我们的客户提供令人惊叹的体验——无论我们来自哪里。