如何在瀑布环境中保持敏捷

也许可以试试循序渐进的策略。
什么东西足够简单，明天就可以测试，而且可以产生一些影响?

关注敏捷宣言，而不是特定的框架。

我听说有人在这种困境中使用看板作为一种温和的方法/热身。我个人还没有尝试过这个方法，但可以看到它的潜力。

另一种选择是使用“头先下潜”的方法进行几天到一周的小型迭代。为了重新学习如何工作，在这段介绍时间内，你要提前交易，实际上交付了任何东西，或者可能是非常小的东西。

这是一个完全不同的世界。他们是更愿意慢慢进入，还是直接进入?两者的利弊，都取决于球队。

你的老板问错了问题。
问题不在于如何将敏捷元素应用于瀑布式而不干扰任何人。
问题是，在瀑布式环境中会出现哪些问题，其中哪些问题对您的业务风险最大，Scrum框架的哪条规则可以帮助使这些问题更加透明，即更早、更频繁地出现，以便您的组织能够更快地学习和适应。

我所看到的工作是从增量/迭代开发和交付开始的。如果你说:嘿，这些绝对是我们的首要任务。我建议我们下个月开始设法交货。我们展示结果，然后开始我们的任务。

人们理解你的提议。如果人们习惯了增量/迭代开发，你就有了Scrum Sprint的起点。

我曾在一家尼亚加拉大瀑布式的公司看到过这种情况。但当时的环境很有利:因为法律原因，他们必须在3个月内交付。这是一个小型的独立团队。

我的老板最近给我布置了一个任务，让我想出敏捷的哪些元素可以应用到瀑布式环境中

只有一个，就是尽量减少各种形式的浪费。如果你的老板理解并重视这一点，并准备提出补救措施，那么这可能会导致一种更灵活、更精简的工作方式。然而，他应该为深刻而普遍的变革做好准备。

敏捷和瀑布法之间的根本冲突在于是否承诺在特定日期之前交付特定的详细范围项目。这是无可避免的。瀑布具有预测性;敏捷是自适应的。Waterfall是为没有设计工作的项目设计的——如果一个业务系统的新版本需要在六个月的时间内对10,000名员工进行基于课堂的培训，包括打印手册，安排教室，讲师签证等，那么它是有意义的....只有当你在设计新东西时，瀑布才不适合。

诀窍是要认识到，在开始构建之前，您可以有点像瀑布一样(只要您的特许状专注于成功标准和外部边界，而不是详细的范围项)，并且您可以在后端，围绕发布和支持，成为一个小瀑布(更可能是迭代，大多数人不知道区别)，同时在开发产品时完全敏捷。

想象一下，你被雇佣来维护一个已发布的产品:你开始了你的第一个冲刺，有一个解决方案架构，开发和QA环境，一个产品backlog，一个团队....在这一点上，构建现有增量的项目类型重要吗?*将这一想法延伸至第一个冲刺阶段——如果你没有一个固定的计划，那么建立环境、选择平台、建立产品待办事项列表的项目类型是否重要?

Scrum交付了“潜在可发布产品的增量”。在一个大型企业业务系统组织中，将产品发布到生产版本的工作可能是瀑布式的，就像关闭项目本身的活动一样……而产品的生命周期在其他项目或生产支持中继续。

*我来回答我自己的问题:有时这很重要，因为瀑布项目有时并不是为了可持续性而设计的。叹息。

我同意Ian的回答，消除浪费是关键。作为一种更精益的方法，我想在这种情况下从看板开始会不那么痛苦，因为它可以最初应用在任何瀑布之上，以专注于持续改进。如果你做得对，你将开始逐渐转向一个更敏捷的环境，并可能最终得到与Scrum非常相似的东西。另一种选择是从Scrum开始，但如果你试图将其与瀑布法混合在一起，那么压力会更大，因为Scrum需要更多的奉献精神和组织协调才能使其正确。

在Waterfall中，每个阶段本身就是一个项目，在这个阶段中，人们必须管理范围、质量和时间以实现该阶段的目标。例如，在需求阶段，目标是通过各自的文档接收功能性(brd, FRS)和非功能性(NFRs，技术规格)需求的签字。瀑布模型的每个阶段都是几周到几个月。通过对每个阶段采用敏捷方法，可以更好地管理这一点。例如，需求阶段可以分解为可管理的epic到用户故事(如大小)，并在2-3周内完成。此外，Sprint团队可以被确定并分配给每个瀑布阶段。在每个阶段(或每个sprint)的末尾，团队可以召开sprint评审会议和回顾会议，以确保后续阶段得到了最佳的分配和处理。这就是在传统瀑布模型中使用敏捷方法的方法。

问候,
病毒Sodha

也许这只是我的经验，但我还没有看到或听说过将瀑布式和敏捷结合起来的有效方法。

为了保持方法论(瀑布法)的完整性，这些尝试简单地“掩盖”了太多东西，因为方法论本身就低效且繁琐。

为什么我们还要考虑“管理”范围、质量和时间?敏捷告诉我们这些属性是无法管理的。

保持分阶段的方法(即需求阶段)如何促进敏捷性?我们很快就能生产出可工作的软件吗?我们是在促进组织中角色之间的协作，还是在强化低效的竖井?

不稳定、专业化的团队如何提高敏捷性?为什么我们要考虑这样一种糟糕的实践，比如把史诗和用户故事变成任务保留区，以支持每个孤立的、非敏捷的瀑布阶段?

除了持续改进的原则，我看不出敏捷还能应用到传统的项目管理方法中去。

的歉意。范围当然可以在敏捷环境中进行管理。事实上，在Scrum中，只有项目约束(时间、成本、范围、质量)应该根据反馈和方向进行改变。

敏捷是一种思维方式，而不是一个模板。从这个意义上说，这种思维方式可以应用于瀑布模型。

@病毒

同意敏捷不是一个模板或方法，而是一种思维方式的改变。

然而，我强烈认为，在瀑布模型中诚实地应用敏捷将不可避免地改变瀑布模型，因为如此多的瀑布实践直接与敏捷相矛盾。

我很想听听你对以下内容的看法，以及你将敏捷应用于瀑布法的经验:

1)在你的例子中，你为企业提供早期的、频繁的、持续工作的软件在哪里?

2)在“需求”阶段之后，你如何管理不断变化的需求?你如何应对变化?

3)在传统瀑布项目的不同阶段，你如何促进不同团队之间的持续改进和回顾讨论?您的“测试”团队将如何从“需求”团队讨论中受益?

4)在你的瀑布/敏捷混合方法中，你会继续执行哪些“计划”和评估?

5)在你的例子中，频繁的客户合作发生在哪里?

我想如果我推荐你读这篇文章会很合适敏捷方法论是什么?用现实解决方案最简单的解释是什么有很多关于敏捷的信息和一些现实生活中的解决方案。

我认为敏捷方法并不总是相关的，也不适合每个项目和开发人员。
在某些情况下，其他方法更合适，特别是因为它们有很多。
有时甚至是DevOps或看板

我想推荐一篇文章面向初创公司的DevOps:敏捷并不适合应用开发

我想这个也许能帮到你

@Scrum.orgSupport，你能移除上面的两条评论吗?这两条评论对社区没有任何价值，但目的是为链接的url生成权威。亚博一百送一百

每隔几周，我们就会看到这样的评论冒出来，很遗憾它们被允许出现。

Scrum的支持瑞安·伊斯特布鲁克(SDO)通知你^

[我不认为你有一个内部跟踪系统来提醒你当你被叫出去的时候]

嗨,尤金,

新年快乐，并感谢您在社区论坛上所做的有益贡献!亚博一百送一百

不幸的是，我们目前无法删除经过审核的旧帖子。我们确实努力确保我们的论坛不被用作营销平台。我们将继续尽最大努力来验证新的评论是否符合主题的精神。

感谢您的反馈和建议，祝您有愉快的一天!

你可以结合使用极限编程和Scrum。阅读这篇文章，它可能会有帮助Scrum vs极限编程:有什么不同?

当然，您可以而且应该智能地处理代码库，坚持其模块化、弱连通性等等，以帮助进行重构工作，但是重构工作应该贯穿整个过程。这还在继续。这是迭代的。而是让事情变得更好。但你也必须这么做需求预测．不要担心理论化已经完成，看看滞后元素，让它决定完成什么。

我的老板最近给我布置了一个任务，让我想出敏捷的哪些元素可以应用到瀑布式环境中

**这只是我的个人观点和想法…

看看瀑布模型，将不同阶段堆叠在一起。

然后，问做这项工作的人，“我们如何看待我们需要交付的东西，并做一个包含所有堆叠瀑布阶段的小部分?”-个人和交互胜于过程和工具

当那一小块工作完成(集成、测试等)时，它能工作吗?-工作软件优于全面的文档

一旦那一小部分工作完成了，我们可以向涉众寻求反馈吗?它仍然是我们想要继续的方向吗?-客户合作胜过合同谈判

如果方向发生了改变，或者范围发生了改变，或者某些内容需要改变，那么我们是否能够努力执行反馈并再次重复这些步骤?-对变化做出反应，而不是遵循计划

如果我们可以这样思考，关于如何执行它，你会想到什么?

附注:我乐于接受反馈。

我也有类似的情况。我工作的公司认为安装AV解决方案(如LED屏幕)是一个项目。考虑到这一点，有几个实际的项目被视为一个:-

• LED显示屏制造
• 地基工程和物理安装
• 内容解决方案——基于软件(包括硬件)

LED制造方面的工作由中国的一家工厂自行完成，但物理安装方面的工作和软件产品方面的工作几乎是两个独立的项目。由于安装方既使用外部的，也使用内部的和瀑布式的方法，让这种方式继续下去，并潜在地将关键日期放在项目软件方面的sprint结束的旁边，这似乎是有效的吗?

在敏捷方法中，大量的工作被划分为更小的块，称为“sprint”。以并行的方式开发和测试冲刺。这意味着测试不是一个单独的阶段，而是开发过程中不可分割的一部分。测试团队的主要目标是确保及早识别错误、问题和缺陷。

敏捷方法的主要好处是在较短的时间内将产品交付给客户。

遵循循序渐进的策略。

敏捷也有设计、构建、测试、部署周期，以迭代的方式，向最终客户交付小的增量/迭代产品。

确定MVP，在与涉众达成一致的小迭代中交付MVP。

遵循Shu-Ha-Ri

从scrum开始，然后根据需要整合其他敏捷方法。

使用Scrum和看板- ScrumBan(现在很流行)。这将有助于简化交付、交付、使用看板板、泳道的部署。可以帮助限制在制品。

CFD对即兴表演也有很大帮助。

在敏捷方法中，大量的工作被划分为更小的块，称为“sprint”。以并行的方式开发和测试冲刺。这意味着测试不是一个单独的阶段，而是开发过程中不可分割的一部分。测试团队的主要目标是确保及早识别错误、问题和缺陷。

如果我们可以这样思考，关于如何执行它，你会想到什么?

在敏捷方法中，大量的工作被划分为更小的块，称为“sprint”。以并行的方式开发和测试冲刺。这意味着测试不是一个单独的阶段，而是开发过程中不可分割的一部分。测试团队的主要目标是确保及早识别错误、问题和缺陷。

在敏捷方法中，大量的工作被划分为更小的块，称为“sprint”。

我不同意这种说法。例如，看板不使用冲刺。当然，我们也没有必要使用“冲刺”。sprint是Scrum的一部分，但Scrum不是一种方法论，而是一个框架。

我同意测试必须包含在工作中，以产生“已完成”的东西。如果您没有审查工作是否产生了涉众所期望的行为/结果，那么您将自己置于失败和大量返工的困境中。