对于任何拥有实时SAP系统的公司来说，在不危及现有业务流程顺利执行的情况下提供新功能都是重中之重。传统观点认为，管理风险和控制事情的最佳方法是遵循发布管理流程。这意味着在规定的时间间隔内交付一组更改，以允许更多的集成和回归测试。同时，一个常见的建议是在交付新功能的方法中包含敏捷哲学。那么这两件事是如何结合在一起的呢？为了得到这个和其他问题的一些答案，我最近和GP策略的Scott Barber进行了讨论。作为敏捷专家和认证Scrum大师，他开发并提供了关于敏捷框架的培训课程。你如何定义敏捷？它是一种方法论，还是一种框架？SCRUM如何适应？

Scott Barber：从软件开发的角度来看，敏捷是一种哲学。它源于改变软件开发文化的努力，新云，从命令和控制，到正式的组织结构和"Dilbert式"过程。软件开发是如此复杂，数据统计，以至于这不能很好地工作。敏捷哲学以经验主义为基础，有三个组成部分：透明、检查和适应。

另一方面，Scrum是一种变得更加敏捷的方法，作为一个轻量级的项目管理框架，个人网站建站，具有共同的责任和领导。每个团队由以下成员组成：

产品负责人，负责决定团队要实现的目标（产品待办事项）开发（Scrum）团队是一个自组织、自管理的团队，负责完成工作Scrum大师，他是团队所有成员的教练。

Marcel van den Top：我想我对敏捷项目和瀑布式/传统项目的工作原理有了基本的了解。主要的事情是定义更小的sprint，更频繁地交付更小的功能增量，允许您适应不断变化的业务需求并纠正您的方法。Big Bang Greenfield SAP实施项目通常没有遵循敏捷方法，因为您不能以完全集成的业务流程为增量进行实施。但是，让我们首先来看一个示例，该公司已经运行了一段时间的SAP解决方案，并且正在继续提供增强功能、支持修复和更新。将更改请求和新功能拆分为Sprint对我来说是有意义的，每个Sprint都是一个新的版本。这是一种将敏捷原则应用到SAP支持环境中的方法吗？

斯科特·巴伯：是的，这是一种方法。在Scrum中，你所做的是冲刺中的时间框，每次冲刺中总是有相同的活动。Sprint计划会议开始时，每天都要召开Scrum会议，云计算和大数据的区别，最后演示Sprint期间构建的可交付成果，然后进行Sprint回顾。团队讨论他们应该停止做的事情，因为他们不工作，什么是新的想法开始做，你应该继续。这促使下一个sprint的方法变得更有效。

更广泛地说，采用敏捷方法是否合理取决于工作的复杂性。我要问的问题是，我知道我们在做什么，我们将如何去做吗？你越能回答"是"，你就越不需要敏捷。如果你已经做了很多次，大数据系统，并且知道如何计划，那么你可能不需要采取敏捷的方法。当路径不太清晰，事情在改变，还有很多未知的时候，敏捷有更大的好处。YouTube上有一个名为"Spotify工程文化"的案例研究，你可以在那里看到它在为Spotify产品开发新功能时是如何为他们工作的。

Marcel van den Top:那么更大的实施项目呢？通常，这些都涉及到许多相互关联的组件，而这些组件是无法以较小的片段交付的。敏捷和Scrum在这里是如何工作的？在这种情况下，您如何定义"sprint"？

Scott Barber：组成整体的不同组件可以在Sprint中开发和交付。你所做的工作并不重要，重要的是你的工作方式和团队合作的方式。敏捷和Scrum的目标是让团队更有效地合作，并为您的任何目标提供更相关的结果。

Marcel van den Top：现在想想我现在的客户，他们每周提供休息/修复运输。每个传输都是独立管理的。在真正的发布管理方面没有做很多工作。它们确实也提供了很多增强功能，但只有少数功能被组合到半年一次的版本中。你建议从哪里开始改进？什么样的敏捷概念能在这里有所帮助？

斯科特·巴伯：每周的日程安排比典型的冲刺要快。在Scrum中，您通常会进行2到4周的sprint。从每周发布到每月发布将允许您遵循一个典型的模式。但是您可以合并Scrum方法论，而不管每个发布有多大或多频繁。sprint不必在一个sprint中提供从设计到部署的完整操作功能。您还可以将版本中的不同工作阶段分解为更小的包，作为Sprint产品Backlog。例如，初始设计是一个sprint的目标，原型的不同部分是下一个sprint的目标，然后是组件的详细设计和开发，等等。sprint可以包含您想要定义的任何内容。因此，无论您是处理每月的、次要的版本，还是频率较低的主要版本，您可以在发布的每个阶段定义单独的工作产品。