你是如何签署敏捷项目的合同的?(不是你认为你会怎样,你是怎样做的)[关闭]

我在政府工作。

我们最近运行了一个软件开发采购流程,并选择了三个供应商来进行敏捷项目。一些注释:

1. 我们已经75%确信我们想要运行一个敏捷项目,因为我们知道我们的需求是模棱两可的,因为它是一个具有重要设计元素的面向公众的Web项目。所以我想说,如果你的客户了解敏捷并从一开始就购买它,即使他们实际上没有在内部实践,它也会有很大的帮助。请注意,对敏捷的接受在(一些)政府圈子中不断增长,因此这可能会变得更容易。

2. 我们使用的一个安全措施是雇佣一位经验丰富(独立)的Scrum大师为我们工作,代表我们的团队领导/架构师/可用性人员处理软件项目管理职责。我们花了很多时间寻找这个人,并从三个优秀的申请人中挑选出来。这是昂贵的,但值得。

3. 一旦我们选择了我们的供应商并大致同意了他们的角色(设计、前端、后端),我们就制定了一份快速的谅解备忘录,概述了我们进行项目的意图、可能的项目预算、每个供应商的团队规模、承诺在月底前签署一份完整的合同以及T中的时间和材料协议。他临时的。

4. 然后,我们参加了一个技术规划/规模确定会议,并开始了这方面的工作。这段时间没有进行开发工作或设计,但是我们做了大量的大小调整和高级评估。

5. 到了月底,我们为每个供应商制定了合同(一个供应商迟到了,但没问题)。一个供应商提出了我们可能使用的合同样本,一个基于三分之一的项目付款,另一个基于完成冲刺。我认为最终我们完成了冲刺(按月计费),在我们的标准合同模板的付款部分使用了一些供应商建议的语言。

总的来说,我们同意这种方法(尽管承认存在一些风险),因为我们认为项目总体上没有巨大的实际技术风险,而且我们对采购过程和我们选择的供应商有很大的信心。

最后,这是一个非常成功的项目,我们已经开始在其他项目中使用Scrum。我认为拥有一个伟大的团队是关键。我们对供应商很有信心——不仅他们可以完成这项工作,而且他们对作为一个团队工作的态度,以及每个人都有明确的角色(即,他们不会为了相同的钱竞争)。

如果我们的供应商不是很好,我们会对签订这样的合同有更多的保留,但经营采购几乎和科学一样是一门艺术,我们知道我们从其他高质量的受访者中选择了最适合的团队。

从那以后,我们已经将所有三个合同都推迟到了第二年的开发阶段,尽管这次进展不太顺利(新的Scrum大师,不同的团队组成),但它仍然是一个值得参与的伟大项目。

你也会发现这很有趣: Outsourcing Agile .

因为我主要在内部网应用上工作,所以这对我来说并不是什么问题。然而,我经常为其他部门做应用程序,有时,特别是当项目规模较大时,我们确实就项目范围(预期)持续时间和成本签署了谅解备忘录(MOU)。因为我是以敏捷的方式工作的,所以这些事情都不是固定的,这通常很难向以前没有这样工作过的其他部门解释。通常,我将包括对过程本身的描述——几个段落——解释项目是如何在他们和我之间进行合作的,我们一起决定什么时候完成。

到谅解备忘录真正写好的时候,我已经在这个项目上投入了很多时间来发现需求是什么(这些是以标准的小时费率处理的)。基于这一点,再加上对我的速度和与以前项目的相似性的估计,我对所需特性的时间和成本进行了广泛的估计——再次解释,真正的成本取决于我们实际实现的特性以及它真正需要多长时间。这需要相当多的信任,但由于我们一直在一起努力开发需求,所以我通常会与我直接处理的个人合作。我经常试图把实际估计数从谅解备忘录中去掉,但如果他们的经理坚持的话,我会把它包括在内。我确实试着给他们一个预算数字。

我的经验是,一旦项目开始,你开始为客户提供价值,他们很少不高兴。通常,他们要求(并支付)比原始项目范围更多。通常,我们都同意一些原始特性是不需要的,但我一直希望如此。毕竟,他们真的没有办法确切地知道,直到他们真正看到了他们真正需要的东西。通常,我们会删除一些特性,并根据实际开发添加其他特性。我想如果我们不这样做,那么使用敏捷方法就没有意义了。

我认为关键问题是信任。我建议在小项目上与新客户合作,或者明确地将大项目分解为小项目,以建立信任。一旦他们和你知道你可以相互信任,用正确的特性来构建正确的产品,我认为,突然退出客户的风险——而且总是有一个——是最小化的。

我曾经工作过的唯一敏捷项目是内部、时间和材料(T&M)或按周期付费项目。

问题是,正如您所指出的,项目有失败/提前结束的风险。但是,这和任何项目都不一样吗?如果你去T&M,你将承担所有风险,如果你去固定价格,客户将承担所有风险。通过按周期付费,您将承担大部分风险,但一次只将其中的一小部分风险传递给客户一个周期。事实上,你和客户都不想冒任何风险,这就是为什么你发布了这个问题。

问题是,承担风险是企业的全部,你承担的风险越大,利润越大,如果没有,损失也越大。如果风险太大,你无法处理,唯一的解决办法是找其他人来承担风险,但你必须支付。如果你和客户都不准备接受,那么可能只有两个答案:

1. 找个有钱的傻子来承担风险(比如买保险)。
2. 把风险分散在许多人中间,直到每个人承担的风险很小,可以接受为止。

我认为这第二个选择是什么使接触器如此受欢迎。因为他们很容易摆脱,他们最终承担了提前终止项目的风险。由于风险将在多个风险之间分散,因此风险将分散到可接受的水平。他们会因为额外的风险而向你收取比雇员更多的费用,但这就是你试图避免风险的原因。

在敏捷项目中,您最不希望看到的是固定范围(通常是包含在传统瀑布项目合同中的内容)。你需要的是一个固定计划的协议,一个固定规模的团队负责处理一个优先的产品积压工作。

如果您在启动过程中强制您的业务合作伙伴定义一个固定的范围,那么他们将把他们在合同中能想到的所有东西都塞进。不是因为它有价值,而是因为以后很难进行更改,他们可能需要它。

可以为业务合作伙伴请求的一组功能提供高级估计。但是,由IT和产品所有者组成的团队接受范围和优先级在实现特性期间将很容易改变。通过将重点放在最重要的特性上,团队首先成为价值驱动的,而不是计划驱动的。如果有什么东西从清单上掉下来了,它的价值就更少了,而且已经被团队学到的更重要的东西所取代了。

固定范围的契约使团队在最不了解特性的情况下可以进行范围决策。专注于优先级,允许优先级和范围在迭代之间灵活变化,确保交付的内容具有价值。

与其与业务部门签订固定范围的合同,不如与业务伙伴一起参加敏捷训练营。课程应该概述敏捷过程和产品所有者的角色。如果企业接受敏捷方法,那么就可以开始开发了。构建产品积压工作,对其进行优先级排序,提供高级评估,构建发布和迭代计划,并开始交付价值。

我们处理关系的方式 首先是把业务伙伴送到敏捷训练营。然后我们培训业务合作伙伴成为产品所有者。然后我们建立了积压工作,提供了一个高水平的估计,并确定了团队的规模和时间限制了开发。两周之内,第一个工作软件就被演示了。从那时起,业务合作伙伴就参与进来了,并且随着他们了解的更多,了解了进行更改的价值。关于固定范围合同的任何讨论都很快被遗忘了。

我们处理这件事的方式非常有成效。

我们的客户基本上购买迭代。客户签署了一份合同,上面写着“x 2周迭代”。有一个客户教育的过程(和我从事过的所有敏捷项目一样)来帮助客户加快计划过程,并且他们在开发过程结束时实际得到的东西在项目开始时不是具体的,而是控制最终结果。

我们的团队已经合作了近六个月,我们有坚实的技术基础,我们已经发展了自己,以尽量减少风险。我们对我们正在进行的速度方面的能力有一个非常可靠的了解——这有助于我们预测满足所需客户结果所需的迭代次数。

我们的PM实践仍然赶上了交付软件的敏捷方法。大多数情况下,出于谨慎考虑,初始合同定义了高级目标,但对具有可预见技术挑战的功能附加了限制。一些主要的交付里程碑,例如alpha、beta、final,都是定义和定价的。附加范围定义为补充原始合同的变更请求。这是一种学习体验,因为我们不再使用传统的瀑布方法;我看到的最大问题是,像常规部署这样的东西很难定价,因为您永远不知道解决迭代的“反馈”需要多少时间。我们曾经说过“这太棒了,我们进展顺利!”我们已经有了“这是200个缺陷的列表”;对于频繁发布的目的在客户中有不同程度的理解。

自从我们转向敏捷之后,我们的合同没有改变,客户仍然希望在主要的里程碑上获得构建,并且在Sprint的每一个结尾都无法直接参与。产品所有者不必是合同另一端的人,可以是执行经理。产品所有者不断地与真实客户的需求沟通,他评估需求,并将其展示给客户。不过,如果客户频繁发布信息,那么他与客户机的沟通就容易得多。