Project management 在固定长度/固定价格的项目中使用Scrum？

我是Scrum新手，希望在我的公司中实现Scrum。获得购买权不是问题，这是我的公司，开发商非常乐意这样工作

问题是，我们75%的收入来自固定长度/固定价格的项目

肯·施瓦伯（Ken Schwaber）在他的书《Scrum的敏捷项目管理》（Agile Project Management with Scrum）中，在书末的附录中介绍了固定长度/固定价格项目的投标主题

经过大量的自我反省，肯得出结论，只有在这种情况下，当你能说服潜在客户以不同的方式思考时，Scrum才有用。客户必须接受大量的不确定性（关于最终成本和最终交付日期），以换取更快地获得可以使用的东西，并且不必实现所有功能的可能性可以为他们节省资金

我不相信这是在固定长度/固定价格项目中实现Scrum的唯一方法

---

我想知道其他人是如何成功竞标定长/定价项目并从中获利的。

我不确定竞标和利润，但scrum方法肯定可以应用于定长/定价项目。如果需求是已知的和可靠的，那么可以将其放入产品待办事项列表中，并根据需求和时间限制计划冲刺。您仍然可以利用每日scrum会议、消耗图表等的好处来确保项目保持在正轨上。

是的。我想你可以。看

“走出固定价格的框框”这一话题并不难。客户也看到了失败。他们已经看到了需求文档的长时间延迟。他们看到了无休止的变更单。他们也不喜欢

但是，如果您确信客户不希望以不同的方式进行管理，则必须采取混合方法

定价不灵活——不可能。为了安抚顽固的顾客，你必须制定一个价格。很明显，你会有一些总体规划来证明价格的合理性。大多数情况下，您希望从这个总体规划中得到的只是积压工作。其他细节只不过是假设的规划假设。[他们总是计划假设，但一些首相认为最初的计划是一个神圣的预言，必须遵循。事实并非如此。]

然后，以小而灵活的增量步骤执行。你必须尽早和经常地与用户接触，并且你必须让对话发生。但是积压工作中的每一项变更都必须作为范围、成本或进度的潜在变更进行检查

在每个sprint结束时，任何backlog变更都可能是项目范围和合同变更

---

敏捷降低了您的风险，因为您正在积极地与客户一起更早、更高效地处理范围变更。尝试定义（并冻结）范围并不是一项增值活动，所以请停止这样做。按猜测的方式对待范围，并在每次冲刺时处理范围的变化。

可以假定您指的是固定长度、固定价格和固定范围吗？我投票结束这个问题，因为它与编程无关