软件开发模型的思考

1 瀑布模型
关于瀑布模型的介绍可参考瀑布模型，下图中根据每个任务迭代阶段，都是一个典型的瀑布模型。

项目管理中虽然计划是渐明渐细，但是需求如果没有出来，那么计划就是拍脑袋的。
所以在实际中，我们会做此调整。将【需求分析】放到了【软件计划】的前面，【需求分析】阶段由产品经理完成，并交付成果物《XX系统需求说明书》和《XX系统原型》。接下来技术经理和测试经理进行工作量的评估，安排计划。

这里可能会有人问，那么项目经理做什么呢？项目经理岗位的没落，原因有三：一、现在的业务是复合的，大一点的公司都是“平台+应用”，技术线涉及安卓、IOS、java、JS、CSS、C++，大多数公司出于成本考虑，都会将那种只做管理工作的岗位撤掉，采取技术经理来掌控项目进度和质量，也更满足技术人员对管理智能的欲望，一石二鸟；二、从管理策略上讲，领导也会考虑234原则（2个人干4个人的活，分3个人的钱）。公司需要的是干活的；三、产品经理是需求的整理者和提出者，产品经理对最终的产品的负责，则更没有项目经理什么事了。
2 迭代模型
从网站搜索很多关于迭代模型的图，你会发现，上图中将【需求分析】挪到了【软件计划】前面，居然就编程了迭代模型，例如下图从百度上搜索到的图。

分析百度百科中经典的螺旋迭代模型，你可以不仅将开发调整到需求前面，而且在原型阶段着重强调了【风险分析】。
迭代模型起于需求计划，这个很好理解。因为产品经理需要与业务部门进行多轮的需求讨论，这个讨论不是无限期的。故需求计划中规定了需求的截止点，到了这个截止点。如果业务部门还有其他方面的需求，那么就调整到下一阶段的迭代阶段。

使用原型让使用者在第一时间感受，自己的需求与实现的偏差，不过很多时候，这个时候的使用者主要是着眼于功能层面，而且当开发周期是1~2月的时候，业务在调整，系统的跟进就不会多么上心。《需求说明书》和《原型》导入到研发之后，开发工程师和测试工程师各自根据文档做自己的宫缩。对于产品其实是一个空档期，这个时候除了一些需求变更，产品经理已经可以开始着手下一阶段的需求了。
3 需求分析阶段的成果
苏杰的《人人都是产品经理》确实带动了一批人，以设计的产品被很多人或企业使用而感到骄傲自豪，人人都是产品经理网站。当产品经理的位置凸显的时候，软件开发过程中的成果交付物也随着发生变化。
按照以往的惯例，《需求分析说明书》由需求工程师编写，《需求规格说明书》由软件工程师或者需求工程师编写。项目、系统开发中的需求分析说明书和需求规格说明书的区别。理论没有错，问题有二。一、需求工程师，即现在的产品经理为什么不将《需求分析说明书》和《需求规格说明书》合成一个文档，因为配合原型和一份《需求说明书》就已经可以清晰反应产品的具体需求了。二、《需求规格说明书》如果让软件工程师来编写，那么测试工程师、QA又将以哪个作为他们开展工作的基础。软件工程师、测试工程师、QA必须要站在各自对立的立场，才能相互制衡，促进项目良好运作。否则软件工程师作为软件的具体实施者，往往后期具有过于强势的力量，阻碍了一个更好的产品诞生。
所以我的观点是，产品经理在【需求分析阶段】的主要输出物是《需求说明书》和《原型》，编写完成后由各干系人进行评审。最终评审通过的版本作为项目开发过程中各岗位开展工作的蓝本为好。
4 设计阶段做什么
我面试过很多工作过4~5年的人，连李智慧的《大型网站技术架构：核心原理与案例分析》都没看过，都敢说自己做过架构设计，我只能呵呵。做一个系统用了activimq、redis、采用了springmvc，可以自己搭一个工程，就敢说自己是做架构设计，也真是敢要价。要么我说他们搭过的公司没有做过任何技术沉淀，很low，要么我可以告诉他，我带的刚毕业的新人很快也做到他们这些4~5年就做到的事情，技术人员如果不能“stay foolish，stay hungry”，最终难免落下产品建成后“飞鸟尽，良弓藏“的悲剧。
看了软件开发生命周期模型 瀑布模型、增量模型、原型模型、螺旋模型、喷泉模型总结这篇文章，我有些另外的思考。
当公司的技术选型较为严谨，技术沉淀做到一定程度，那么当做一个子系统的时候，设计阶段该做什么呢？
一、接口设计，接口涉及到系统之间的通讯，无论是rest接口，还是dubbo接口或者hessian接口，都涉及协议标准，协作起来才好做事情。
二、数据库设计，数据库设计定义的表，直接影响到系统实现的复杂度，也为后续开发工作奠定了基础。
三、概要设计，每个月开发工程师的KPI考核中总有设计能力这一项，我一直没搞明白该如何评价一个人的设计能力。因为大多数据情况的设计都是由技术经理对子系统进行设计，高级工程师顶多参与或者不是第一时间参与，更别说中初级的了。在前面环节，我们对产品经理的需求和原型提高了要求，那么此时就需要对开发人员的设计能力进行拔高。否则人才梯队建立不起来，那么永远就是那么几个人做设计的事情，于公司发展不利。
至于详细设计，我看就算了，像北京很多公司，以及外包公司招的人很多都是从培训班出来的，详细设计更会让他们摸不着头脑，结对编程（六种不同的结对编程模式对比）在中国不太现实，大多数公司都认为时间才是互联网的王道，唯快不破。怎么会给那么多时间给开发人员想的特别清楚呢。而且开发人员觉得的特别清楚，在测试人员面前往往又是那么不堪一击。
5 概要设计写什么
有一段时间呆在研发中心，跟一位副总讨论概要设计的模板。也参考过华为的概要设计，华为的概要设计写的特别仔细，像详细设计，想象一下华为的体量，然后对比自己的公司，衡量一下收益对比，就知道方式不能复制。华为后面有一堆外包公司，我们需要掂量掂量。
“越是艰难处，越是修心时”，静下心来思考。我们已经做到了标准功能模板化，通用功能组件化，那么开发人员在设计中