如何使Scrum的12条原则适应产品开发

项目一开始并不总是很清楚最终会是什么样子。毕竟，一般条件可以改变，也可以改变客户的要求。Scrum提供了响应变化的框架条件的可能性。请阅读本博客文章，了解Scrum与常见项目管理模型的不同之处，以及如何调整敏捷项目管理方法的12条原则，这些原则最初来自软件开发，用于您的产品开发。

 

为了执行项目，我们都习惯按照所谓的瀑布模型进行操作：一旦完成一个步骤，团队就开始实施下一个步骤。这种方法有三个优点：

• 明确定义了不同的项目阶段。
• 规划和控制很简单。
• 可以提前清楚地估算项目的成本和范围。

这些优点至少在开头已经清楚项目应该如何准确看起来时才适用。然而，我们生活在动荡的时代，变化的速度在不断增加。即使项目只需要几个月，框架条件和需求也可能发生变化。瀑布模型很难适应这种变化; 它太静态了。

 

敏捷项目管理的工作原理

敏捷项目管理方法（如Scrum）更加灵活。在这篇博客文章中，您将了解Scrum的工作原理。当然，Scrum的机制可以在一个页面上以更短的图形显示。如果您想了解有关项目管理方法的更多信息，可以在此处找到Scrum开发人员不断开发的指南。对于那些想要广泛了解敏捷项目管理的人，我们推荐将于5月17日和18日在格拉茨举行的2018年敏捷奥地利会议。

 

接力与橄榄球队

Scrum的两位祖先Hirotaka Takeuchi和Ikujiro Nonaka将经典的开发过程与接力赛进行了比较。每个跑步者的任务是覆盖部分路线，然后将接力棒传递给下一个跑步者。另一方面，Scrum遵循橄榄球的方式：球队一起覆盖整个距离，但是来回灵活地进行球。

坚持与运动的这种比较：在接力赛中，不需要个人跑步者的知识和创造力：他有尽可能快地覆盖从A到B的距离的命令，可以这么说。橄榄球是不同的。在这里，每个团队成员都必须了解自己的战略，根据具体情况实施，并对每一个变化做出反应。一方面，每个人的整体潜力都是需求的，另一方面，每个人都有自己主动行动的必要自由。

 

敏捷项目管理宣言

顺便说一句，与橄榄球的比较并非偶然。Scrum不是一个缩写词，但在这项运动中代表着有序的人群。为了确保这个“人群”也能产生结果，参与该过程的人必须遵循某些原则。顺便提一下，这些基本规则来自软件行业：2001年，17名替代项目管理方法的专家从美国犹他州的滑雪小屋撤出了三天，并制定了“敏捷宣言”。Scrum Ken Schwaber，Mike Beedle和Jeff Sutherland的三位创始人也是这一群体的一员。因此，该宣言适用于Scrum，可归纳为四点：

1. 个人和互动不仅仅是流程和工具
2. 功能软件比综合文档更重要
3. 与客户的合作比合同谈判更有价值
4. 应对变化比遵循计划更重要

 敏捷宣言的12条原则

该宣言基于12项基本原则。因为“敏捷宣言”最初是用于开发软件，所以这些规则也在原始版本中引用它。但是，Scrum适​​用于任何其他开发过程。但是，在使用这些规则之前，您应该根据需要调整这些规则。这个过程叫做“ Scrumbut ”（我们使用scrum，但是......）。原始版本中的12条规则如下所示，我们已根据产品开发进行了调整：

1. 我们的首要任务是通过早期和持续交付有价值的软件来满足客户。 
   但是，如果要开发产品，您应该设置里程碑的早期和持续交付，理想情况下，MVP（最小可行产品）作为每个sprint之后的目标。MVP的要求根据项目进度而变化。第一条规则的核心声明保持不变：您应该能够尽快向客户展示切实的进展。
2. 发展的后期也欢迎要求的变化。敏捷流程使用变更来获得客户的竞争优势。
3. 在几周或几个月内定期交付工作软件，更喜欢更短的时间跨度。 
   如果产品是MVP，则此规则应适用于MVP。
4. 专家和开发人员必须在项目期间每天一起工作。
   当然，您可以根据项目团队的时间选项调整此规则。如果Scrum项目不是团队唯一的任务，那么它也可以安排一个或多个固定的工作日进行工作。重要的是，专家和开发人员应定期合作，随后的协调会在站立会议中定期进行。
5. 围绕有动力的个人建立项目。为他们提供所需的环境和支持，并相信他们能够胜任这项工作。
6. 向开发团队和开发团队内部传递信息的最有效和最有效的方式是面对面交流。
   对于其成员位于不同位置的团队，此要求不容易满足。这是视频会议解决方案可以提供帮助的地方。提供这样的是Scrum Master的任务。
7. 功能软件是最重要的进步衡量标准。
   对于产品，MVP当然是指这里。最好事先与客户协调如何展示您的进度。特别是在第一次冲刺中，允许使用草图形式的概念。
8. 敏捷过程促进可持续发展。客户，开发人员和用户应该能够在无限的时间内保持稳定的步伐。
9. 对技术卓越和良好设计的持续关注促进了敏捷性。
10. 简单性 - 最大化未完成工作量的艺术（因为它是不必要的） - 是必不可少的。
11. 最好的架构，要求和设计，以及产品的MVP和概念，都是由自组织团队创建的。
12. 团队定期反思如何变得更有效并相应地调整其行为。