跨职能 DevOps 团队中的 8 个角色

图片来源：

WOCinTech Chat。由 Opensource.com 修改。 CC BY-SA 4.0

如果您刚开始使用小组模式，您可能不确定您的团队顺利运作需要哪些角色。我们 IBM 数字业务集团的小组模式基于 Spotify 小组框架。从高层次来看，小组是一个小的、跨职能的团队，拥有执行其小组任务的自主权。小组任务和跨小组优先级是在组织层面设定的。然后在每个小组内，他们决定“构建什么、如何构建以及在构建时如何协同工作”。

我们稍微调整了 Spotify 小组模式，以适应我们自己的工作风格。对我们来说，一个关键的区别是，我们的小组比 Spotify 的小组寿命更长。我们组织中的一些小组将持续几个月，而另一些小组将持续几年。构建和运营新服务的小组往往是长期存在的，而使用现有服务构建新事物的以任务为导向的小组往往是短期存在的。

这里的关键要点不是我们为角色分配责任的方式是最好或唯一的方式。事实上，我们自己的组织内的小组之间也存在一些差异。最重要的是，对于每个参与者来说，谁负责什么要一清二楚。也许您会在这个职责列表中看到一些您以前遗漏的东西。那么，让我们深入了解第一个角色。

人力资源经理/DevOps 教练

一线经理代表业务。他们还充当团队的导师和教练。我们的许多经理曾经是技术主管、项目经理或产品经理，他们选择承担更多的人员管理责任。他们处理以下任务

人员配置
人力资源问题
资金（采购、报销等）
开发规范（代码审查指南、测试覆盖率等）
发布管理规范（支持计划、灾难恢复计划等）
合规性（商业行为、可审计性、安全性等）
公司倡议
繁文缛节和文书工作
消除障碍（设备需求、技术需求、未满足的依赖项等）
职业规划和发展（需要改进的领域、拓展任务、重新分配）
敏捷过程辅导

小组负责人

小组负责人是每个小组的主要利益相关者。他们拥有小组工作的内容。

小组负责人从粗略定义的史诗和长期业务计划开始。从那里，他们定义并确定里程碑、目标和故事积压的优先级，以指导团队的工作。

定义故事积压的优先级
- 故事采用以下格式：“作为 [谁]，我想要 [什么]，为了 [原因]”。
- 故事必须包括描述、商业价值和验收标准。
- 考虑惊艳/愉悦因素
- 我们也可以包括技术基础故事
与其他小组负责人合作管理其他小组的优先级
确定即将到来的故事所需的活动的优先级和计划
- 设计工作
- A/B 测试
- 用户研究
- 其他客户反馈
与技术主管和 Scrum Master 安排并运行每周故事审查。在这些会议上，他们确保故事具有
- 明确定义的验收标准和假设
- 明确定义的依赖项和先决条件
- 根据需要进行设计和 A/B 测试
- 确定哪些故事已准备好调整大小并计划冲刺
与开发人员安排并运行每周故事大小调整会议。由于之前的审查，故事应该已经清晰且准备好调整大小，因此在大小调整会议上，团队可以讨论并快速调整故事的大小。
在故事完成后，审查它们以确保它们符合验收标准
参加冲刺结束演示

技术主管

技术主管决定如何实施小组的故事。首先，他们是小组的贡献成员，我们确实希望他们编写代码、配置系统等等。他们以身作则，并且对小组内的技术决策拥有最终决定权。

他们的其他一些职责包括

定义组件边界和接口
帮助小组负责人和 Scrum Master 定义和改进故事
与 Scrum Master 协商选择当前冲刺的故事
- 从积压工作的顶部
- 定义明确
- 没有未满足的依赖项或阻塞器
将任务添加到看板/冲刺计划中
负责故事的交付；故事必须按时满足验收标准
负责技术债务并指出必须完成的技术基础工作
与开发人员安排并运行故事分解会议。在故事分解会议上，团队将故事分解为任务，并将任务按逻辑优先级顺序排列。
安排并运行每周学习/团队建设活动

项目经理

项目经理协助人力资源经理和小组负责人进行协调任务。并非所有小组都有专门的项目经理；在这种情况下，工作通常在人力资源经理和小组负责人之间分配。

项目经理执行以下任务

创建状态报告
在其他小组中提出需求
从其他小组获取状态更新
计划非开发活动，例如翻译和全球化
完成发布管理活动，例如安全审查和开源审查
提供财务审批
管理设备订单和采购订单
跟踪机器和办公空间使用情况
管理维护请求
项目管理办公室的任何其他活动

Scrum Master

Scrum Master 保持 Scrum/看板/Scrum-ban 流程顺利进行。我们允许各个小组自行决定他们希望在团队内管理其工作流程的方式，只要他们使用史诗和故事来沟通跨团队的依赖关系。拥有专门项目经理的小组通常会将部分或全部这些职责交给项目经理；其他小组则将这项工作分配给技术主管。许多小组都有轮换的 Scrum Master，因此每个人都更深入地了解敏捷软件开发方法。通常，值班开发人员将成为本周的 Scrum Master。

Scrum Master 执行以下任务

运行所有每日站立会议
- 保持会议简短并专注于“我昨天做了什么，我今天要做什么，任何障碍”
- 根据需要将讨论移至 Scrum 后停车场
缺陷分类，以确定哪些缺陷需要立即处理，哪些缺陷稍后处理
将重要/紧急缺陷添加到看板或冲刺计划中以进行修复
调查部署错误并修复它们
在冲刺演示期间进行演示
记录和处理障碍
跟踪和跟进外部缺陷
跟进阻塞的缺陷
安排并运行每周团队建设活动
运行每周回顾会议并记录回顾会议结果。回顾会议要求团队成员写下并讨论哪些方面做得好或帮助他们完成工作，哪些方面做得不好或拖慢了进度，以及他们在未来可以做得更好哪些方面。

小组成员

所有小组成员都遵循一些通用指南来管理他们的工作

实施看板/冲刺计划中的任务。
缺陷的优先级高于新任务
当您准备好时，选择新的最高优先级任务。当您准备好时
- 您已审查了自己的代码
- 单元测试和功能测试已就位
- 您的代码已准备好进行审查，在拉取请求中
- 您已要求小组审查您的更改
- 您已审查小组的所有未完成拉取请求
- 您已解决对您的更改的未解决审查意见
- 您的审查过程中没有超过一项其他任务
优先选择您不知道如何实施的任务，以便您始终在学习
任务可以单独、成对甚至集体实施
学习实施任务所需的技术和框架
自己弄清楚您能做什么，但不要害怕寻求帮助
对于使用 Scrum 的团队：一旦冲刺的故事完成，您可以从事您喜欢的工作
对于使用看板的团队：您可以将 20% 的时间分配给副项目，只要它们以某种方式使我们公司或我们的客户受益
尝试新技术并与团队分享您所学到的知识
一些小组还运行自己的运营基础设施。这些小组将进行轮班值班。一旦技术主管认为开发人员已经准备好并且能够处理中断，开发人员就会加入轮班值班。我们喜欢在冲刺演示中提到这一点，并为晋升到这个级别的开发人员欢呼。

提交者/+2's

Github 提交者或 Gitlab +2 是质量的守护者。他们是有权将代码合并到主分支的人。这很重要，因为在持续交付系统中，将代码合并到主分支会触发部署到生产环境。因此，这是一个责任重大的职位。

提交者权限是通过成为优秀的code reviewer获得的，并且由每个存储库的当前维护者/提交者提名新的提交者。我们有一个严格的代码审查流程，基于 OpenStack 和 Github 贡献模型。所有代码更改，无论是缺陷修复还是新功能，都必须经过除发起人之外的至少两个人审查和批准，其中一人必须是提交者。

如果开发人员习惯性地以不负责任的方式行事，或者更常见的情况是，如果开发人员停止在代码库中工作足够长的时间以至于忘记如何维护它，则可能会失去提交者权限。

通常，我们的提交者是那些 24/7 值班支持应用程序的人员。也就是说，所有小组成员都会帮助修复生产环境中的关键问题，而不仅仅是提交者。