logo标签列表

放弃敏捷，转向瀑布流——这样做是否正确？

agilewaterfall
53
我目前在一个敏捷开发环境中工作，现在的情况让客户觉得他们更喜欢瀑布流式开发方式，因为他们认为当前的敏捷模式失败了。这种想法产生的原因是在迭代的最后阶段出现了大量设计层面上的变化，我们（开发人员）无法在规定时间内完成。
像往常一样，我们互相指责对方。从我们的角度来看，末期的变化太多了，需要修改的设计/代码也太多了。而客户则抱怨说我们（开发人员）没有完全理解需求，并提出了“不符合”他们需求的解决方案（例如他们要求我们画老虎，而我们画了一只猫）。
因此，客户（而不是我们）认为敏捷开发过程不正确，他们想转向瀑布流式开发方式，但我认为这将是灾难性的。简单地说，客户在使用敏捷模式时都不够满意，那么在瀑布流式开发的设计阶段花费那么多时间后，他们又如何容忍输出结果呢？
请给出您的建议。
你的客户是否在开始开发之前对你的设计进行技术审查并计划签署确认文件？ - JoseK
@JoseK：客户没有技术审查。他们更多是终端用户，而不是技术人员。 - bragboy
1
该问题似乎不适合讨论，因为它是一个概念性问题，而不是一个具体的编程问题。 - svick
16个回答
53
首先，请问您是否真正地实行了敏捷开发？如果是的话，你应该已经在前几个Sprint中向客户交付了大量可用功能，满足了他们的需求。理论上，“损害”应该仅限于最后一个Sprint，在那里你发现需要进行重大的设计更改。既然如此，你应该已经证明了自己的能力，并且现在需要与客户进行对话，计划所需的更改。
但是根据您的描述，我怀疑您已经陷入了只是按两周循环开发而没有实际每次投产并且有一个固定的首次正式发布截止日期的陷阱。如果是这种情况，那么您实际上在进行迭代式瀑布式开发，而没有提前进行需求分析/设计——通常是不好的做法。
完全的瀑布式开发不一定是答案（有足够的证据表明其存在问题），但某些程度的前期规划和设计通常在实践中比“纯粹”的敏捷理念（与精益方法相符）更可取。如果只是开始随意编写代码并希望在若干个Sprint之后一切都好起来，大型项目就不能指望实现合理稳定的架构基础。
除了上述问题，“纯粹”的敏捷开发还存在另一个常见的问题——客户期望管理。敏捷开发被宣传为这种神奇的东西，可以让客户推迟决策、改变想法并添加新的需求。然而，并不意味着最终日期/预算/所需工作量保持不变，但人们总是忽略了这一点。
28
敏捷开发方法在您的需求不明确且可能需要在项目后期进行设计更改时特别适用。在这种情况下，瀑布流方法就不太合适了。瀑布流方法适用于我们已经很好理解的项目，并且项目期间需求不太可能发生变化。但是它似乎并不适用于这里描述的情况。
你们的Sprint（迭代周期）有多长呢？另一种方法可能是缩短Sprint的长度——至少在项目开始阶段如此。更频繁地向客户交付新版本，并与客户讨论更改。如果您没有按照他们的要求进行操作，这将更快地变得明显，因此不会浪费太多时间来实现无法满足客户要求的解决方案。
27
+1，听起来你需要更快地“失败”，而瀑布模型会让你失败得更慢。 - Paul Dixon
每个迭代的持续时间为2周，我们会对每个迭代进行中期审查和演示。前5个迭代的生活很美好。但在第6和第7个迭代期间，所谓的众多更改开始涌现，这影响了已经实现的功能。需要更多的代码重构和修改/影响。这最终导致/正在导致项目不稳定，并且对按时交付项目产生了疑虑。 - bragboy
6
@Bragboy: 最近几次开发迭代中，你似乎承诺了超过自己能力范围的任务。如果你知道设计更改是必要的，那么在评估时应该考虑到这一点。不要在一个迭代中包含超过你能够完成的功能。如果你直到迭代的一半才意识到需要进行设计更改，那么你将不得不向客户解释你的评估错误，并表示你是在实施过程中学习到了这个问题。转换为瀑布模型也没有帮助——你在评估时会更加缺乏知识。 - Mark Byers
26

我不确定你经营的是哪种商店，所以很难给出好的建议。但我可以提供两个指导原则：

  1. 如果你与客户沟通不畅，任何开发方法都无法拯救你。
  2. 只要餐点美味，顾客并不关心厨师如何组织厨房。
5
然而，当服务员每十分钟就像短跑一样跑到桌边，说出类似这样的话：“嗯……我们现在用奶油来配酱汁，搭配的是……嗯……我想你还是点了火鸡，对吧？” 那么或许坐下后拿起餐具之前的过程需要改进。客户和厨房之间的对话总是很重要的。 - reinierpost
2
“敏捷厨师”？又诞生了一档名人烹饪比赛节目！ ;) - drxzcl
10

听起来你们有严重的项目管理和架构/设计问题，通信也出现了问题。我认为从根本上说，改变你们的开发方法论并不能解决这些问题，因此这是错误的做法（尽管可能会恢复一些客户信心）。

我特别担心你们向瀑布模型靠拢，因为现在你们选择了仅仅捕捉需求一次（我们知道这是你们的问题），没有机会获得反馈。这种刻板性对于不灵活的交付目标很有用，但在这里完全不适用，因为你们总是面临变化——那就是敏捷！

  • 短期内，我建议你们回头再次检查他们的需求，重新谈判并确认当前状态。

  • 中期内，我建议你们加强与客户的沟通——尝试让他们参与日常站立会议一段时间（直到你们恢复信心，然后可以更加灵活）。

  • 长期内，你们必须担心你们的项目经理和高级开发人员如何将你们推到这个位置。如果客户不合理，那是一回事（但这仍由项目经理来处理，所以你们不能脱责）。抱怨有太多的变化是不合理的，这意味着你在确定需求时出了问题（这是一个对话，而不是独白），或者你需要更多但可能更短的迭代周期。

总之，我认为向瀑布模型靠拢根本不可能是正确的。它并不能直接解决任何问题，我只能看到它会加剧你们已经指出的问题。

免责声明：我无法客观地评价瀑布模型，因为我从未见过它有效地工作，而且在我看来，对于企业项目来说，它已经完全过时了。

2
就像你自己所说的那样，这是一种有偏见的回答，甚至没有考虑到瀑布式开发，尽管有效的瀑布式开发过程显然经常发生。虽然我可以猜测，即使在这种情况下，原帖作者也不想公正地评估瀑布式开发的优点，而是希望得到重申坚持敏捷开发对客户最有利的意见。 - Nakedible
7
敏捷开发并不能使你免于实际上需要设计一种你和客户都能类似理解的设计的负担。敏捷只是让你可以分小块来设计，而不是一次性全部完成。并且，在遇到困难的客户时，设计一个合适的方案需要时间。

因此，我会花更多精力与客户坐下来，用白板讨论他们真正想要的是什么。在这种情况下，开发过程是敏捷还是瀑布并不重要。

7

敏捷或瀑布模型只是词语而已。有些做法行得通，有些则不行。 软件开发对于许多人来说似乎是虚拟的，他们不理解为什么修改他们要求的小事情难度如此之大。

你的客户应该明白，构建软件就像建造房屋一样：当你建好所有的基础和墙壁时，要更改整个房屋的最终计划和房间设计就很困难了。

一些实践可以避免这种问题：数据建模、数据字典、数据流图...其目的是完全了解每个需求。将产品切分成许多独立的块有助于在继续设计或指定最终产品的其他部分的同时开始编码。

参见Steve McConnell的书籍《快速软件开发：驯服狂野的软件进度》，了解所有有效的实践方法。

1
+1 对于“敏捷或瀑布模型只是词语”的支持。请查看我对 Dan's answer 的评论。 - GreenMatt
即使在建造房屋时，客户也希望进行更改...尽管他们可以看到用大理石替换廉价的陶瓷将会影响他们的钱包。或者增加另一个房间也需要更多时间。当客户亲眼看到这一切时，他们更容易理解。 - aqwert
4
他们认为这样想的原因是，在冲刺结束阶段发生了大量设计层面的变化，而我们（开发人员）无法在他们规定的时间内完成。

Scrum 可以看作是一种“短暂的瀑布式开发”，在冲刺期间应该与需求变更隔离。但似乎现实并非如此！因此，不要认为改用传统的瀑布式开发能够带来好处，而应坚持在冲刺期间冻结需求。也许你们的迭代周期太长了？（我假设你们采用 Scrum，因为提到了 sprint）

与客户沟通并达成以下共识：

- Shorter iterations, up to 3 weeks max.
- No changes in requirements during the iteration. 
- Features are planned at the beginning of the iteration 
- Every iteration ends with deliverable: fully functional software with all features that are fully operational
- Iteration length does not change. Unfinished features are left for the next iteration (or maybe discarded if client changes his mind).
- Number of "feature points" you can deliver in a single iteration should be based on the team metric, not client insistence. This is your "capacity".
- Client decides what features (but not how many of them) are planned for the iteration

你应该问自己的另一件事是为什么你的应用程序中有如此多的“设计级别更改”。到目前为止，您应该已经具备基本的体系结构和设计。也许您应该审查实际的设计并尝试强制执行一些设计指南并实施一些模式。例如，在典型的企业Web应用程序中，您可能最终会使用类似DAO的东西。当您添加新功能时，您将创建新的DAO，但基本架构和设计不会改变。
然而，似乎您没有提供客户想要的内容。在这种情况下，向客户交付可工作的产品非常重要，以便他可以为下一次迭代提供明智的反馈。
关于"我们（开发人员）无法在规定的时间内完成"：
客户不应该指定迭代时间框架。迭代长度应始终相同。进入迭代的要求应作为客户优先级结果获得，但计划用于迭代的要求量应基于团队执行的评估和您能够在迭代期间交付的“点”数。
2
“Scrum 在某种程度上是一个“短瀑布模型”，这句话基本上概括了我的观点。” 我一直在想为什么会有关于这个问题的圣战，因为这句话已经很清楚地表达了我的看法。 - GreenMatt
@Green 因为这是错误的。QA 应该从迭代开始，并且应该是一个持续进行的活动，而不仅仅是在迭代结束时完成的事情。请参见 Iterative Development Gone Wrong - The Mini-Waterfall Anti-Pattern 和其他许多关于此主题的帖子。 - Pascal Thivent
@Pascal Thivent：如果你做事情做得好，那么你在任何工程/开发过程中，包括瀑布式软件开发方法中，都要从一开始就进行QA。 - GreenMatt
1
@Matt 哦？这对我来说是新的。据我所知，瀑布模型是一个顺序过程，验证阶段是在实现之后完成的。至少，在温斯顿·罗伊斯在原始论文中描述的方式是这样的。因此，根据定义，我认为你所描述的不能被称为瀑布模型。我并不是说你不能这样做，只是说这不能被称为瀑布模型（而且当人们使用瀑布模型这个术语时，肯定不是指这个）。因此出现了迷你瀑布反模式。 - Pascal Thivent
1
@Pascal：首先，我不是在为瀑布式开发方法辩护。我的初始评论是试图表达有许多“喊叫”是不必要的。据我所知，瀑布方法没有硬性和明确的定义（罗伊斯博士的论文没有使用这个术语），我曾看到过一些文章，在这些文章中人们谈论从似乎是瀑布式方法的开始就进行QA。然而，<哎>我们似乎正在走向我所抱怨的无果的来回讨论，所以我会在这里停止。 - GreenMatt
3
对我来说，敏捷项目中似乎没有“大计划[TM]”。使用敏捷过程并不意味着没有长期计划，而是更多地处理远期不确定性。例如，应该有一个发布计划，其中包含未来2个月内所有发布的计划功能（以及功能较少的计划，用于之后的发布），这样客户就清楚地知道何时可以期望某项功能，并且在可能更改需求时也很清楚。
此外，对我来说似乎没有足够的客户参与到流程中。我知道这是一个非常棘手的问题，但如果每次迭代结束时都可以与客户讨论当前进展情况，这会帮助很多。正如@Mark Byers所写，从客户那里获得的反馈越多，你就越好。
此外，请尽量不要归咎于任何人，因为这会阻碍人们。尝试使用检查和采用方法来获得更好的流程。
3
“您所提到的设计变更类型不太清楚，是指图形设计？用户体验设计？还是代码设计呢？”
“不管怎样，最好的解决方案是与客户进行更多、更早的讨论。共同开发明确、具体的示例来满足客户的要求。您可以将这些示例转化为回归测试，以确保您继续满足要求。”
“另外，在进展过程中继续讨论。展示可用的输出，不要等到接近冲刺结束才展示。并且首先处理最有可能引起问题的部分。此外，探索使经常变动的部分更易修改的方法。”
“关键是让客户更加参与，甚至在设计迭代中也是如此。也许你需要一些专注于设计的讨论。”
3
您的客户并不知道如何开发软件，或者如何管理软件开发流程。不要期望客户在这些问题上提供有意义的指导。作为一个特例，客户并不真正知道“瀑布”和“敏捷”等术语的含义；不要期望他们对您的开发方法提供有意义的输入。此外，只要在约定的预算和时间范围内满足要求，客户就不会真正关心这些细节。不要期望他们关心，并且不要用大量无关的信息和不充分的版本来混淆他们对内部流程的认识。
以下是客户真正关心的内容，并且正在与您讨论（部分使用您自己的技术术语）：他们的需求、他们对预期的失望以及您与他们沟通的方式。在这些问题上，客户是绝对权威的。将他们所说的理解为关于您的关系和产品，而不是可用的内部流程评论。不要用您的内部截止日期和流程来混淆视听，而是讨论进展、期望和关系。（如果他们坚持谈论内部事务，您可以重新映射术语：例如，他们理解的“下一个发布”可能在内部被称为“下一个主要发布”，或其他）。
在我看来，客户可能希望在被要求反馈或玩坏的版本之前有更高的门槛。值得验证是否属实。如果是这样，您应该尊重客户的需求-并且如果您的团队认为这是最好的，仍然在内部使用敏捷方法。如果他们说“瀑布”，您可以将其解释为“我们设定了需求的最后期限，然后一段时间内不允许添加更多功能。”与客户讨论是否适合他们在需求截止日期后进行此类冻结。
您的团队中需要有一个代表客户的人，并关注客户的问题并为他们奋斗。这位代言人不能被边缘化，也不能对抗客户；他们应该是代理老板。然后您可以将内部流程沟通（团队到代言人）与外部沟通（代言人到客户）分开。代言人可以在某种程度上隔离客户不喜欢的闲聊和构建，而不会在您的内部流程上人为地施加某种管理或安排。
澄清一下，我绝不认为您应该对客户保密或保持距离，但是您应该（A）听取客户对关系和沟通方式所说的话，并尊重这一点；（B）将其与内部开发过程分开，该过程应以最终满足客户期望的方式管理。
谢谢您勇敢的反馈。我们也感到缺乏这种“倡导者”，事实上，昨天在会议上我们讨论了这个问题。再次感谢您的建议。 - bragboy
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接