使用devops的团队

如果您刚开始使用小队模型，则可能不确定团队要顺利运作需要哪些角色。 我们在IBM Digital Business Group中的小队模型基于Spotify Squad框架 。 在较高的级别上，小队是一个跨职能的小型团队，具有执行小队任务的自主权。 小队任务和跨小队的优先级是在组织级别上确定的。 然后，在每个小组中，他们决定“构建什么，如何构建，以及在构建过程中如何协同工作”。

我们对Spotify小队模型进行了一些调整，以适应我们自己的工作方式。 对我们来说，一个主要的不同是我们的团队比Spotify的团队寿命更长。 我们组织中的一些小组将持续几个月，而其他小组将持续几年。 建立和运营新服务的团队通常是长期存在的，而使用现有服务来构建新事物的面向任务的团队通常是短暂的。

这里的主要收获不是说我们为角色分配职责的方法是最好的或唯一的方法。 实际上，我们自己组织中的班级之间存在一些差异。 最重要的是，所有负责此事的人都非常清楚。 也许您会在此职责列表中看到之前没有的内容。 因此，让我们开始探讨第一个角色。

人力资源经理/ DevOps教练

• 人员配备
• 人力资源问题
• 金钱（采购，报销等）
• 开发纪律（代码审查指南，测试范围等）
• 发布管理规范（支持计划，灾难恢复计划等）
• 合规性（业务行为，可审核性，安全性等）
• 企业举措
• 繁文tape节和文书工作
• 消除障碍（设备需求，技术需求，未满足的依存关系等）
• 职业规划和成长（需要改进的领域，扩展任务，重新分配的领域）
• 敏捷过程指导

小队长

班组长是每个班级的主要利益相关者。 他们所拥有的球队运作上。

团队领导者从松散定义的史诗和长期业务计划开始。 从那里，他们定义里程碑，丘陵和故事积压并对其进行优先排序，以指导团队的工作。

• 定义故事待办事项并确定其优先级：
  • 故事采用以下格式：“作为[谁]，我想[什么]，以[理由]”。
  • 故事必须包含说明，业务价值和接受标准。
  • 考虑哇/高兴因素
  • 我们还可以包括技术基础故事
• 与其他班级一起工作可管理其他班级的优先事项
• 优先安排和计划即将发生的故事所需的活动：
  • 设计工作
  • A / B测试
  • 用户研究
  • 其他客户反馈
• 与技术主管和Scrum负责人安排并每周运行一次故事清理。 在这些会议上，他们确保故事具有：
  • 明确定义的接受标准和假设
  • 明确定义的依赖项和先决条件
  • 根据需要进行设计和A / B测试
  • 确定哪些故事已准备好确定大小并计划冲刺
• 与开发人员安排并运行每周一次的故事大小调整。 借助早期的清理，故事应该已经很清楚并且可以调整大小了，因此在规模会议上，团队可以讨论故事并快速确定故事大小。
• 故事完成后，对其进行复查以确保它们符合验收标准
• 参加冲刺结束播放

技术负责人

技术负责人决定如何执行小队的故事。 首先，他们是该小组的成员，我们确实希望他们编写代码，配置系统等。 他们以身作则，对小组内的技术决策拥有最终决定权。

他们的其他一些职责包括：

• 定义组件边界和接口
• 帮助班长和Scrum主管定义和完善故事
• 与Scrum主管协商选择当前冲刺的故事：
  • 从待办事项顶部
  • 定义明确
  • 没有不满意的依赖项或阻止者
• 向看板/冲刺计划添加任务
• 负责故事的传递； 故事必须按时达到验收标准
• 负责技术债务并指出必须完成的技术基础工作
• 与开发人员安排并运行故事细分。 在故事分解会议上，团队将故事分解为任务，并将任务按逻辑，优先顺序排列。
• 安排并进行每周的学习/团队建设练习

项目经理

项目经理帮助人事经理和班长领导协调任务。 并非所有的团队都有专门的项目经理。 在这种情况下，工作通常由人事经理和班长负责。

项目经理执行以下任务：

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

Scrum大师

Scrum主管使Scrum / Kanban / Scrum-ban流程保持平稳运行。 我们给各个班子留出空间来决定他们想要在团队中管理其工作的过程，只要他们使用Epics和Stories在团队之间传达依赖关系即可。 具有专职项目经理的小队通常将部分或全部这些职责交给项目经理； 其他小队将这项工作分配给技术主管。 许多团队都拥有轮换Scrum Master，因此每个人都可以学习更多有关敏捷软件开发方法的知识。 通常，待命的开发人员将是本周的Scrum管理员。

Scrum管理员执行以下任务：

• 运行所有日常站立
  • 让他们简短些，专注于“昨天的工作，今天的工作，所有阻碍因素”
  • 根据需要将讨论移至Scrum后停车场
• 对缺陷进行分类，以确定现在和以后需要处理哪些缺陷
• 在看板或冲刺计划中添加重要/紧急缺陷以进行修复
• 调查部署错误并修复它们
• 在冲刺回放中出现
• 记录并处理障碍
• 跟踪并跟踪外部缺陷
• 跟踪被阻止的缺陷
• 安排并进行每周的团队建设练习
• 运行每周回顾并记录回顾结果。 回顾会议要求团队成员写下并讨论哪些方面进展顺利或帮助他们完成了工作，哪些方面进展不佳或速度变慢，以及将来他们可以做得更好。

小队成员

所有班组成员均遵循一些一般性准则来管理其工作：

• 实施看板/冲刺计划中的任务。
• 缺陷比新任务具有更高的优先级
• 准备好后，接一个新的优先任务。 在以下情况下您已准备就绪：
  • 您已经审查了自己的代码
  • 单元测试和功能测试到位
  • 在请求请求中，您的代码已接受审核
  • 您已要求小组审查您的更改
  • 您已经审查了班级的所有公开拉取请求
  • 您已对更改发表了出色的评论意见
  • 在审核过程中，您只有一项以上的任务
• 优先执行您不知道如何执行的任务，因此您始终在学习
• 任务可以单独，成对甚至是暴民来实施
• 教育自己完成任务所需的技术和框架
• 自己弄清楚可以做什么，但不要害怕寻求帮助
• 对于使用Scrum的团队：完成Sprint的故事后，您可以进行自己喜欢的工作
• 对于使用看板的团队：您可以分配20％的时间用于辅助项目，只要它们以某种方式使我们公司或客户受益
• 尝试新技术并与团队分享您学到的知识
• 一些小队还运行自己的运营基础架构。 这些小队将有一个待命轮换。 一旦技术负责人感觉到他们已经准备好并且能够处理中断，开发人员便可以加入轮播。 我们希望在sprint播放中提及这一点，并为毕业于此级别的开发人员加油打气。

提交者/ + 2

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

提交者的权利是由出色的代码审阅者获得的，并且由每个存储库的当前维护者/提交者来提名新的提交者。 我们基于OpenStack和Github贡献模型有严格的代码审查过程。 所有代码更改，无论是针对缺陷修复程序还是新功能，都必须由发起人以外的至少两个人进行审核和批准，其中之一必须是提交者。

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

通常，我们的提交者都是随时待命以支持24/7应用程序的人。 也就是说， 所有班组成员都可以帮助解决生产中的关键问题，而不仅仅是提交者。

测试和行动小组

您可能会问，为什么一个期望小队拥有并运营自己的部门的组织会有测试和小部门？ 简短的答案是，让一些真正的测试和操作专家对新团队进行教育，评估新工具并分享最佳实践仍然有帮助。

各个小队拥有自己的单元测试和功能测试。 需要代码覆盖率报告，我们的目标是100％。 覆盖率低会给系统和集成测试带来风险。 如果小队报告的测试覆盖率很低，我们只要求他们计划在每个冲刺阶段增加测试覆盖率，直到他们拥有完整的测试覆盖率。

我们的测试和运营团队中的测试人员针对以下方面编写自动化测试：

• 端到端，跨组件流
• 多浏览器支持
• 跨组件的全球化和本地化
• 性能，可伸缩性，安全性等
• 自动化测试可能会使构建/阻止部署失败
• 我们的测试人员还会进行一些创造性的手动和自由形式的测试

这些专家帮助其他团队学习如何使用新的测试工具。 他们通过文档编制，培训课程和结对编程来做到这一点。

我们的“测试和操作小组”中的操作专家会教其他人如何设置和调整：

• 生产监控器
• 警报
• 升级
• 通话轮换
• 日志收集与分析
• 网络管理
• 内容交付网络

该团队还维护可操作的仪表板，以帮助我们可视化各个组件的系统运行状况。 最后，该团队为运行实验（A / B测试等）建立了框架。

结论

简而言之，IBM Digital Business Group的团队模型就在那里。 三年来，我们一直在与大约80-90名小队一起进行这项工作。 希望您已经学到了一些最佳实践，对我们有帮助。

我要感谢Richard Gebhardt对我们IBM小队模型角色和职责所做的贡献。

[请参阅我们的相关故事， 如果没有这7个部门的支持 ， 您的DevOps尝试将失败。

翻译自: https://opensource.com/article/18/6/roles-squad-model

使用devops的团队