下载掌阅APP，畅读海量书库
立即打开
Tailwind Gears选择了两个团队开始他们的DevOps转型，将这两个团队迁移到GitHub作为新的DevOps平台。这个战略性的决定是将所有内容都移动到GitHub，并使用GitHub Projects和GitHub Issues来管理工作。这也使得需要在监管环境下工作的一些团队能够实现端到端的可追溯性。同时，在迁移到新平台时，开发流程也应该得到调整。
其中一个试点团队已经使用Scrum一年多了，他们使用Jira来管理他们的待办事项，并以3周的迭代周期（sprint）为单位工作。对迭代周期的仔细分析显示，在每个周期中，有很多问题无法解决。此外，大多数问题都是从周期开始同时处理的。当被问及时，团队报告说他们在周期开始时计划了所有的工作，但由于依赖企业的ERP系统，有些工作被阻塞了。当被工作阻塞时，开发者开始处理另一个任务。此外，一些开发者仍然需要处理一些他们的旧项目。他们从反馈系统中接收工单（ticket），并且必须提供第三级支持。这些任务很难计划，并导致团队中其他依赖这些开发者工作的开发者需要等待。
为了在新平台上开始工作，我们将从Jira导入所有未关闭的需求，并将其标记为需求、计划和业务。如果有新的任务出现，我们同意手动添加一个新的问题，并将其标记为错误、未计划和IT。我们创建一个单独的泳道来跟踪这些问题，因为它们通常是具有高优先级的现场问题。为了自动化集成，我们创建了我们的第一个团队问题，将其标记为基础设施、计划和团队，并将其置于待办事项列表的顶部。
为了减少计划和等待时间，并建立更具拉动性（pull-based）的工作流程，我们同意不计划整个迭代，而是专注于待办事项列表中的前三个需求。团队将这三个项目的工作细分，并为正在进行中的任务建立了一个5个工作项的WIP限制。
第二个团队仍然使用经典的瀑布式开发；他们的需求在IBM Rational DOORS中，他们习惯根据规范文件进行工作。为了转向更加敏捷的方式，一些新成员加入了团队：
●一位敏捷教练，担任Scrum Master的角色。
●一位需求工程师，担任产品负责人的角色。
●一位来自架构团队的架构师，负责在开发开始之前更新软件架构。
●一位质量工程师，负责在发布应用程序之前进行测试。
为了开始工作，我们将需求从DOORS导出并导入GitHub Projects中。我们保留DOORS ID以便能够将我们的待办事项追溯回原始需求。
在为第一个需求拆分工作时，我们发现工作量太大，无法在一个迭代周期内完成。产品负责人将需求拆分成多个小项，以减少批处理大小。对于最重要的两个项的拆分显示，每项都可以在大约1周内完成。团队需要为架构师和质量工程师预留一些时间，他们确信这两位可以帮助团队完成一些任务。对于团队而言，这仍然比将工作移交给另一个团队的等待时间更短。