# 瀑布法、敏捷法、 Scrum 法、看板法

方法论，方法论-瀑布、敏捷、 Scrum、看板 项目管理近年来有了很大的发展。我记得在我的第一个项目中，我使用了瀑布方法论。已经采用了一些项目管理框架和方法，以确保在工作场所进行有效的团队管理和协作。 在为项目选择要采用的方法时，了解众多因素也是至关重要的。每种方法都有不同的需求，包括优点和缺点，每个元素都有自己独特的原因和方式。 在这个博客中，我将带你了解瀑布、敏捷、 Scrum 和看板方法，以及它们如何为团队项目增值。了解敏捷是项目管理中的一个总括术语，Scrum 和看板是敏捷方法论的一部分，这一点至关重要。 我们开始吧！ 瀑布模型是第一个流程模型，也称为线性顺序生命周期模型。我了解到的一个有趣的事实是，它起源于构建和制造，也是软件开发生命周期(SDLC)所采用的模型。 让我们深入研究一下。这是一种涉及到几个阶段的方法，在开始下一阶段之前，每个任务都需要完成。反过来，这避免了任何阶段的重叠。工作流程设计为单向流动，包括项目构思、启动、分析、设计、施工、测试、部署和维护等阶段。 优点: 其中包括一个更为成熟的项目规划和设计阶段，在开发团队和客户之间同步项目交付成果。由于项目范围是事先知道的，因此更容易衡量进展情况。此外，整个团队不需要在单个阶段工作，例如，如果项目 a 仍处于早期阶段，测试人员可以专注于另一个项目 b 的其他任务，直到产品 a 准备好进入测试阶段。 缺点: 瀑布模型确实有一些好处; 但是，它是一种相当严格的方法没有容纳新变化/更改或采用迭代方法的余地这就导致了在重新审视早期阶段时的困难以及遇到的任何错误/缺陷一旦计划完成，项目就会一直进行到 SDLC 结束这意味着，当顾客需求和市场趋势经常发生快速的、不可预见的变化时，这个过程不容易实现和维持同时，由于在后期阶段发现的 bug 比在早期阶段发现并修复它们的成本更高，这也使得代价更高 什么是敏捷软件开发 这是个很好的问题！为了满足行业对快速周转解决方案日益增长的需求，软件开发任务被分成更小的可管理的部分。 然后大块的时间帮助集中于计划的特性，这些特性将在2-3周的时间内开发完成。敏捷方法学从瀑布模型开始，但是它是不同的，因为你不能一次完成所有特性和规范的特定阶段。相反，你可以选择2-3周内可以开发的特性(称为 sprints)。然后一次性运行这些特性的分析、设计、开发、测试和实现的整个周期。它确保了产品功能的快速开发，为更快地在市场上推出产品提供了空间。 敏捷结合了一些政策，这些政策允许团队进行更好的规划、开发、及时和早期交付项目，同时保持对突发变化的准备，并能够适当地响应这些变化。 作为最大的软件开发过程之一，敏捷方法有各种各样的框架，企业使用这些框架以迭代的方式创建他们的产品，其中包括: Scrum Lean XP Kanban FDD Crystal Clear RAD

一些统计📊

Capterra指出71％的公司正在实施敏捷。

VersionOne显示，采用敏捷已经帮助了98％的公司。

《哈佛商业评论》宣称，采用敏捷方法后，有60％的公司实现了收入增长和利润增长。

🤔我不确定Agile是否存在一些陷阱，因为我个人还没有经历过。 但是有一些。 预测新项目启动时的工作，例如成本，时间和资源，可能是具有挑战性的。 导致资源计划不佳，因为您无法确定从第一天起该项目将是什么。 我听过很多次，敏捷意味着没有/没有文件。 此外，文档从一开始就不会发生，而是更多的是在最后一刻/及时地发布，从而使文档变得不那么详细，并导致倒退。 敏捷更多地是增量开发，可以使产品更快地投放市场。 但是，在不同的周期中要处理不同的组件，从而使输出过于分散且无法组织。 由于出现了新的要求和意外的功能，最终产品的外观尚不清楚。 容易被跟踪。

Scrum

Scrum是一种管理项目（通常是软件开发）的敏捷方法。 用Scrum进行敏捷软件开发通常被认为是一种方法论。 而不是将Scrum视为方法论，而是将其视为管理流程的框架。

Scrum概念更多地是关于分解工作以最大程度地提高效率并减少任何瓶颈，从而使团队更加团结，并积极朝着项目完成和主要是客户满意度迈进。

Scrum团队由开发团队以及产品所有者和Scrum管理员组成，每种目的都有一组定义的角色。

该框架鼓励客户在每个阶段参与。 Scrum以Sprint和Daily Scrums的形式帮助设置项目时间表。 Sprint以产品待办列表的形式表示监视产品负责人完成定义的一组任务的时间。

Sprint可以持续7天到一个月，具体取决于客户要求和项目可行性。 另一方面，“每日Scrum”包括团队，产品所有者，Scrum Master与客户和管理人员之间的每日站立会议（建议），以评估每日水平的任务完成情况以及与障碍和潜在风险相关的可见性 这些任务。

通过在指定的时间段内分配角色来设置里程碑的概念旨在通过透明的工作流程和监视方法来提高项目完成率。 由于在整个项目开发生命周期中都鼓励参与，因此客户满意度也更高。 ✅优点：Scrum的优势包括整个团队都有一个目标，即完成冲刺和完成冲刺目标。 每个团队成员的个人努力清晰可见。 团队共享成功和失败的经验，以负责任。 例如，如果弹簧没有按时关闭，则不是个别故障，这完全是团队的责任。 该团队高度专注于改善开发过程和改善整体产品。 所有团队成员都参与了Scrum会议，并积极表达意见并为所有决策做出贡献。 该团队能够轻松地沟通并尽快消除障碍。 适用于快速发展的开发项目。 一些项目可能要求优先级和产品功能不断变化。 设置较短的Scrum Sprint可使产品所有者在每次Sprint之后添加，确定优先级或更新产品规格。

😐缺点：如果在开发过程中不断将任务添加到sprint中（也称为Scope Creep），则Scrum不会按预期工作。 如果在团队中添加或删除资源，那么灵活起来可能会有点困难，因为这意味着整个团队的估算和速度都会受到影响。 由于涉及诸如Sprint计划，每日站立会议，Sprint审查和每个Sprint的Sprint回顾会议之类的仪式，这也可能是一个耗时的过程。 另外，如果您是第一次从不同的流程迁移到Scrum，那么由于Scrum需要一支训练有素且忠诚的团队来成功进行项目交付，因此希望前几个sprint会有些挑战。 看板

看板在日语中被称为招牌或广告牌。 它是用于精益制造和即时制造（JIT）的计划系统。

但是，在SDLC中，它是另一种敏捷框架。 通过持续改进，看板可以使项目的生命周期更加简化，团队协作可以更加有效。 它几乎没有学习曲线，使团队可以灵活地进行生产，而不会给流程增加不必要的复杂性。 看板致力于在集体或团队层面上改善项目流程和产品质量。

作为精益管理的一部分，该系统的高度可视性使团队可以更轻松地就需要完成的工作以及何时进行的沟通。

与Scrum冲刺板类似，看板会跟踪“待办事项”，“进行中”，“正在审阅”，“阻止”和“完成”活动，但它受“进行中”（WIP）活动的数量限制（该数量由团队经理定义） 并且不能超过）。 这使团队可以随时了解变化，并根据需要轻松实现过渡。

此WIP限制确定在任何时间实例都保持某种状态的工作项数或工作量。 达到预定义的WIP限制意味着不允许在该状态下对新作品进行分类。 这迫使团队在处理新实体之前先完成待处理的项目。

看板板可以由团队中的任何人使用和修改，只要它能说明工作实体的状态和所涉及的修订。 这意味着没有一个人可以确保团队保持一致或遵守既定的工作政策。

看板通过帮助团队持续改进项目，从而有助于总体优化项目开发周期。 最终，这将导致更高的吞吐率和时间，同时保持最终产品的质量。 ✅优点：看板具有很大的优势，例如团队中的每个人都可以在板上看到所有内容，因此他们在同一页上。 每个团队成员都可以查看/更新每个项目/任务的状态。 因此，它非常透明。 它也是非常灵活的，因为它是事件驱动的，而不是时间限制的。 例如，如果对某个需求有需求，则可以从“待办事项”列中删除任务。 瓶颈很容易发现，因为整个团队可以看到大多数任务拖慢了交付过程的专栏。 最后，看板很容易理解和采用。

😐缺点：看板框架有一些缺点； 当不同团队之间共享资源时，这可能变得困难而效率低下。 这导致开发团队受阻，无法等待资源添加到产品中。 看板板也可能导致开发过程受阻。 为何如此？ 如果某个任务没有移到适当的列（阶段），并且依赖该任务的其他任务将被阻止，并且不会收到通知。 TL; DR –瀑布式，敏捷式，Scrum式和看板式方法论💫

总之，作为一个团队，我们非常仔细地决定产品需求，以及您的产品如何从上述框架和方法中受益。 敏捷意味着拥有敏捷的心态并选择最适合敏捷团队的框架。 但是，如果您决定进行瀑布式流程，则需要了解如何成功交付客户需求。 无论选择哪种方法，目标都应该是产品的高质量和快速交付。

作为一名测试人员，我认为最好在敏捷团队中工作，因为测试人员从一开始就参与其中。 我也曾在瀑布项目中工作过，直到很晚才开始测试。 通过构建自动化脚本并手动进行测试，测试人员可以通过向开发人员提供早期反馈来增加价值。 敏捷测试是产品开发的一种方法，在该方法中，我们的目标是在生产周期中尽快开发出高质量的产品，并且每个相关人员都为质量做出贡献。 测试人员采用早期正确的方法进行手动测试或测试自动化可以极大地受益。

这里有一个简单的类比，可以概括所有summarize：想象一下烤蛋糕并遵循确切的食谱。 那就是瀑布方法。 如果我自发地烘烤​​同一块蛋糕，那么那更多是一种敏捷方法。 没有方法是错误的，请选择最能交付产品的方法。

目的是：

through通过优质的最终产品交付价值，而不是简单地交付有效产品。

🌟管理交付该产品的清晰流程。

# author

石头 磊哥 seven 随便叫

# company

thoughtworks（离职了。。。。）

大家好，本人不才，目前依旧混迹于thoughtworks，做着一名看起来像全栈的QA，兴趣爱好前端，目前是thoughtworks 西安QA社区的leader，如果有兴趣分享话题，或者想加入tw，可以找我

# roles

QA（营生） dev（front-end dev 兴趣爱好）

# 联系方式

如果想转载或者高薪挖我 请直接联系我 哈哈

# wechat:

qileiwangnan

# email:

qileilove@gmail.com