敏捷开发团队中谁来把控质量_谁是您团队中的关键人物？

敏捷开发团队中谁来把控质量

这是一个测试：您认为您的组织需要多长时间才能启动全新的工作？ 几天？ 一周？

您的团队准备得如何？他们是否已经知道如何规划，协调一致，确定优先次序并相互协调？

您的团队是否成功结束了任何浪费的活动？ 这些措施可能包括运行未使用的AWS堆栈，两次构建相同的东西，或者始终在策略上进行本地化优化，而不是与其他团队进行战略协作。

如果您的组织正在开展此类活动，那么您可能会走上正确的道路。 如果不是这样，那就是一个警告信号，表明您的团队缺少一些核心功能，您将需要成功启动任何新的尝试（无论是否大流行）。

您的组织是否允许胶粘人员开发这些核心功能，或者您正在迫使他们留在自己的盒子里？

僵尸scrum，速度计数器，剪贴板教条主义者和其他职业危害

不久前，我很高兴地采访了一家美国公司的一些自由项目管理工作。 经历很奇怪。 表示一碗冷豌豆汤热情的招聘人员，要求我完成比分配的时间和内容更多的任务，甚至要达到中等水平的目标。 我因指出我从未见过Scrum（书名Zombie Scrum）在任何组织中都成功而受到惩罚。 而且，根据我的经验，我因提出分析性问题而受到责骂，而这些问题对于提高重点和清晰度至关重要。

我没有进入流程的下一个阶段，部分原因是招聘人员说我的僵尸混乱评论是一个危险信号。 我认为这是一种赞美。 但是我也为任何项目经理（或Scrum主管，敏捷教练或任何其他有创造力的人）感到遗憾，他们将Cookie切割器解决方案应用于需要倾听，同理心和创造力的情况。 “遵循本书”是一种简单，反智的方式，粉碎创新并产生关于专业人员的刻板印象，这些专业人员的宝贵工作旨在将团队，部门和叙述结合在一起。

也许这些东西在某处起作用？ 我没看过

从来没有一个好时机向您的员工施加压力，要求他们简化流程，现在尤其不是一个好时机。 您的组织需要更多的东西来组成一个高效的胶粘人：

• 实用主义
• 客观性和确定假设的习惯
• 沟通技巧，即使在平静时期，大多数高科技公司也难以克服
• 良好的听力能力
• 模式检测
• 研究技能
• 中立与外交
• 战术，快速解决方案，森林换树思维的战略思维

如果您不支持团队评估和鼓励员工中的这些属性（无论其职称是否包括“敏捷”），请立即开始。

当然，有些担当“敏捷从业者”角色的人实际上更喜欢教条主义者，按书的人和错误计数器。 在这种情况下，您有两种选择：要么查看他们是否愿意探索他们工作的不同方法，要么查看他们是否愿意探索其他人。

了解您的PMO

如果您听到团队抱怨您的项目管理办公室（PMO）是一群阻碍进度的非技术性剪贴板人员，请挑战这些偏见。 也许您的PMO确实无效； 有些是。 但是也许工作中存在另一个问题，要么是微观管理问题，要么是组织其余部分缺乏问责制。

一位朋友向我描述了一种情况，在这种情况下，他们公司中的两名工程主管经常抱怨PMO，原因尚不清楚。 清楚的是，工程主管们并不重视透明度或问责制。 同时，我的朋友说，公司中许多人发誓说，没有PMO，在任何合理的时间内都不会做任何事情。 更换领导后，工程主管被替换了。 PMO仍然存在。

如果问题出在PMO，请考虑指导团队以提高效率。 这可以通过回顾来完成，也可以通过一对一的方式来完成。 我很幸运地在三个与高性能PMO组织合作的组织中工作。 他们安排了与团队的对话，以同样地关注目标和围绕他们的广泛发展。 他们很善解人意-试图理解为什么程序滞后而不是责怪或ming。 他们专注于创造价值-调整团队，使工作透明化，使会议井井有条，富有建设性，并提出务实的问题，避免了灾难或战略上的空白。

他们没有检查别人是否在做他们的工作，而是帮助团队找到互相帮助的方法。 在许多情况下，他们通过举办有效的会议或主持专门的对话来帮助推动知识交流，使新的思想和解决方案相互授粉。

如果问题出在您的组织，请与PMO合作，以查看您的领导团队如何成为PMO工作的更好拥护者。 有时，PMO的问题是缺乏公共关系和声誉管理。 可悲的是，PMO可以成为不满的各方投射他们疯狂的一切的画布，这对任何人都没有帮助。 当产品经理放弃责任，解决您的技术架构或解决两位工程师之间的所有冲突时，都不存在对PMO能够解决产品战略问题的开箱即用的期望。 您的组织可能只是在滥用您的PMO权力，从而加剧了他们对工作的现有偏见或误解。 想办法制止这种情况。

作为一个人的PMO，我与组织中的利益相关者紧密合作，以通过轻量级可视化分解复杂性，阐明结果并跟踪正在进行的工作。 都是讲故事的。 我与敏捷教练团队紧密合作，为交付团队奠定基础，以形成一致的构想，然后与教练合作，与特定团队合作，以提高绩效并确保在该构想上更好地发挥作用。 这不是巫术，多年来我从其他成功的PMO展示和教给我的东西中回收了它。 它似乎有效。

为您的敏捷教练和Scrum管理员提供有意义的指标

“我以为敏捷教练只测量速度和故事点，而Scrum大师也这样做，而且还会使JIRA保持最新，”地球上有多个人说。 他们是如何得出这个结论的？ 可能是在一个组织中工作，该组织要求教练和Scrum主管专注于产出而不是价值。 也许那些组织没想到甚至不在乎教练是否证明了他们的有效性。 教练和Scrum主管在那里服务，例如敏捷性的安全毯。

如果交付的作品没有价值，则故事点和速度是毫无价值的指标。 计算回溯的次数，或计算每个团队的bug数量（容易玩的游戏）的减少或对编程花费的时间也是如此。 这些指标不一定能说明有关您组织的故事，也不能帮助教练和Scrum主管成长。

我喜欢Andy Sio的这份敏捷教练指标列表 ：通过寻找效率的证据，减少会议或通过使用教练的建议进行改进来收集团队周围的数据点来衡量影响。 对于Scrum大师，Ryan Ripley邀请领导者重新考虑服务角色 ，挑战现状。 寻找其他人更新JIRA并记笔记。

也许您对授权教练和Scrum Master感到很酷，但是现在您在问：“我们有产品经理和业务分析师，为什么我们需要教练来做到这一点？” 因为分娩功能障碍通常是全身性的。 这是关于讨论，决策，沟通和其他零碎工作的融合，起初缓慢，直到全部累加成为一个更大的问题。

教练可以帮助您的产品经理，分析师和开发人员发现更大的问题，了解根本原因，并找到更有效的替代方案。 如果足够紧急，这可能意味着成功与失败之间的区别。 例如：

• 如果分配给两个或三个团队的Scrum Master可能会持续多久才能有效？ 领导团队无法胜任的工作？
• 如果一个团队不共享路线图，该如何与其他团队保持一致？
• 如果有两个相互竞争的路线图，如何使工程和产品保持一致？
• 如果您正面临冠状病毒，您的产品经理，开发人员和分析人员是否有时间解决所有这些系统性功能障碍，或者他们可以使用一些帮助吗？

确定组织中的“胶粘人员”，并找到通过专门针对最多一两个结果的重点计划来利用它们的方法。 考虑建立一个“实践社区”，这是一个非正式的环境（精益咖啡或其他格式），供他们共享最佳实践或突出并解决组织中与流程相关的需求。

如果您的胶水人员已经不堪重负，请考虑雇用更多的胶水人员。 如果您要裁员，这听起来似乎违反直觉，但是要花更多的钱-雇用一名程序经理来做好这项工作，或者让十名开发人员和产品经理在没有做平常工作的同时专注于较少的工作？

希望您能够确定组织中可以点点滴滴，讲述您的故事并使所有人聚在一起的人员。 也许您甚至雇用了专门人员来考虑您的流程，但还没有裁员。 请不要！ 他们可以拯救您和您公司中的其他所有人。 但是只有在您授权他们的情况下。

如果您是从头开始，请支持您的胶粘人员，防止其他人失去情节。 然后，您建立了一种维持情节的文化。 当它是您的新计划或新产品的基础时，迭代和改善这种文化要比在养成许多反模式和最坏习惯的情况下强迫它更容易。 当然，渐进式变更可以使团队和组织重回正轨，但是为什么首先要容忍偏离轨道呢？ “从一开始就走得更快”并不是一个很好的理由。 您可以超快地进行实验，仍然可以保持团队的团结。

过程可以是简单且轻量级的，实际上应该如此。 但是，仅通过在日历中安排一些会议并在Confluence中写下所有内容就无法解决此问题。 必须对其进行定制和策划，创建以实现并维持流程，并根据需要进行调整。 否则，它将成为障碍，浪费时间而不是援助，人们会讨厌它。 它可能不会源于本书的混乱，也不是本书的任何东西。

翻译自: https://opensource.com/open-organization/20/6/glue-person

敏捷开发团队中谁来把控质量