组织敏捷程序：第1部分，简介-CSDN博客

如果您想要组织一个敏捷程序，那么您可以在敏捷程序中管理功能流，则有一些选择。这取决于程序的大小。敏捷程序中的通信结构很重要。

您的敏捷程序有多大？

我认为程序是小型，中型和大型的。是的，这很笼统，对我有所帮助。一个小程序最多可容纳三个团队。一个中等计划是四到九支球队。一个大型程序是十个团队或更多。您的里程肯定会有所不同。因团队规模而异。

这就是为什么我认为这些准则有用的原因。还记得我写《团队规模为何重要吗？如果您尝试绘制一个5人团队的沟通路径图，那么您将看到一个类似于左侧图的图。

现在，您只增加了一个人，并且您将通讯路径增加了五个。这就是为什么团队规模在您考虑自己的程序以及您是否拥有小型，中型或大型程序时都非常重要的原因。

如果您有四人团队，而又有三个团队，那么您的程序很小。如果您有十人团队，那么您可能还会有一个小程序。但是你在推它。您可能有中等大小的程序。您知道在数据大小改变时有时必须在代码中更改数据结构吗？程序也会发生同样的事情。您想考虑您正在使用的组织和沟通结构，以确保它们可以增强您正在做的产品开发，而不是使您退缩。

请记住，敏捷团队依靠成员之间每天的微小承诺来取得进步。您尝试在组织中的功能上取得进展的团队越多，您就越希望加强这种沟通。因此，您想选择一个可以增强交流的程序组织。

程序也有沟通途径

具有实践社区的技术计划

在敏捷计划中，技术项目团队相互承诺。他们不仅在团队内部而且在团队之间都有沟通路径。他们交流的方式可能会有所不同，具体取决于程序是小型，中型还是大型。您如何组织该计划将改变您的沟通方式。您有选择。

许多人将Scrum用作他们的敏捷选择方法。 Scrum是一个很棒的项目管理框架。它是为5-7人并置的团队而设计的。

如果您想扩展Scrum，尤其是对于小型程序，则许多人会使用一种称为Scrum-of-Scrums的技术。

Scrum of Scrums是一个层次结构

我没有反对Scrum-of-Scrums。在我看来，这不是很多回报，而是很多开销，但是它对很多人有用。而且，更重要的是，这是一个很多比他们在做什么更有效。你了解我。如果它更有效并且成功了，那就继续吧！

而且，SoS是一个层次结构。 Scrum团队在站在一起时会聚在一起，然后将他们的Scrum Master送到另一个站，在那里Masters会聚在一起并每天讨论跨程序风险。然后，他们必须与团队重新团结起来。是的，他们每天都这样做。

因此，问题在上链和下链都存在。现在，在一个小型程序（例如三个团队）中，尤其是如果团队很小并且人们在敏捷方面训练有素，并且他们习惯于采用端到端编写的小功能，则人们可以自己解决问题。爱丽丝走到某人并说：“嗨，鲍勃，我有问题。你能看看这个，告诉我怎么了吗？”

但是，我看到的是，即使在小型程序中，也没有将团队并置在一起。爱丽丝与鲍勃不在同一时区。爱丽丝需要她的Scrum Master与Bob的Scrum Master进行协调。而且，因为协调是Scrum Master的工作，所以协调也不是任何其他人的工作。

让我重复一遍。因为促进和维护协调工作是Scrum Master的工作，所以这样做不是别人的工作。为什么？因为其他所有人都忙于完成其功能。这是人的本性。如果这是应该的方式，我们会将问题推到层次结构上，以供其他人删除。

这不是Scrum的错。这是人类的事情。这就是我们的制造方式。

添加实践社区

Scrum Master不能也不应跟踪测试，体系结构，UX和数据库以及与和……的所有细节，这取决于您的程序。您很可能需要每个团队中与实践社区相关的人员。而且，您需要与计划团队联系的每个团队的成员。因此，您的图片更加混乱。但是，如果您拥有更有效的程序，谁会在乎您是否一团糟？

这张图片内置了一个实践社区。您可以使用SoS进行此操作。您不需要权限。现在，由只有5人的小型团队组成的三团队计划，您可能不需要它。但是，如果您有10人团队，或者您的地理位置分散，则可以。

问自己以下问题：我们是否要在每个团队中完成每个功能的每个迭代？我们有相互依存的问题吗？而且，如果您的团队规模超过三支，则几乎可以肯定需要不同的结构。如果您不能对这些问题回答“是”，或者您无法正常使用程序中的功能，则需要使用其他结构。

实践社区的帮助。

精益工程

对于那些想知道的人，是的，您始终可以采用精益方法。这适用于任何规模的团队。我将为中型和大型团队更多地讨论这一点，因为精益确实很重要。所以挂在那里待会儿。

讨论的重点是团队之间的沟通结构，而不是各个团队应在程序中使用的流程或生命周期。作为项目经理，我不关心团队使用什么，只要他们履行对项目的承诺即可。希望您不要对此感到惊讶。稍后，将对此进行更多介绍。

使用网络而不是层次结构

除了使用层次结构，您还可以选择使用网络，即使您使用的是Scrum。即使您只有一个三团队计划。

当拥有团队网络时，您不必使每个人都与其他人互连。而且，您不仅需要相互连接的Scrum Master。您需要团队紧密联系自己。而且，您需要团队之间的联系松散。这就是所谓的小世界网络。（不要唱迪士尼的歌。不，我告诉过你不要！）

如果您听说过凯文·培根（Kevin Bacon）六度分离法，那就是它的工作原理。您不需要所有团队都相互连接，只要它们都与其中一些连接即可。
对于三团队计划，所有团队都将联系在一起。这很容易。由于在敏捷中我们希望鼓励人们进行协作，因此小世界网络模式是可以使用的合理模式。

在一个小的世界网络中，如果Bob和Alice有问题，他们会互相问。他们有义务这样做。如果他们不知道，他们应该问对方，这是他们的义务，问别人谁可能知道。那个人不一定是Scrum Master。或敏捷项目经理。或程序经理。是他们网络中的某人。这个问题不会涉及到层次结构。它通过网络。

这不是无政府状态。这是协作。这是来自Clay Shirky的《每个人都来自这里：组织的力量》一书

人们必须互相协作才能完成任何事情的协作生产比简单的共享要困难得多，但是结果却可以更深刻。新工具允许大型团体通过利用非财务动机并通过不同程度的贡献来进行协作。

我画了五个团队的照片，因为尽管小型世界网络对于小型程序很有用，但您确实可以看到它对于中等程序是如何开始发光的。对于小型程序，请使用最简单的方法。（无论如何都这样做。）真正的问题是：随着程序的增长，您在做什么规模？

对于我的客户，答案是否定的。实际上，对于我的客户而言，Scrum of Scrums甚至没有为三个团队工作。为什么？因为他们没有得到培训或指导。他们试图从书本中学习Scrum。他们已经派一个人去上一堂课，并试图以这种方式学习。这不是学习任何有关敏捷的成功方法。

当我的客户放弃Scrum of Scrums方法并恢复到网络（这是他们以前在组织中完成工作的方式）时，他们就会完成工作。不要问我为什么他们认为所有问题都必须通过Scrum Master来解决。我不知道。我确实知道网络方法适用于他们。而且，对于可怜的Scrum Master / Agile Project Manager来说，其开销要少得多