资助敏捷项目

13

我所工作的公司正在努力地迈向敏捷项目管理策略-一次又一次地体验了瀑布的“欢乐”。这样做的关键是将重点转移到交付功能上，而不是满足艰巨的截止日期。

尽管通过敏捷开发的迭代发布肯定会改善开发过程和客户关系，但事实证明，将相同的原理应用于该项目的融资策略更加困难。客户通常不习惯诸如敏捷之类的概念，并且对他们认为“准备就绪后就会准备就绪”的情况表示极大的关注。

我想听听人们在资助敏捷项目方面的想法和经验

编辑： 我想强调的是，我不是在要求人们向我解释敏捷方法的优缺点，也不是我相信敏捷等同于“准备就绪后就会准备就绪”，这是由我提倡敏捷开发实践时曾与之合作的客户/企业。

我感兴趣的是人们解决了根深蒂固于业务客户/关系中的“传统”瀑布式预算方法与更先进的开发方法之间的冲突的经验，以及他们为支持这种演进而采用的预算策略。

agile 
— 孙武功
source
2
来自Gartner的Lisa Crispin和David Norton对“销售敏捷”有一些好的想法。看一看他们怎么说：bit.ly/rlRF4U
— 敏捷侦察兵

Answers:

4

如果您能够在项目上提供所有功能的确切截止日期的报价，那么为什么要改用敏捷方法？您和其他所有人都为此感到挣扎，而敏捷方法已成为这个事实的先行一步。用它来宣传比赛。西南航空不会像其他任何人一样向您保证一个岛位，然后再将其分配给其他人。

当然，客户需要确切的结束日期。他们希望能够廉价地交付无缺陷的廉价软件，而不管对原始请求的任何更改。告诉您的销售团队学习如何使用敏捷原则销售项目。您进行的互动越多，您就越可以知道项目何时完成。客户还可以学习考虑变更请求的影响。

— 杰夫
source
“告诉您的销售团队学习如何使用敏捷原则销售项目”-我将尽我最大的努力……{;）
— sunwukung
5

敏捷项目无法按照“准备就绪时就准备就绪”的方式工作。那是瀑布工程的经典路线。

当客户决定不愿意在其他功能上花更多的钱时，敏捷项目就完成了。您的销售人员可以将其转换为关键卖点。客户无需为固定的金额投入一组固定的功能（可能不需要事先知道这些功能），而是可以从初始金额开始使用初始功能集，然后逐步使用。这将保证以下几点：

  • 只要正确确定了功能列表的优先级，客户就会始终获得下一个交付的下一个最重要的功能，从而从其支出中获得最大的收益（他“物有所值”）。
  • 如果客户的钱用光了，那么他将最大程度地投资，并且您已经为交付的商品付款。没有人受伤，每个人都从中获利。
  • 客户可以在每转一圈（每次转换的每个结束）时改变主意和功能。与普通固定价格合同相比有明显的优势。

可能还有更多，但以上内容足以使您的销售人员朝正确的方向发展。

— 沃尔夫冈斯
source
回复：“没有人受伤，每个人都获利”-除了那个被解雇的人，因为他向老板保证，只要支付X美元，他就可以得到执行XYZ的软件包。不幸的是，由于敏捷，该软件包仅适用于XY。离开经理，解雇未达标的人。也许我与大多数敏捷支持者所处的行业完全不同，因为他们看不到仅向客户提供部分解决方案的问题。OTOH，我看不出提供部分解决方案的目的，因为很可能会使产品对客户毫无用处。
— Dunk
显然，您尚未在适当的敏捷环境中工作，否则您不会发表这样的评论。如果需要XYZ，则将交付XYZ。RST和UVQ可能无法交付，但是由于它们的优先级较低，因此客户也不必为此付费。当然，如果您的开发人员与他们的估计值相差甚远，甚至无法按自己的估计值提供XYZ，那么这里有一些教训需要学习。
— wolfgangsz
3

好吧，我不认为它是“准备就绪后就会准备就绪”的情况。敏捷方法可以定期（例如每两周一次）促进提供可交付成果。这就是为什么客户在项目的整个生命周期中都是项目中重要且非常活跃的部分的原因，因为客户可以就产品功能的形成方式提供指导。如果有的话，客户将更快地看到结果，而不是像瀑布方法那样在项目结束时看到结果。

只要您重申一个事实，那就是客户将成为项目的积极组成部分，并且他们将看到项目早日成形，因此可以向他们保证，不必等待完成。

— 马龙
source
只是要清楚一点-我并不是说我相信敏捷等同于该描述，但这就是客户/销售人员经常看到的描述。敏捷在迭代方面很出色-但是很难确定项目的结束对吗？
— sunwukung 2011年
4
@sunwukung-您的销售团队并没有卖出一个事实，那就是没人能一开始就准确地预测一个漫长项目的结束。
— JeffO 2011年
我想对项目结束有个最好的想法是与客户举行项目计划会议，并列出他们想要的所有功能。然后，您可以构建完整而完整的项目积压。与您的团队坐下来，让他们填写整个待办事项的估算。使用这些估计作为项目完成时间的粗略指导。
— JuniorDeveloper1208 2011年
1
@sunwukung-不，不是真的，坐下来计划积压也是敏捷的一个好主意，这是开发过程的实现使敏捷与瀑布有所不同（敏捷是迭代的）。我认为向客户出售敏捷产品后，您面临的主要障碍实际上是实施它。我已经经历了几次，这可能是一个痛苦的过程。
— JuniorDeveloper1208
1
抱歉-是的，我了解-我们一直在使用积压方法来估算预计的交付时间（使用Pivotal Tracker，很棒的应用程序顺便说一句）。张力是由这种方法产生的模糊性引起的，这种模糊性是由该方法得出的初始里程碑与实际ETA（一旦速度开始下降）之间的差异引起的。国际海事组织它是所有关于我们如何处理客户关系-但是这是一个有点政治因素
— sunwukung
2

尽管我工作的地方确实可怕地折磨了敏捷，但我认为客户更喜欢迭代而不是完整版本的软件开发。

迭代适合客户的个别请求，因为他们请求一些东西，并在实现功能时获得它，而不是一次完成，并且与它组合在一起以发布的所有其他功能也都完成了。

我从未见过客户说：“我们想要此功能，我们希望等待8个月才能将其与其他我们不关心的其他功能一起交付。”

— 肖恩·D。
source
1
这可能取决于客户的规模。我认为在桌面软件的情况下，大型公司不想进行大规模重新安装/图像测试/等工作并不少见。经常使用，在这种情况下，他们希望使用不太频繁的“发布”。但是，开发人员仍然可以在内部进行迭代，并仅按客户希望的时间间隔向这些客户展示该应用程序的正式版本。
— 亚当李尔
+1表示“我们想要此功能，并且我们希望等8个月才能将其与我们不关心的其他功能一起交付。”
— sunwukung 2011年
2

如何建立与迭代一致的付款周期？敏捷的思想是，您只能在短时间内真正地计划和估算，并且在这些短周期内，推动和投入仍然很强劲。因此，为什么不以相同的方式瞄准资金-让客户在提供指导的同时又以$$为工作贡献。毕竟，如果他们没有得到他们想要的东西，那么他们不应该为此付出代价。

然后弄清楚在项目终止时会发生什么情况，例如，客户端是拥有代码还是仅拥有可执行文件？但这与以前的瀑布式项目是一致的。

— 贝特拉克希米
source
我同意这一点，我怀疑该业务的部分问题在于通过这些“短期”资金投入来预测其年收入（从而使投资者感到满意）。
— sunwukung 2011年
我想知道您是否可以从订约模式中窃取？如果客户突然说“谢谢但没有”，这确实增加了停机的风险，这应该类似于合同工模式吗？
— bethlakshmi 2011年
1

敏捷的想法是，您可以快速迭代并准确确定每次冲刺结束时要交付的内容，因此，当冲刺的2/3/4周用完时，您的应用程序/项目中将具有明显的功能您可以呈现给客户并获得反馈。

预计到达时间：您可以将“冲刺”与已建立的交付物捆绑成“里程碑”，并按里程碑收取付款。

— 初级开发人员1208
source
这就是我要在行业中推广的-支付“舞台门”的费用。关键问题是最终交货日期-客户是否必须放弃具体的最终交货期限？
— sunwukung 2011年
很难说，经过几次冲刺，您应该能够确定团队的速度（每个冲刺可以完成的工作量），并证明您有一个完整而完整的待办事项列表（构成任务清单的任务/用户案例的列表）完整的项目），您应该能够通过观察自己的疲倦状况来合理地预测完成日期（团队速度图表，可以用来推断完成日期，并查看您是否能够完成sprint中的所有工作）。
— JuniorDeveloper1208 2011年
2
@sunwukung，在每个人都向您如此完美地描述了这一点之后，您再次错过了这一要点。敏捷保证客户在每次冲刺结束时都能获得工作软件。如果他们仍然希望所有功能的完成日期都可以完成，那么他们可以拥有该日期，但仅适用于他们在签署交易时达成的功能。他们改变要求并期望最后期限保持不变是不公平和不合理的！
— maple_shaft
1
好吧，只要告诉他们，在开发过程中，他们将能够在每个sprint结束时查看他们的项目，始终处于工作状态并准备好进行反馈，这不应该是一件容易的事，敏捷非常好。
— JuniorDeveloper1208 2011年
1
@sunwukung，听起来像如果您在这种情况下代表业务部门，公司会做得更好:)我不知道您可以对业务部门说什么，以说服他们您已经知道的事情。他们可能不会听你的。不幸的是，听起来像技术方面正在进入21世纪，而业务方面已经过去。这不是一个容易的问题，您很可能无法解决此问题。
— maple_shaft
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.