地理分布团队的敏捷生命周期

在过去的几年中，我一直与分布在各地的团队合作。 他们中的一些人在相当大的程序上，而某些人则很小。 他们都有一个共同点，就是他们都希望过渡到敏捷。

他们中的大多数人都是以这种方式开始的：有人参加了Scrum课，感到很兴奋。 很好 然后现实来了。 Scrum适​​用于并置的地理跨职能团队。 哦哦

几乎所有这些团队都是按职能分开的：开发人员在一个地方，测试人员在另一个地方，业务分析师在第三位，项目经理在第四位，以及是否有产品所有者（或产品负责人通过），他们通常位于第五位置。 团队的每个职能与团队中的每个其他成员分开并不少见。 因此，团队不符合Scrum标准。 哦哦

由于Scrum具有如此高的品牌知名度，所以这些人认为，如果他们不能做Scrum，就不能做敏捷。 不，不是这样。 他们需要做的就是从《敏捷宣言》的价值观和原则开始，然后再从那里开始。 他们创建自己的生命周期和自己的敏捷品牌。
当我与一个客户一起工作时，那个客户认为他们可以扩展迭代。 不，如果有的话，这意味着您可以使迭代时间更短，因为当没有人在同一个地方时，您需要更频繁的反馈。 好吧，有话。 还有更多的话。 但是，如果您从这些值开始，那么您会发现，如果要变得敏捷，可以使用短迭代。 否则，您将获得分阶段交付，这是一个可爱的生命周期，但并不敏捷。

我正在博客一系列示例。 请不要问我为什么人们最终来到这些地方。 我不知道。 我所知道的就是那群人。

示例1：将项目经理与迭代，筒仓团队一起使用

一个IT组织拥有与乌克兰的开发人员，印度的测试人员，英国的产品经理和项目经理以及美国东部的企业架构和公司管理团队。
该组织进行了为期两周的迭代。 开发人员比测试人员领先3.5小时，这并不可怕。 该组织存在以下问题：

1. 产品经理必须学会成为产品所有者，并写出足够小的故事以在一次迭代中完成。
2. 企业架构师必须停止对没有功能的架构提出要求，以使其脱离架构。
3. 开发人员和测试人员必须学习按功能实现，以便架构师可以帮助团队了解不断发展的体系结构。

该组织需要大量的命令和控制来启动。 项目经理需要为团队提供便利，而不是控制他们。 架构师需要帮助团队了解如何组织产品，而不是告诉开发人员该怎么做。 测试人员不必像接受开发人员的订单那样是接受订单的人。

您可能会问，为什么组织要转向敏捷。 高级管理层希望敏捷，因为发布的时间越来越长，并且无法适应变更。 敏捷是彻底的文化转变。 为期两周的迭代以及敏捷的功能路线图很有帮助。
试点项目团队由开发人员，测试人员，产品经理和项目经理组成。 团队拒绝企业架构师作为团队成员，因为架构师拒绝编写代码。 发布计划：项目经理和产品经理以稻草人的身份对发布计划进行了初步削减，并将其提交给团队。 “你能做这个吗？ 你怎么看？”

迭代计划：团队共同进行迭代计划，以确保每个故事都是小故事，中故事或大故事，整个故事可以在不到三天的时间内由整个团队完成。 团队确保他们在迭代结束时就能完成所有入门故事。
每日承诺：团队每天检查一次，而不是站起来。 他们将签到的时间限制为15分钟。 他们问这些问题：

• 你昨天完成什么工作？和谁在一起？ （加强了人们一起工作的想法）
• 您现在在做什么，和谁在一起？
• 你有什么障碍？

由项目主管而不是命令/控制者来管理障碍。
该试点项目有两个经验丰富的敏捷人员：项目经理和开发人员。 两者都是仆人领袖。

测量：燃尽图，阻隔图

试点团队已经在一起六个月了，并取得了成功。 这不是Scrum。 不是看板 它是敏捷的并且正在工作。 他们准备开始另一个项目团队，以吸引人的方式工作。

示例2：将项目经理与看板，筒仓团队一起使用

这是一个产品开发组织，在意大利的开发人员，在印度的测试人员，在纽约的更多开发人员，在加利福尼亚的产品所有者和项目经理。
该组织首先尝试迭代，但是团队无法完成任务。 问题在于故事太大。 通常，我建议使用较小的迭代，但其中一位开发人员建议将其移至看板。

纽约开发商面临的问题是他们无法咀嚼的问题更多。 因此，一切都没有动摇。 意大利开发人员拥有一个委员会，工作确实在整个委员会中进行。 这些团队每天为董事会拍照，并在基于项目的Wiki中共享工作。 这使总部位于纽约的开发商可以看到整个意大利的工作进展。 并且，这鼓励纽约人打电话给意大利人并提出一些问题。 那帮助纽约人通过与产品所有者合作来改变他们的工作规模。

现在，为什么纽约人本来有这样的麻烦？ 由于开发人员比产品所有者“知道得更好”，因此他们在最初将故事转换为建筑功能时就将其更改为建筑功能。 （现在他们不这样做了。他们将故事保留为真实故事。）
发布计划：加利福尼亚州的管理人员使用敏捷的路线图进行计划。 他们具有在接下来的6周内每周计划的功能，并且在此之后每季度采用更多方法。

迭代计划：没有迭代计划，因为他们正在使用看板。

每日承诺：因为他们使用看板，所以不需要每日承诺。 他们作为技术团队每周都会进行几次签入，以确保他们不会造成瓶颈，并确保他们遵守WIP（在建工程）的限制。

一方面，纽约和意大利的开发人员团队都创建了自动化测试，以便测试人员可以赶上并保持赶上回归测试的步伐。 他们每两周添加一次类似的故事，并且还清自动测试债务。

项目经理密切关注在制品，正在进行中。 项目经理还督促产品负责人保持进来的工作队列的完整和适当的排名。 产品负责人是臭名昭著的改变传入工作队列中的所有时间。 项目经理确保团队进行回顾，并且不清楚如何在这样的分布式团队中进行回顾。 项目经理不确定他们的回顾工作是否有效，并已开始制定障碍清单，以确保团队对他们的障碍透明。

度量：累积流量，将功能发布到产品中的平均时间。

示例3：将项目经理与迭代以及看板团队和筒仓团队一起使用

在这里，开发人员在马萨诸塞州剑桥，产品负责人在旧金山，测试人员在班加罗尔，项目经理总是在某个地方飞行，因为项目经理在多个项目中共享。 开发人员了解时间盒迭代，因此他们使用时间盒。 高级管理人员已决定解雇所有本地测试人员，并在开发人员的反对下购买便宜的测试人员时间，然后将测试移至班加罗尔。 印度的测试人员非常聪明，并且不熟悉该产品，因此开发人员建议测试人员在迭代过程中逐个功能地测试功能。

项目经理建议他们使用累积流程图和周期时间测量值，以确保开发人员对测试人员的开发速度不会太快。 起初，仍然为失去“测试人员”而感到不安的开发人员对此感到不安。 然后，他们意识到了这一说法的真实性，并开发了这个看板。

您可以在此板上看到四个项目正在等待系统测试。 哦哦 开发人员超出了测试人员的能力。 这正是看板可以向您显示的内容。

测试人员并不愚蠢或缓慢。 他们是新的。 他们跟不上开发人员。 这是生活的事实，而不是生活的奥秘。 开发人员必须采取某种方式来帮助测试人员，否则整个项目将失败。 他们在时间盒中工作以及使用看板的原因是，他们有几个合同可交付成果，管理层祝福他们的小小心灵。 时间框允许团队或产品所有者与客户见面并向他们展示进度。 （他们在决定我上次与团队合作时会见谁。）看板委员会帮助使进度更加透明。
迭代计划：产品负责人和项目经理共同制定敏捷功能路线图，产品负责人对此负责。 产品所有者拥有并生成积压。 在迭代开始时，产品负责人和敏捷项目经理向团队提出了一个稻草人迭代积压。 他们很难找到让每个人都醒来并发挥作用的迭代计划时间，祝福高级管理人员的小小的心灵。

日常承诺：他们进行交接，互相询问当天完成的工作以及存在的障碍。 如果您已阅读“ 管理它”！ ，您知道我将三个问题修改为“您完成了什么，您打算完成什么，您的方式如何？”
度量：累积流量，将功能发布到产品中的平均时间。 他们正在试验燃尽图和障碍图。 他们仍然无法使测试人员加快速度。

是的，他们在每次迭代结束时进行回顾。 是的，产品所有者拥有积压订单。
我将在最后一部分总结下一个条目。

（想要学习在您的地理位置分散的团队中更有效地工作吗？请与Shane Hastie和我一起参加2012年4月17日至18日的研讨会 。）

参考：来自JCG合作伙伴的 地理分布团队的敏捷生命周期 ，第1部分 ， 地理分布团队的 敏捷生命周期 ，第2部分和地理分布团队的敏捷生命周期，第3部分   Johanna Rothman，《 产品开发管理》博客。

翻译自: https://www.javacodegeeks.com/2012/03/agile-lifecycles-for-geographically.html