我正在敏捷环境中工作，事情已经发展到客户认为他们更喜欢瀑布的状态，因为当前敏捷方案的失败（这就是他们的想法）。让他们这样思考的原因是在冲刺的最后阶段发生的大量设计水平变化，我们（开发人员）无法在他们指定的时间内完成。
像往常一样，我们俩互相指责。从我们的角度来看，最后说的变化太多了，设计/代码的改动太多了。从客户的角度来看，他们抱怨说我们（开发人员）并没有完全理解这些要求，而是提出了“不”他们在要求中的意图的解决方案。 （就像他们要我们画一只老虎一样，我们画了一只猫）。因此，客户感觉（不是我们）敏捷过程不正确，他们想要切换到瀑布模式，恕我直言将是灾难性的。简单的原因是它们在敏捷模式下的满意程度本身还不够，那么在瀑布开发的设计阶段花费这么多时间之后它们如何能够容忍输出呢？
请提出您的建议。
答案 0 :(得分：52)
首先 - 问问自己，你真的做敏捷吗？如果您那时应该已经向客户交付了大部分可用功能，满足了他们在早期冲刺中的要求。从理论上讲，“损坏”应该限制在您发现需要进行大型设计更改的最终冲刺中。在这种情况下，您应该已经证明了您的交付能力，现在需要与客户进行对话，以规划现在所需的变更。
然而，鉴于您的描述，我怀疑您已经陷入了仅仅在两周周期内开发而没有实际投入生产的陷阱，并且在第一次正确发布时有一个固定的结束日期。如果是这种情况，那么你真的在没有需求分析/设计的情况下进行迭代瀑布 - 这通常是一个不好的地方。
完全瀑布不一定是答案（有足够的证据来证明问题是什么），但是在实践中，一些前期规划和设计通常比新兴建筑的“纯粹”敏捷精神更为可取（其中实际上符合精益方法）。如果大型项目只是开始破解代码并且希望它们能够在一定数量的冲刺中发挥作用，那么它们就无法实现一个明智的稳定架构基础。
除了上述“纯粹”敏捷的另一个常见问题是客户期望管理。敏捷作为这个奇妙的东西出售，这意味着客户可以推迟决策，改变主意，并在他们认为合适时添加新的要求。然而，这并不意味着所需的结束日期/预算/努力仍然是固定的，但人们似乎总是错过这一部分。
答案 1 :(得分：28)
当您的需求不明确以及您可能需要在项目的后期阶段进行设计更改时，敏捷开发方法尤其适用。在这种情况下，瀑布是一种不太合适的方法。瀑布方法适用于很好理解的项目，以及在项目生命周期内不太可能改变需求的项目。这听起来并不像这样。
你的短跑多久了？另一种方法可能是减少冲刺长度 - 至少在项目开始时。更频繁地向客户提供新版本，并与客户讨论变更。如果您没有按照自己的意愿行事，这将更加明显，因此在实施不符合客户要求的解决方案时浪费的时间更少。
答案 2 :(得分：26)
我不确定你经营的是什么样的商店，所以我很难提出好的建议。我可以提供两个指导原则：
答案 3 :(得分：9)
听起来您有严重的项目管理和架构/设计问题，听起来您的通信也已崩溃。从根本上说，我认为改变你的开发方法不会解决任何问题，因此做错了（虽然它可能会恢复一些客户的信心）。
我会特别关注将移向瀑布，因为您现在选择基本上只捕获一次要求（我们知道您有问题）而没有输入容量。这种刚性对于不灵活的交付目标是有利的，但是在这里你总是有变化是完全不合适的 - 这是敏捷的！
短期内我会退后一步，在这个阶段仔细检查你的要求。重新协商并确认您当前的状态。
中期，我会与客户进行更多沟通 - 尝试让他们参与日常的scrum一段时间（直到你恢复信心，然后你就会更灵活）。
从长远来看，你必须担心你的PM和高级开发者如何设法让你进入这个位置。如果客户是无法解决的，那就是一件事（但是仍然由PM来管理，所以你不能解除）。抱怨有太多变化是不合理的，这只是意味着你搞砸了确定要求（这是一个对话，而不是一个独白），或者你必须有更多，但可能更短的冲刺。
最重要的是，我看不出走向瀑布可能是正确的。它没有直接解决任何问题，我只能看到它加剧了你已经突出显示的问题。
警告：我真的不能对瀑布有一个平衡的看法，因为我从来没有看到它有效地工作，而且它刚刚完全过时的企业项目。
答案 4 :(得分：8)
敏捷或瀑布只是单词。只有有用的东西，有些东西没有。 对许多人来说，软件开发似乎是虚拟的，他们不明白为什么很难改变他们要求的小东西。
您的客户应该明白，构建软件就像建房子一样：当您建造了所有的基础和墙壁时，很难改变所有的房屋最终计划和房间设计。
一些实践有助于避免此类问题：数据建模，数据字典，数据流图......目标是详细了解每个需求。在许多独立的块中切割产品有助于在继续设计或指定最终产品的其他部分时开始编码。
请参阅Steve McConnell的书：“快速软件开发：为所有有效的实践驯服野生软件时间表”。
答案 5 :(得分：7)
敏捷开发并不能免除您实际设计的负担，而您和客户都可以相似地理解这一设计。敏捷只是可以以较小的增量提出设计，而不是一次性完成。而且，对于困难的客户，提出合适的设计需要时间。
所以，我会花更多的精力与客户坐在一起，用白板，重温他们真正想要的东西。在这种情况下，如果开发过程是敏捷或瀑布，我认为这不重要。
答案 6 :(得分：4)
让他们这样思考的原因是在短跑的最后阶段发生的大量设计水平变化，我们（开发人员）无法在他们指定的时间内完成。
Scrum在某种程度上是一种“短瀑布”，你应该与冲刺持续时间的变化要求隔离开来。看来这不会发生！因此，不要看到你将从切换到传统瀑布中获得任何收益，但你应该坚持对冲刺持续时间的冻结要求。 也许你的迭代太长了？ （我假设你遵循Scrum，因为你提到冲刺）。
与您的客户交谈并同意以下内容：
- 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，但基本的架构和设计不会改变。
然而，似乎您没有提供客户想要的东西。在这种情况下，向客户提供工作产品至关重要，因此他可以为下一次迭代提供合理的反馈。
关于
“我们（开发人员）无法完成 在他们指定的时间内。“
客户端不应该是指定迭代时间范围的客户端。迭代长度应始终相同。进入迭代的要求应该作为客户端优先级的结果获得，但是为迭代计划的需求量应该基于团队执行的估计以及您在迭代期间能够提供的“点数”的数量
答案 7 :(得分：3)
对我而言，听起来好像敏捷项目中没有“Big Plan [TM]”。使用敏捷过程并不意味着没有长期计划，而是更多地要处理未来日益增长的不确定性。例如，应该有一个发布计划，其中包含未来2个月内所有版本的计划功能（以及之后发布的功能的详细计划），因此客户可以清楚地了解功能的何时，以及何时需要有可能改变要求。
同样对我而言，似乎没有（足够的）客户参与这个过程。我知道这是一个非常有问题的问题，但如果可以在每次迭代结束时与客户讨论当前的进展，那么它会有很大帮助。正如@Mark Byers已经写过的那样，您从客户那里获得的反馈越多越好。
也试着不指责，因为这会阻止人们阻止。尝试使用检查和采用方法来获得更好的过程。
答案 8 :(得分：3)
目前尚不清楚你的意思是什么样的设计变化。图形设计？用户体验设计？代码设计？
无论如何，最好的解决方案是与客户进行更多，更早的讨论。共同开发满足客户要求的明确，具体的例子。您可以将这些示例转换为回归测试，以确保您继续满足它们。
此外，随着进展继续讨论。在可用时显示您的输出 - 不要等到冲刺结束时。并且最有可能首先产生问题的部分工作。还要看看如何更容易地改变你经常发现的变化。
重点是让客户端更多，甚至是设计的迭代。也许你会希望在设计上只讨论 。
答案 9 :(得分：3)
解雇客户端。即使你不理解他们的意思是你的错，瀑布也会给他们一次机会在每次冲刺结束时给你反馈而不是机会。有些人/客户实际上是如此愚蠢，以至于他们不值得为之努力。解雇他们，或告诉他们你正在使用瀑布而不实际切换。
答案 10 :(得分：3)
您的客户不知道如何开发软件，或者如何管理软件开发过程。不要指望客户就这些问题提供有意义的指导。作为一个特例，客户并不真正知道“瀑布”和“敏捷”之类的术语;不要指望他们为您的开发方法提供有意义的输入。此外，只要在商定的预算和时间范围内满足要求，客户就不会真正关心这些细节。不要指望他们关心，也不要将他们与大量不充分的构建和内部流程的无关信息混淆。
以下是客户关心的事情，并试图与您讨论（部分使用您自己的技术术语）：他们的要求，失望的期望以及与他们沟通的方式。在这些问题上，客户是绝对的权威。解释他们所说的与您的关系和产品有关的内容，而不是对内部流程的可用评论。不要用你的内部期限和流程来淹没水，讨论进展和期望以及这种关系。 （如果他们坚持谈论内部，你可以重新映射这些术语：例如他们所理解的'下一个版本'可能在内部被称为'下一个主要版本'，或者其他什么。）
在我看来，客户可能需要更高的门槛才能获得反馈或使用糟糕的版本。值得验证这是否属实。如果是这样，您应该尊重这一点 - 并且如果您的团队认为最好的话，仍然会在内部使用敏捷方法。如果他们说“瀑布”，你可以在内部解释为“我们为需求设定了截止日期，然后我们暂时不允许添加更多功能”。与客户讨论是否适合他们在此类冻结之后的要求截止日期。
您团队中的某个人需要成为客户支持者，并且在客户的问题上处于最佳状态并为他们而战。这个倡导者不能被排除在外，也不能让团队一方反对客户;他们应该是代理老板。然后，您可以将内部流程通信（团队与倡导者）从外部通信（倡导者到客户端）分开。在某种程度上，倡导者可以将客户与他们不欣赏的聊天和构建隔离开来，而不会人为地对您的内部流程施加某种管理或安排。
为了澄清，我根本不认为你应该对客户保密或疏远，但是你应该（A）听取客户对这种关系的看法，以及你如何沟通和尊重这种关系，（B）保持与内部开发过程分开，内部开发过程应以最终满足客户期望的任何方式进行管理。
答案 11 :(得分：2)
这里明显的问题是与客户的沟通。如果您真的想做敏捷，您必须在日常基础知识上与客户沟通。只有客户才能做出决定。如果您仅在春季中期和冲刺结束时与客户沟通，那么您以后会发现应用程序出现问题是很自然的。此外，sprint中实现的功能必须由客户接受和测试。直到功能没有完成。
我写这篇文章是因为我目前的项目有类似的问题，但我知道失败的地方。
答案 12 :(得分：1)
如果团队和客户之间的沟通问题没有得到解决，那么如果客户只在完成后看到产品（隧道效应），那么瀑布的情况可能会更糟。
您评论了冲刺6-7的变化开始导致在早期冲刺中实现的任务的返工。应该早些时候检测到这些变化 - 在Sprint评审期间。
如果功能描述中存在误解，并且团队未实现客户期望的内容，则应在不迟于实施功能的Sprint中检测到这一点，并且理想情况下应在当前Sprint中进行修复。
如果客户改变了主意，那么新的想法应该被添加到产品Backlog中，为Sprint确定优先级和选择，与任何其他积压项目一样。这不应被视为返工。
您是在每次冲刺后将软件交付给客户，还是只是在演示它？
错误传达的根源可能出现在Sprint计划中：团队应该只承诺明确定义的积压项目。项目的定义应包括验收标准。客户是产品负责人，是产品负责人吗？
答案 13 :(得分：1)
开发过程的远程调试非常困难，我会毫不犹豫地就应该做什么提出任何意见。在我看来，你团队之外的任何人都没有足够的信息可以对此作出非常有用的判断。
最后得出的结论是猜测出了什么问题。根据您的描述，这听起来像早期的可交付成果，您认为这是在银行取得的进展，最终被重新修改。
其中一个常见原因是“所有”要求的后期发现/创建，对于项目范围内的所有内容应该是真实的。如果认真考虑，这些可能会非常致命：例如，“所有对话框必须可调整大小”这样简单的事情，显然超出了微软改装Windows的能力。
可以找到关于此类失败的经典帐户（尽管在非敏捷项目中）here
“一旦他们看到我们编写的代码的产品，他们就会说，'哦，我们必须改变它。这不是我的意思，'”SAIC的雷诺兹说。 “那是我们在变更请求之后的变更请求之后开始记录变更请求的时候。”
例如，根据SAIC工程师的说法，在八个团队完成了大约25％的VCF之后，FBI希望在所有屏幕上添加“页面碎屑”功能。这个导航设备也被称为“面包屑”，这个名称受Hansel和Gretel童话故事的启发，为用户提供了一个URL列表，用于标识通过VCF到达当前屏幕的路径。 SAIC工程师说，这种新功能不仅增加了更多的复杂性，而且延迟了开发，因为完成的线程必须使用新功能进行改造。
关键词是“所有屏幕”。面对这种性质的变化，那么，除非你有一些预先存在的工具支持，你可以打开（改变所有背景颜色真的应该是微不足道的），你有麻烦。你认为你已达到这一点的进展将追溯到虚幻。
解决此类问题的唯一方法是首次正确使用它们。如果失败了，就把他们弄错了。
答案 14 :(得分：1)
许多商店都添加了敏捷装饰，让自己“期待敏捷”给那些期待它的客户。也许你只需要添加一些瀑布装饰，并且每2次冲刺就会向他们展示一次。
答案 15 :(得分：0)