从瀑布到敏捷(1): Project Lifecycle

软件项目的生命周期管理, 从上个世纪八九十年代时以瀑布为主流,
到01 年时敏捷宣言的提出后, 敏捷软件开发变得如火如荼.

也许很多人认为, 瀑布已经过时, 应该被淘汰出局, 我们应该全面的拥抱敏捷. 但现实中, 依然有很多公司采用的是瀑布或者部分敏捷的模式. 正如软件行业的警示名言没有银弹, 我们应该在合适的场景下, 选择适合当前项目的方法.

作为系列的开篇, 简要介绍一下三种生命周期模型.

1. 瀑布模型(Waterfall)

• 一系列的开发阶段.

  • 需求(Requirement), 设计(Design), 开发(Development), 测试(Testing), 维护(Maintenance).

    
    
    

    Paste_Image.png
• 每个阶段都有清晰定义的交付(deliverables).
  • 例如, 软件需求规格书, 基本设计, 详细设计, 代码等等.

2. 迭代模型(Iterative,Incremental)

�迭代模式

• 递增式地构建系统, 从基本功能开始, 逐渐地添加新功能, 直至整个系统完成.
• 面对新需求和需求变更, 能够获得更大的灵活性.
• 之前迭代中获取的经验, 可以在下个迭代中�应用.

3. 敏捷(Agile)

敏捷

• 将交付周期从月减到周. 每个阶段都有交付.
• 敏捷的主要关注点:
  • 保持代码简单.
  • 频繁测试.
  • 尽快地交付软件的功能单元.

4. 个人认为的敏捷产生的意义

• 使用瀑布模型时, 我们的终端用户, 只有在最终阶段完成之后, 才能看到产品.
  • 这可能已经是开发了几年的产品.
  • 客户在项目开始时的需求, 可能在此时已经发生了变化.
    • 作为一个人来说, 他想象中他想要的, 跟他实际想要的, 很可能完全不是一回事.
    • 当客户看到了成品后, �最经常说的话可能就是, 啊, 我并不想要这个啊.
  • 一个规模较大的软件, 应对需求变更的灵活性是较差的.
    • 此时对任何需求变更的对应, 都需要很多的工时.
• 敏捷最重要的意义, 是缩短了反馈周期.
  • 敏捷要求我们频繁的交付可见的功能给用户.
  • 面对真实的产品, 用户能够尽早的验证和矫正自己想象中的需求.
    • 而此时, 软件对应需求变更的灵活性是很强的.

5. 选择

• 需求的稳定性.
  • 如果软件的需求是有清晰定义的, 比如会计软件, 需求是有法律明确规定的. 是可以选择瀑布模型的.
  • 如果是互联网产品, 可能自己对项目的最终形态都不太清晰, 需要不停地得到用户的反馈, 然后矫正自己的方向. 这就是敏捷最适合的场景了.
• 终端用户是集中的还是分散的.
  • 针对集中的用户, 是比较容易采集和汇总他们的需求的. 所以瀑布模型也是可以展开的.
• time-line是�保守的还是激进的.
  • 保守的time-line, 由于有清晰定义的边界, 瀑布模型还是可以展开的.
• 项目的规模
  • 大规模的项目需要多个team 协同工作, 所以需要清晰定义的交付. 此时还是推荐使用瀑布的.
• 项目组的物理分布
  • 敏捷需要频繁的密切交流. 至少也要有通信工具保证大家能够实时的交流.
  • 瀑布提供了清晰的交付和里程碑.
• �关键资源.
  • 有些项目需要一些特殊的资源, 例如有金融专业知识的测试人员.
  • 而这些资源通常是不能在被需要的时候就能立马得到的.
  • 瀑布模型能够更好的对应这种情况.
    • 在进入下一个阶段时, 每一个里程碑都已经被满足.