• 可以放慢脚步:BA效率不是通过击键来衡量的
  • 业务分析的通配符身份
  • 是的,您可以在Covid-19期间实际上有效地提出要求!
2015年5月4日星期一14:20

敏捷是一项团队运动

撰写者

根据定义,敏捷开发是一项团队运动。重点是团队一起工作和交付。不是通过开发团队产生多少用户故事来衡量,而是通过团队可以产生多少完成/完成的故事来衡量。

质量不是测试人员“拥有”的东西,而是整个团队的责任。实际上,您不是在尝试“测试”质量,而是在“构建”质量。

它使协作和团队合作高于单独工作的个人。它重视工作周围的配对和蜂拥而至。它重视限制在制品,以便团队成员一起工作。

在大多数组织和团队中,通常会丢失的是,当您专注于让个人忙于并在功能级别进行优化时,会遇到孤岛,交接和依赖的情况,您会变慢。当然,感觉每个人都在努力……而且确实如此。但是结果,吞吐量,价值通常比敏捷的协作协作要慢得多。

侧边栏

我经常在课堂上提出这一点,并在这里与您分享。对于上述内容,请不要相信我。而是运行一个实验。无需太多协作即可以通常的方式运行sprint。看看您完成了多少故事。然后采用大致相同的故事组合,并着重于协作和蜂拥而上。不必担心让每个人都忙,而要专注于协作,群聚和吞吐量-尽可能多地完成工作。

迄今为止,我还从未见过团队比他们的瀑布行为更出色。如果他们进行诚实的实验,他们通常会通过合作完成50%-100%甚至更多的工作。我知道,这违反直觉,但是请–在两个冲刺之间进行实验。

然后反思发生了什么……并尝试做更多的事情。

分布式团队

前几天我在和一个潜在的客户聊天。他们的团队分布广泛。让我描述一些动态:

  • 开发商遍布全国。每个都在单独的位置;
  • 测试人员位于远程办公室的中央。
  • 产品负责人和Scrum Master一起在中心办公室。

当我对他们说话时,他们说他们“敏捷并做Scrum”。但是由于团队的分散性,他们跳过了一些关键的事情。例如,每天站起来对他们来说非常不便。所以他们跳过了。相反,他们发送状态电子邮件消息作为试图保持同步的一种方式。

也没有冲刺计划或积压的改进。每个开发人员基本上都会同意他们的具体工作并在其游戏计划中寄出邮件。质量检查小组的成员要设法弄清楚如何为每个人提供支持。基本上,所有开发人员都在每次sprint结束时都将代码扔给测试人员,以期创造奇迹。

但是奇迹很少发生,他们正在努力交付。但是你猜他们还说什么?

鲍勃,显然敏捷在分布式环境中不起作用。我们相信我们失败了,因为我们采用了敏捷。

我问他们,在采用敏捷之前,您是否拥有相同的团队结构?

是。

您以前有送货问题吗?

当然,那会更糟。我们无法按时交付任何东西,而最终不会自杀。但是我们认为转向敏捷将解决问题。

我的回复

在我的敏捷教练和培训旅行中,我总是会遇到这种压力。几乎每个人都在问敏捷在分布式环境中如何工作。他们的挑战始终是-它行不通。

那么,如何在分布式团队环境中成功实现敏捷性呢?

一些事情,但协作团队的关键之一是协作。

您必须作为一个团队进行协作-想象一下!

您是否听说过“假装直到完成”的表达?我认为它也适用于敏捷性。而不是因为“他们太难了”而扔掉所有协作的东西,而是为什么不假装自己在过渡中敏捷。换句话说–致力于协作!致力于自我指导的团队合作,问责制,质量,透明度等原则。

而且,如果您决心做到这一点,那么我的假设是,每个团队都会想出一种使事情顺利进行的方法。
敏捷协作的一些关键方面是什么?

  • 尽可能面对面 –我知道,我知道您没有预算。好吧,为此计划一些预算。需要建立团队,您无法远程完成所有工作。考虑来回飞行的人,或者考虑每个人聚在一起的特殊活动。如果您要与分散的团队一起开始一个新的敏捷项目,那么您可以做的最好的事情之一就是让整个团队团结起来,共同制定或启动该项目。让他们“好像”在同一地点运行第一个冲刺。让他们互相了解并团队合作。我在这方面谈论更多 博客文章.
  • 配对– 3-好友–尽可能配对(远程配对) –不要在浪费时间的情况下查看它;而是将其视为对协作和团队合作的投资。我不仅在谈论开发人员与开发人员之间的配对。测试人员可以配对。或拥有测试人员的开发人员,或者您可以从事 3-Amigo风格的协作。在您的团队中完成的个体性越少,孤独的狼工作越多,协作的结果就会越好。但不要强行配对。它必须来自每个团队成员内部,并且是机会主义和受欢迎的。但是,请鼓励并不要“数小时”,而要查看配对对提高生产率和质量的结果。
  • 每日站立 –拥有一个 每日同步点或协作 团队活动。它为团队建立了沟通的“心跳”,分享成功和挑战,并互相帮助。因此,无论您的团队有多分散,您都需要在共同的时间达成共识并在那里。但不只是参加。您需要参与站立练习-倾听所有人的声音并充分参与。请记住,您应该作为一个团队而不是分散的个人致力于Sprint目标,因此您应该对每个对话都感兴趣。
  • 代管 –拥有分散团队的人们不断提出的观点之一是,他们不能在同一地点。我同意,这是拖累。敏捷团队的“最佳位置”之一是跨职能,位于同一地点,自我指导的团队的概念。所以这是一个缺点。但这并不一定要阻止所有协作。戴上富有创意的“思想帽子”,尝试设置虚拟的,位于同一地点的环境。使用网络摄像头,共享白板,使用您拥有的任何工具,是的,拿起电话。我发现,分布式团队在设置几乎与“在那儿”一样好的虚拟托管环境中可以发挥不可思议的创造力。但麻烦的是,您必须付出额外的努力才能做到。
  • 成群结队 –我曾在一家公司工作,该公司拥有一些分散的团队成员,他们不断推动工作量的增加–希望每个故事都由一个人来工作。实际上,如果我什至提到蜂拥一词,它们就会变得烦躁。想象一下这种文化如何处理更分散的团队动态吗?是的,非常糟糕。他们的结果呢?充其量是破裂的。在冲刺计划中,您将尽可能地计划进行协作。我意识到很难集中讨论1点用户故事。所以不要但是13点的用户故事呢?冲刺执行的目标应该是完成每个故事(ASAP),而不要让个人忙。
  • 探索性测试 –太多的敏捷团队对探索性测试一无所知。这是一种将应用程序作为一个整体“探索”并跟踪您的“旅程和发现”的技术。我喜欢成双做。团队花了一些时间在有时间限制的会话中成对测试。每个会话都有一个章程,定义了要探索的应用程序对的区域。然后,这对夫妇在一个会话的范围内进行测试-假设是90分钟。在每个会话时间段结束时,他们将汇聚一堂,汇报他们的发现,进度,并计划下一步操作(如果他们要进行另一个会话)。这不仅是对整个团队进行测试的绝妙方法,而且还可以加强配对和协作。
  • 客户演示 –通常,我们忘记了在您进行了sprint演示并收到反馈之前,才完成sprint。该演示是一个全团队的活动,因此每个人都需要参加。哎呀,忘了在那里,团队需要互动才能展示他们的结果。现在,对于分散的团队成员而言,这可能尤其具有挑战性,但是会对自己施加一些创造性压力,以“弄清楚”如何获得 整个团队参与计划和执行Sprint演示.
  • 待办事项细化& 球队-based Planning –事实证明,积压改进会议, 正在进行的积压细化以及sprint计划是针对团队的。他们需要全团队的参与。这通常是分布式团队的争论点,因为在“便捷”的时间让所有人聚在一起可能是一个挑战。我说强硬!这些是基于团队的活动,团队需要弄清楚如何使每个人不仅参与计划,而且参与其中,并在计划和每次冲刺执行期间共同努力。这些会议是敏捷结果的基础,因此是必需的。

领导问责制

而专注于使其成为一项团队运动不只是为了团队。组织领导必须对以下方面负责:

  1. 用他们无穷的智慧以分布式的方式建立组织;
  2. 意识到在分布式团队中工作效率较低;即将存在“阻力”和持续的挑战;
  3. 支持他们的团队对工具,旅行和其他任何促进协作的需求;
  4. 随着时间的流逝实现他们的责任是:
    1. 听取每个团队的反馈意见,
    2. 尽可能减少团队的分散性。

随着时间的流逝,请尝试将工作移到尽可能多的位置。即使这意味着短期内增加成本或破坏在决定“敏捷”之前制定的战略计划。

我想我想说的是分布式团队是一种选择。而且我发现,在减少随时间推移的分布方面,存在巨大的领导“摆动空间”。

包起来

我经常发现高性能的分布式敏捷团队。他们经常踢同居地点的同行。

为什么?通常有两个高层次的原因。

首先,团队致力于敏捷原则和跨团队协作。您可以将其中的一些送上月球,而他们仍然可以找到一种方法,使其发挥作用,为客户带来价值。

其次,他们的领导团队了解到,他们已经使团队面对了从一开始就面临的挑战,但是他们竭尽所能来支持组织内部的协作并减少随时间的分布。

换句话说,他们富有创造力和奉献精神。

顺便说一句:我喜欢曲棍球的图片,因为冰上曲棍球是其中最多2名球员获得助攻得分的球员所组成的真正团队合作的运动之一。谈论蜂拥而至…

保持敏捷,我的朋友们,
鲍勃

不要忘记在下面留下您的评论。

罗伯特·加伦

罗伯特·鲍勃·加伦 是RGCG L.L.C的总裁兼首席顾问。基于NC的Cary敏捷方法指导&培训顾问。他是一位经验丰富的敏捷教练,活跃于敏捷社区并定期撰写文章。&讲授与敏捷方法有关的所有主题。鲍勃写了这本书 Scrum产品所有权,重点放在团队交付中的角色和驱动价值上。鲍勃可以在 [email protected] 并通过他的LinkedIn进行联网 个人资料.

©BA Times.com 2020

麦格雷戈徽标白色网站