敏捷团队如何处理非敏捷组织结构？

Question

我的整个职业生涯都是在同一个雇主工作(现在已经13年了)。我们很重要而且处理敏感数据。技术不是我们的产品，但它有助于支持我们的主要产品。

我想知道其他大型组织是如何组织的。在这里，我们有许多功能领域在IT中。我们有单独的部门负责云工程、身份管理、应用程序生命周期管理(维护构建服务器和构建定义)、数据库管理员和信息安全。这些不同的地区都有各自不同的优先事项和行军命令。

我是开发scrum团队的成员。我们代表底部的水平条。我们执行跨越上述所有功能领域的项目工作。这对我们来说意味着，当我们想要执行一个项目时，我们会向所有这些区域提供服务请求票。通常，一个新的项目将开始于我们通过大约50张票请求服务。这让我们开发人员都快疯了。

大公司就是这样做的吗？在科技不是他们的主要业务线的公司中，这可能更有可能发生吗？你在角色中看到了什么样的替代结构？

Answer 1

过去，我曾用我认为是“影子IT”的评论中的人来处理这个问题。如果我们需要一个庞大的伐木组织做些什么，我们就想出一种方法，把我们当时需要的东西做得足够好，并计划在将来某个时候整合外部团队的结果。

例如，如果我们需要获得一个新的VM来运行二进制包服务器(nuget等)，但我们知道这可能需要一个月的时间，我们将首先在我们控制的地方设置一个VM。我认为这是一种原型化，这样我们就可以在向IT提出潜在的昂贵请求之前确保它的工作正常。我们确保在我们这一方实现一些东西，这样一旦“真正”服务器就位，我们就可以轻松地切换它。

如果您对配置数据库具有依赖关系，则可以执行相同的操作。在开发人员框上做一段时间，然后切换到“真正的”一个一旦它可用。

这种方法的一个优点是，您可以按照自己的速度工作，这会迫使您确保您设计的系统不会严重地交织在一起。

Answer 2

当您查看常见的敏捷实践时，通过简短的迭代和维护一个可部署的代码库，您实际上可以做很多事情。本质上，您将保持事物的灵活性，直到您准备好部署。在这一点上，你必须使用大组织现有的任何流程来实现。

支持大的重流程所需的所有内容都会作为sprint中的任务进行跟踪。如果有文件必须在某一特定日期提供，您可以将任务添加到适当的sprint中，并将文件输入。

最大的问题是在大组织里完成任务的成本。因此，您最终通过请求资源来进行补偿，这比您能够合理地确定您能够获得资源的时间要早得多。

对于我们来说，一个发行版看起来可能是这样的(每一颗子弹一到两颗子弹)：

• 冲刺1：
  • 成功所需的基础设施/软件请求
  • 首先实现必须具备的特性。

• Sprint 2:偿还技术债务/更多功能
• Sprint 3:修复bug/回归测试
• Sprint 4:提交发行版，计划下一个版本

这只是一个高级结构的例子。一旦我们屈服于大组织(大CM)，那么它就有了自己的生命。我们有一个团队跟踪这一点，并准备好在最终批准时执行安装。

Answer 3

如果你认为这对你有用的话，你可以在你自己的部门里保持敏捷。但是，当涉及到与利益相关者和(或)供应商的沟通时，不管出于什么原因，他们都不会合作，而且你没有上级管理层的支持来改变这种状况，因此没有必要踢死那匹死马。顺其自然吧。

票务系统，在同一个组织内做生意对生意，它可能是根深蒂固的。你最好的办法可能是学会理解官僚主义，让它为你服务。提前想一想，尽早提出要求，并要求比你所期望的更多。

不可能没有所谓的敏捷方法，敏捷不应该仅仅因为它是你所知道的全部而成为一个目标。你必须处理的看似僵化的系统可能会有一些意想不到的可能性。它可能有助于先问：“我要做什么才能得到这个或那个？”问问那些你认为是系统代表的人，你所经历的这些人是令人沮丧的。:-)