打造高效团队
工程师可在能够保持专注且进入最佳状态的环境下茁壮成长。 团队经常面临分心和相互竞争的优先事项的问题,从而迫使工程师切换上下文并分散注意力。 他们需努力平衡埋头苦干的时间和抬头观望的时间。 添加新功能要求团队成员埋头苦干并集中精力。 响应客户问题并解决实时站点问题要求团队抬头观望并了解具体情况。
为减轻干扰,团队可将自身划分为两个群体:一个用于实现功能,一个用于监视实时站点运行状况。
此双群方法可提高工作效率和可预测性。 成功实现则依赖于以下关键元素:
- 明确定义群体角色
- 清晰定义的群体轮换流程
- 频繁调整群体规模
功能群体
功能群体或 F 群体专注于未来。 他们将扮演一个具有明确使命和目标的有效单位,从而构建和交付高质量功能。
F 群体不受现场服务所造成的日常混乱的影响,从而确保他们有时间设计、生成和测试自己的工作。 他们可以充分享受最少的分心和充足的自由,而不必解决随机出现的问题。 鼓励他们尽量不查看自己的电子邮件,从而避免被牵扯到其他问题中,除非他们对此至关重要。
当 F 群体的成员加入对话或偶尔被牵扯到一系列电子邮件中时,其他团队成员应对他们说:“你属于 F 群体,你在干什么?”如果 F 群体的成员需解决严重问题,则鼓励他们将其委托给客户群体并回到功能开发的工作上。
F 群体将作为一个紧密组织的团队来运作,同时聚焦于一小批功能。 良好的“正在进行的工作 (WIP)”限制应为:由 4-6 人负责两个功能。 通过密切协作,他们可以构建起深度共享的上下文,并可找到粗略代码评审会错过的关键 bug 或设计问题。 专用群体可实现更可预测的吞吐量速率和提前期。 团队成员经常将 F 群体称为平静且专注的群体。 他们发现,深入关注一个功能从而充分关注它会让人感到心情平静和精神焕发。 大家将时间用于 F 群体也会感觉精神重振且富有成就感。
客户群体
客户群体或 C 群体专注于当下,并负责为客户和实时站点问题、bug、遥测和监视提供一线支持。 C 群体经常会挤在计算机周围,调试严重的实时站点问题。 他们的头号优先任务是监控实时站点运行状况。 通过高度专注于此环境,他们可培养出专家调试和分析技能。 客户群体通常被称为盾牌团队,因为他们负责保护团队的其余人员免受干扰。 C 群体不负责处理即将推出的功能,而是充当客户与当前产品之间的桥梁。 群体成员会积极回复电子邮件、Twitter 和其他反馈渠道。 客户想知道他们的反馈有人处理,而 C 群体的工作便是如此。 C 群体会对客户报告的问题进行分类,并迅速联系和协助受阻的客户。
随着传入任务的泛滥,处理节奏十分快速的 C 群体有时会令人感到振奋。 在繁忙的一周内,他们会处理多个电子邮件、现场调查和 bug。 当这些操作平静下来之后,他们会努力改进遥测和报告,并投入时间来简化服务维护。
C 群体允许团队在不将团队成员拉离其他优先事项的情况下解决问题,并确保客户和合作伙伴的反馈有人处理。 对疑问和问题的响应已成为 C 群体的骄傲所在。 然而,这种节奏可能会被耗尽,因此需在各个群体之间频繁轮换。
群体轮换
定义清晰的轮换流程可让两组人员有效开展工作。 你可以简单地交换群体(F 群体变成 C 群体,反之亦然),但这会限制群体之间和各自内部的知识共享。 因此,可改为选择每周轮换。
在每周结束时,举行短暂的交换会议,期间由团队决定在群体之间交换哪些人员。 可使用白板图表来跟踪当前每个群体有哪些成员以及他们的交换时间。 每个群体中任期最长的那些成员通常应相互交换。 但是,在任何具体的一周内,有人可能希望继续完成现场调查或功能开发的工作。 虽然不乏灵活性,但在某个群体待得越久的成员,就越有可能进行交换。
每周轮换有助于防止团队中出现知识孤岛,并确保在各群体之间保持信息和视角的持续流动性。 工程师的频繁移动可形成共享的团队工作知识,这有助于 C 群体在没有其他人帮助的情况下解决问题。 通常,新的 F 群体成员会很快发现以前被忽视的设计或代码缺陷。
群体规模
群体规模会发生变化,从而保持团队的健康。 如果团队的现场问题率很高,或者存在大量技术债务,C 群体就会扩充,反之亦然。 每周调整群体规模会提升团队可交付成果和依赖关系的可预测性。 在几周内,团队可能会将每个人都转移到 C 群体来解决来自重大发布的反馈。
此策略简化了与管理层的通信。 如果没有双群体体系,工程师便通常会同时处理多个任务。 当一周内出现多个让人分心的任务时,开发中的功能通常就会延迟。 因此,团队可能无法自信地为将来的功能开发工作提供时间表。
通过组建专用 F 群体,可预测吞吐量和提前期。 在群体之间拆分资源会增加团队内部的问责,并与管理层一起了解团队每周和每个冲刺可以完成哪些工作。
后续步骤
双群体体系可帮助团队了解工程师应将时间花在哪些方面,同时在众多相互竞争的优先事项上取得进展。
除了提高工作效率和可预测性外,双群体体系还可提高团队士气。 每个团队的工程师都清楚地了解了各自的角色和职责,并可更加独立地工作,同时承担大得多的问责。 此方法非常适合负责开发和运营的 DevOps 团队。 但是,此方法也可应用于处理相互竞争的优先事项的几乎所有敏捷团队。
Microsoft 是全球最大的敏捷公司之一。 了解 Microsoft 如何在 DevOps 规划中组织团队。