放弃敏捷，切换到瀑布 – 这是正确的吗？
我在一个敏捷的环境中工作，事情已经到了客户觉得他们更喜欢瀑布的状态，因为当前敏捷scheme的失败（这是他们认为的）。 造成他们这样想的原因是我们（开发人员）在他们指定的时间内无法完成的冲刺结束阶段发生的巨大devise水平变化。
像往常一样，我们都在互相指责。 从我们的angular度来看，最后的变化太多了，devise/代码的变化太多了。 而从客户的angular度来看，他们抱怨说我们（开发人员）并不完全理解这些要求，并提出了与他们的要求无关的解决scheme。 （就像他们要我们画一只老虎一样，我们画了一只猫）。
所以，客户觉得（而不是我们）敏捷过程是不正确的，他们想切换到一个瀑布模式，恕我直言，这将是灾难性的。 简单的原因就是他们的敏捷模式本身的满意度还不够，那么在瀑布式开发的devise阶段花费那么多时间之后，他们怎样才能容忍产出呢？
请给出你的build议。
首先 – 问问自己，你是否真的在做敏捷？ 如果你是那么你应该已经交付了大量的可用的function，客户满足了他们在早期冲刺的要求。 从理论上讲，“伤害”应该限制在最后的冲刺阶段，在那里你发现你需要大的devise改变。 如果是这种情况，您应该已经certificate了您的交付能力，现在需要与客户进行对话以规划现在所需的更改。
然而，考虑到你的描述，我怀疑你已经陷入了两周周期而没有真正投入生产的陷阱，并有一个固定的结束date记在第一次正确的发布。 如果是这样的话，那么你实际上是在没有需求分析/devise的前提下进行迭代式瀑布 – 通常是一个糟糕的地方。
完整的瀑布并不一定是答案（有足够的证据显示出问题所在），但是在实践中，一些前期的规划和devise在实践中远远优于新兴的架构的“纯粹的”敏捷思维（这适合于精益的方法实际上）。 大项目根本不可能希望如果他们刚刚开始篡改代码，希望能够实现一个明智的稳定的架构基础，并希望一些冲刺下来。
除了上述“纯粹”敏捷的另一个常见问题是客户期望pipe理。 敏捷以这种美妙的东西出售，这意味着客户可以推迟决策，改变主意，并增加他们认为合适的新要求。 然而，这并不意味着所需的结束date/预算/努力仍然是固定的，但人们似乎总是忽略这一部分。
敏捷开发方法尤其适用于需求不明确以及在项目的后期阶段需要进行devise更改的情况。 在这种情况下瀑布是一个不太合适的方法。 瀑布式方法适用于已经很好理解的项目，以及在项目生命周期中不可能改变需求的情况。 这听起来不是这样的。
你的冲刺多久了？ 另一种方法可能是减less冲刺长度 – 至less在项目开始的时候。 更频繁地向客户提供新版本，并与客户讨论变更。 如果你没有做到自己想做的事情，这个问题就会变得越来越明显，所以在实施不符合客户要求的解决scheme时浪费的时间就会减less。
我不确定你的店铺是什么样的，所以我很难提出好的build议。 我可以提供两个指导原则：
- 如果你和客户沟通不好，没有任何开发方法可以帮你节省。
- 只要餐点美味，厨师如何组织厨房就不是餐馆的事。
这听起来像是你有严重的项目pipe理和架构/devise问题，听起来你的通讯也已经崩溃了。 从根本上说，我不认为改变你的开发方法将会解决任何问题，因此是错误的（尽pipe它可能会恢复一些客户的信心）。
因为你现在select的只是一次（我们知道你有问题的），而没有input的能力，所以我会特别关注向瀑布方向发展 。 这种刚性对于不灵活的交付目标是有好处的，但是在这里你总是有变化，这是完全不合适的 – 这是敏捷的！
-
短期我会退后一步，在这个阶段与他们仔细检查你的要求。 重新谈判并确认你目前的状况。
-
中期来说，我会和客户进行更多的沟通 – 尝试让他们参与到每日的Scrum中（直到你恢复信心，那么你可以变得更加灵活）。
-
长远来说，你必须担心你的首相和高级开发人员如何设法让你进入这个位置。 如果客户不能做到这一点是不可能的（但是pipe理层仍然要做到这一点，所以不能免除）。 抱怨做太多改变是不合理的，只是意味着你在确定需求（这是一个对话，而不是一个独白）或者你必须有更多的，但可能更短的冲刺。
最重要的是，我看不到朝瀑布移动可能是正确的。 它不直接修复任何东西，我只能看到它加剧了你已经强调的问题。
警告：因为我从来没有看到它有效的工作，所以我并不是真正能够对瀑布进行平衡的观点，对于企业项目来说，这完全是过时的。
敏捷或瀑布就是文字。 只有东西是有效的，而不是东西。 软件开发对许多人来说似乎是虚拟的，他们不明白为什么很难改变他们所要求的一件小事。
你的客户应该明白，build立一个软件就像build造房子一样：当你build立了所有的基础和墙壁，很难改变所有的房子最终的计划和房间的devise。
一些做法有助于避免这种问题：数据build模，数据字典，数据stream图…目标是要详细了解每个需求。 在许多独立块中切割您的产品有助于开始编码，同时继续devise或指定最终产品的其他部分。
请参阅Steve McConnell的书籍：“快速软件开发：驯服通用软件时间表”，了解所有可行的实践。
敏捷开发并不能让您免于实际上想出一个您和客户相似理解的devise。 敏捷使得以较小的增量来devisedevise成为可能，而不是一次就完成。 而在困难的客户情况下，devise一个合适的devise需要时间。
所以，我会花更多的精力与客户坐在一起，用白板，来回顾一下他们真正想要的东西。 如果开发过程是敏捷或者瀑布，我认为在这种情况下它并不重要。
造成他们这样想的原因是我们（开发人员）在他们指定的时间内无法完成的冲刺结束阶段发生的巨大devise水平变化。
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 你应该问自己的另一件事是为什么你的应用程序中有这么多的“devise级别的变化”。 现在，你应该有基本的架构和devise。 也许你应该审查实际的devise，并尝试强加一些devise指导方针和实施一些模式。 例如，在一个典型的企业级networking应用程序中，您最终可能会使用类似DAO的东西。 当您添加新function时，您将创build新的DAO，但基本体系结构和devise不会更改。
但是，似乎你没有提供客户想要的东西。 在这种情况下，将工作产品交付给客户是最重要的，所以他可以为下一次迭代提供合理的反馈。
关于
“我们（开发商）在指定的时间内无法完成。”
客户端不应该是指定迭代时间范围的客户端。 迭代长度应该始终相同。 进入迭代的需求应该作为客户优先级的结果来获得，但是计划迭代的需求量应该基于团队执行的估计和迭代期间你能够提供的“点数” 。
对我来说，这听起来好像在敏捷项目中没有“大计划（TM）”。 使用敏捷的过程并不意味着没有长远的计划，更多的是要处理更加不确定的未来。 例如，应该有一个发布计划，在未来2个月内发布所有版本的计划function（以及稍后的发布function较less的详细计划），因此客户可以清楚何时预期某个function，以及何时有可能改变要求。
对我来说，似乎没有（足够的）客户参与这个过程。 我知道这是一个非常棘手的问题，但是如果能够在每次迭代结束时与客户讨论当前的进展情况，这将有很大的帮助。 正如@马克·拜尔斯（Mark Byers）已经写到的，从客户那里得到的反馈越多，你就越好。
也尽量不要责怪，因为这会阻止人们。 尝试使用检查和采用方法来获得更好的stream程。
目前还不清楚你的devise有哪些变化。 graphicsdevise？ 用户体验devise？ 代码devise？
无论如何，最好的解决scheme是更多，更早的时候与客户进行讨论。 共同开发满足客户要求的明确，具体的例子。 你可以把这些例子变成回归testing，以确保你继续满足它们。
此外，继续进行讨论。 显示你的输出 – 不要等到接近冲刺结束。 并且首先处理最可能产生问题的部分。 另外看看如何更容易地改变你发现的东西经常改变。
关键是让客户更多地参与，甚至是devise的迭代。 也许你只想谈一些关于devise的讨论。
发射客户。 即使你不明白他们的意思是你的错，瀑布会给他们一个机会给你的反馈，而不是在每个冲刺结束的机会。 有些人/客户实际上很愚蠢，他们不值得为之工作。 解雇他们，或者告诉他们你正在使用瀑布而不切换。
您的客户不知道如何开发软件，或者如何pipe理软件开发过程。 不要指望客户在这些事情上提供有意义的指导。 作为一个特例，客户并不知道“瀑布”和“敏捷”这些术语的含义， 不要期望他们为您的开发方法提供有意义的input。 而且，客户不会真正关心这些细节，只要在商定的预算和时间范围内满足要求即可。 不要指望他们在意，也不要把他们与你内部stream程中的许多不适当的构build和不相关的信息混为一谈。
这里是客户关心的事情，并试图和你谈谈（部分使用你自己的技术术语）：他们的要求，他们失望的期望，以及你与他们沟通的方式。 在这些问题上，客户是绝对权威。 解释他们所说的关于你的关系和产品，而不是对内部过程的可用评论。 不要在你的内部最后期限和stream程中使用水，讨论进展，期望和关系。 （如果他们坚持谈论内部的话，你可以重新映射这些术语：比如，他们所理解的“下一个版本”可能被内部称为“下一个主要版本”或其他）。
这听起来像客户可能需要一个更高的门槛，然后他们被要求反馈或玩坏构build。 这是值得validation的，如果这是真的。 如果是这样，你应该尊重这一点 – 如果这是你的团队认为是最好的，仍然在内部使用敏捷方法。 如果他们说“瀑布”，那么你可能会把它解释为“我们为需求设定一个最后期限，然后我们不允许增加一些function”。 与客户讨论是否适合他们有一个要求的最后期限，这种冻结。
你的团队中有人需要成为客户的支持者，并且坐在客户的问题之上为他们而战。 这个倡导者不应该被排除在外，他们也不能站在客户的立场上， 他们应该是代理老板。 然后你可以从外部沟通（倡导者到客户）分离内部过程沟通（团队到主张）。 倡导者在某种程度上可以隔离客户不受他们不理解的喋喋不休的构build，而不会对您的内部stream程进行某种forms的pipe理或调度。
为了澄清，我根本不认为你应该与客户保密或者疏远，但是你应该（A）听取客户对于这种关系的意见，以及你如何沟通和兑现，（B）保持与内部开发stream程分开，应该以任何方式进行pipe理，最终达到客户的期望。
这里的明显问题是与客户沟通。 如果你真的想做敏捷的话，你必须在日常的基础上和客户沟通。 只有客户应该能够做出决定。 如果你只在春季中期和冲刺结束时与客户进行交stream，那么稍后自然会在你的应用中发现问题。 在sprint中实现的function也必须由客户接受和testing。 直到那个function没有完成。
我正在写这个，因为我目前的项目有类似的问题，但我知道我们失败的地方。
如果团队和客户之间的沟通问题不是固定的，那么如果客户只有在产品完成后才看到产品（隧道效应），那么情况会更糟糕。
您评论了冲刺6-7的变化开始导致在之前的冲刺中完成的任务的返工。 在Sprint评论期间，应该早些检测到这些变化。
如果在特性描述中存在误解，并且团队没有实现客户期望的内容，则应该在Sprint中检测到该特性，并且在当前的Sprint中理想地固定。
如果顾客改变了主意，那么新想法将被添加到产品待办事项列表中，作为Sprint的优先次序和select，作为任何其他积压项目。 这不应该被认为是返工。
在每次冲刺之后，您是否将软件交付给客户？还是只是在演示？
沟通不畅的根源可能在于Sprint计划：团队只应对Backlog项目做出明确定义。 项目的定义应包括验收标准。 客户是产品负责人，是产品负责人吗？
开发过程的远程debugging是非常困难的，所以我会毫不犹豫地提供你应该做什么的意见。 在我看来，在你的团队之外，没有人能够合理地获得足够的信息来做出有用的判断。
稍微跳到一个结论就是猜测哪里出了问题。 从你的描述来看，这听起来像早期的交付成果，你认为这是银行的进步，最终被重新修改。
造成这种情况的一个常见原因是“所有”要求的晚期发现/创造，对于项目范围内的所有事情都应该是真实的。 如果认真对待这些可能是非常致命的：像“所有对话框必须可resize”这样简单的东西，显然超出了微软改造Windows的能力。
在这里可以find这种失败（尽pipe在一个非敏捷项目）的经典账户
上汽的雷诺兹说：“一旦他们看到我们编写的代码的产品，他们会说：'哦，我们必须改变这一点，这不是我的意思。 “这就是我们在变更请求发生变更请求之后开始logging变更请求的时候。”
例如，据上汽工程师介绍，在八支队伍完成VCF的25％之后，联邦调查局希望在所有屏幕上增加“页面碎片”function。 该导航装置也被称为“面包屑”，其名称受到Hansel和Gretel童话的启发，为用户提供了一个URL列表，用于识别通过VCF进入当前屏幕的path。 上汽工程师表示，这种新function不仅增加了复杂性，而且延迟了开发，因为完成的线程必须加装新function。
关键词是“所有屏幕”。 面对这种性质的变化，那么，除非你有一些预先存在的工具支持，否则你可以开启（改变所有的背景颜色真的应该是微不足道的），你有麻烦了。 你认为你所取得的进步将会追溯到事实上是虚幻的。
解决这些问题的唯一已知方法是让他们第一次正确。 如果失败了，就要让他们错了。
许多商店增加敏捷装饰，使自己“看起来敏捷”的客户谁期望它。 也许你只需要添加一些瀑布饰物，并每2次冲刺一次向他们展示产品。
我相信你的客户是错误的移动到瀑布。 它正在治愈症状，而不是疾病。 你描述的问题是沟通 – 客户想要一只老虎，你给他们一只猫。
瀑布模型包括许多步骤来validation所写的要求正在交付 – 但是不能确保书面要求是业务意味着的。
我会研究影响映射 ，行为驱动开发（ BDD ）和故事映射等技术来改善沟通。
