开发之乱 -- 变化（2）

开发之乱 -- 变化2（开发流程）

 

 

      软件开发的流程模式自1970年经典瀑布模式[1]问世以来学术界以及工业界又提出了许多模式：迭代

模式、极限编程模式、测试驱动模式以及敏捷开发模式等等[2]。其本质目的是为了适应并减少变化，从

而使得整个开发流程能够稳定并在预期内完成软件开发。可惜至今也没有一个放之四海而皆准的开发模式
，不同的公司开发不同的项目可能会采用不同的软件开发模式。毕竟需求不一样，人员不一样，预期进度
也不一样，在众多的模式中兼容并包，找到适应自己团队的，这才是最重要的，没有绝对好的，适合自己
的才是最好的。

 

     团队采用的软件开发流程也不是一成不变，需要随着环境变化而作调整。当年SaaS项目刚才美国转移
过来时，整个团队才6、7个人，但是整个公司采用瀑布模式已经十多年了，照搬公司成熟的开发模式又不
是很合适。SaaS需要快速响应市场的需求，如果采用瀑布模式发布一个版本至少需要11个月，黄花菜等的
都凉了。因此采用了敏捷开发模式，将所有市场需求列表排序，先实现比较容易实现开发时间比较少的。
将团队分成若干个小团队，并行开发若干功能。每天早上花15分钟开会：每人总结昨天的任务结果以及简
单描述今天的任务。开发人员撰写的文档尽量简洁，开发人员跟测试人员沟通方式以口头或者白板为主。
每个季度发布若干个功能。这种方式及其依赖于团队成员的能力，团队成员具有高度自主权，需要快速选
择方案解决问题，需要紧密沟通合作，高度弹性的解决各种问题。例如：文档要简单到什么程度？测试要
进行到什么粒度？最终发布的功能质量如何？

    随着团队规模的增加，从6、7人增加到15、16人，发现采用上述敏捷开发模式不像以前那么适用了，
人太多了，日会所花费的时间太多了；文档太简洁了或者跟代码已经不一致了，熟悉维护代码也比以前麻
烦了；每个人对功能的认识不太一样，测试发现的缺陷增多了；功能太复杂了，没办法切割成小块，需要
若干季度才能开发完成。因此我们又借鉴了瀑布模式中的优点，把功能需求都文档化确定后，使得所有开
发人员对功能有统一认识；又借鉴了成对编程实践，一个写，一个看，review时候让看的人主讲；取消大
的日会，每个小团队自己内部开日会，每个小团队有高度自主权等等。这样改变后，开发又趋于稳定。

   白猫、黑猫，只要捉住老鼠就是好猫。不要盲从开发模式，要借鉴式的选择适合自己团队的开发模式。



附注：
  [1] Royce, Winston (1970), "Managing the Development of Large Software Systems",
Proceedings of IEEE WESCON 26 (August): 1-9。
  [2] http://en.wikipedia.org/wiki/Software_development_process