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

敏捷生命周期

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

他们中的大多数人都是以这种方式开始的：有人参加了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

敏捷生命周期