我是SAP Solution Manager顾问和测试专家。作为一名认证的专业Scrum大师，我总是希望帮助客户变得更加敏捷。""快速、安全和经济高效"，Inventy说，长话短说：这篇文章不是针对SAP的，而是给你一个敏捷SCRUM框架的总体概述！如果您对以SAP为中心的敏捷框架感兴趣，请看一看SAP Activate方法论。

敏捷软件开发并不适合所有人。

让我先澄清一点：如果您的项目中几乎没有变化和不确定性，您就不需要"敏捷"。敏捷宣言（Google it now！）在假设发生变化的情况下，为降低成本和风险，更好地满足客户的期望提供了极好的方法。对初创企业和小公司来说，"快速失败"是最有利的，因为直接客户的反馈有助于他们发现人们真正需要的东西，而不仅仅是他们所说的最好拥有的东西，除非你想因为错误的需求评估而导致数月的延迟。当产品开始变得可互换，或已转换为您可以购买的服务时，为可靠性和再现性而优化的系统更有价值。

"我24个月后给您回复。"敏捷软件开发只不过是将下一个realeease分解成更小的周期（通常在1到6周之间），而不是交付一个巨大的realeease，其功能可能会或可能不会说服客户。一个周期（或"Sprint"或"iteration"）基本上是一个小型实现项目，云服务器好吗，它关注于您的新的增量功能，并将成为您的下一个上线版本。许多SAP顾问更喜欢较长的冲刺时间，因为这会让您产生一种错误的安全感，而且感觉更像是您熟悉的瀑布式方法，需要远离它。

因为团队在这个过程中没有时间浪费，所以工作必须以高度协作的方式进行。这意味着实时通信，例如定期面对面交流，而不是每天发送几十封（更可能是几百封）电子邮件；以及由开发人员、分析师、顾问、领域负责人和促进者（交互设计师、赞助商、，请注意，Scrum强调的是共同的责任：作为一个团队，你失败了。更重要的是，大数据什么意思，你作为一个团队取得了成功，因此你必须尽早取得快速胜利，以激励团队继续前进。

这一切都是关于你的。敏捷宣言和Scrum方法论是两个不同的东西：第一个永远是第二个的先决条件。Scrum旨在促进敏捷开发（SAP实现），并支持创建自组织的敏捷团队。例如，许多人正在寻找的Scrum大师认证，应该可以帮助你承担起传统项目经理（集中、协调）和促进者（通过指导和指导）的角色。项目经理不应该指导团队，而应该帮助团队成员感受到对其他团队成员的承诺。

敏捷Scrum开发项目的里程碑。*启动会议（即半天）。这应该是对项目需求的一个介绍，选择"用户情景"来分解为可编程任务，并估计完成时间。你应该试着让客户了解谁是你的客户，你想要达到什么目标，大数据的现状，以及为什么对你的团队来说表现良好是如此重要。团队成员共同决定"Sprint backlog"，这是每个Sprint要完成的优先工作列表。与启动会议不同的是，你希望你的员工了解他们应该做什么的细节。应该欢迎任何人添加或删除任务，然后根据每个卷在团队中分发任务。ScrumMaster，如果你雇了一个，将有助于建立个人对团队的承诺。同一时间，同一地点，每天。除非医生说，否则任何人都不准坐。团队成员应该单独回答3个简单的问题：1）自从上次会议以来我完成了什么？；2）我接下来要做什么？；3）阻碍我实现目标的问题有哪些？。你要确保团队中的每个人都朝着同一个冲刺目标前进，如果已经决定了，就改变优先顺序。

*回顾会议。在每次冲刺结束时，数据分析怎么做，你应该展示团队所取得的成就。你也可以利用这样的机会召集团队，评估哪些工作做得很好，或者在下一个Sprint中哪些需要改进。冲刺。烧毁"）

这对QA测试有什么帮助？敏捷思考者相信测试（使用SolutionManager7.2测试套件！）需要在整个迭代周期中进行集成，而传统的项目经理认为这应该是最后的一个阶段。再一次，当你的项目是你知道闭上眼睛就能做的事情时，单独的测试阶段没有错。但是，如果对即将发生的事情一无所知，采用正式的方法论，甚至精益思想是非常危险的。

一个可悲的事实是，数据支持，质量测试人员和顾问之间的竞争非常激烈。因为测试专业人员从一开始就参与进来，同时拥有关于需求和客户需求的相同信息，所以QA和顾问之间的沟通和协作通常更好。他们朝着一个共同的目标努力，并通过每天的会议来保证这一点。建立自我组织的团队也意味着每个人的声音都有同样的分量，但产生了互补的工作：测试人员更善于确定备选方案，而顾问（分析师）则提供具体的结果。