可以在合同定义的项目中使用敏捷软件开发吗？

14

我最近与一位开发人员就敏捷软件开发进行了交谈。虽然我理解该原理，但似乎不断变化的需求为该项目带来了持续发展的潜力。但是，至少在我工作的地方，项目需要完成，因为这是合同。

也就是说，第一次迭代可能需要几个月的时间，因为对于某些项目，客户不能使用不完整的应用程序。对于某些项目，我认为您需要先定义完成，然后可以将其分解为多个迭代，并在每次迭代后完善定义。但是您必须始终具有此定义。

如果敏捷软件开发包含不断变化的需求，您如何知道它的结尾？当最终结果总是变化时，您如何为项目预算？

敏捷软件开发是否与敏捷产品有关，而不是与敏捷产品有关？

agile

— 维拉克斯
source

当您需要实际交付有用的东西而不是动手修改时，它就结束了。到那时，您必须开始施加结构，计划，修复需求和截止日期，并开始工作而不是无所事事。

— jwenting 2011年

每次敏捷迭代都会产生一个可交付使用的可行产品，客户可以使用该产品并从中学到更多。一直持续到他们满意为止，这通常比原先计划的要早。这样可以保证产品始终在运行，并考虑到软件永远不会完成，而是会永远发展或消失的事实。当您认为产品足够好时就选择一个时间点，然后就此停下来。

— Martin Wickman

@Martin Wickman：我理解这一点，但是这里的问题是“客户可以使用的可交付产品”。在这种情况下，第一次迭代可能需要几个月的时间，因为对于某些项目，客户不能使用不完整的应用程序。对于某些项目，我认为您需要先定义完成，然后可以将其分解为多个迭代，并在每次迭代后完善定义。但是您必须始终具有此定义。

— Verax

@Verax：创建了敏捷宣言来管理更改。如果您的项目没有更改，那么敏捷不适合您。故事结局。

— Martin Wickman'7

2

@Verax：您应该澄清问题并为其添加更多上下文。您的评论表明问题还有更多。从答案的投票数来看，这也是显而易见的，并且接受的答案与实际的问题文本无关（甚至说“来自OP的评论...”）。

— Martin Wickman

7

从OP的评论看来，他像我一样在一家咨询店工作，在那里我们为客户提供开发服务...我认为是因为在这种思维框架下引起他/她的困惑...所以我要陈述一个众所周知但从未陈述过的事实。

敏捷与合同定义的软件开发不兼容。

合同必须是艰苦的，您要支付X我们要Y。您要X + M您要支付我们Y +（M * N）
合同必须是可满足的（即IE不限期限），否则它们不是合法联系人。（当涉及到联系人时，您必须经过严格的变更控制过程。）

许多咨询商店声称敏捷，他们在撒谎。他们只是说，因为敏捷获得了Buzz字词身份。

敏捷最适合程序员全职工作的内部开发，预算很少。只是时间框架和功能。

— 白痴
source

随着我对此的更多了解，我得出了相同的结论。您的最后一句话似乎是绝对正确的。我曾经为政府工作，而我的客户是我所服务的代理商，因此，只要有员工在使用这些程序，它们就必须维持多年。我可以看到敏捷在那里工作。现在，我开发嵌入式系统。机器工作时（全部或全部），项目结束。如果机器部分正常，则无法出售-项目失败。

— Verax

2

实际上，我几年前在一家咨询店工作过，实际上有一篇由敏捷信奉者撰写的论文，描述了如何将敏捷融入固定价格服务模型。

— mcottle

2

我不同意这个答案。原因是，如果您拥有的合同不是开放式的，则意味着您不想管理范围蠕变（这几乎总是发生）。我通常看到的合同开始于：您支付X，我们支付Y。然后它们有一个子句，指出任何范围更改都需要额外的价格。只要您很早就了解通知范围的蠕变（这需要额外的资源和时间），那么早期的客户就可以对更改做出反应（从高层管理人员那里获得批准和预算等）。然后，管理过程本身变得敏捷。

— Spoike 2011年

如果合同是针对服务（编写代码）而不是产品（成品软件）的，则这是不兼容的。敏捷允许估算将在什么预算下完成的工作，如果需求发生变化，预算也必须发生变化。您想要其他功能吗？您必须再签约500个工时。功能爬升也是价格爬升，开发人员完全满意，如果客户愿意付款，我们该向谁提出质疑？

— SF。

2

有敏捷合同，因此显然，根据定义，这个答案是错误的。

— Martin Wickman'7

20

如果您首先专注于（相信）最重要的事情，那么该项目将在以下情况下完成：

您已经花了预算的钱。
您已经花费了预算的时间。
您不再想要添加或更改任何内容。
下一批最高优先级的更改不值得花多少钱。

— 戴尔·埃默里（Dale Emery）
source

5

1.没有更多的钱-客户将所有的钱都花在了不完整的无用产品上。2.没有更多时间-客户仍然有不完整的无用产品。3.没有补充-是的！4.不值得-客户只是放弃了该项目。---我想念什么？这对我来说没有意义。

— Verax

7

对于1和2：如果您先做最重要的事情，那么当您用光金钱时，您将拥有最重要的事情，您可以以金钱获得。时间上也差不多。我承认3很罕见。对于4：停止并不一定意味着客户刚刚放弃。这可能意味着他们拥有他们想要的最重要的东西，现在宁愿用自己的钱做其他事情。您如何决定何时结束其他项目？您现在使用的任何条件在敏捷项目中仍然可用。

— Dale Emery

1

戴尔，谢谢您的想法。我认为这仅在客户分别为每次迭代支付费用并将每次迭代视为产品本身的情况下才有效。我不认为这对于固定成本的产品或要求全部或完全不需要的产品如何有效。

— Verax

5

@Verax：没有像“全有或全无”这样的产品。总有一些特性仅仅是“很容易拥有”，而有些bug只是表面上的而不是功能上的。如果钱用完了，剩下的全部钱，那么固定成本的项目就是成功的。敏捷方法试图使这种可能性最大化。

— Michael Borgwardt'7

1

当然，改变需求是有代价的。如果您在一次迭代中构建某些东西，然后在下一次更改这些东西的需求，那将是有代价的。敏捷降低了成本。它并没有消除它。如果您有预算，则在确定是添加新功能还是更改现有功能时，请牢记预算，同时要知道您总是在权衡一项。您将学习确定优先级和重新确定优先级，并了解后果。

— Dale Emery

14

当企业确定他们不希望再进行任何迭代时，您将停止。您希望这是在交付大量价值之后，但在您过分陷入收益递减的领域之前。

无论在何种情况下，它都应始终由“业务”驱动。它可以是内部开发环境中的软件开发商店的高级管理层或实际的商业赞助商。他们将决定下一次迭代的成本何时超过下一次迭代将可交付的功能的收益。

— 麦考特
source

5

永远不会，那就是它的美。

该项目从未完成。您到达了另一个发行版，一个新的里程碑，但是只要资金流了，总会有一个新功能要添加，一个要完善的功能，另一个要修复的错误。该项目将在不再需要时终止，但将永远无法完成。与带有需求->项目->产品->结束的瀑布模型相反，这是一个可以永远旋转的循环-只要您得到报酬。

该技术不是经常提及的业务功能，对吗？

— SF。
source

2

瀑布项目也从未完全完成，只是更有可能缺少重要功能而直接交付或离开，因此需要一个新的昂贵项目。

— Michael Borgwardt'7

4

这里有一个误解：敏捷不鼓励更改项目要求。相反，它允许进行更改而不会浪费工作或牺牲重要的开发领域。

任何工程项目都有四个基本约束；范围，成本，时间和质量。瀑布假定这些将是静态的。那是一个错误的假设；这些中的一个或多个总是会改变。范围爬升，削减的预算以及其他“未知未知数”总是会干扰项目，从而改变了约束条件。Waterfall不会预料到这一点，因此，当它发生时，项目将以不希望的方式发生变化。尚未添加的重要功能会消失，无法快速完成，或者必须推迟发布，或者由于PM向新开发人员投入资金来帮助他们正确完成工作而导致成本上升。

相比之下，敏捷允许约束发生变化，并且实际上是期望的。它根据所有者的优先级，通过在可用的小块中进行工作来完成此工作，因此，理想情况下，这些块立即对项目所有者有用。因此，通过在未知数很大的时间范围内不制定大型计划，可以减少对未知数的暴露。如果时间轴发生变化，则可以添加团队，或者将不重要的功能“取消范围”，并且团队已经构建的系统不受影响。

它还可以更好地估算以所需质量生产给定示波器所需的时间和成本。众所周知，人们不擅长估计大工作。要正确执行此操作，需要大量的经验和大量的前期计算。相比之下，人们通常会很好地判断一天或一两周内可以完成的工作。这样很快就会产生一个稳定状态，您可以在此状态下根据您的历史步伐推断出要完成的工作的时间和成本，而且准确性很高。

至于定义端点，您是对的。敏捷项目可以永远进行下去。但是，传统的SLDC也可以。客户通常会带来更多的钱和升级愿望清单。区别在于，从整体上看项目时，“分析”，“设计”，“开发”和“维护”之间没有明确的界限；这一切都是一砖一瓦，一个冲刺一个冲刺。如果所有者希望在任何时候称该项目为“完成”，则可以，并且他们将在坚固的“墙”中获得已支付的“砖”的总和；它可能没有最初计划的那么高，也没有扩展到最初的计划，但是它已经牢牢地固定在位，可以正常工作，并且可以在以后添加，而不会造成任何破坏。

— 基思
source

抱歉，但是“它允许更改而不会浪费工作”，是一个巨大的谬论，用于说服管理层对其有多出色。重构和/或重新设计系统以适应意外更改是否不算浪费工作？它在瀑布营地中使用，显然不在敏捷营地中。同样，如果客户只想要一份需要2周才能完成的工作，那么使用什么方法都没关系，人们可以给出很好的估计。客户真正想要的是我拥有完整的产品要花多长时间，敏捷度并不比其他估算方法更好。

— 邓肯

1

同样，您觉得所有者可以随时称其为完成是一件好事，而您完成的工作就是他得到的。IME，一般来说，客户想知道在自己花钱之前，他的X美元将提供某些功能。我不认为客户花大笔钱仅获得预期功能的一半是有好处的。我认为这对发展中的公司来说是失败的，即使他们可能已经交付了他们称之为工作的东西

— 。...– Dunk

2

如果客户签订了房屋合同，但在屋顶铺设之前钱用光了怎么办？敏捷营地仍将称其为成功。没有人愿意特别是客户。

— 邓肯

1

至于估算，团队估算他们可以在sprint中完成的工作，然后推断得出整个项目的时间表。同样，它有助于保护开发人员和客户端。您可以将任何想要的内容放入合同中，包括“不超过”金额和日期。这是可以商量的。通过很快向双方展示约束是否可行，敏捷仍然可以提供帮助。两周后，如果看起来不能按时完成，则可以添加团队，扩大功能范围或延长时间表。

— KeithS 2011年

1

如果它在瀑布SLDC中做了同样的事情怎么办？要么开发将停止并且客户端可能会获得具有严重功能漏洞的代码库，要么是预期金钱/时间短缺，那么剩余的时间表将被挤入剩余的时间。那总是要牺牲质量，而在这样的项目结束时，开发团队就被炒掉了。而且，由于传统的瀑布式开发直到完成才生产产品，因此发生了很多成本超支。限制了客户说“那不是我想要的”的能力。

— KeithS 2011年

1

一旦实现了所有功能并修复了所有错误，它便结束。

如果截止日期是固定的，并且要求也是固定的。这样就不会有问题了。但是，如果截止日期是固定的，但是需求在变化，那么您应该做一些事情才能成功地进行项目。

固定价格第1部分，有什么不好？

固定价格部分2，敏捷修复！

— 查理斯
source

很难知道何时修复所有错误。

— Martin Wickman

也许“当所有值得修复的已知错误都已修复时”？

— 丹·雷

@CharithJ，您的链接已损坏。他们还在某个地方吗？谢谢。

— TwainJ

1

敏捷开发背后的一个大假设是，不管使用哪种方法，需求总是在变化。现在，您当然可以构建需求文档，制定执行计划并最终交付，看来您的需求似乎没有变化。他们可能没有改变您的计划，但是随着市场的变化以及您和您的客户对产品的更好理解，关于客户需求的需求将会发生变化。敏捷进来并提出了一个流程，该流程不会通过固定的时间表隐藏这些更改，而是构建对流程中不可避免的更改的响应。

现在，当您完成工作时，将从完成固定计划的时间转变为何时将产品交付到可以交付足够业务价值的地方，客户可以在该位置以当前状态运送和销售软件。完成工作与您交付的价值有很大关系，而不是您遵守时间表。

— 布赖恩·盖斯勒
source

1

敏捷的支持者错误地做出了一个错误的假设，即在瀑布式世界中，开发人员在签订合同后就消失了，直到产品突然出现后再也没有听到过。它在现实生活中的工作方式是，有大量的检查点和许多评论，客户可以根据需要尽可能多地参与其中。如果他们不喜欢这个方向或决定，他们可以要求更改。在交付产品时，就应该是客户想要的程度（客户选择参与其中）。对于许多项目而言，敏捷并不能改善这一点。

— Dunk