开发过程感想

开发流程，一般是随公司一起成长。

     几个人的时候，什么都无所谓，因为直接沟通的成本是很低的，所以反而不需要繁琐的流程，这是的开发往往是作坊级别。

     几百的人的时候，如果还是作坊式的开发，会带来很多问题。比如责任不清，需求遗漏，需求和设计和编码不一致，等等，直接沟通的成本也增加。这是要考虑人的模块化，分项目组，接口人。开发也要文档化（需要分档，设计文档，测试文档，用户文档), 还需要项目管理文档。 这时候主要是文档和减少不必要沟通。开发模式类似于瀑布模型。最高境界就是(IPO, CMM)

     公司成长到几千上万的开发人员时，IPO,CMM也有问题，成本太高了，响应时间太长，反馈时间也太长。这时候，开发流程开始走简化，文档开始简化，项目驱动，增加项目的沟通。最高境界就是（Agile, Lean)

 

 所以流程是成长起来的，不是制定出来的。流程也没有最优，只有适合什么状况的公司的制度。

 

当制度是制定出来的，被强迫执行时，往往效率不高。为为什么呢？

第一， 制度的制定者，不是开发人出身。这是个很不好的兆头，不是开发出身的能做好这个极少，为什么，因为他们的思维里只有美好的制度，很少考率一线开发者，也不能准确的理解开发者遇到的问题。

第二，相信所谓的神话(什么设计做好就没有BUG), 要明白任何流程都是要成本的，从经济的角度看，投入越早，成本越高，回报大于它的机会成本，才是可以投资的。

第三，制度没有考虑到开发者的执行，制度变成了法律，公司变成了军队。记住公司永远不是军队，军队是要用命来拼的，员工没几可以。这样的制度的危险在于缺少了反馈和调整。成败在于制度的制度者的水平，更在于运气，这就像中国历史上的人治。

      如果一条制度不能帮助开发者 提高工作效率，只会占用时间，那么开发者总会有办法敷衍（上有政策，下有对策)。 真正的好制度，不是规定代码要CheckIn, 要写UnitTest, 要做CodeReview. 而是怎么样通过这些工具和流程，帮助开发者解决问题，提高效率，少加班。 让过程和工具成为助手，而不是障碍。 通过培训，听取开发意见（如果开发者问题不能解决，最好不要强行推)，开发者总结来推进更好。