关于SCRUM的误解很多。 有些人喜欢它。 有人讨厌它。 我个人一直在努力区分其理论基础和许多实现。
经过近一年的产品管理实践经验，我很幸运地参加了Roman Pichler在伦敦举行的CSPO（认证的SCRUM产品负责人）课程。
在为期2天的研讨会中，我学习了一些课程，这些课程将永远塑造我的产品开发道路。 我将与您分享。
1. SCRUM并非适用于所有公司
- SCRUM承担信任 。 这意味着将决策过程下放给团队。 因此，它并不适用于所有公司。
- SCRUM假定接受失败 。 它指出主要学习来自失败。 这种冒险的态度并不适合每个公司。
2. SCRUM不适用于每个产品阶段
对于不确定性很高的早期阶段 ， SCRUM是理想的选择 。 实际上，它通过限时的冲刺和确定的目标来保护团队。 其他敏捷框架（例如看板）更适合于后期阶段，后者的重点是持续改进，业务需求更可预测。
3. SCRUM不会告诉您要构建什么
SCRUM不能帮助您发现产品 。 SCRUM是在高度不确定性条件下进行软件开发的组织框架。 它可以帮助您从积压的产品过渡到有效的产品。 但没有说明如何在经过整理的待办事项清单中翻译最初的想法。
4.产品必须为用户和企业创造价值
- 产品是一组功能， 可通过其自身为用户和企业提供价值 。
- 功能是用户可以与之交互的产品功能。
- 组件是架构构建块。
产品，功能部件和组件可用作PO的缩放选项（请参见下面的第6点）。
5.真正的采购订单具有3级产品责任
- 真正的采购订单拥有产品愿景 （=最终目标）。
- 真正的采购订单拥有产品策略 （=实现愿景的途径）。 用于此目的的主要工具是产品路线图。
- 真正的采购订单拥有产品策略 （=战略路径的步骤）。 用于此目的的主要工具是产品积压。
这三个级别可用作PO的缩放选项（请参见下面的第6点）。
6.没有适用于PO的缩放选项是完美的
在产品的早期阶段，只有一个人来管理产品具有很大的好处，因为它可以使决策过程更快。 随着产品的成熟，可以选择多个缩放选项，例如：
- 功能部件与组件所有者 ：采购订单同时管理策略和战术级别，保留产品积压和优先级决定。 相反，功能和组件优先级决定由管理团队的功能和组件所有者决定。
- 战略PO与战术PO ：前者管理战略级别（战略，路线图，利益相关者等），而后者管理战术级别（待办事项，故事，团队等）。 密切协作对于避免战术和战略层面之间的脱节至关重要（尤其是该战术会反馈到战略中）。
7.成长心态是关键的PO技能
PO角色本质上是跨学科的。 采购订单需要了解业务，技术和用户体验。 然后在特定产品领域具有成熟的垂直专业知识。 因此， PO学习的速度比您知道他开始学习的知识要重要得多 （在我当前的项目中，我不仅要学习技术和UX，还需要了解Messenger营销，Facebook API和用户入门） 。
8.开发团队是一个自组织的实体
PO的目标是管理产品，而不是过程或团队。 这些是SCRUM管理员的职责[我仍然为此感到困惑。 在我当前的项目中，我们没有SCRUM管理员，这意味着管理团队动态仍然在PO→me]上 。
9.自上而下的产品计划可增强自下而上的敏捷执行力
产品路线图是产品规划的关键工具。 确实，SCRUM开发的产品应该来自用户反馈。 但是，拥有清晰，自上而下的目标有助于使执行与产品愿景和业务战略保持一致，并满足对利益相关者负责的需求。
10.优先级标准取决于产品阶段
- 在早期阶段最好由风险来确定优先级 。 快速的失败与学习减少了不确定性，增加了成功的机会。
- 在后期阶段，最好按成本/收益划分优先级。 这样，重点可以转移到优化和有效性上。
11.产品质量隐含在“完成的定义”中
传统的项目管理理论讨论了3个约束（成本，时间和范围）。 有时质量会添加到列表中。 产品质量是SCRUM过程的属性，在“完成的定义”中是固有的。 只要PO不更改定义，他就不会在质量上妥协（质量→可交付的增量=软件正在运行，测试和记录）。
12.产品积压工作是提高透明度的工具
待办事项是一种战术工具，其项目应为：
- 优先
- 修饰过的
- 紧急情况
- 详细
- 没有依赖
13.产品积压更新需要新知识
SCRUM的主要目标是学习和减少不确定性。 仅当采购订单具有比以前更多的证据时，才应更新积压订单 。 新的反馈应纳入其项目，这些项目在以下情况下定义为就绪：
- 共同的理解
- 小
- 可测试（=带有接受标准）
14. 3C是故事的主要组成部分
- 卡片：简洁，小巧且易于可视化（促进协作）。
- 对话：这是与开发团队共同创建的活物。 谈论它是故事本身的基本组成部分 。
- 确认：它具有接受标准，以便可以测试它们并将其标记为完成。
