SDLC，意为软件开发生命周期（SDLC），是一个软件开发过程。它包括需求收集、设计、开发、测试和维护。软件开发生命周期是一个软件开发过程，包括需求收集、设计、开发、测试和维护等阶段。

1. 什么是SDLC
2. SDLC的阶段是什么？
   1. 需求分析
   2. 规格
   3. 软件架构
   4. 编码
   5. 测试
   6. 文档
   7. 软件培训和支持
   8. 维护服务

3. 结论

什么是SDLC

SDLC是一个通过调查、分析、设计、实施和维护来开发信息系统的过程。SDLC也称为信息系统或应用程序的开发。它也被称为瀑布模型。可以使用几种方法或模型来指导软件开发的生命周期。其中包括以下内容：

1. 线性或瀑布模型
2. 敏捷方法论
3. 快速应用程序开发（RAD）
4. 联合应用程序开发（JAD）
5. 原型

软件开发生命周期（SDLC）是开发软件产品的正式、逻辑步骤的过程。SDLC的阶段可能略有不同，但通常包括以下内容：

SDLC的阶段是什么？

需求分析

创建它的第一个任务是提取所需软件产品的需求。虽然客户可能相信他们知道需要做什么软件，但识别不完整、不明确或矛盾的需求可能需要软件工程方面的技能和经验。

规格

规范的任务是准确描述要严格数学编写的软件。在实践中，大多数成功的规范都是为了易于理解和适应应用程序而编写的。尽管安全关键型软件系统通常在应用程序开发之前被仔细指定，但它们已经得到了很好的开发。规范对于需要保持稳定的外部接口至关重要。

软件架构

软件系统的体系结构是指系统的抽象表示。体系结构涉及确保软件系统满足产品的要求，并确保未来的要求能够得到满足。体系结构步骤还处理软件系统和其他软件产品与硬件或主机中的操作系统之间的接口。

编码

将设计简化为代码可能是软件工程工作中最明显的部分，但不一定是最大的部分。

测试

测试软件的各个部分，尤其是在两个不同的工程师必须一起工作的情况下，是软件工程师的责任。

文档

为潜在的服务和更新记录软件的内部体系结构是一项重要任务。文档是最重要的外部接口文档。

软件培训和支持

大量软件项目失败是因为开发人员不知道如果开发团队中没有一个人最终使用软件，他们需要多长时间才能构建软件。偶尔人们会抗拒改变，恐惧是新的，作为部署过程的一部分，为最热情的软件用户提供培训班非常重要（建立兴奋感和信任感），将培训转移到中立用户和狂热的支持者身上，并最终将组织的其他部分纳入他们的采用中。用户会对软件有很多疑问和问题

维护服务

这可能比程序最初创建时需要更多的时间来更新和升级软件，以处理新发现的问题或规范。代码不仅可能与原始设计不匹配，而且只有软件开发人员才能决定软件完成后的功能。大约2/3的软件工作是维护，这可能会产生误导。一点错误修复是其中的一部分。希望这些文章有助于理解SDLC

请参阅SDLC文档

结论

软件开发生命周期（SDLC）是一个指导软件项目从概念到实施的框架，确保在预算范围内按时达到最高质量标准。这个博客考察了项目的各个阶段，从最初的规划和需求收集到编码测试、部署和维护。

软件过程是用于指定、设计、实现和测试软件系统的一系列活动。软件过程模型是过程的抽象表示，它从某些特定的角度对过程进行描述。有许多不同的软件过程，但都涉及:

• 规格（Specification ）-界定系统应做的工作;
• 设计及实现（Design and implementation ）-界定系统的组织架构，并实现系统;
• 验证（Validation ）——检查它是否满足了客户的需求;
• 进化（Evolution ）-改变系统以响应不断变化的客户需求。

软件过程模型的类型

软件过程、方法和框架的范围从组织在日常工作中可以直接使用的特定的说明性步骤，到组织用于生成针对特定项目或小组的定制步骤集的灵活框架。在某些情况下，“赞助者”或“维护”组织分发一组描述过程的正式文档。

软件过程和软件开发生命周期模型

软件开发过程的一个基本概念是SDLC模型，它代表软件开发生命周期模型。为了实现不同的需要的目标，已经开发了许多开发生命周期模型。这些模型指定了过程的各个阶段以及它们被执行的顺序。最常用、最流行和最重要的SDLC模型如下:

• 瀑布模型
• V模型
• 增量式模型
• RAD模型
• 敏捷开发模型
• 迭代式模型
• 螺旋模型
• 原型模型

瀑布模型

瀑布模型是将项目活动分解为线性顺序的阶段，其中每个阶段依赖于前一个阶段的可交付成果，并对应于任务的专门化。这种方法在工程设计的某些领域是典型的。

V模型

v模型表示一个开发过程，它可以被认为是瀑布模型的扩展，并且是更通用的v模型的一个例子。编码阶段结束后，处理步骤向上弯曲，形成典型的V形，而不是线性地向下移动。v -模型演示了开发生命周期的每个阶段与其相关联的测试阶段之间的关系。水平轴和垂直轴分别表示时间或项目完整性(从左到右)和抽象级别(最上层的粗粒度抽象)。

增量式模型

增量构建模型是一种软件开发方法，在这种方法中，模型以增量的方式设计、实现和测试(每次都增加一点)，直到产品完成。它涉及到开发和维护。当产品满足了它的所有需求时，它被定义为已完成。每次迭代都要经过需求、设计、编码和测试阶段。系统的每一个后续版本都会向前一个版本添加功能，直到所有设计的功能都实现。这个模型结合了瀑布模型的元素和原型的迭代哲学。

迭代式模型

迭代生命周期模型不会首先关注初始的、简化的用户特性集，然后逐步获得更多的复杂性和更广泛的特性集，直到目标系统完成，从而尝试从完整的需求规范开始。当采用迭代方法时，增量开发的哲学通常也会被自由地、可互换地使用。

换句话说，迭代方法从指定和实现软件的一部分开始，然后可以对其进行审查并确定优先级，以确定进一步的需求。然后通过为每个迭代交付软件的新版本来重复这个迭代过程。在一个轻量级的迭代项目中，代码可能代表系统文档的主要来源;然而，在一个关键的迭代项目中，可能还需要一个正式的软件规范。

RAD模型

快速应用程序开发是对在七十年代和八十年代开发的计划驱动的瀑布流程的回应，例如结构化系统分析和设计方法。快速应用程序开发(RAD)通常被称为适应性软件开发。RAD是一种增量式的软件开发原型方法，终端用户可以在检查实时系统时产生更好的反馈，而不是严格地使用文档。它较少地强调计划，而更多地强调适应性过程。

当应用程序投入生产时，RAD可能会导致较低级别的拒绝，但是这种成功通常是以项目成本和进度的急剧超支为代价的。RAD方法特别适合于开发由用户界面需求驱动的软件。因此，一些GUI构建器通常被称为快速应用程序开发工具。

螺旋模型

螺旋模型是由Barry Boehm在1986年首次描述的，它是一个风险驱动的软件开发过程模型，引入它是为了处理传统瀑布模型中的缺陷。螺旋模型看起来就像一个有许多循环的螺旋。螺旋的确切循环数是未知的，并且可能因项目而异。该模型支持风险处理，并且项目是循环交付的。螺旋的每个循环称为软件开发过程的一个阶段。

在开发软件产品所需要的瀑布生命周期的早期阶段中的螺旋模型的初始阶段。根据项目风险的不同，开发产品所需要的阶段的确切数量可能会有所不同。由于项目经理动态地决定阶段的数量，所以项目经理在使用螺旋模型开发产品方面扮演着重要的角色。

敏捷开发模型

敏捷是一组基于敏捷宣言中所表达的价值观和原则的方法和实践的总称，它是一种思维方式，使团队和企业能够创新，快速响应不断变化的需求，同时降低风险。使用许多可用的框架，比如Scrum、看板、精益、极限编程(XP)等，组织可以变得敏捷。

敏捷运动提出了传统项目管理的替代方案。敏捷方法通常用于软件开发，以帮助企业应对不可预测性，它指的是一组基于迭代开发的软件开发方法，在迭代开发中，需求和解决方案通过自组织的跨功能团队之间的协作而演变。

敏捷的主要目标是赋予开发团队创建和响应变化的能力，以便在不确定和动荡的环境中取得成功。敏捷软件开发方法通常在快速和小周期中运行。这将导致更频繁的增量发布，每个发布都构建在以前的功能上。进行彻底的测试以确保软件质量得到维护。

用可视化范式(Visual Paradigm)管理软件过程

Visual Paradigm提供了一组丰富的项目管理工具，帮助软件团队执行主要的开发活动，并管理整个过程中创建的工件。

项目管理的向导

使用自动化的指导流程启动任何规模的IT项目，包括逐步指导、输入参考和示例。与您的团队成员渐进地和协作地开发可交付成果。

准时PMBOK(项目管理知识体系)/项目管理流程图

人们在项目管理上面临着很多困难，比如陡峭的学习曲线和雇佣认证专业人员的高成本。Visual Paradigm独特的自动化项目管理知识体系工具为以最小的成本启动IT项目管理提供了所有的帮助和指导。

原文：https://www.visual-paradigm.com/guide/software-development-process/what-is-a-software-process-model/

本文：http://jiagoushi.pro/node/1215

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

介绍

您是一家大型企业的项目经理，希望与供应商合作进行一些工作吗？

为企业客户准备和交付工作声明（SOW）似乎是一项艰巨的任务。在项目发现阶段牢记这四个关键点将有助于项目负责人和经理定义构成SOW的每个组件。

由于SOW是及时的快照，并且文档概述了软件开发提供商满足规定要求的一系列活动，可交付成果和时间表，因此它应该具有支持成功项目交付的详细程度。

在准备SOW时，尽可能多地关注以下四个关键点将实现这一结果，并向客户展示能力。

 

1.尽可能详细地定义范围

在SOW中列出估计的可交付成果时，重要的是要考虑需要多少细节。详细程度取决于几个因素：

发现时间/成本

项目发现阶段可用的时间和资源量将在最终范围的详细程度中发挥重要作用。投入时间和资源更详细地识别和详细说明交付项目将在估算对其的努力时提供更高的信心。

项目方法论

如果将Agile用作项目交付框架，那么所需的置信水平最初会降低，但随着交付团队学习如何协同工作并在每个sprint中交付工作软件而增加。瀑布式方法需要更高的置信度才能使业务开始交付舒适。

关键利益相关者可用性

通常，作为项目一部分的主题专家和供应商将被要求详细说明初步理解，并提供更清晰的所需要的图片。由于各种原因，在发现期间可能并不总是这样。如果是这种情况，则估计值必须补偿较低的置信因子。

供应商/系统规范和设计完整性

在大多数情况下，需要根据某种系统，接口规范或高级设计至少进行一些估算。这些可能并不总是完整的或提供足够的细节以获得全貌。这些知识差距可能能够被技术主题专家等所掩盖。如果不是这种情况，则需要添加假设列表并降低相关可交付项目周围的置信度。

最终，这些因素将限制SOW的准确性，重要的是通过将总体置信度评级作为百分比来在文档中说出来。

该评级将为那些负责接受和签署他们可以预期的差异的人提供背景。如果利益相关者不接受信任程度，则应在交付前将其视为知识中不可接受的差距。

 

2.用一组可靠的假设来估算估计值

接受团队在发现过程中对项目的了解总是比任何其他阶段都要少。考虑到这一点，将需要一个涵盖任何未知和未经证实的约束的工具。这个工具将是卑微的假设。

格伦 - 卡斯滕斯 - 彼得斯-190592-unsplash
一套定义明确的假设不仅有助于解释为什么以可信方式估算已确定的可交付项目的原因，它们还可用于弥补在发现期间无法关闭的知识缺口。

应尽可能详细地定义假设，这一点非常重要。在这里，最好具有高水平假设以及内联可交付水平假设，因此假设可以根据需要进行广泛或具体。

通过与其他利益相关者聚在一起并分享假设列表，然后将它们与预期交付团队中其他人的假设进行比较将是非常有益的。与其他人一起验证和探索已确定的假设通常会导致比单个人单独生产更好的覆盖范围。

如果对假设清单进行了合理的努力并且采用了上述策略，那么当澄清开始飞行和交付起飞时，项目将处于有利位置。

3.交付阶段定义应反映实际过程

在定义项目的交付阶段时，请注意项目在交付期间将使用的流程。相位越接近实际过程，相变就越平滑。这是因为在商业利益相关者同意的SOW中就可以了。与此不同将导致混淆，并可能阻止项目团队进入下一阶段，而项目经理试图与业务利益相关者澄清。

定义阶段时要包括的一些关键项是：

• 意图：这应该以简洁的方式描述阶段的意图。
• 输入：此阶段需要启动的依赖项，始终包括在不是第一阶段之前的阶段的输出。
• 产出：应列出任何预期的关键成果和可交付成果，以便每个人都理解并同意预期的内容，这将形成要签署的验收标准。一套明确定义的验收标准可以说是阶段描述中最重要的焦点。
• 签署：这应列出签署阶段所需的利益相关者。这种情况常常被排除在外，并且出现了“谁说你可以进步？”这个不可避免的问题。

使用敏捷项目交付框架，应该可以采用“完成定义”中定义的内容，并使用它来描述交付阶段，反之亦然，因为这将是每个阶段完成的真实反映。

 

4.同行评审SOW

对SOW进行同行评审将为参与者提供在仅考虑个人观点时可能遗漏的洞察力，并将导致最终SOW中的差距缩小。

由于害怕判断，首次向他人展示工作通常是令人生畏的，然而，这个过程越多，所有参与者就越容易，整体结果将具有更高的品质因素。

与相关团队成员分享SOW的简单过程 - 通常是 - 确定一些想法或发现一个未被考虑的关键问题导致

确定遗漏的可交付成果或关键假设。对于确定可交付项目的范围也是如此，与同事共享列表的简单行为通常会识别出一些未被考虑过的项目。

有许多方法可以进行同行评审，并且有无数篇文章描述了良好的同行评审系统的关键因素和机制，在此过程中最重要的是与其他人共享SOW。 Bob Ronan撰写的文章“成功项目的秘诀：同行评审”是一个这样的例子，因为它写得很好并且表明了同行评审过程的重要性。

 
结论

使用上述4个关键点来关注生产SOW时的可用时间，将输出放在最佳位置，以实现成功的项目交付。

如果您对本文有任何意见或想法，请随时在下面的评论部分分享。

 

任何成功项目的根本在于项目经理(PM)的价值。虽然有些人认为项目经理的唯一工作就是提醒每个人关于截止日期和召开状态会议，但事实并非如此。

他们所做的是一门科学——他们对项目管理的五个阶段有着深刻的理解，并且能够完美地执行。在这篇文章中，我们将讨论每个阶段需要做什么，并分享在每个阶段提高成功的秘诀。

项目管理由项目管理学会(PMI)开发，包括概念和启动、计划、执行、绩效/监控和项目结束五个阶段。PMI成立于1969年，是世界上最大的项目管理专业非营利性会员协会。它为项目、计划和项目组合管理设置了标准，并提供培训和认证。该协会的黄金认证标准是项目管理专业(PMP)®认证。对于不同类型的项目管理，还有七种其他的认证。

为了规范项目管理信息和实践,一组超过80 PMI成员创建了文本,指导项目管理知识体系(PMBOK指南®)目前在其第五版,项目管理知识体系®指南是不断更新的采购经理人指数和股票的基本做法,全球使用达到最好的结果。PMBOK指南包括一个可以应用于许多项目的过程标准;然而，它承认每个项目都是不同的。由项目管理人员来应用项目管理知识体系(PMBOK)指南中涵盖的技术和阶段，以满足项目的独特需求。

PMBOK®项目生命周期指南概念

在讨论项目管理阶段时，不可避免地会提到项目生命周期。那么有什么区别呢?项目阶段组成了项目生命周期，因此，这些阶段可以根据项目的需要进行调整。根据PMBOK®指南，项目生命周期的元素应该定义:

• 必须完成的工作
• 必须生成和审查哪些可交付成果
• 谁必须参与
• 如何控制和批准每个阶段

确定这些元素需要一个项目从开始到结束。它提供了一个系统的、及时的、可控制的过程，使项目的涉众受益。这有助于项目经理定义在进入项目的下一个阶段之前需要完成什么。

项目管理的5个阶段

根据PMI，“项目管理是对知识、技能、工具和技术的广泛应用，以满足特定项目的要求。“项目管理有五个阶段，如果生命周期提供了项目的高级视图，那么这些阶段就是完成项目的路线图。”

阶段1:项目启动

这是项目的开始，此阶段的目标是在更广泛的层次上定义项目。这个阶段通常从一个业务案例开始。这时你要研究这个项目是否可行，是否应该进行。如果需要进行可行性测试，这是该项目将在其中完成的阶段。

重要的干系人将尽职调查以帮助决定项目是否“可行”。如果获得批准，你将需要创建一个项目章程或项目启动文件(PID)，概述项目的目的和要求。它应该包括业务需求、涉众和业务案例。注意:有大量的PID模板，坚持PMBOK®指南指南，你可以下载，以帮助你开始。

提示:在创建PID时，不要太拘泥于技术需求。这些将在第2阶段加以澄清和明确界定。

第二阶段:项目规划

此阶段是成功的项目管理的关键，并关注于开发每个人都将遵循的路线图。这个阶段通常从设定目标开始。设定目标的两种比较流行的方法是S.M.A.R.T.和CLEAR:

S.M.A.R.T. Goals （目标）——这种方法有助于确保你的目标被彻底审查过。它还提供了一种明确理解目标设定过程的含义的方法。

• 具体（Specific ）——要设定具体的目标，请回答以下问题:谁、什么、在哪里、何时、什么、为什么。
• 可衡量的（Measurable ）——创建一个你可以用来衡量一个目标成功与否的标准。
• 可实现的目标（Attainable ）——确定最重要的目标以及实现这些目标需要做些什么。
• 现实（Realistic ）-你应该愿意并且能够朝着一个特定的目标努力。
• 及时（Timely ）——为实现目标制定一个时间表。

 

C.L.E.A.R. Goals 一种新的设定目标的方法，考虑到当今快节奏的商业环境。

• 协作（Collaborative ）——目标应该鼓励员工一起工作。
• 有限的（Limited ）——他们的范围和时间应该是有限的，以保持可控。
• 情感上的（Emotional ）——目标应该激发员工的激情，并成为他们能够形成情感联系的东西。这可以优化工作质量。
• 可观的（Appreciable ）—把大的目标分成可以很快完成的小任务。
• 可细化-（Refinable ）当新情况出现时，要灵活并根据需要细化目标。

在此阶段，定义项目范围并制定项目管理计划。它包括确定成本、质量、可用资源和现实的时间表。项目计划还包括建立基线或绩效度量。这些是使用项目的范围、进度和成本生成的。基线对于确定项目是否在正轨上至关重要。

此时，角色和职责被清楚地定义，因此每个参与的人都知道他们的责任是什么。以下是项目经理在此阶段将创建的一些文件，以确保项目保持在正轨上:

• 范围陈述——明确定义业务需求、项目利益、目标、可交付成果和关键里程碑的文件。范围声明可能在项目过程中发生变更，但不应在没有项目经理和发起人的批准下进行。
• 工作分解计划(WBS)——这是一个可视化的表示，它将项目的范围分解为团队可管理的部分。
• 里程碑——确定整个项目中需要实现的高层目标，并将其包含在甘特图中。
• 甘特图-一个可视化的时间线，你可以使用它来计划任务和可视化你的项目时间线。
• 沟通计划——如果你的项目有外部干系人参与，这一点尤为重要。围绕项目制定适当的消息传递，并根据交付成果和里程碑制定与团队成员沟通的时间表。
• 风险管理计划——识别所有可预见的风险。常见的风险包括不切实际的时间和成本估计、客户评审周期、预算削减、需求变化以及缺乏承诺的资源。

提示:当创建WBS时，工作包不应该超过10天。一定要征求团队成员关于他们具体任务的意见和观点。

阶段3:项目执行

这是开发和完成可交付成果的阶段。这通常感觉像是项目的核心部分，因为在这段时间内发生了很多事情，比如状态报告和会议、开发更新和性能报告。“启动”会议通常标志着项目执行阶段的开始，在这个阶段，所涉及的团队被告知他们的职责。

执行阶段完成的任务包括:

• 开发团队
• 分配资源
• 执行项目管理计划
• 采购管理(如有需要)
• 项目经理指导和管理项目执行
• 建立跟踪系统
• 执行任务分配
• 状态会议
• 更新项目进度
• 根据需要修改项目计划

虽然项目监控阶段有一组不同的需求，但这两个阶段经常同时发生。

提示:考虑使用基于云的项目管理软件，这样团队成员就可以实时更新任务状态。

阶段4:项目执行/监控

这一切都是关于度量项目进展和性能，并确保所有发生的事情都与项目管理计划相一致。项目经理将使用关键绩效指标(kpi)来确定项目是否在正轨上。PM通常会选择其中的两到五个kpi来度量项目绩效:

• 项目目标:衡量项目是否按照进度和预算进行，可以指示项目是否满足涉众的目标。
• 质量交付:这决定了特定的任务交付是否被满足。
• 工作和成本跟踪:项目经理将考虑工作和资源成本，以查看预算是否在轨道上。这种类型的跟踪将根据当前的性能通知项目是否满足其完成日期。
• 项目绩效:监控项目中的变化。它考虑出现问题的数量和类型，以及解决问题的速度。这些可能发生在未预见的障碍和范围更改中。

在此期间，项目经理可能需要调整时间表和资源，以确保项目处于正轨

提示:在每个阶段结束时回顾业务案例，并根据需要对项目计划进行调整。

阶段5:项目结束

此阶段表示已完成的项目。雇佣来专门为这个项目工作的承包商此时被终止。有价值的团队成员会得到认可。有些项目经理甚至为参与项目的人组织小型工作活动，以感谢他们的努力。项目完成后，PM通常会召开会议——有时被称为“事后分析”——以评估项目中哪些工作进行得很好，哪些工作失败了。这对于理解学到的经验教训特别有帮助，以便为将来的项目做出改进。

一旦项目完成，项目经理仍然有一些任务要完成。他们需要创建一个项目目标清单，列出在项目中没有完成的事情，并与团队成员一起完成这些事情。执行最终项目预算并准备一份最终项目报告。最后，他们需要收集所有项目文档和可交付成果，并将它们存储在一个地方。

提示:使用基于云的软件解决方案是在项目生命周期中收集和保存所有项目文档的一种简单方法

 

原文：https://www.smartsheet.com/blog/demystifying-5-phases-project-management

本文：http://jiagoushi.pro/node/1206

讨论：请加入知识星球【首席数字化转型官】或者小号【cio_cdo】或者QQ群【2245019】

也许，从运营的角度来看，最可怕的软件开发方法之一可能对小公司再次有意义。

肯施瓦伯——Scrum 的联合创始人和 Scrum.org 的创始人——说瀑布“真的毁了我们的职业”。 “它让人们被视为资源，而不是有价值的参与者。”预先完成了如此多的计划，员工变成了车轮上的一个齿轮。
瀑布式开发模式起源于制造业和建筑业；高度结构化的物理环境意味着设计更改在开发过程中很快就会变得非常昂贵。当首次用于软件开发时，基于知识的创造性工作没有公认的替代方案。

问题

构建软件程序的努力是众所周知的。尽管与其他所有类型的工程相比，软件的发展速度相当快，但没有可以在半秒内编译和处理我们的工作以将结果显示在计算机屏幕上或将其暴露在可交互层上的花哨和快速的机器.必须用程序的所有逻辑对纸板进行打孔。只有这样，机器才能读取一盒穿孔卡片。打字错误通常意味着重新打孔整张卡片。

当然，回想起来这听起来很痛苦，而且确实如此！需要几个专业人员来运行一个简单的编译。有些人只负责在盒子里整理卡片。这不是一项非常专业的工作，但必须有人去做。为了降低这种繁琐操作的成本，Waterfall 发挥了作用。如果事先做好计划，就不需要整天安排大量高度专业化的专业人士坐着打卡。这非常有效。可以避免许多错误，并且开发程序所需的时间更少。

向前走

众所周知，组织在采用新概念方面的缓慢跟不上机器的发展。越来越多的硬件资源变得更容易和更便宜地访问，程序编译不再需要与计算机进行物理交互，网络在全球范围内被发明和实施，使开发人员能够在任何地方分享知识。

在如此快速和协作的环境中，瀑布不再有意义。任何人都可以在您舒适的家中拥有一台机器并编写甚至有时会动摇已知市场实践基础的破坏性程序。投入数月的计划，编写数百页（通常是书籍）的需求文档和图表开始听起来是压迫性管理的不必要步骤。必须做出改变。

旧与新

近年来，许多人都将敏捷作为组织内部软件甚至非软件开发过程的核心和必须遵循的方法论。普遍的心态是，它是所有问题的答案。无论在哪个部门，涉及什么/谁以及性质是什么，都会有一个适合您的敏捷框架。
每个组织都是独一无二的，并面临着各种内部因素（即规模和当前结构）和外部因素（即客户和商业模式）。在按照敏捷宣言创建新框架以满足各种不断出现的问题的需求方面已经做了大量工作。简单性来自这样一个事实，即它是一组遵循并根据您的需求调整的原则。没有万能的解决方案。每个部门都有自己的角色、问题、流程、人员和技能。哪种组合对团队有利将取决于内部和外部因素、需求和目标。

在敏捷环境中，与瀑布式方法相比，团队之间的协作更加频繁，后者编写文档然后传递给下一个。每个被问到的问题都只是用一个简单而懒惰的“阅读文档”来回答。受到对未来愿景的启发，或者只是整理了房间里每个人似乎都很常见的糟糕经历，敏捷宣言变得栩栩如生。对于每一种好的方法，只有一个目标很重要：解决问题。

（旧）新问题

在当时（90 年代、00 年代），谁负责构建一个好的软件产品几乎没有区别。大部分工作在开发人员手中。用户体验本身并不是它自己的东西。显然，它总是存在的，但如果一个产品有很好的接受度，那就有点神秘了。用户界面设计被视为不重要，并呈现出一些可怕的结果。

然而，今天，您可能需要几个具有不同技能的人来构建并保持市场上具有竞争力的产品。 UX/UI 设计师、产品经理（及其变种）、后端开发人员、前端开发人员、移动开发人员、基础设施专业人员等（在这里看到一个模式？）很明显，对更多人员、不同职位的需求正在增加日。

更重要的是，大型科技公司开始变得绝望。没有足够的专业人士来满足他们的需求。在十年（2001-2011 年）中，工资增长高达 35%，最后一个增长高达 47%，具体取决于地区。软件危机时代会再次发生吗？
Waterfall 的主要目标是降低开发阶段（实际代码编写）的成本。薪水如此之高，而且缺乏可用的专业人士，预示着提前计划的卷土重来。小公司不能仅仅与大科技公司的薪水竞争，并让专业人士“更快地犯错”。
你怎么看？在实际执行之前进行计划是否值得？还是每个人都应该使用试错法？也许两者兼而有之？在下面留下您的评论。

这不是方法论之间的比较。我只是指出行业历史的模式、动机以及他们试图解决的运营和技术问题。
谢谢阅读！

 

一些精彩的评论：

评论1：

瀑布和敏捷有根本的区别。 瀑布基本上是一种适用于软件开发的问题解决方法。 敏捷是围绕以原型设计为导向的方法论编织的一堆愿望（宣言），它已经过度扩展成为现在的时尚。 随着时间的推移，它已经与诸如“计划快速失败”之类的破坏性口号联系在一起。
瀑布从不严酷或可怕。 它的“缺陷”被夸大了，只是为了让敏捷看起来不错。
正如您所说，重要的是，瀑布是关于将思考放在首位，并为整个过程提供一个正式的结构，以鼓励（重）可用性并插入运行组织的传统方式 - 规划、成本会计、项目管理等。敏捷可能会占有一席之地 ，但是当它很重要时，或者正如你所说的那样，当公司不能继续更快地犯错时，瀑布是解决方案。 瀑布是迭代的，但有一个整体的计划和结构。

评论2：

当然，瀑布项目有一席之地。在一个不复杂（non-complex）但复杂（complicated ）的世界中，结果是可以预测的。我们可以知道，“如果我们这样做，将会发生以下情况。”在我们重复自己的情况下，重复做同样的事情。那么瀑布式方法是一个不错的选择。
在复杂的（complex ）世界中，我们或客户不可能事先知道一切，结果无法预测，我们需要在知道之前学习。然后我们需要另一种方法。一种实验性的方法，我们可以随时做出决定并尽可能晚地做出这些决定。敏捷已成为这些复杂情况的一种解决方案。
当今的数字和网络物理系统通常属于复杂（complex ）类别；我们不可能知道会发生什么，当我们有更多的知识时，我们想做出迟到的决定，并且随着我们的进展获得更多的理解。
我们不会经常两次构建相同的软件。所以我认为任何一种系统的开发通常都不会落入复杂的范畴。但是，为客户安装软件系统可能需要多次完成，虽然很复杂（complicated），但并不复杂（ not complex），我们可能会使用瀑布方法。
说了这么多，我还想强调一下，敏捷并不意味着我们不应该计划。在敏捷宣言中，我们说：“响应改变胜过遵循计划。”关键字结束了。我们仍然需要计划；但是，我们应该计划得恰到好处，并尽可能晚地计划，以应对我们和我们的客户在开发过程中获得的知识所带来的变化。

评论3：

我认为您有一个非常好的观点，即随着开发人员时间成本的增加及其上升趋势，任何可以减少这种情况的方法（规划、使用更便宜或更高效的资源来进行规划等）都在进行得到一个强大的外观。
我不确定瀑布是否是这个问题的答案。我不认为敏捷已被证明是正确的。敏捷肯定有好处，但省钱*不是*其中之一。十多年来，我一直在使用低代码/无代码工具，我确信它们是解决方案的一部分，但不是整个解决方案。
我*知道*花时间写一个技术细节用户故事，上面写着“从这个表中获取数据并使用这些条件连接到那个表，像这样过滤，然后在屏幕上填充列表和他们一起……”（即伪代码）在发现用户故事中的漏洞、帮助了解技术困难等等方面走了很长很长很长的路。我认为伪代码在很大程度上是一门失传的艺术，我在开发过程中看到的许多问题都可以通过预先编写伪代码来避免。

评论4：

瀑布的核心问题：您在计划中忘记了一个项目，这将在开发阶段永远困扰您。
敏捷的核心问题：仅仅因为你在彼此之上添加切片（sprint），你不一定会建造一个埃菲尔铁塔，而是建造比萨斜塔（最终会崩溃）。
您需要更广泛的规划和敏捷实施的健康组合

评论5：

应该定义“瀑布方法”的论文是 Winston Royce 的“管理大型软件系统的开发”。有趣的是，本文没有出现“瀑布”一词。它也没有说你必须一步一步地前进，永不回头。事实上，它说的恰恰相反，并清楚地表明，当发现问题时，您需要回到之前的步骤。那么为什么这么多人认为罗伊斯是在提倡“瀑布式”开发呢？我相信有两个原因。首先，人们只阅读第二张图，它列出了软件开发的步骤，并且确实可以作为瀑布来阅读。其次，这篇论文被敏捷的布道者当作稻草人，他们需要一些东西来打败现有的想法。如果人们真的阅读了这篇论文，他们会发现其中没有与敏捷（或敏捷，如果你愿意的话）不兼容的地方。真的是必读。作为另一篇经典论文，Parnas 和 Clements “一个理性的设计过程，如何以及为什么要伪造它”。

评论6：

瀑布一直占主导地位，并且系统地未能创造价值。 瀑布和敏捷之间的核心区别在于，在前者中，问题解决和解决方案实施由不同的人完成，而在后者中，两者都由团队共同执行，利用跨职能技能。 这就是为什么功能团队不是敏捷，而是具有肤浅敏捷构成的瀑布（冲刺、每日站立，...）。 这就是为什么功能团队不是结果而是输出驱动的原因。

评论7：

我认为这里的答案是更加敏捷。 后端和前端开发人员？ 那是一种反模式。 创建一个团队并给他们解决问题。 为解决方案创建验收标准，让团队与客户交谈。 并为团队提供学习他们缺乏的技能所需的资源。
而且，顺便说一句，瀑布从未起作用，并且在首先讨论瀑布的论文中被描述为一种反模式......

原文：https://medium.com/@marcel_paschoal/agile-is-dead-waterfall-is-coming-b…

本文：https://jiagoushi.pro/node/1997

前几天，当我在思考为什么许多大型组织看到他们的许多IT计划失败或成绩不佳时，我想出了一个相当简单的结论：“项目思考”是这些失望的根本原因。让我解释。

项目方法背后的基本原则是每个项目都有明确的目标，固定的预算，开始，交付日期和具体结果。这种方法的一个重要原因是它通过控制幻觉给管理层一种治理感：他们认为他们一开始就知道他们最终会得到什么，他们可以通过观察支出衡量进展，他们可以大喊大叫当事情出错时，有人（即项目经理）。由于项目是临时的，因此生产线管理层不负责任。他们可以推迟（并责备）计划和项目经理，让他们自己做出决定。

项目方法也存在各种其他缺点：需要熟悉问题和解决方案空间的新团队;管理层坚持像Prince2这样的方法（因为它们是'行业标准的最佳实践'）而强制执行的官僚机构;这些方法所需的起停时刻，可以中断进度并减缓项目进度;建立功能只是因为它们在项目计划中，而不是因为它们实际上是需要的，等等。

而且，这种方法仅在静态情况下起作用（如果勉强）。在当今复杂多变的环境中，项目的客户往往无法明确说明他们想要什么或需要什么（“当我看到它时，我就知道了”）。即使（他们认为）他们可以，这些目标甚至在项目开始之前就开始转变。经典项目管理将这种“范围蔓延”视为对项目成功的威胁。作为一种反应，项目经理通过建筑墙壁来捍卫其范围，不包括重要要求和相关的外部影响。因此，用户满意度是无法实现的，并且保证了失败。

范围

更糟糕的是，这个范围本身通常被定义得过于宽泛。在没有适当分离关注点的情况下，通过构建一个巨大的“应用程序”或“系统”来定义应该解决业务或政府问题的项目。除了技术乐观主义的谬论之外，我将在另一个时间讨论这种方法，即使这个大型拼图的一小部分不适合，这种方法也会失败。如果你定义怪物项目，项目怪物会吞噬你......

最后，有一个想法是IT项目有一个“交付”的时刻，当结果完成并准备好使用时。众所周知，大型组织80％以上的IT支出都是“维护”;一个混乱的概念，因为这通常意味着添加新功能，那么这与“开发”有何不同？

前进的方向

我们应该停止将变更视为例外，由“正常”操作之外的项目和程序处理。 “新常态”中的组织处于不断变化的状态。正如Gartner所述（主题演讲ITXpo 2013）：

“2017年，每家公司都将成为一家数字公司。能够迅速改变并保持敏捷的能力势在必行。“

我们需要对IT和业务能力和资源的整个生命周期采取更全面的方法，从而消除“构建”和“维护”之间的这种人为区分。应将业务和IT环境视为一系列元素，每个元素都有自己的业务价值，生命周期和节奏。我们可以根据预期和测量的业务价值为这些功能和资源分配和重新分配预算。通过匹配他们的节奏并流畅地对外部影响做出反应，我们可以创建更灵活的组织，使其与周围环境保持一致。

敏捷运动中的各种实践都是朝着这个方向迈出的步伐。与客户密切互动的短暂迭代，使用DevOps实践的持续交付，以及Google，Netflix和Spotify等公司的“始终处于测试阶段”的方法就是这样的例子。像Lean和Kaizen这样的管理方法也采取了这种持续改进和生命周期的立场。诸如Scaled Agile Framework等方法所采用的“价值流”概念也是朝着正确方向迈出的重要一步。

我们提倡使用企业架构作为知识中心，以连接组织变更所涉及的各个学科。企业架构可帮助您集成和共享组织中各种结构的信息。它为您提供相关输入，用于确定转换的优先级和规划。它为您提供跨价值流的程序级协调，以一致的方式实现这些变化。它可以帮助您跟踪预期收益的实现，从而在必要时纠正您的课程。与此密切相关的是，企业组合管理使您能够采用基于价值的方法来管理资产并更改组织中的计划。这有助于使一切与所需的业务成果保持一致，当然应该将重点放在客户或公民身上。

具有前瞻性的首席执行官和首席信息官开始以不同的方式思考组织和管理组织能力的演变。在过去几年中，我与政府，银行和保险组织的几位经理谈过，他们意识到需要一种新的工作方式。他们正在建立基于这样的价值流，生命周期和持续交付方法的变革能力，专注于开发和发展业务能力组合。让我们希望其他组织能够效仿他们的榜样，摆脱项目怪物的困境。在BiZZdesign，我们很乐意帮助客户建立这样的业务转型能力。

原文：https://bizzdesign.com/blog/escaping-the-jaws-of-the-project-monster/

本文：http://pub.intelligentx.net/project-management-escaping-jaws-project-monster

讨论：加入知识星球或者小红圈【首席架构师圈】