读“大教堂与集市”有感

    有些经典的书，越早读越好，能够帮你少走弯路；当然读的晚了，也没关系，可以帮助你一起梳理过往的经验，再次成长。最近刚看完的“大教堂与集市”，就是这样的一本书，读的有点晚了。

    这本书很多地方都提到了这两本书我读过，所以也就着这个机会，又重温了一些经典片段。这本书主要是探讨了开源文化的来源，本质，以及开源模式对软件开发的影响。整本书由几篇文章组成，最核心的还是“大教堂与集市”这篇。文章讨论在软件不断发展的过程中，对比传统项目管理模式下主导的软件开发，开源管理模式的优势在哪里？

    传统项目管理一般采取的瀑布式开发流程：需求分析 -> 系统设计 -> 编码测试 -> 上线优化等几个阶段。上一个阶段结束时，则下一个阶段开始，每个阶段切换时，一般都是这个项目的一个里程碑事件，并且有很多的交付输出物，例如文档，会议纪要，各种图示等。每个阶段有不同的部门参与，每个部门对自己所参与的阶段和交付输出物负责。在这种项目管理模式下，软件的开发人员责任心不高，为代码做出的设计努力很容易被忽视：因为编码仅仅只是一个小小项目阶段，程序员在整个项目的贡献占比太低，很少有机会给程序员表达自己对整个项目的看法；与此同时，其他人员也很难评价程序员最终的实现效果，因为只能到最后的测试阶段，通过几次(操作，性能)测试bug报告来反馈给程序员，而一般到这个时候项目工期都比较紧张了，如果出现比较大的问题，也很难调整，从而导致项目失败的风险激增。

    开源项目组织没有严格的阶段区分，管理比较松散。从项目建立起，系统的代码输出物就一直是公开的，任何项目的相干人都可以直接(针对源码)提出自己的疑问。项目的设计目标是一步步被实现的，用户可以随时获取一个可以使用的版本。每次新版本的发布都会包含对上个版本的bug修复和新功能的实现，让用户能够时时刻刻的感受到自己对整个软件的影响。这种组织模式下，程序员一开始就参与到了项目的进程中，而且从头至尾，都占据了比较重要的位置，程序员的能力会被激发出来，责任心会增强；而用户由于从项目一开始就能够看到代码的实现效果，那么从某种意义上说，也是参与到了编码过程中，bug提出会比较及时，减少了项目重大问题出现几率，也降低了项目失败的风险。

    一般软件公司自己开发商业产品，或者是承担某些甲方公司软件项目的开发，让这些代码拿出来开源，估计不可能，也没有必要。那么开源模式是否能够针对这些软件开发提供一些新的管理思路呢？我个人的看法是，肯定是可以，而且作用很大。

    1、让系统架构师和1-2个高级程序员从一开始就加入项目初始阶段。因为这些程序员都比较有经验，他能够根据自己的过往项目经验判断出，哪些是可以使用原有的代码，哪些是需要重新开放。这些东西其实也是某种意义上的‘传承’。而且这些内容是只有一线的代码程序员能够提供，那些‘高高在上的’管理者，架构师，以及业务需求人员是没有办法给出真实意见的。这些对项目风险评估是第一手资料。

    2、在系统设计阶段，就开始编码，实现项目原型，用以佐证系统设计是否符合需求方向。

    3、按照1-2周的版本迭代周期，发布功能实施线路图。这种模式可以验证系统的设计是否具有很好的扩展性。业务人员每次新周期开始时，需要提供功能实现意图，以及功能测试用例。测试人员总结上个版本测试用例的实施情况，以及评估新周期的测试用例。程序员总结版本bug修复情况，以及新功能开发意见。

    4、每2-4个迭代周期做一次非功能测试和系统集成测试。

    按照上述思路，我们可以压缩需求分析和系统设计阶段的时间，将编码测试阶段扩充到整个项目的60-70%时间占比。当然这么做的话，对那些非开发人员来说，承担了比原来传统方式下要多的工作，不知道人家是否同意？这是不是就应了一句老话：改革就必然带来新的利益分配？（可能也有变通的做法，就是让开发部门让一部分人从事业务部门需求设计工作，一部分人从事测试部门的测试工作）

    当然不同的项目，不同的团队，不同的预算，在管理上都会有区别，正所谓思无定式，还是因地制宜，因人而异才好。软件管理在软件整个发展过程中就是一个很大的研究课题，新的管理办法提出，都是结合了当今软件发展的最新趋势，但是如果你的环境离‘最新趋势’还差的很远，那么最先进的管理模式还真不一定对你来说是一把好刀。