软件开发模型-瀑布模型，V模型和敏捷管理

在项⽬管理的培训课程上，培训的资料上提到了这三种模型，加上同事的分享和我⾃⼰在⼯作中的⼀点体会，做⼀个简单的分析和总结。

瀑布模型顾名思义是软件开发的过程就像瀑布⼀样从上到下⼀泻千⾥，不可回溯。软件开发过程严格按照计划，设计，开发，测试和发布的流程进⾏。在设计阶段不可以再去修改计划阶段产出的东西，以此类推。这种模型要求每⼀个阶段要完成的⼯作⼀定是完整的，⽽且是没有任何错误的，例如计划阶段的需求⽂档⼀定是完善的。每个阶段还必须严格按照之前规定的时间点结束掉，⼀旦延迟就会影响到下⼀个阶段的进度。质量和时间的苛刻要求极⼤地增加了项⽬失败的风险。我曾经经历的⼀个项⽬差不多是按照瀑布模型开发的，在设计阶段，UI图出了⼀版⼜⼀版，客户⼀直不太满意，⽽且还要等到所有UI图全部出完，才能进⼊到开发阶段。项⽬的周期是6六个⽉，等到设计交付的时候三个⽉已经过去了，结果就是开发⼈员没⽇没夜拼命的赶进度，最后仍然是延期交付。我个⼈认为瀑布模型就是⼀种理想化的模型，在项⽬过程中不可能严格执⾏。

我之前也听说过V模型，但是体会不深。培训中讲到所谓的V是三个V。第⼀个V，在项⽬的每⼀个阶段都会对应⼀个测试阶段，例如计划阶段对应着测试的计划阶段，这个阶段出的测试相关⽂档包含整个测试计划，测试标准，⼈员分配和UAT的设计。到了设计阶段也对应测试的设计阶段，这个阶段出的⽂档包含SIT的计划，SIT的测试⽤例，如果更完善的的话，随着详细设计的完成，所有的Test Case都会在这个阶段完成。第⼆个V是Verification，是⼀个⾃我校验的过程，其实是测试驱动完成的过程，例如在编写UAT测试时发现有⼀个流程是遗漏的，这时再去完善项⽬的需求规格说明书。第三个V是

Validation，是下⼀个阶段对上⼀个阶段的有效性验证的过程，例如在设计阶段发现有⼀个功能点是多余的，这是需要修改计划阶段的需求规格说明书。我的⼀个同事在⼀个很⼤的⾦融平台的项⽬上，他提到这个项⽬基本上是按照V模型进⾏的，⽽且效果很好。因为我没有⽤过这种模型，所以不知道它还有什么缺点。

敏捷管理是这两年特别⽕的项⽬管理的模型，好像⼀下⼦⼤家都在热衷于它。我有幸参与了⼀个敏捷管理的项⽬。曾经不⽌⼀个⼈和我说，敏捷管理只适合周期⽐较短的⼩项⽬，因为它的⽬的就是要快速上线。我想⽤事实说敏捷管理的项⽬周期也可以很长，⽐如我⾃⼰的项⽬就持续了20个⽉。敏捷管理的⽬的严格上来讲不是为了快速上线，⽽是为了快速交付。⾄于交付的东西是否⼀定要马上上线，这不⼀定的，例如⼀个⽉作为⼀个迭代周期，因此每个⽉都会交付⼀部分功能给客户，并且要客户签字验收，但并不是每个⽉客户都会去上线，客户仍然是等到迭代了⼏个周期后，功能⽐较完善了才会上线。既然是⼏个周期之后才上线，为什么要⽤敏捷呢，原因就是要让客户看到已经完成的部分功能，让他去感受体验已有的功能，UI和性能等等。如果有问题，他会在这个周期提出来，重新整理成需求，然后在接下来的周期再完善，这就是敏捷中说的持续改进的过程。敏捷管理现在⽐较流⾏的是scrum。scrum中⼀个很重要的理念是项⽬成员都积极开⼼的去领取任务并且完成，但是这个真的很难。怎么做到让⾃⼰的项⽬成员都变成⾼效者，这真是⼀门学问，这也是我⽬前在积极探索的问题。等我找到⽅法论，会再进⾏分享。