关闭。这个问题不满足Stack Overflow guidelines .它目前不接受答案。
想改善这个问题吗？更新问题，使其成为 on-topic对于堆栈溢出。
3年前关闭。
Improve this question
我是一名 Scrum 新手，希望在我的公司中实现 Scrum。获得支持不是问题，这是我的公司，开发人员非常乐意这样工作。
问题是我们 75% 的收入来自固定长度/固定价格的项目。
Ken Schwaber 在他的《敏捷项目管理与 Scrum》一书中，在书末的附录中涵盖了对固定长度/固定价格项目进行投标的主题。
经过多次反省，肯得出结论，只有在这种情况下，您可以说服潜在客户以不同的方式思考时，Scrum 才有用。客户必须接受很多不确定性(关于最终成本和最终交付日期)，以换取更快地获得可能可用的东西，并且不必实现每个功能的可能性可以为他们节省资金。
我不相信这是在固定长度/固定价格项目中实现 Scrum 的唯一方法。
我想知道其他人如何成功竞标并从固定长度/固定价格项目中获利。
最佳答案
是的。我想你可以。见 The Waterfall's Not Working .
“走出固定价格框框”并不是很难进行的对话。客户也看到了失败。他们已经看到了获得需求文档的长时间延迟。他们已经看到了无休止的变更单。他们也不喜欢。
但是，如果您确信客户不想以不同的方式管理事物，您就必须采用混合方法。
定价不是敏捷——它不可能。为了安抚顽固的客户，您必须制定价格。显然，您将在这里制定某种总体规划来证明价格合理。大多数情况下，您希望从这个总体规划中获得的只是积压工作。其他细节只不过是假设的规划假设。 [他们是总是 计划假设，但一些 PM 认为最初的计划是必须遵循的神谕。它不是。]
然后，您以小的、敏捷的、增量的步骤执行。您必须尽早并经常与用户互动，并且必须让对话发生。但!积压工作中的每个变化都必须作为范围、成本或进度的潜在变化进行检查。
在每个冲刺结束时，任何积压变更都可能是项目范围和契约(Contract)的变更。
敏捷降低了风险，因为您可以更早、更高效地与客户一起积极地处理范围变更。尝试定义(和卡住)范围不是一项增值事件，因此请停止这样做。将范围视为猜测，并在每个 sprint 中处理范围的变化。
关于project-management - 在固定长度/固定价格项目中使用 Scrum？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/265319/