敏捷式vs.瀑布式：都需要经常，细致的交互

团队和利益相关者之间需要经常并且细致的交互。建立互信，人们之间维持开放并且忠诚的关系非常重要。这样的氛围使得沟通更为有效，帮助大家构建对于正确需求的一致理解。

对于我来说，价值比费用更重要。如果你知道哪一个需求最为重要，那么开发它所需的成本反而不那么要紧。对价值的理解也会激励大家，帮助大家关注于持续选择并开发正确的需求。

使用敏捷项目框架，比如scrum、XP、SAFe或者LeSS并不会自动保证项目的成功。需要以适合项目需求的方式使用这些框架。选择合适的方式，在工作方法上达成一致。不用太担心项目一开始时达不到完美，反思之类的活动会帮助大家持续学习并在过程中不断改进。 2100433B

需求阶段通常定义系统的需求，明白系统的目标。

设计阶段通常确定系统使用什么数据库，系统模块的划分，各个模块的功能。

编码阶段用编程语言对设计阶段的实现。

测试阶段分黑盒测试，白盒测试。测试系统的功能是否实现，是否准确。

维护阶段是根据用户新的需要重新修改系统，使系统更加稳定，更符合用户的要求。

需求阶段的工作是否到位是整个系统开发的关键，在需求阶段有很多方式可以帮助自己完成工作，例如与客户畅所欲言，跟随客户参与业务过程等等。不管任何一种方法，任何一种方式，在需求阶段首先确定系统边界，确定组织边界，然后摸清企业为消费者创造的价值，看清企业的价值链，摸清价值链上的实体。最后要平衡价值链上各个实体之间的利益，争取系统做到大家都满意这个理想的状态。

瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。

瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。

有论文统计他是造成70%软件开发失败的原因。

大体分为这几个阶段：需求分析、设计、编码、测试、维护。

瀑布开发也有一些缺点，但是，在你初履新职，刚刚接手管理一个新的团队，同时获得了一种支持瀑布开发模式的解决方案的情况下，这种开发模式可以令你很快进入角色把工作开展起来，从而为将来采用更高级的开发方式做好了准备。

瀑布开发过程在政府项目中特别受到欢迎，在这样的软件开发项目中，其规划阶段超出了大多数企业部署阶段的时间和力度。采用这种方式的其他用户包括那些理解比较全面和深入的软件项目，相关的解决方案对团队而言非常熟悉，或者只需要小小的改动。

瀑布开发方式的缺点也是明显的。如果期间的每一阶段没有得到坚决贯彻和实现，那么隐藏的问题最终会影响项目的成功。虽然瀑布管理方式对项目经理而言非常方便，但是对开发人员而言就可能显得太严酷了。因为测试过程在开发阶段之后实施，子系统测试所暴露的问题可能需要立即修改代码，这样就显著增加了计划架构的成本。

调试过程可能非常复杂，原因在于，开发人员在同一阶段通常还可以从事其他项目的开发工作，而所需要的软件修改可能会降低开发人员的生产率和工作质量。有时工作区还必须集中到一个地方来，从而威胁到解决方案的完整性。

另一可能的危险是你只有到解决方案启动的时候才能知道当初所预计的是否成功，所以余下用来改正问题的时间和空间都非常有限。而设计工作上的疏漏和缺陷可能会严重地影响解决方案的启动日期。

这种模式的另一问题在于，除了到阶段终止之时，其他时候几乎没有获取反馈的时间，还有，一旦开发工作开始启动那么修改的空间也就没有了。最后，假如系统测试表面功能或者性能没有达到要求也许到这个时候已经没有纠正问题的可能了。

在部署瀑布开发模式之前你必须仔细评估自己所处的环境和条件。如果客户希望在开发工作开始之后加入进来或者你要处理很多未知的问题，那么你或许最好采用一种更具重复性的开发过程。2100433B

瀑布开发也被称作系统开发生命期模式，简称SDLC（Systems Development Lifecycle Model），这是一种软件开发途径，它把项目分解为有限的阶段。每一个阶段都有序执行，并且依赖于先前已完成的阶段。在采用瀑布开发方法的情况下，开发工作的各个部分必须分别评估，而且通常由不同的开发队伍来实施。具体开发阶段的划分存在一定的争议，但各个阶段基本上取决于任务相对繁重的预先规划。以下就是瀑布开发过程的常见阶段划分：

问题评估—也就是概念形成阶段。明确现有解决方案所存在的问题同时收集相关信息。

计划解决方案—提出解决方案的详细说明，包括软件的优点和缺点以及试图解决的问题。确定开发时序，工作结构分解以及其他支持文档。最重要的是明确和分析软件需求。

设计系统架构—提案获得接受之后即可创建解决方案模式，包括工作流和数据流图、模块和功能层次已经其他由解决方案所需要的说明。在这一阶段通常总是伴随一个有力度的检查过程。

开发代码—用以上阶段创建的蓝图编写、调试和单元测试软件代码。接着，集成系统的代码和测试部分。最后测试整个系统。该阶段要到测试完全通过才能结束。

部署和使用系统—部署最终功能，同时向用户提供所需的培训和文档。

维护解决方案—在必要的时候指出和升级软件并且修补软件错误。

有时测试会成为单独的一个阶段，其中包括软件调试而不是在开发阶段进行代码调试。此外，获取软件需求也可能成为独立的阶段。无论采取怎么样的开发路线，以上过程都是一次实施的，同时还要整合到整个解决方案中来。