软件项目的生命周期管理, 从上个世纪八九十年代时以瀑布为主流,
到01 年时敏捷宣言的提出后, 敏捷软件开发变得如火如荼.
也许很多人认为, 瀑布已经过时, 应该被淘汰出局, 我们应该全面的拥抱敏捷. 但现实中, 依然有很多公司采用的是瀑布或者部分敏捷的模式. 正如软件行业的警示名言没有银弹, 我们应该在合适的场景下, 选择适合当前项目的方法.
作为系列的开篇, 简要介绍一下三种生命周期模型.
1. 瀑布模型(Waterfall)
- 一系列的开发阶段.
-
需求(Requirement), 设计(Design), 开发(Development), 测试(Testing), 维护(Maintenance).
Paste_Image.png
-
- 每个阶段都有清晰定义的交付(deliverables).
- 例如, 软件需求规格书, 基本设计, 详细设计, 代码等等.
2. 迭代模型(Iterative,Incremental)
�迭代模式
- 递增式地构建系统, 从基本功能开始, 逐渐地添加新功能, 直至整个系统完成.
- 面对新需求和需求变更, 能够获得更大的灵活性.
- 之前迭代中获取的经验, 可以在下个迭代中�应用.
3. 敏捷(Agile)
敏捷
- 将交付周期从月减到周. 每个阶段都有交付.
- 敏捷的主要关注点:
- 保持代码简单.
- 频繁测试.
- 尽快地交付软件的功能单元.
4. 个人认为的敏捷产生的意义
- 使用瀑布模型时, 我们的终端用户, 只有在最终阶段完成之后, 才能看到产品.
- 这可能已经是开发了几年的产品.
- 客户在项目开始时的需求, 可能在此时已经发生了变化.
- 作为一个人来说,
他想象中他想要的, 跟他实际想要的, 很可能完全不是一回事. - 当客户看到了成品后, �最经常说的话可能就是,
啊, 我并不想要这个啊.
- 作为一个人来说,
- 一个规模较大的软件, 应对需求变更的灵活性是较差的.
- 此时对任何需求变更的对应, 都需要很多的工时.
- 敏捷最重要的意义, 是缩短了反馈周期.
- 敏捷要求我们频繁的交付可见的功能给用户.
-
面对真实的产品, 用户能够尽早的验证和矫正自己想象中的需求.- 而此时, 软件对应需求变更的灵活性是很强的.
5. 选择
- 需求的稳定性.
- 如果软件的需求是有清晰定义的, 比如会计软件, 需求是有法律明确规定的. 是可以选择瀑布模型的.
- 如果是互联网产品, 可能自己对项目的最终形态都不太清晰, 需要不停地得到用户的反馈, 然后矫正自己的方向. 这就是敏捷最适合的场景了.
- 终端用户是集中的还是分散的.
- 针对集中的用户, 是比较容易采集和汇总他们的需求的. 所以瀑布模型也是可以展开的.
- time-line是�保守的还是激进的.
- 保守的time-line, 由于有清晰定义的边界, 瀑布模型还是可以展开的.
- 项目的规模
- 大规模的项目需要多个team 协同工作, 所以需要清晰定义的交付. 此时还是推荐使用瀑布的.
- 项目组的物理分布
- 敏捷需要频繁的密切交流. 至少也要有通信工具保证大家能够实时的交流.
- 瀑布提供了清晰的交付和里程碑.
- �关键资源.
- 有些项目需要一些特殊的资源, 例如有金融专业知识的测试人员.
- 而这些资源通常是不能在被需要的时候就能立马得到的.
- 瀑布模型能够更好的对应这种情况.
- 在进入下一个阶段时, 每一个里程碑都已经被满足.
