如果您刚开始使用小组模式，您可能不确定您的团队顺利运作需要哪些角色。 我们 IBM 数字业务集团的小组模式基于 Spotify 小组框架。 从高层次来看，小组是一个小型的跨职能团队，拥有自主权来完成他们的小组任务。 小组任务和跨小组优先级在组织层面设定。 然后在每个小组内部，他们决定“构建什么、如何构建以及在构建过程中如何协同工作”。
我们稍微调整了 Spotify 小组模式，以适应我们自己的工作风格。 对我们来说，一个关键的区别是，我们的小组比 Spotify 的小组寿命更长。 我们组织中的一些小组将持续几个月，而另一些小组将持续几年。 构建和运营新服务的小组往往是长期存在的，而使用现有服务构建新事物的以任务为导向的小组往往是短期存在的。
这里的关键要点不是我们分配角色职责的方式是最好或唯一的方式。 事实上，我们自己的组织内的小组之间存在一些差异。 最重要的是，让所有相关人员都清楚地知道谁负责什么。 也许您会在这份职责列表中看到一些您以前遗漏的东西。 那么，让我们深入探讨第一个角色。
人力资源经理/DevOps 教练
一线经理代表业务。 他们还担任团队的导师和教练。 我们的许多经理曾经是技术主管、项目经理或产品经理，他们选择承担更多的人员管理责任。 他们处理以下任务
- 人员配置
- 人力资源问题
- 资金（采购、报销等）
- 开发规范（代码审查指南、测试覆盖率等）
- 发布管理规范（支持计划、灾难恢复计划等）
- 合规性（商业行为、可审计性、安全性等）
- 公司倡议
- 繁文缛节和文书工作
- 消除障碍（设备需求、技术需求、未满足的依赖项等）
- 职业规划与发展（需要改进的领域、拓展任务、重新分配）
- 敏捷流程指导
小组负责人
小组负责人是每个小组的主要利益相关者。 他们拥有小组工作的内容。
小组负责人从粗略定义的史诗和长期业务计划开始。 从那里，他们定义和确定里程碑、难点和故事待办事项的优先级，以指导团队的工作。
- 定义故事待办事项并确定其优先级
- 故事采用以下格式：“作为 [谁]，我想要 [什么]，因为 [原因]”。
- 故事必须包括描述、商业价值和验收标准。
- 考虑惊艳/愉悦因素
- 我们也可以包括技术基础故事
- 与其他小组负责人合作管理其他小组的优先级
- 确定即将到来的故事所需的活动并计划其优先级
- 设计工作
- A/B 测试
- 用户研究
- 其他客户反馈
- 与技术主管和 Scrum Master 安排并运行每周故事审查会议。 在这些会议上，他们确保故事具有
- 明确定义的验收标准和假设
- 明确定义的依赖项和先决条件
- 根据需要的设计和 A/B 测试
- 确定哪些故事已准备好进行规模评估并计划冲刺
- 与开发人员安排并运行每周故事规模评估会议。 由于早期的审查会议，故事应该已经清晰且准备好进行规模评估，因此在规模评估会议上，团队可以讨论并快速评估故事的规模。
- 在故事完成后，审查它们以确保它们符合验收标准
- 参加冲刺结束回顾
技术主管
技术主管决定如何实施小组的故事。 首先也是最重要的，他们是小组的贡献成员，我们确实希望他们编写代码、配置系统等等。 他们以身作则，并且对小组内的技术决策拥有最终决定权。
他们的其他一些职责包括
- 定义组件边界和接口
- 帮助小组负责人和 Scrum Master 定义和改进故事
- 与 Scrum Master 协商选择当前冲刺的故事
- 从待办事项列表的顶部
- 定义明确
- 没有未满足的依赖项或障碍
- 将任务添加到 Kanban 板/冲刺计划
- 负责故事的交付； 故事必须按时满足验收标准
- 负责技术债务并指出必须完成的技术基础工作
- 与开发人员安排并运行故事分解会议。 在故事分解会议上，团队将故事分解为任务，并将任务按逻辑优先级顺序排列。
- 安排并运行每周学习/团队建设活动
项目经理
项目经理协助人力资源经理和小组负责人进行协调任务。 并非所有小组都配备专门的项目经理； 在这种情况下，工作通常由人力资源经理和小组负责人分担。
项目经理执行以下任务
- 创建状态报告
- 在其他小组上提出需求
- 从其他小组获取状态更新
- 计划非开发活动，例如翻译和全球化
- 完成发布管理活动，例如安全审查和开源审查
- 提供财务审批
- 管理设备订单和采购订单
- 跟踪机器和办公空间使用情况
- 管理维护请求
- 项目管理办公室的任何其他活动
Scrum Master
Scrum Master 保持 Scrum/Kanban/Scrum-ban 流程顺利进行。 我们允许各个小组自行决定他们希望在团队内管理其工作的方式，只要他们使用史诗和故事来沟通跨团队的依赖关系。 配备专门项目经理的小组通常会将部分或全部职责交给项目经理； 其他小组则将这项工作分配给技术主管。 许多小组都有轮换 Scrum Master，因此每个人都更多地了解敏捷软件开发方法。 通常，值班开发人员将成为本周的 Scrum Master。
Scrum Master 执行以下任务
- 运行所有每日站立会议
- 保持会议简短，并专注于“我昨天做了什么，我今天要做什么，任何障碍”
- 根据需要将讨论移至 Scrum 后停车场
- 缺陷分类，以确定哪些缺陷需要立即处理，哪些稍后处理
- 将重要/紧急缺陷添加到 Kanban 板或冲刺计划中以进行修复
- 调查部署错误并修复它们
- 在冲刺回顾期间进行演示
- 记录和处理障碍
- 跟踪和跟进外部缺陷
- 跟进被阻止的缺陷
- 安排并运行每周团队建设活动
- 运行每周回顾会议并记录回顾会议结果。 回顾会议要求团队成员写下并讨论哪些方面进展顺利或帮助他们完成工作，哪些方面进展不顺利或拖慢了速度，以及他们将来可以做得更好的方面。
小组成员
所有小组成员都遵循一些通用指南来管理他们的工作
- 实施 Kanban 板/冲刺计划上的任务。
- 缺陷的优先级高于新任务
- 当您准备好时，选择一个新的最高优先级任务。 当您准备好时
- 您已审查了自己的代码
- 单元测试和功能测试已就位
- 您的代码已提交审查，在拉取请求中
- 您已要求小组审查您的更改
- 您已审查了小组的所有未完成拉取请求
- 您已解决了对您的更改的未解决审查意见
- 您在审查过程中最多只有一个其他任务
- 优先选择您不知道如何实施的任务，这样您就可以不断学习
- 任务可以单独、成对甚至集体实施
- 学习实施任务所需的技术和框架
- 弄清楚您自己能做些什么，但不要害怕寻求帮助
- 对于使用 Scrum 的团队：一旦冲刺的故事完成，您可以从事您喜欢的工作
- 对于使用 Kanban 的团队：您可以将 20% 的时间分配给副项目，只要它们在某种程度上对我们公司或我们的客户有利
- 尝试新技术并与团队分享您的学习成果
- 一些小组还运行自己的运营基础设施。 这些小组将有轮班值班。 一旦技术主管认为开发人员已准备好并能够处理中断，开发人员就会加入轮班值班。 我们喜欢在冲刺回顾中提及这一点，并为晋升到此级别的开发人员欢呼。
提交者/+2
Github 提交者或 Gitlab +2 是质量的守护者。 他们是有权将代码合并到主分支的人。 这很重要，因为在持续交付系统中，将代码合并到主分支会触发部署到生产环境。 因此，这是一个责任重大的职位。
提交者权限是通过成为优秀的code reviewer获得的，提名新的提交者取决于每个存储库的当前维护者/提交者。 我们有一个严格的代码审查流程，基于 OpenStack 和 Github 贡献模型。 所有代码更改，无论是缺陷修复还是新功能，都必须经过至少两名非发起人的人员审查和批准，其中一人必须是提交者。
如果开发人员习惯性地以不负责任的方式行事，或者更常见的情况是，如果开发人员停止在代码库中工作的时间足够长，以至于忘记了如何维护它，则可能会失去提交者权限。
通常，我们的提交者是同一批 24/7 值班支持应用程序的人员。 也就是说，所有小组成员都会帮助修复生产环境中的关键问题，而不仅仅是提交者。
测试和运营小组
您可能会问，一个期望小组拥有和运营自己的运营的组织，为什么会有一个测试和运营小组？ 简短的答案是，拥有一些真正的测试和运营专家来教育新团队、评估新工具和分享最佳实践仍然很有帮助。
各个小组拥有自己的单元测试和功能测试。 需要代码覆盖率报告，我们的目标是 100%。 低覆盖率数字是系统和集成测试的风险。 如果某个小组报告的测试覆盖率较低，我们只需要求他们计划每个冲刺增加他们的测试覆盖率，直到他们达到完全测试覆盖率。
我们测试和运营小组的测试人员编写自动化测试，用于以下方面，例如
- 端到端、跨组件流程
- 多浏览器支持
- 跨组件的全球化和本地化
- 性能、可扩展性、安全性等
- 自动化测试可能会使构建失败/阻止部署
- 我们的测试人员还进行一些创造性的手动和自由形式的测试
这些专家帮助其他团队学习如何使用新的测试工具。 他们通过文档、培训课程和结对编程来实现这一点。
我们测试和运营小组的运营专家教导其他人如何设置和调整
- 生产监控器
- 警报
- 升级
- 轮班值班
- 日志收集和分析
- 网络管理
- 内容分发网络
该团队还维护运营仪表板，帮助我们可视化跨组件的系统健康状况。 最后，该团队为运行实验（A/B 测试等）设置框架。
结论
这就是 IBM 数字业务集团的小组模式的简要概述。 我们已经使用大约 80-90 个小组进行了三年。 希望您已经掌握了一些帮助我们一路走来的最佳实践。
我要感谢 Richard Gebhardt 对我们的 IBM 小组模式角色和职责的贡献。
[请参阅我们的相关报道，如果这 7 个部门不买账，您的 DevOps 尝试将会失败]
3 条评论