放弃敏捷,转向瀑布式——这是对的吗?[关闭]

首先-问问你自己是不是 真的? 做敏捷?如果是这样,那么您应该已经向客户机交付了大量可用功能,这些功能满足了客户机在早期冲刺中的需求。理论上,“破坏”应该局限于最后的冲刺,在那里你发现你需要大的设计变更。在这种情况下,您应该已经证明自己的交付能力,现在需要与客户进行对话,以计划现在所需的更改。

不过,根据您的描述,我怀疑您陷入了一个陷阱,即只开发一个两周的周期,而不实际每次都交付到生产中,并且为第一个正确的发布有一个固定的结束日期。如果是这样的话,那么您实际上是在进行迭代瀑布式开发,而没有预先进行需求分析/设计——这通常是一个糟糕的地方。

完整的瀑布不一定是答案(有足够的证据表明问题所在),但是在实践中,一些预先的计划和设计通常比紧急架构的“纯”敏捷方法(实际上适合于精益方法)要好得多。大型项目根本不能期望实现一个合理的稳定的建筑基础,如果他们只是开始黑客攻击代码,并希望这一切都会好一些冲刺下来。

除上述之外,“纯”敏捷的另一个常见问题是客户期望管理。敏捷被认为是一件美妙的事情,这意味着客户可以推迟决策,改变主意,并在他们认为合适的时候添加新的需求。然而,这并不意味着所需的结束日期/预算/努力保持不变,但人们似乎总是忽略了这一部分。

当您有不明确的需求,并且在项目的后期可能需要进行设计更改时,敏捷开发方法论尤其合适。在这种情况下,瀑布是一种不太合适的方法。瀑布式方法适用于理解良好的项目,并且在项目生命周期中需求不太可能改变。这听起来不像这里的情况。

你的冲刺时间有多长?另一种方法可能是减少冲刺长度——至少在项目开始时是这样。更频繁地向客户交付新版本,并与客户讨论更改。如果你不按他们的要求去做,这将很快变得明显,从而减少在实现不符合客户要求的解决方案上浪费的时间。

我不知道你经营哪种商店,所以我很难提出好的建议。不过,我可以提供两个指导原则:

1. 如果您与客户的沟通不好,任何开发方法都不会帮您节省。
2. 只要饭菜可口,厨师如何组织厨房与用餐者无关。

听起来你有 严重的 项目管理和架构/设计问题,听起来您的通信也出现了故障。从根本上讲,我不认为更改您的开发方法论可以解决任何问题,因此这是错误的做法(尽管它可能会恢复一些客户的信心)。

我特别担心搬家 朝着 瀑布式,因为您现在选择基本上只捕获一次需求(我们知道您有问题),没有输入能力。这种僵化对于不灵活的交付目标很好,但是在这里你总是有变化是完全不合适的——那是敏捷的!

• 短期内,我会退后一步,在这个阶段与他们再次检查您的需求。重新协商并确认与这些相关的当前状态。

• 中期来看,我会与客户开放更多的沟通——试着让他们参与一段时间的日常工作(直到你恢复信心,那么你就可以变得更灵活)。

• 从长远来看,你必须担心你的首相和高级开发人员是如何让你进入这个职位的。如果客户是无法挽回的,这是一回事(但这仍然取决于首相来管理,所以你没有得到赦免)。抱怨有太多的变化是不合理的,这意味着你在确定需求上搞砸了(这是一个对话,而不是独白),或者你必须有更多的,但可能是更短的冲刺。

最重要的是,我看不到朝瀑布移动可能是正确的。它不能直接解决任何问题,我只能看到它加剧了您已经强调的问题。

警告:我真的不能在瀑布上看到平衡的视图,因为我从来没有看到它有效地工作过,而且imho它对于企业项目来说已经完全过时了。

敏捷或瀑布只是语言。只有有用的东西,没有用的东西。 对于许多人来说,软件开发似乎是虚拟的,他们不明白为什么很难改变他们要求的一件小事。

你的客户应该明白构建软件就像建造一座房子:当你建造了所有的基础和墙壁,很难改变所有的房子最终计划和房间设计。

一些实践有助于避免这类问题:数据建模、数据字典、数据流图…目标是完全详细地了解每个需求。在许多独立块中切割产品有助于在继续设计或指定最终产品的其他部分时开始编码。

请参阅SteveMcConnell的书:“快速软件开发:驯服野生软件时间表”,了解所有有效的实践。

敏捷开发并不能让你从实际提出一个设计的负担中解脱出来,这个设计是你和客户都很相似地理解的。敏捷只是使以较小的增量来设计成为可能,而不是一次完成。而且,在一个困难的客户的情况下,想出一个适当的设计需要时间。

所以,我会花更多的精力和客户坐在一起,用一个白板,检查他们真正想要的是什么。我认为在这种情况下,如果开发过程是敏捷的或瀑布式的,那么它并不真正重要。

让他们这样认为的原因是,在冲刺的最后阶段,我们(开发人员)无法在他们指定的时间内完成大量的设计级更改。

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,但基本架构和设计不会改变。

然而,似乎你没有实现客户想要的。在这种情况下,最重要的是将工作产品交付给客户机,这样客户机就可以为下一个迭代提供合理的反馈。

关于

“我们(开发人员)无法完成 在他们指定的时间内。”

客户机不应该是指定迭代时间范围的客户机。迭代长度应始终相同。进入迭代的需求应该作为客户机优先顺序的结果获得,但是为迭代计划的需求量应该基于团队执行的估计以及迭代期间您能够交付的“点”的数量。

对我来说,听起来好像敏捷项目中没有“大计划”。使用敏捷的过程并不意味着没有长期的计划,它更多的是要处理未来不断增加的不确定性。例如,在接下来的2个月内,应该有一个包含所有发布的计划功能的发布计划(以及一个包含之后发布的功能的更详细的计划),这样客户就可以清楚地知道何时需要某个功能,以及何时有可能更改需求。

在我看来,在这个过程中,客户的参与似乎还不够。我知道这是一个非常有问题的点,但是如果在每次迭代结束时可以与客户讨论当前的进度,那么这会有很大帮助。正如@mark byers已经写的那样,你从客户那里得到的反馈越多,你就越好。

也尽量不要责怪别人,因为这样会让人闭嘴。尝试使用检查和采用方法来获得更好的过程。

不清楚你的意思是什么样的设计改变。图形设计?用户体验设计?代码设计?

在任何情况下,最好的解决方案都是尽早与客户进行讨论。共同开发满足客户要求的明确、具体的示例。您可以将这些示例转换为回归测试,以确保您继续满足它们。

此外,继续进行讨论。在输出可用时显示它——不要等到冲刺结束时再显示。最有可能首先产生问题的部分。另外,看看如何更容易地改变你发现经常改变的事情。

关键是要得到客户 更多 包括,甚至是设计的迭代。也许你想集中讨论 只有 关于设计。

启动客户端。即使你不理解他们的意思是什么,瀑布也会给他们一个机会给你反馈,而不是在每次冲刺结束时给你一个机会。有些人/客户真的很愚蠢,他们不值得为之工作。启动它们,或者告诉它们您使用瀑布而没有实际切换。

您的客户不知道如何开发软件,或者如何管理软件开发过程。不要期望客户就这些问题提供有意义的指导。作为一种特殊情况,客户机并不真正知道“瀑布”和“敏捷”等术语的含义;不要期望它们为您的开发方法提供有意义的输入。此外,客户不会 真的? 关心这些细节,只要在商定的预算和时间框架内满足要求。不要期望他们关心你,也不要把他们与你内部过程中不充分的构建和不相关的信息混淆。

以下是客户真正关心的,并试图与您谈论的(部分使用您自己的技术术语):他们的需求、他们失望的期望以及您与他们沟通的方式。在这些问题上,客户是绝对权威。解释他们所说的是关于你的关系和产品,而不是关于内部过程的可用评论。不要在你的内部期限和流程中蒙混过关,讨论进展、期望和关系。(如果他们坚持谈论内部,您可以重新映射这些术语:例如,他们所理解的“下一个版本”可能在内部被称为“下一个主要版本”,或者其他任何版本)。

在我看来,客户可能需要一个更高的门槛,然后才能得到反馈或玩一个坏的建设。这是值得验证的,如果这是真的。如果是这样的话,您应该尊重这一点——如果您的团队认为这是最好的,那么您还应该在内部使用敏捷方法。如果他们说“瀑布式”,那么您可以在内部将其解释为“我们为需求设定了一个期限,然后我们在一段时间内不允许添加更多的功能。”与客户讨论是否适合在需求期限之后进行这种冻结。

你团队中的某个人需要成为客户的拥护者,并且坐在客户的问题上为他们而战。这个提倡者不能被排挤,也不能站在团队的一边反对客户;他们应该是代理主管。然后,您可以将内部流程沟通(团队到倡导者)与外部沟通(倡导者到客户)分开。在某种程度上,倡导者可以将客户与他们不欣赏的闲谈和构建隔离开来,而不必人为地在您的内部流程上强加某种管理或调度。

为了澄清,我一点也不认为你应该对客户保密或疏远,但你应该(a)倾听客户对关系的看法,以及你如何沟通和尊重,(b)将其与内部开发过程分开,而内部开发过程应该以任何方式进行管理,最终满足客户的期望。内容。

明显的问题是与客户的沟通。如果你真的想做敏捷,你必须在日常基础上与客户沟通。只有客户才能做出决定。如果您只在春季中期和Sprint结束时与客户进行通信,那么很自然,稍后您会在应用程序中发现问题。此外,在Sprint中实现的特性必须被客户接受和测试。直到这些功能没有完成。

我写这个是因为我在当前的项目中有类似的问题,但我知道我们在哪里失败了。

如果团队和客户之间的沟通问题没有得到解决,那么瀑布式的情况可能更糟,如果客户只在产品完成后才看到它(隧道效应)。

您评论了Sprints 6-7中的更改,这些更改开始导致对早期Sprints中完成的任务进行重做。这些变化应该早在Sprint审查期间就被检测到了。

如果功能描述中存在误解,并且团队没有实现客户期望的内容,那么应该在不迟于实现该功能的sprint之前检测到这一点,并在当前sprint中进行理想的修复。

如果客户改变了主意,那么新的想法应该添加到产品积压中,作为任何其他积压项目,优先排序并选择用于冲刺。这不应视为返工。

您是在每次冲刺后将软件交付给客户,还是只是演示它?

错误沟通的根源可能是Sprint计划:团队应该只提交明确定义的积压项目。项目定义应包括验收标准。客户是产品所有者吗?是产品所有者吗?

开发过程的远程调试是非常困难的,所以我会犹豫是否对您的开发过程提供任何意见。 应该 做。在我看来,在你的团队之外,没有任何人能够有足够的信息来作出一个非常有用的判断。

得出结论的一个小跳跃就是猜测出哪里出了问题。从你的描述来看,这听起来像是早期的可交付成果,你认为这是银行的进步,最终被大量改写。

其中一个常见的原因是延迟发现/创建“所有”需求,即项目范围内的所有内容都应该是真实的。如果认真考虑,这些可能是非常致命的:例如,像“所有对话框都必须可调整大小”这样简单的事情显然超出了微软对Windows的改造能力。

对于这种失败(尽管是在非敏捷项目中),可以找到一个经典的描述。 here

“一旦他们看到我们编写的代码的结果,他们就会说,‘哦,我们必须改变这个。’“这不是我的意思,”上汽的雷诺兹说。这就是我们开始在变更请求之后记录变更请求的时候。”

例如,根据上汽工程师的说法,在八个小组完成了大约25%的VCF之后,FBI希望在所有的屏幕上增加一个“页面碎片”功能。这个导航设备也被称为“面包屑”,这个名字受到汉塞尔和格雷特童话故事的启发,它为用户提供了一个URL列表,用于标识通过VCF到达当前屏幕的路径。上汽工程师说,这种新功能不仅增加了更多的复杂性,而且还推迟了开发,因为完成的螺纹必须用新功能进行改装。

关键短语是“所有的屏幕”。面对这种性质的变化,那么,除非您有一些预先存在的工具支持,否则您只需打开(更改所有背景颜色真的应该是微不足道的),您就有麻烦了。你认为你在这一点上所取得的进展将被追溯到过去,结果是虚幻的。

唯一已知的解决这类问题的方法就是第一次把它们解决好。如果失败了,就要忍受他们的错误。

许多商店增加了灵活的装饰,使他们自己“看起来灵活”的客户谁期待它。也许你只需要增加一些瀑布装饰,并向他们展示每2个冲刺一次的产品。

我相信你的客户搬到瀑布去是错误的。它是治疗症状,而不是疾病。 你所描述的问题之一是沟通——客户想要一只老虎,你给他们一只猫。

瀑布模型包括许多步骤来验证所编写的需求是否被交付——但是它并不能确保所编写的需求是业务所指的。

我会看一些技术 impact mapping 行为驱动的发展( BDD ) story mapping 改善沟通。