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

我是一个Scrum新手,并希望在我的公司实施Scrum.获得买入不是问题,这是我的公司,开发人员非常乐意这样工作.

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

Ken Schwaber在他的书"Scrum的敏捷项目管理"中,在本书末尾的附录中介绍了固定长度/固定价格项目的招标主题.

在经过多次灵魂搜索后,Ken得出Scrum仅在这种情况下才有用,因为你可以说服潜在客户以不同的方式思考.客户端必须有很多不确定性(关于最终成本和最终交付日期),以换取更快可能可用的东西,并且不必实现每个功能的可能性可以节省他们的钱.

我不相信这是在修复长度/修复价格项目中实施Scrum的唯一方法.

我想知道其他人如何成功竞标并从修复长度/修复价格项目中获利.

是.我想你可以.看瀑布不工作.

"走出固定价格盒子"并不是一个难以进行的对话.客户也看到了失败.他们看到了需求文件的长时间延迟.他们看到了无休止的变更单.他们也不喜欢它.

但是,如果您确信客户不想以不同方式管理事物,那么您必须采取混合方法.

制定价格不是敏捷 - 它不可能.为了安抚不妥协的客户,您必须付出代价.显然,你将在这里有一些总体规划来证明价格合理.大多数情况下,您在此总体规划中想要的只是积压工作.其他细节只不过是假设的规划假设.[他们总是在计划假设,但有些PM认为最初的计划是一个必须遵循的神圣的神谕.不是.]

然后,您执行小型,敏捷,增量步骤.您必须尽早和经常与用户互动,并且必须让对话发生.但!积压的每次变更都必须作为范围,成本或进度的潜在变化进行检查.

在每个sprint结束时,任何积压更改都可能是项目范围和合同更改.

敏捷可以降低您的风险,因为您可以更早,更高效地与客户一起积极地处理范围变更.尝试定义(和冻结)范围不是增值活动,所以只是停止这样做.将范围视为猜测,并在每个sprint中处理范围更改.