改变团队规划、构建和发布软件的方式
SEYA Group 所实践的企业转型，是改变一个软件组织规划、构建和发布系统的方式：谁拥有什么、一项变更如何到达生产环境、哪些工具把它送到那里。它面向的是发布流程本身已经成为业务瓶颈的组织。
适用对象
发起了“DevOps”或“数字化”计划、需要它真正改变团队工作方式、并有一个可以照着执行的顺序的 CIO。看到团队之间的交接、工单和等待时间、却分不清哪些是必要的 IT 总监。工具链是一次一次采购堆出来的、已经与人们的交付方式不再匹配的工程负责人。被交付了转型任务、需要一份写明先做什么的路线图的 IT 项目经理。
如果问题是某一个应用需要重建，那属于 云原生开发。 如果是一组已知的工作负载需要迁移，那属于 云平台与迁移。 本页面讲的是跨团队的运营模式。
我们解决的问题
- 工作被拆散在工单和团队之间，没有人对它所服务的产品负全责。
- 发布需要变更委员会、一个周末，以及一个记得手工步骤的人。
- 构建和部署工具的选择与它们本应服务的发布路径脱节。
- 对于哪些交付实践真正在用，没有一份共享且诚实的描述。
- 来自高层的转型指令，却没有商定的第一步。
您将获得
- 交付评审。将您的团队目前规划、构建、测试和发布的方式与一组简短的有效实践进行对比，直白地写出差距，并对建议的改变排序。
- 战略与路线图。一份有先后顺序的交付改进计划，与您指出的约束条件挂钩，写明先做什么并记录原因。
- 运营模式。谁拥有一个产品、一项需求如何到达生产环境，以及哪些交接因为所有权已经明确而可以取消。用您团队自己的语言编写，供他们执行。
- 工具链设计与构建。用于集成、测试和发布范围内系统的工具，围绕这些系统设计，并在简报包含时予以构建。
- 设计工作坊。简报要求时，一次由我们引导的工作会议，把一个产品问题转化为团队可以立即开始的、范围明确的待办清单。
项目如何开展
- 发起人沟通。您描述转型指令、范围内的团队，以及最想消除的那个约束。
- 交付评审。对各团队进行访谈和观察，阅读当前工具链，并形成一份可以在内部分享的书面基线。
- 路线图与运营模式。我们起草两者，与将要在其中工作的人一起评审，然后修订。
- 首批改变。路线图上的首批事项与相关团队一起落实，包括商定范围内的工具链构建，让计划尽早接受现实检验。
- 交接。您的领导者拥有路线图和运营模式；如果您想要第二次度量，评审可以在之后重复进行。
技术范围
工具链工作跟随您运行的系统。SEYA 曾在 Microsoft 技术栈（Team Foundation Server、Octopus Deploy、PowerShell）上，也曾用 Jenkins、GitHub Actions 和 Terraform 在 AWS、Azure 和 Google Cloud 上设计和构建交付流水线。运营模式工作与平台无关：产品所有权、发布流程和环境管理适用于任何工具链。
您需要具备的条件
一位对范围内团队拥有权限的高管发起人、为访谈和观察提供与实际做事的人接触的机会，以及愿意让现状被如实写下来。改变由您的团队来做；SEYA 负责设计、引导，并在商定的范围内构建，不会接管您的发布流程。
本页不在范围内的内容：虚拟桌面、数字化工作场所产品和远程工作区搭建；流水线内部的安全检查，这属于 安全与 DevSecOps；以及是否采用云的决策，这属于 云采用。如果您需要在一项明确的工作上增加工程人手，请参阅 规模化软件工程。
安全
交付路径内部的安全检查是单独的范围，在 DevSecOps 页面有说明。转型路线图可以为这项工作排序，但它本身并不能让流水线达到某个指定标准。
相关案例
常见问题
这是一次组织重组吗？
有时会导向重组，如果在现有结构下无法把所有权理清，我们会直说。出发点是工作流和它的归属；结构由此而来。
你们会让我们购买新工具吗？
只有在现有工具不支持您需要的发布路径时才会。评审经常发现，问题在于工具之间如何衔接，而不是用的是哪些工具。
交付评审需要多长时间？
随范围内团队和系统的数量而变化。我们在发起人沟通中商定清单，评审结果既写给参与的团队，也写给管理层。
之后路线图归谁所有？
归您。路线图、运营模式和任何流水线代码都是为您的组织编写的，存放在您的系统中。
你们如何与我们的团队协作？
亲身在场。访谈、观察和工作会议都与实际做事的人一起进行，路线图上的首批事项也与他们一起落实。
如果发布流程已经成为所有人都在等的那件事，请 预约交付评审沟通， 我们会告诉您评审会为您的团队覆盖哪些内容。
联系我们
发送有关云、平台、数据或可靠性项目的咨询。营销邮件在表单中为单独选项。