放弃敏捷,切换到瀑布 - 这是对的吗?

bra*_*boy 52 agile waterfall

我正在敏捷环境中工作,事情已经发展到客户认为他们更喜欢瀑布的状态,因为当前敏捷方案的失败(这就是他们的想法).让他们这样思考的原因是在冲刺的最后阶段发生的大量设计水平变化,我们(开发人员)无法在他们指定的时间内完成.

像往常一样,我们都互相指责.从我们的角度来看,最后说的变化太多了,设计/代码的改动太多了.从客户的角度来看,他们抱怨说我们(开发人员)并没有完全理解这些要求,而是提出了"不"他们在要求中的意图的解决方案.(就像他们要我们画一只老虎,我们画了一只猫).

因此,客户感觉(不是我们)敏捷过程不正确,他们想要切换到瀑布模式,恕我直言将是灾难性的.简单的原因是它们在敏捷模式下的满意程度本身还不够,那么在瀑布开发的设计阶段花费这么多时间之后他们如何才能容忍输出呢?

请提出你的建议.

Pao*_*olo 52

首先 - 问问自己你真的在做敏捷吗?如果您那时应该已经向客户交付了大部分可用功能,满足了他们在早期冲刺中的要求.从理论上讲,"损坏"应该限制在您发现需要进行大型设计更改的最终冲刺中.在这种情况下,您应该已经证明了您的交付能力,现在需要与客户进行对话,以规划现在所需的变更.

然而,根据您的描述,我怀疑您已陷入仅仅在两周周期内开发而没有实际投入生产的陷阱,并且在第一次正确发布时考虑到固定的结束日期.如果是这种情况那么你真的在没有需求分析/设计的情况下进行迭代瀑布 - 这通常是一个不好的地方.

全瀑布不一定是答案(有足够的证据来证明问题是什么),但是在实践中,一些前期规划和设计通常更适合于新兴建筑的"纯粹"敏捷精神(适合于实际上是精益方法).如果大型项目只是开始破解代码并希望它们能够在一定程度上实现一些冲刺,那么大项目就无法实现一个明智的稳定架构基础.

除此之外,"纯粹"敏捷的另一个常见问题是客户期望管理.敏捷作为这个奇妙的东西出售,这意味着客户可以推迟决策,改变主意,并在他们认为合适时添加新的要求.然而,这并不意味着所需的结束日期/预算/努力仍然是固定的,但人们似乎总是错过这一部分.


Mar*_*ers 28

当您的需求不明确以及您可能需要在项目的后期阶段进行设计更改时,敏捷开发方法尤其适用.在这种情况下,瀑布是一种不太合适的方法.瀑布方法适用于很好理解的项目,以及在项目生命周期内不太可能改变需求的项目.这听起来并非如此.

你的短跑多久了?另一种方法可能是减少冲刺长度 - 至少在项目开始时.更频繁地向客户提供新版本,并与客户讨论变更.如果您没有按照自己的意愿行事,这将更加明显,因此在实施不符合客户要求的解决方案时浪费的时间更少.

  • +1对此 - 听起来你需要"更快地失败"而瀑布模型会让你失败得慢得多 (27认同)
  • @Bragboy:看来在最近的短跑中你已经承诺了更多的可能性.如果您知道设计更改是必要的,那么您在估算时应该考虑到这一点.不要在sprint中包含比可以提供的功能更多的功能.如果您在sprint中途之前不知道需要进行设计更改,那么您必须向客户解释您的估算不正确,并且您在实施阶段就已经了解了这一点.改为瀑布对这里没有帮助 - 在估算时你会有更少的知识. (6认同)

drx*_*zcl 26

我不确定你经营的是哪种商店,所以我很难提出好的建议.我可以提供两个指导原则:

  1. 如果您与客户沟通不畅,那么任何开发方法都不会为您节省开支.
  2. 只要用餐很美味,厨师如何组织厨房并不是用餐者的事.

  • 然后,当服务员每隔10分钟冲到桌子上时,会发出如下消息:eeeerrr ......我们现在正在使用奶油来调味酱......错误的......我认为它仍然是火鸡对吧?那么坐下和拿起前叉之间的过程可能会有一些改进.客户与厨房之间的对话始终很重要. (5认同)
  • "敏捷厨师"?另一个名人烹饪比赛计划诞生了!;) (2认同)

ann*_*ata 9

听起来你有严肃的项目管理和架构/设计问题,听起来你的通信也已经崩溃了.从根本上说,我不认为改变你的开发方法会解决任何问题,因此做错了(尽管它可能会恢复一些客户的信心).

我会特别关注迈向瀑布,因为您现在选择基本上只捕获一次要求(我们知道您有问题),没有输入能力.这种刚性对于不灵活的交付目标是有利的,但是在这里你总是有变化是完全不合适的 - 这是敏捷的!

  • 短期内我会退后一步,在这个阶段仔细检查你的要求.重新协商并确认您当前的状态.

  • 从中期开始,我会与客户进行更多沟通 - 尝试让他们参与日常的scrum一段时间(直到你恢复信心,然后你可以更灵活).

  • 从长远来看,你必须担心你的PM和高级开发人员如何设法让你进入这个位置.如果客户是无法解决的,那就是一件事(但是仍然由PM来管理,所以你不能解除).抱怨有太多变化是不合理的,这只是意味着你搞砸了确定要求(这是对话,而不是独白),或者你必须有更多,但可能更短的冲刺.

最重要的是,我看不到走向瀑布可能是正确的.它没有直接解决任何问题,我只能看到它加剧了你已经突出显示的问题.

警告:我真的不能对瀑布有一个平衡的看法,因为我从来没有看到它有效地工作,而且它刚刚完全过时的企业项目.

  • 就像你自己说的那样,一个有偏见的回复,甚至没有考虑瀑布式开发,尽管有效的瀑布式开发过程显然一直在发生.虽然我猜不到原版海报想要一个公平的评估瀑布在这样的情况下是值得的,而是希望重新确认坚持敏捷也符合客户的最佳利益. (2认同)

Jér*_*dix 8

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

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

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

请参阅Steve McConnell的书:"快速软件开发:驯服野生软件时间表",了解所有有效的实践.


Nak*_*ble 7

敏捷开发并不能帮助您免除实际设计的负担,而您和客户都可以相似地理解这一设计.敏捷只是可以以较小的增量提出设计,而不是一次性完成.并且,在困难的客户的情况下,提出适当的设计需要时间.

所以,我会花更多的精力与客户坐在一起,用白板,重温他们真正想要的东西.在这种情况下,如果开发过程是敏捷或瀑布,我认为这并不重要.