很少有人找到出路，有些人即使找到了也看不到它，许多人甚至没有寻找它。
从爱丽丝梦游仙境
本文提出了以下问题。
- 关于“ Scrum +固定价格”外包公式的组成部分不一致。
- 错误选择Scrum工具之前可能发生的一种错误（根本原因）。
- 关于确实存在将Scrum和固定价格结合在一起的问题的一种情况，这需要深入分析和权衡才能解决。
本文涉及一个非常有争议的观点，没有明确的观点，并且是无休止的讨论的主题。因此，在阅读时，请记住您的观点可能与所提出的观点不一致，但这并不意味着我们中的任何人都是绝对正确的，也不意味着有人绝对是错误的。
如文章“如何在外包中启动伪Scrum”所述，在许多外包项目中，其团队结合（或一厢情愿）Scrum和固定价格，因此无法正确识别项目生命周期（LC）。那些。在迭代的增量或灵活的生命周期之间进行选择时犯了一个错误。结果，选择了错误的管理工具-Scrum框架。这种选择的后果是出现了许多问题，有关敏捷，Scrum和尝试的错误结论（来自“酷刑”一词？）将这两个相互排斥的概念结合在一起。
互斥？！
现在我争辩。
假定读者进一步熟悉以上文章的材料。
Scrum + Fixed Price – , ?
, , .在订立提供外包服务的合同时，客户几乎总是坚持采用固定价格（交钥匙计划）。他的愿望是确定产品范围（或工作量），请参阅预算，截止日期。他想看看他在“购买”什么。客户很少同意时间和材料。
“ ”
因此，关键点是：在合同中确定客户的需求，服务提供商应履行合同中规定的义务，并确保在开发开始后参数保持不变，并具有可预见的错误（由于在销售和签约阶段存在一定程度的不确定性和风险）。减少不确定性和风险程度的问题是与产品范围相关的发现（预售，诊断）阶段的可行性和质量问题。
很明显，如果我们修理了一件东西（我们根据合同向客户保证），那么我们就必须以确保履行我们义务的方式来计划和管理它。那些。管理计划（或项目三角形的固定特征）。
固定价格只是迫使我们优先考虑计划管理。否则，为什么我们需要在事先知道会改变的情况下进行修复，而我们并不打算进行管理？只是签合同？已建立的销售流程中的一个严重错误：我们已解决该问题，并且事先知道我们将进行更改，仅是为了签订合同！
我们为什么要改变？因为Scrum总是关于不确定性及其结果-变化。这与变更管理的优先级有关。并且它们有可能出现在第一次冲刺之后。为什么？
关于变更可能原因的题外话变更
可能是什么原因？例如，在某种程度上可以定义产品范围的情况下，它可能处于发现（预售，诊断）阶段中，表现不佳（例如，请参阅本文中案例研究的第3段），但是对于由于某些原因，此操作尚未完成。在这种情况下，这是阶段和内部流程的问题，而不是为固定价格合同选择Scrum的原因，而是灵活的生命周期而不是迭代的生命周期，以补偿所犯的错误。
公平地说，尽管我注意到外包的销售（业务分析师的售前活动）（从产品范围的角度来看，这是最成问题的阶段之一！），但并不是所有的事情都像购买具有特定特性的成品时的商店那样简单（功能）。发现阶段是业务分析师和团队难以出售的活动。但是，将不确定性最小化到一个程度或另一个角度来评估风险是精心构建的销售流程的主要任务之一。以及在客户中形成对这些活动的必要性和重要性的理解（这很困难！）。但是为此，有足够数量的技术和工具。这归结为所提供服务质量的问题，而不是“猪戳”的销售。
另一个原因可能是当前无法确定产品范围和愿景（例如，请参阅本文中案例研究的第 2点）。当出现严重矛盾并提出在提供外包服务时将Scrum和固定价格相结合的问题时，这对于双方而言确实是一个非常困难和不利的情况。它需要仔细的分析，采取其他措施以形成对客户的全面理解（通常在技术上和意识形态上与开发过程的现实相距甚远），以了解可能遇到的困难和风险，并寻求折衷方案。
那么为什么选择Scrum？要管理因例如错误执行的发现阶段（预售，诊断）或在此阶段无法确定产品范围而导致的更改？我认为第一种情况是错误的。在第二种情况下，很难以固定价格实施。
选择Scrum作为敏捷工具的第三种可能选择是灵活的生命周期，而不是在发现阶段确定产品范围并将其固定在发现阶段（售前，诊断）以及合同中的固定价格情况下，而不是迭代的增量周期。在我看来，这也是不合理的：为什么选择一种管理变更的工具（毫无重点的事情显然是重中之重-一项计划），何时将其可能性最小化？
返回文章的主要思想。
但是，假设选择了Scrum。同样，Scrum是一种变更管理工具，只有在过程中以及使用适当的方法时才能减少不确定性程度。而这种下降是这一过程的结果。
但是固定价格合同优先考虑计划的管理！
因此，“公式”“ Scrum +固定价格”被转换为“同时进行变更管理+计划管理”。经理的任务是在不同程度上管理计划和变更，但是只能有一个优先级：计划或变更。
计划管理或变更管理是一种嵌入在管理和业务分析基础中的公理。它反映在针对管理人员（PMBOK）和业务分析师（BABOK）的基本手册中（不仅如此）。生命周期的分类（以及与特定项目相关的标识）依赖于生命周期的分类：存在设计用于管理计划的生命周期（例如，Waterfall，迭代增量（IID））和灵活的敏捷用于变更管理。生命周期（以及随后的工具）的选择基于管理中的优先级。
弹性生命周期是具有某些主要特征/特性的项目的一种迭代增量生命周期（以上文章中列出了一些检查问题）），让您将其标识为单独的生命周期，并“全力以赴”进行变更管理。这些功能可以归因于：无法“在这里和现在”实现产品范围的一定程度的确定性（最重要！），搜索将“射击”的业务解决方案（或其快速交付给业务以生成反馈），形成关键功能列表产品（主要功能），短迭代，可变性，实验，功能的逐步构建，回顾，不仅是产品的改进，而且还包括对过程的改进，以便获得最佳的产品版本。在这种情况下能否获得足够的预算和条款估算？
魔鬼只是一个细节，或者...都是关于产品范围的
一切都有自己的道德，您只需要能够找到它！
从爱丽丝梦游仙境
在销售阶段，发现阶段，外包项目开始时，您对产品范围和愿景的确定性（建立它的能力）有什么看法？
如果由于产品独特性的原因，启动的想法，有关业务决策有效性的不确定性（需要找到它们）以及确定产品关键功能的难度，需要验证的假设的存在等原因而无法定义，评估，确定产品范围，则无法确定产品范围。 ... （见再次指向案例研究的2 这里），然后，当然，Scrum的框架是最合适的工具。
但是，对于外包来说，这种情况由于客户在签订合同时使用固定价格方案的愿望而变得非常复杂，这对双方都不利。在某种程度上，基于某些假设，在承包和管理此类项目时可以达成折衷方案。重要的是要形成对客户（投资者）的正确理解和正确期望，评估风险，在可能的情况下考虑其他财务互动方案，并在项目实施过程中不断与客户的忠诚度等合作。我不会深入探讨这个问题，因为它不在本文的讨论范围之内。
在外包中，最常见的问题主要在于与产品范围和正确生命周期的选择有关的发现（预售，诊断）阶段的胜任行为。并且，如果在可以确定产品范围的情况下选择了敏捷和Scrum（在由于某些原因而未按时完成产品，并期望将来对其进行开发），并且同时在合同中确定价格的情况下更是如此。我认为正在犯一个错误，这对该项目的积极成果产生了怀疑。
感谢您的关注！