我从事Web开发领域的敏捷工作已有10多年了。 他们中的大多数人必须处理最流行的敏捷框架-scrum（ 根据VersionOne ）。 我想与您分享积累的观察和结论。
我将从一个隐喻开始，因为有时我不得不在这种情况下看到scrum的引入：
- 乱七八糟之前 ：婴儿期的“ 成长 ”-她是有目的的，但她不知道如何正常走路，但她确实想学习以达到目标。
- 简介 ：老师来了（ scrum培训，课程，敏捷教练等 ）并演示了如何走路。 这个孩子很高兴，他一步步走！ 自上而下。 我们有冲刺-我们去吧！
- 介绍之后 ：耐心的利益相关者说：“好吧，我们开车去了目标，”他们得到了“不要推动团队，我们去！”的目标。 开发写出有趣的轨迹并享受过程，但是目标却被遗忘了。
- Scrum-no ： Scrum-no ：从业务中获取真理，使scrum“变异”并允许业务从开发中获取某种产品。 而且，不幸的是，“我们在Scrum上工作”的复选标记已正式打勾，但是开发团队的真正潜力尚未透露，他们说“ scrum并非真实”。
我认为，发生这种情况的原因是Scrum通常是“机械地”实施的，而没有意识到框架及其元素的本质。 我想揭示“机械性混乱”的症状； 了解这种方法的缺点是什么； 了解“真正的敏捷敏捷”会更好 并找到方法来对抗Scrum症状 我将在这里专门介绍几篇文章，并对您的评论和问题感到高兴。
首先，让我们定义什么是“机械混乱”。 从我的角度来看，这是Scrum的所有角色，事件和人工制品都正式存在，但价值观和目标却被遗忘的时候。 没有敏捷文化时（ 即高度了解和接受敏捷宣言和原则 ）。 当没有理解甚至试图弄清楚为什么需要这个或那个工件时，或者scrum中事件的目的是什么时。 就像视频中的机器人一样，他知道如何扭转筋斗，但是谁会称他为体操运动员呢？ 在实施Scrum时，重要的是向团队传达其目标和价值观，而不仅仅是机制。 敏捷文化增强了混乱并使其“真实”。 Scrum对于定期交付价值和接收及时反馈很有用。 Scrum与速度和产品开发有关。 从理论上讲听起来过时了吗？ 让我们尝试弄清楚如何在Scrum上工作，并且一路上不失去scile的文化和价值观。
在ScrumGuide中解析scrum元素时，角色是最早要解析的角色之一，我们将执行相同的操作。 因为 原来有很多资料，然后，为了有机会实现它，它分为三个部分（ 第2 部分 ， 第3部分 ）。 让我们从产品负责人开始分析。
产品负责人-产品负责人（PO）：
产品负责人是负责产品的人，他“拥有”产品待办事项列表。 PO的主要工具是产品开发的愿景，主要任务是使团队生产的产品的价值最大化。 一切似乎都很简单：“如果您勇敢，灵巧和技巧……”，但有细微差别。 他们没有在PO教我们，但在PM（项目经理）教书，并且PM通常会成为PO，因为他们相信这只是名称的更改，并且您可以保留旧的工作方法。 但是敏捷并不是那样。 怎么需要？
PO与产品之间的交互，积压
症状 ：PO不负责待办事项的构成，它仅适用于过程中从其他参与者收到的故事。 或PO不负责确定待办事项元素的优先级。 他的工作是将积压工作提高到团队接受的标准，并且他不确定团队将做什么的内容和优先级。
不好的是 ：如果PO没有勇气或没有创造产品的能力（ 形成积压，确定优先次序，进行实验等 ），则这不是PO，而是某种其他活动。 而且没有PO混乱，也没有混乱。 如果不形成积压订单，PO不能对产品负责。 如果不是PO负责积压，则采用产品决策需要额外的沟通-这是额外的时间，会对团队的速度产生负面影响。
如何处理 ：您需要授予PO唯一的权利来做出产品决定和积压产品的责任。 如果非决策者是既定订单，那么很难在一夜之间改变这种状况。 如果PO是代理，则
- 或者，我们从等式中将其删除，然后使PO真正成为负责积压的组成和优先级的PO。 开发团队和特殊的产品发现团队都可以帮助PO处理积压的订单，但是积压的组成和质量的责任应该只有一个人-PO。
- 或者，我们逐渐学习/允许/强迫我们承担责任并做出当前PO的决定（ 积压元素的组成，元素的优先级等 ）。 迭代很重要：巩固成功，获得反馈。
症状 ：PO没有产品开发的愿景，没有全球战略，没有目标将产品带到何处以及为什么。
不好的地方 ：PO的主要优势是产品的愿景，了解为什么以及为谁创造的。 通过这种愿景，他可以激励和“感染”周围的人。 如果没有远见，那么该产品就不太可能成为必需品和好品。 比赛结果不会被“指控”。
如何治疗 ：PO重要的是首先制定产品愿景。 他必须能够以电梯音高格式告诉他他在做什么，为谁做什么以及为谁做了什么很酷的事情。 敏捷性价值之一就是透明度。 通过可视化各种产品开发工件，我们正在努力提高透明度。 PO可以阐明他的愿景并将其发布在团队面前。 最好以某种频率完成电梯俯仰和视觉的制定工作，例如其他Scrum事件（ 计划新的迭代-完成-收集反馈 ）。
症状 ：PO无法计算待办事项元素，未将其带入团队采用的协议，未更新待办事项元素，未清理它，未整理待办事项 。
不好的是 ：如果采购订单当前不定期对积压进行足够的关注，他仍然必须这样做（ 需要收集冲刺 ），但这会带来更大的压力和成本（ 例如：集体清理冲刺计划中的积压 ）。 通信开销将从分配给开发的时间中抵消。 采购订单将开始失去团队的信任：它不会投资积压的订单-团队不会投资增量。 错误/无关的积压降低了所有相关方的透明度。 没有透明度的混乱不是混乱。
如何处理 ：在PO之前，您需要传达处理积压工作的重要性-文章，书籍，培训等。 我们需要制定进行产品积压细化（PBR）的规则/规定，以便这些会议是有用且有效的，在PBR之后进行一次小型回顾，您可以通过几次迭代来定性地改善此事件。 团队需要改进进行PBR的机制，以实现PO与开发团队之间的最大协同作用。 积压需要定期清理。 获取最新信息，除了将新的故事添加到待办事项之外，您还必须记住清理失去相关性的故事。 待办事项列表应包含对团队清楚的元素，并应（ 在特定团队的协议框架内 ）制定2-3个冲刺的内容；更深入地工作待办事项列表可能会失去相关性。 一般而言，积压的产品至少应包含路线图至少一年，以便所有相关方都认为该产品具有未来。 将积压的工作量按近似的增量打破，将有助于团队提前考虑冲刺目标 。
症状 ：PO在几种不相关的产品上工作或与多个团队一起工作。 作为一种选择-除了主要的PO外，它还在Scrum流程（开发人员或SM）中扮演不同的角色。
不好的是 ：要成为一名采购员并不是一件容易的事，需要很高的回报。 如果PO的作用与其他活动结合在一起，则很有可能严重影响结果的质量。 如果这些产品“相关”或属于功能紧密的大型产品的一部分，则经验丰富且成熟的PO可以同时运行多个产品并与多个团队合作。 例如，很可能只有非常非常独特的人才能同时做移动设备的图形编辑器和陆军飞行模拟器。 为了发挥作用，您必须先专注于一个目标，然后再努力。
如何对待 ：采购订单应批判性地看待其产品：愿景的制定和完善程度如何？ 团队如何理解和接受这一愿景？ 待办事项的发展情况如何？ 对所有有关人员透明吗？ 有产品路线图，每个人都清楚吗？ 团队是否了解接下来的2-3次冲刺会做什么？ 用户和市场的知名度如何？ 与开发团队互动的质量如何？ 如果在某些此类问题中仍有改善质量的空间，则应只剩下一种产品，并专注于它。
采购订单和团队互动
症状 ：PO指令控制着团队，实际上是在经典的PM方案上工作。 PO会做出所有决定，即使是最小的决定，团队也会在任何问题上向他求助。
不好的地方 ：如果PO参与团队内部的微观管理，积极参与开发，那么，一方面，它会使团队失去动力并阻止其发展（ 没有自组织性，因为本地决策的责任仍由PO承担 ）；另一方面，这是不好的对于产品而言，因为PO的工作直接指向过程内部，因此产品可能会被忽视。
如何对待 ：PO需要杀死自己的PM，尝试使用非定向管理方法并停止将人们视为资源。 如果在PO和开发团队之间建立了指令管理方案，则值得由外部或内部协调人来调整交互作用。 需要明确定义采购订单和开发团队之间的责任界限-这是透明的。 PO与团队之间必须存在信任关系：团队在很大程度上信任PO及其产品解决方案，PO信任团队以及团队为实施积压要素而采取的决策。 每个人都知道为单一目的而进行的工作。 用于PO的可能工具之一可能是其“产品”团队，其中包括分析师。 当假设基于数字和数据时，它们就更可信。 PO的主要目的是不要忘记与开发团队共享此数据。 如果团队不是独立的，那么采购订单需要学习如何委派。 然后，由于责任，团队将被迫做出决定，并逐渐成为一支混乱团队。
症状 ：PO与开发团队经常发生冲突，存在不断的对抗，没有相互了解。
不好的是 ：PO和船员在同一条船上航行，如果他们之间没有建立有效的沟通，那么这种船就不可能航行得很远。 很多精力将花费在建立交互上，而不是产品开发上。 PO和团队的目标是相同的，这意味着不应存在常规冲突。
如何治疗 ：我们需要经验丰富的调解人，他们可以确定冲突的实质，消除冲突并建立工作关系。 如果所有的努力都不能导致相互理解，那么就值得改变坦桑。
症状 ：PO几乎不与团队沟通。 例如，它仅在强制性会议（计划，冲刺审查）中可用。
不好的是 ：团队创建了一个新的复杂产品（ Scrum是用于开发，交付和维持复杂产品的框架。 ），因此它在不确定性很大的情况下工作。 为了提供最大的价值，他们需要在大多数情况下只有PO才能提供的信息（ 这是他的工作 ）。 在没有信息的情况下，可能会做出错误的假设和决策，结果，纠正它们会浪费宝贵的时间。
如何决定 ：团队应该可以使用PO，但团队不应滥用PO，否则PO时间将仅用于特殊问题。 应该制定一种适合所有人的交互方式，在这种方式下，团队应及时从采购订单中接收团队真正无法自行做出的必要信息和决策。 您可以按一定的规律调用采购订单回顾，并在那里讨论频率，工具和沟通格式的问题。
症状 ：PO不会灌输或促进团队反馈文化。 或PO通过过滤掉赞美或批评来提供单向反馈。
不好的原因 ：如果采购总监没有定期向团队提供诚实的反馈，这会使团队失去动力。 期望和结果没有同步。 团队不会感到共谋，他们实际上不是产品的创造者，他们只是履行职责。 “团队定期提供增量。 团队会定期收到对他们工作的诚实反馈-这似乎是公平的。
如何看待 ：当然，采购总监不应该向团队收取他自己使用的所有信息，包括他从用户和分析人员那里获得的所有信息。 他必须汇总和发布对于团队来说已经很重要并且可以理解的信息。 最好提出不同的反馈格式，而不仅仅是基于空号（ 例如：现场测试，访谈等 ）。 团队本身应该提醒PO需要反馈：提出问题，建立定期接收反馈的流程。 如果您将PO设为sprint审阅事件的“所有者”，并因团队需要反馈而感到困惑，那么它至少会使PO联想到反馈工作，并可能导致组织采用更具创造性的方法。
PO与市场用户之间的互动
症状 ：PO不认识“他”的用户； 该产品具有一系列功能。 PO会忽略用户请求和现有用户的信息。 不与实时用户通信。
不好的原因 ：首先，该产品是为有（ 可能还不知道 ）需求的用户创建的。 而且，如果您不了解和理解用户，则不可能按照Scrum指南的“承担实现产品最大价值的责任”。
如何对待 ：进行定性研究的工具很多，例如深度访谈，用户画像， 客户旅程图 ，收集定性（相对于定量）分析的工具等。 等 您需要尝试各种工具，并保持有用/对您的产品有效。 输出中的大多数这些工具都具有可视化的结果，值得将它们放在团队面前以提高透明度。 这些工件值得不时更新。 您可以组织产品发现团队来帮助您进行质量研究。 如果PO设法与用户建立交互，则他可以使用此联系人进行sprint审查：例如为用户提供新的增量，团队将检查用户将如何处理任务，并帮助他们解决增量问题。
症状 ：PO不研究市场/竞争对手。
不好的地方 ：产品的生活就像在真空中一样，与现实脱离了，您需要有远见，才能在这种条件下创造有价值的产品。
如何对待 ：产品所有者有许多实践，如何研究和创建市场，值得尝试各种实践，并从中受益。 在此活动中，PO可以由分析师或团队帮助。 经常寻找“ 蓝色海洋 ”非常有用。 当然，您应该从培训，美食会议中获取灵感。
结论
其余角色的分析将在以下部分中显示。 现在，让我们看看这些信息如何对您有用。 我们检查了一些可能的症状，指出混乱中出现了问题，并提供了更改情况的选项。 如果需要，请在末尾列出一个清单：
- 阅读几乎所有项目，您就会认出自己（ 您的团队/组织 ），即 您有一个不规范的理解。 然后值得提出问题：您是否完全需要Scrum？ 为什么需要混乱？ 你为他设置什么任务？ 企业文化是否已准备好采用敏捷价值观和原则？ 如果您有答案并理解了为什么需要Scrum并真的打赌，那么请继续第二种选择。 如果没有，那就停止自欺欺人。
- 阅读一些观点，您认为这与您无关。 有些观点提示您进行推理，并且您还记得自己的处境。 如果是这样，则选择可能适用于您的情况的那些项目。 以卡片形式打印。 与团队讨论症状：对您公平吗？ 讨论风险，您是否同意这些风险，或者您可能会从症状中看到更多的危险后果。 然后，抓住最让团队最担心，最危险的症状的卡。 考虑提议的解决方案，它适合您吗？ 集体想出如何改善情况，如何缓解症状。 演戏！ 处理完一种症状后，请继续处理下一种症状，并定期返回一般复查，以确保您已经获得的结果没有下垂。
- 如果您阅读所有内容并且在这种情况下不认识自己的现实，那么我们就对了。 真的有这样的组织吗？ 您是伟大的伙伴，请务必在评论中分享您是如何实现的！
PS我希望本文将为Scrum团队提供一个自我完善的工具。
PPS非常感谢您的说明。
UPD 第2 部分和第3部分 。