总结

为了开始他们的 DevOps 转型，Tailwind Gears 选择了两个团队，将其迁移到 GitHub 作为新的 DevOps 平台。

战略决策是将一切迁移到 GitHub，并使用 GitHub 项目和 GitHub 问题来管理工作。这也使得某些在受监管环境中工作的团队所需的端到端可追溯性得以实现。此外，开发流程应与迁移到新平台的过程中保持一致。

其中一个试点团队已经使用 Scrum 工作了超过一年。他们使用 Jira 管理他们的待办事项，并以 3 周为一个迭代周期。仔细查看迭代发现，在每个 Sprint 中，有很多问题无法按时解决。此外，大多数问题从 Sprint 开始就同时被处理。当被问及时，团队报告称他们会在 Sprint 开始时规划所有工作。但由于依赖公司 ERP 系统，一些工作被阻塞。当被阻塞时，开发人员会开始处理其他任务。此外，一些开发人员仍然有旧项目的职责。他们会从帮助台的工单系统接收票据，并需要提供三级支持。这些票据难以规划，导致其他依赖这些开发人员的团队成员需要等待。

为了开始使用新平台，我们将所有来自 Jira 的开放需求导入，并标记为需求、计划和业务。如果有票据进来，我们同意手动添加新问题，并将其标记为缺陷、未规划和 IT。我们创建一个单独的泳道来跟踪这些问题，因为它们通常是生产环境中的问题，具有较高优先级。为了自动化集成，我们创建了第一个团队问题，并将其标记为基础设施、计划和团队，并将其移至待办事项列表的顶部。

为了减少计划和等待时间，并建立更加拉动的工作流，我们同意不计划整个 Sprint，而是专注于待办事项列表中排名前三的需求。团队将这三项工作拆解，且我们为正在进行的任务设置了 5 个的 WIP 限制。

第二个团队仍然使用传统的瀑布模型；他们的需求存储在 IBM Rational DOORS 中，并习惯于基于规格说明文档来工作。为了转向更敏捷的工作方式，团队新增了几名成员：

为了开始工作，我们从 DOORS 导出需求并将其导入到 GitHub 项目中。我们保留 DOORS ID，以便能够追溯到原始需求的待办事项。

在拆解第一个需求时，我们发现工作量对于一个 Sprint 来说太多。产品负责人将需求拆分为多个小项，以减少批处理的大小。对于最重要的两个项，拆解结果显示，每个项大约需要 1 周的时间。虽然架构师和质量工程师仍然会有一些等待时间，但团队相信他们有任务可以帮助这两位成员完成。对于团队来说，这样做比将工作交给其他团队等待要快得多。