Dan*_*kas 35 agile project-management scrum
要执行敏捷项目,首先需要一份合同.没有合同 - 没有项目!没有项目 - 没有敏捷,SCRUM或任何东西!
如果我们谈论大中型项目,合同必须有明确的安全触发器.即客户希望非常肯定,如果我们同意在时间上结束项目= T,预算= B和范围= S,我们最终不会以时间= T×2,预算= B×3或范围= S/2.
另一方面,作为提供产品的公司,我们不希望项目意外结束.即如果经过一番迭代,客户说"现在我发现这实际上就是我们所需要的.我们现在停下来." 这个项目计划再过2个月,而不是没有计划工作的人.如果3-6人不是一个大问题,15-25可能是一个真正的问题!
然而,我没有找到任何具有安全功能的合同的真实示例,这将允许项目以完全敏捷的方式执行(声明或未向客户声明).我在许多论坛上找到的标准说法 - 与客户交谈,向他解释这是一种更有成效的工作方式等,并不能说服我和我的管理层.并不是说我们不相信敏捷实际上是一种更好的方式.只是安全触发器中的差距是如此明显,以至于我们的客户都没有买它而且我们不喜欢它们(差距,而不是客户;)).
请不要"它可能会以这种方式工作......" - 我已经阅读了大量的内容.只对"为我们这样工作"感兴趣.毫无疑问,跳过所有自信的信息.
PS据我所知,标准迭代,特征驱动的方法建议客户在每次迭代(迭代次数)后付款,并且能够在任何迭代之后由客户和项目执行者停止项目而不会过多地说明后果,而不是说"无论如何都会失败,所以越早越好"(这是正确的,但在签订合同时并不是很有帮助).
Ano*_*don 11
我在政府工作.
我们最近运行了一个软件开发采购流程,并选择了三家供应商来开展敏捷项目.一些说明:
我们已经75%确定我们想要运行一个敏捷项目,因为我们知道我们的要求是模棱两可的,因为它是一个面向公众的Web项目,具有重要的设计元素.所以我会说,如果你的客户知道敏捷并从一开始就购买它会有很大帮助,即使他们实际上没有在内部实践它.请注意,在(某些)政府圈子中对敏捷的接受程度正在增加,因此这可能会变得更容易.
我们使用的一个保护措施是聘请经验丰富的(独立)SCRUM主人为我们工作并代表我们的团队负责人/架构师/可用性人员处理软件项目管理职责.我们花了很多时间找到这个人,并从三位伟大的申请人中挑选出来.这很昂贵但值得.
一旦我们选择了我们的供应商并广泛地同意了他们的角色(设计,前端,后端),我们整理了一份快速的MoU,概述了我们继续进行的意图,项目可能的预算,每个团队的可能规模.供应商,承诺在本月底签署一份完整的合同,并在此期间签订时间和材料协议.
然后,我们参加了技术规划/规模调整会议,并将事情的一部分推进.在这段时间内没有开发工作或设计,但我们做了很多尺寸和高级估算.
到本月底,我们为每个供应商制定合同(一个是迟到的,但没关系).一个供应商提出了我们可能使用的样本合同,一个基于项目三分之一的支付; 另一个完成冲刺.我认为最终我们使用标准合约模板的付款部分中的一些供应商建议的语言完成了冲刺(每月结算).
总体而言,我们对这种方法没有问题(尽管承认存在一些风险),因为我们认为整个项目中没有大量的实际技术风险,而且因为我们对采购流程和供应商有很大的信心.选了.
最后,这是一个非常成功的项目,我们已经开始在内部使用SCRUM进行其他项目.我认为拥有一支优秀的团队是关键.我们对供应商充满信心 - 不仅是他们能够完成这项工作,而且他们非常适合他们作为一个团队工作的态度,并且对于每个团队都有明确的角色(即他们会不要争夺同样的钱).
如果我们的供应商不是那么好,我们会对签订这样的合同有更多的保留意见,但是运行采购几乎与科学一样艺术,我们知道我们选择了最合适的团队来自其他高质量受访者的态度.
我们已经将所有三份合同都延期了第二年,虽然我说这次不是那么顺利(新的SCRUM大师,不同的团队组成),但它仍然是一个很好的参与项目.
你可能也会发现这很有趣:外包敏捷.
tva*_*son 10
由于我主要在Intranet应用程序上工作,这对我来说并不是一个问题.但是,我经常为其他部门做应用程序,有时候,特别是当项目很大时,我们会就项目范围,(预期)持续时间和成本签署一份谅解备忘录(MOU).由于我以敏捷的方式工作,所以这些都没有修复,这往往很难解释为之前没有这种方式的其他部门.通常情况下,我将包括对流程本身的描述 - 几段 - 解释项目如何是他们和我之间的合作企业,我们共同确定何时完成.
在实际编写谅解备忘录时,我已经在项目中投入了大量时间来发现要求是什么(这些是以标准的小时费率处理的).基于此估计我的速度和与之前项目的相似性,我对所需特征的时间和成本进行了广泛的估计 - 再次解释,实际成本取决于我们实际实现的功能和真正需要多长时间.这需要相当多的信任,但由于我们一直在共同制定要求,我通常会与我直接处理的个人一起制定这些要求.我经常试图将实际估计数从谅解备忘录中删除,但如果他们的经理坚持要包括它.我确实试着给他们一个预算编号.
我的经验是,一旦项目启动并开始为客户提供价值,他们很少会感到不快乐.通常,他们要求(并支付)超过原始项目范围.通常,我们都同意不需要一些原始功能,但我总是希望如此.毕竟,他们真的无法确切地知道,直到他们真正看到他们真正需要的东西.通常,我们会删除一些功能,并根据实际开发添加其他功能.我想如果我们不这样做,就没有任何意义使用敏捷方法.
我认为关键问题是信任.我建议在小型项目上与新客户合作,或明确将大型项目分成小型项目以建立信任.一旦他们和您知道您可以相互信任以构建具有正确功能的正确产品,我认为客户突然撤出的风险 - 并且总有一个 - 被最小化.
我曾经参与的唯一敏捷项目是内部,时间和材料(T&M)或每周期付费项目.
正如您所指出的那样,问题在于项目有可能导致项目早期失败/结束.但是,是不是和任何项目一样？如果您去T&M,您将承担全部风险,如果您去固定价格,客户将承担全部风险.通过按周期付费,您将承担大部分风险,但是每次将一小部分风险传递给客户一个周期.因为它发生了你或客户都不想承担任何风险,这就是你发布这个问题的原因.
问题在于承担风险是企业的全部意义,风险越大,获利的风险就越大,但如果没有,损失也就越大.如果风险太大,您无法处理,唯一的解决方案就是找到可以承担风险的其他人,但您将不得不支付他们的费用.如果您和客户都不准备接受它,那么可能只有两个答案:
我认为第二种选择是让接触者如此受欢迎的原因.因为它们很容易摆脱,所以最终会冒着早期项目终止的风险.由于风险将在其中一些风险之间传播,风险将扩散到可接受的水平.由于额外的风险,他们会向您收取的费用超过员工,但这是您自己试图避免风险的原因.