爱华网第二部分：浅析项目开发模式：瀑布VS.敏捷
一、项目背景
这里要分析的案例项目是某网络公司的一个真实项目，简称为B项目。B项目是做一款WEB应用产品，目标用户是某一特定范围的网民，具有相似的爱好、某一年龄段、具备相似的关注点和生活习惯等。下面，简单介绍一下项目相关的情况：
项目人员组成：9人，其中，
项目经理1人，负责整个项目的规划与执行；
产品工程师1人，负责产品定义，需求收集与分析，页面以及美工设计；
研发工程师4人，负责技术选型，完成系统设计以及具体的开发工作；
测试工程师3人，设计测试用例，执行测试任务，负责产品的质量保证工作。
二、B项目遇到的问题
这个项目有一个比较复杂的客观情况，也可以说是难点吧。那就是：这是一个新产品开发，受众面较大，用户的想法和需求很难预先获得，或者说用户可能也说不清楚哪些是他需要的或者喜欢的，产品到底是不是真的满足客户需求的事先评估再怎么做也做不到最准确。这种困扰，在很多软件开发项目中都存在。其实，用户只是有个方向，大致的想法，具体是什么样的，怎么操作比较顺手，这些细节都是模糊的，含混不清的。这种情况，就必然会导致，事前集中花时间想把需求不完整、清楚，然后lockdown，这是不可能的。变更是必须的，客观存在的。完整，清楚，更不用提，做不到。提前花整块的时间来做需求，是不现实的。
如果按照惯例，采用瀑布式开发流程的话，那么，需求不清，变更频繁对后续的开发测试工作有什么影响呢？
瀑布式开发模式，各个阶段划分得非常清晰，需求->设计->编码->测试–>发布，一般周期都比较长。如果，想让各阶段按部就班地进行，那这个项目计划就无比地复杂，要全面，要具体。项目成员不断地开发出新模块，最后都齐活了才进行整体集成，将各个工程师所写的编码整合到一起，预测整体系统的行为，包括可靠性和性能等。如果需求发生变化，意味着什么？调整计划，要花费几倍的精力，来调整计划以及后续所有阶段的工作。很可能之前所做的工作会被废弃，架构也要调整，导致大量的重复工作。这种浪费对于项目来说是致命的，时间紧迫了，项目的节奏被打散了，很可能到了截止日期却拿不出可用的产品，项目只好延期。
新产品研发，需求不甚清晰，这种情况下，划分需求阶段的做法是没有意义的。显然，瀑布式开发模式不太适合的。
三、B项目的解决方案
那怎么办呢？这个项目是怎么做得呢？
引入需求池，拥抱变化，迭代式开发，快速应对变化。需求不是不能提前做到完整、清晰嘛，好，那就分为短期和长期两部分。长期表示前进的方向，宏伟的目标，这是确定的而且基本不会变化的。短期目标，就是在目前掌握信息的水平上想清楚多少就完成多少用户需求。这些想好的，确定的，明确的需求不断地放入需求池中。研发工程师，就从这些已经确定的需求中不断地取出需求，设计，编码，测试，产出。产品工程师拿到产出进行评估，各种范围的评估，甚至拿给部分用户进行评估。然后得到反馈，就这样，不断地边做边想便评估，不清楚的需求自然就慢慢变得清晰起来，又可以纳入到需求池中，作为下一次的迭代的目标。
我们来看这个变化，需求管理方式的变化导致项目开发流程也发生了变化：如果想快速的推出 产品给产品工程师评估，就要尽量的并行工作，减少串行，缩短bug反馈和修复的时间间隔，那么研发工程师和测试工程师就不能像瀑布式一样，严格的串行。研发工程师交给测试工程师的就不能是一个琐碎的零件，而应该是端到端的可见的功能，用户使用的一个功能。再往前推，那产品工程师提出的需求就不能是零件，而应该是一个feature，而且要足够的小，最好是1天之内的工作量。根据B项目成员的能力水平，这个迭代周期，他们选择了2周，2周给出一个评估版本。
很显然，B项目采用了敏捷开发的模式。
四、敏捷模式和瀑布式有何区别
瀑布式开发模型分为若干阶段：需求分析、系统设计、编码和单元测试、系统集成，以及运行和维护等几个基本阶段。瀑布模型做了4个主要假设：
如果我们花时间来理解的话，存在着一套定义相当明确的需求
在开发过程中，需求的变化非常小，使我们能够应付，而不用重新构思或者修改我们的计划
系统集成是一个适当且必要的过程，我们能够在架构和计划的基础上合理地预测系统集成的运行情况
创建一个大型的新软件应用程序所需要的软件创新和研发工作，是可以按照预先制定的时间表进行的
但是，很遗憾，现实情况表明这4个假设都是错误的，很难站得住脚的。
假设1，已经在B项目中被证实是不存在的了。即使是在最擅长的行业领域，客户想法的变化，独特化，都是没有办法保证需求是可以一下子就全面到位的。
假设2，确定需求和交付系统之间的时间间隔越长，变化也就越多。如果开发速度很慢而变化发生的太快，那情况就很糟了。
假设3，系统集成会顺利进行？别开玩笑了，这个假设的前提是，只要进行适当的计划和分析，我们就可以预测复杂系统那个的所有组件系统工作的情况。现实情况，告诉我们，前期所有的分析，既不能预知也不能控制系统集成的过程。问题过于复杂，变化不断发生；项目进行期间技术不断革新；关于集成的假设都是错误的，并且发现错误时已经为时太晚。
假设4，计划其实是一种预测，只能反映预测的精确程度，但并不见得能够反映实际情况，尤其是超大的计划。超出4周，就基本上是胡说了，变化太快。
其实，不是瀑布式模型概念错误了，而是从瀑布式模式被提出到现在这30多年来，我们都错误的理解瀑布式模型。其实，瀑布式模型的应用是有前提条件的。Royce在1970年发表的《管理大型软件系统的开发》中，提到：这个模型建议在关键的原型阶段之后应用，在原型阶段首先要充分的理解所要应用的关键技术以及客户的实际需求。
瀑布式开发模式想得很美好，但是，在残酷的现实面前，却因为缺乏灵活性，适应性不佳而渐渐被放弃。与此同时，业界不断探寻适合软件项目的开发模式，其中，敏捷软件开发模式越来越得到大家的关注和采用。接下来，让我们看看有何不同。
图二敏捷颠覆了瀑布模式的传统假设
图二显示，瀑布模式倾向于需求（功能）而不是评估资源和日期（成本和日程）。在敏捷中，假设是不同的：日期和资源是固定的，因此，为了满足日期的要求，需求必定是可变的。这是敏捷的关键原则：任何事情都安排在时间盒内完成。这条原则迫使团队筛选最高优先级的需求，首先交付最高客户价值的条目。同时，这条原则迫使团队承认，我们不知道什么时候交付什么，仅知道哪个时间段。
在概念上，敏捷是简单的，但是却改变了大多数事情。
图三敏捷带来的变化
![软件项目管理论文[转载] 软件项目进度管理论文](http://img.aihuau.com/images/01111101/01061036t0144f229d5e2ae527d.jpg)
图三通过对比的方式描述了敏捷带来的变化，可以说这些变化都是颠覆瀑布模式的。
敏捷让团队和组织从遵循计划发展到能够响应变化。这是从传统的工作分解结构到基于优先级实现故事和需求的“以交付价值为中心”的转变。最重要的就是可执行的、经过测试的并可以使用的代码。计划是灵活的，可以调整。实际交付是在当时情况下能够达到的最好情况。实际交付可以发布。
瀑布模式下，管理固定了范畴、期限和资源，并且为团队明确了技术方向，同时也为团队的效率负责。在敏捷方法中，正好相反。管理指明方向，团队竞标，并计划如何在规定的时间框架内完成尽可能多的工作。为了实现目标，团队必须有自我组织的能力。团队制定技术决策，并根据需要在执行中纠正。
敏捷模式下，管理工作是排除组织内的干扰，信任团队能够实现目标。团队完全负责交付产品，并且负责满足时间期限和交付质量。其实随着所看到的工作进展，每个迭代不断交付的产品，这种信任感不断增加。
在敏捷方法中，团队不用投入几个月来构建详细的软件需求规范、架构模型。团队的注意力集中在尽早交付科技城的有价值的需求模块。尽早交付有助于测试，证实对于需求和架构的假设，来避免风险。如果软件不可用，团队就需要重新调整，直到可用。这种方法增加了用户的可视化，甚至用户可以在团队工作环境中配置或评估迭代的产出，允许用户的持续反馈。管理和用户不必再一边祈祷团队能够做出正确的东西，一边默默地等上几个月。
编码方式是不同的。在瀑布模式下，开发人员对所有的功能同时编码，最后产生一个大的，完全的软件包。而在敏捷模式下，整个团队首先集中精力解决最早、最明确、最高优先级的功能。持续地集成，不延缓测试。仅生成一种代码：测试过的、工作良好的、及成果的代码。反馈及时并且持续，每个队员都知道，为了实现迭代的目标，每天应该在什么位置，完成什么事情。
敏捷模式下，对测试组织的影响是实质性的。测试不再是生命周期的一个阶段，而是持续的行为。测试人员不在测试没有经过测试的大块代码，而是测试系统，包括已经完成的单元代码和经过准入测试的代码。这种转变，要求项目组必须开展代码集成和自动化测试。测试水平随着测试者参与技术决策以及测试自动化的开发而得到增强。测试人员不再是纯手工的测试执行者。而是水平提高，等同于研发人员。
规划并没有在敏捷模式中消失，实际上，应用得更加充分了。在两个层次上都要做规划：为产品发布制定整体计划，为迭代制定的细致规划。根据迭代的推进，规划也是滚动式的进行，在开发过程中不仅制定一次规划，在每次发布和迭代的前期都要进行规划。规划不再是粗略的和即兴的，变成了系统和常规。
规划被极大地简化，每次都是在提前知道确定日期的情况，再来筛选feature的。追踪也变得简单，每天的站会和平凡的演示显示出实际的项目进展。计划和实际之间不再隔着深深地鸿沟。
上文我们提到过：日期和范畴相比，总是优先考虑日期。更确切地说，迭代长度决定开发范畴，而不是范畴决定开发周期的长度。在计划驱动的的方法中，范围决定时间，范围和时间在每个规划周期和每次重大变化中都会发生改变。由于敏捷模式下，固定时间，并根据时间来定义范围，所以，团队能够自由的根据需要进行，将注意力持续集中在到期需要完成的任务上。即使因为某些原因，交付的结果缺少有效的功能而成为未完成的任务，那么也不用担心，因为，下一次迭代仅需要两周时间，一个月或者两个月之后的下一次发布将是可用的。
敏捷崇尚时间盒内创建小块的可工作的代码。软件项目大多饱受需求不清，变化太快，就像B项目一样。但是，又没有足够的能力把敏捷方法一次性的投入到开发流程中，那就从时间盒入手吧。这是敏捷模式的重要动力。当团队掌握这个技巧后，自然就会带来敏捷方法集中的其他特征和办法。
以上来自百度文库
