在 33 年的软件工程生涯中，我有幸与一些最聪明的人才和领导者共事。我也很幸运地为一位经理工作过，他每天都让我质疑我的职业生涯，并系统地摧毁我的热情——就像一场破坏性的火焰吸走了密封空间中的氧气。那是一段令人不安的时期，但一旦我挣脱出来，我意识到我有机会反思有效团队最糟糕的反模式之一。
毫不奇怪，当开始 DevOps 思维模式 转型时，组织及其工程团队的文化是最大的挑战。组织需要通过领导力和自主性来影响，促进学习和实验的文化，在这种文化中，失败是创新的机会，而不是惩罚。应该像印度古老的 萨蒂 习俗一样反对对报复的恐惧。团队需要感受到他们在安全的环境中运作，了解转型的含义，并知道他们将如何受到影响。
那么，有效团队的蓝图是什么？自主性、自组织和自我管理的概念是敏捷实践的核心。此外，精益实践提倡减少浪费、创建短反馈循环、使用轻量级变更审批、限制在制品 (WIP)、反思并根据反馈采取行动以及透明地可视化工作管理。所有这些优势都需要反映在您的蓝图中。
让我们回顾一下有效团队蓝图的基因信息。
如下图所示，自组织 是一个在团队内部创造秩序的自然过程。它概述了自主团队如何协作和协调。自我管理 定义了多元化的团队成员如何在他们自己的方式中协同工作，与领导层拥有的共同愿景和治理保持一致。
自主权和治理界限。
团队规模 是一个引发热烈讨论的话题。有人说理想的规模是 7±2，有人说 6±3，而另一些人则认为没有上限。另一个论点来自人类学家 R.I.M. Dunbar，他在他的关于人类新皮层大小和群体规模之间关系的 论文 中说，“有效团队中个人的数量存在认知限制”。他认为，如果您想要一个高度凝聚力的团队，请将您的团队规模保持在 12 人以下。
亚马逊 CTO Werner Vogels 的名言“谁构建，谁运行”让人想起蜘蛛侠的伟大主题名言：“能力越大，责任越大。”我们需要培养所有权、问责制和责任感。团队中的每个人都必须被授权、接受业务运营培训、负责任并在待命状态。当发生线上事故时，所有指定的响应人员，包括来自相关功能团队的成员，都必须加入凌晨 2 点的电话会议，以收集证据、调查并在根本原因级别进行补救。
顿悟
凌晨 2 点的叫醒电话是生产就绪心态的最佳动力。让任何工程师在凌晨的线上事故中待命几次，质量标准就会神奇地提高。
跨职能 是有效团队蓝图基因信息的另一个关键部分。与普遍看法相反，这并不意味着团队中的每个人都可以做所有事情。相反，如下图所示，跨职能团队基于 T 型技能或 T 型人的概念。T 字的横条代表广泛的专业知识和与他人协作的能力，而竖条代表单一专业知识的深度。假设我们有一个由开发、测试和用户体验专家组成的三人团队。每个人都有自己 T 型技能。当我们结合这三位专家的基因材料时，我们得到一个联合的 T 型团队，该团队具有专业化和广泛的专业知识，可以作为一个跨职能团队来设计、开发、测试和支持功能。学习文化不仅确保团队的综合广泛和专业知识与业务需求保持一致，而且还授权和激励团队及其成员。信息共享和棕色袋子活动是两个优秀的团队建设工具。
测试人员短缺？没问题；在测试专家的支持下，开发和用户体验专家可以暂时融入测试角色。当测试人员自动化测试、学习和分享良好的编码实践、帮助改进反馈循环并帮助团队扩展其单元和回归测试以外的技能时，开发人员和测试人员之间的界限开始模糊。开发人员和测试人员的角色演变为工程师角色。
这就提出了一个问题：“如果团队成员拒绝成为跨职能人员怎么办？” 在有效的跨职能团队中，没有英雄或骑士的位置——为他们找到另一个家。
在实现目标时，激励 和 庆祝 团队和组织的成功。它激励团队，激发团队精神，并成为其他人追求卓越的主要灵感来源。您的团队可以享用一轮玉米片来庆祝工作做得好，玩 GetKanban 游戏并从中学习，鼓励团队成员在忙碌的冲刺后与家人一起庆祝，或者回顾并庆祝快速反馈作为您日常站会的一部分。选择是无穷无尽的——只需确保您作为团队一起度过时光。
例如，我们的 Scrum Master 总是反思我们的成就，无论我们是否通过了冲刺。我最终意识到，这不仅将我们团结成一个团队，而且其他人也渴望像我们的团队一样。
最后，请记住 保持简单 以降低风险、培训成本、流程和产品。启用刚刚足够好 (JBGE) 的方法。简单性对可维护性产生积极影响，并使跨职能团队能够更有效地协作和互相填补空缺。
您可能想知道为什么以上内容都没有任何新的启示。正如在 分析 DevOps 的 DNA 中讨论的那样，我们相信 DevOps 继承了数十年的实践和学习，包括瀑布模型、精益思想、敏捷和“真实世界”的凌晨 2 点线上事故电话。我们没有发明任何新东西；相反，我们继续反思、学习和简化我们的蓝图。DevOps 思维模式基于一些成熟的基础，当团队专注于交付、遥测、生产支持以及（最重要的是）团队团结时，DevOps 就会焕发光彩。一个不喜欢在一起的团队不是一个团队；他们是一群被告知要一起工作的个人。
那么，让我们回到我提到的最大的反模式。有效团队（他们是自主的、被授权的、自组织的和自我管理的）是基于领导层的 信任、激励 和 支持。如果缺少任何这些重要的支柱，毒性就会上升，热情就会下降，您就会亲眼目睹最具有破坏性的反模式，这将注定任何多元化、协作和有效的团队走向失败。
具有 DevOps 思维模式的有效团队蓝图。
那么，您是否在一个有效的团队中？您是否经历过影响您的 DevOps 转型的反模式、负面模式或正面模式？请在评论中告诉我们！
1 条评论