最近半年一直在反思瀑布模式和敏捷模式的使用。

因为我的第一家公司是传统软件公司，软件流程包含了一整套的初始需求、方案设计、招投标、需求分析、概要设计、详细设计、开发、测试、试运行、全面上线、后续改造与维护等流程，虽说知道的不深，但也还算是了解。因此可以说，我对传统的瀑布模式是比较熟悉的。

现在的这家公司，因为是互联网企业，所以要求速度要快，快速响应最火的热点。但去年这家公司用瀑布模式比较多，速度慢且费时费力。因此今年在大力推进敏捷+微服务。

我很赞同之前我的老板和我说的一句话：“没有任何一个系统是按部就班就能做成功的”，因此我即不认同标准规矩的瀑布模式，也不认同疯狂激进的敏捷模式。

举例说明A：在上一家公司瀑布流程标准的时代，我负责的一个社保项目，由于开发团队对项目的需求和流程十分熟悉，配合熟练，因此，我们跳过了概要设计和试运行阶段。

举例说明B：之前有业内BAT人员来给我们讲解敏捷模式，各种疯狂，例如表的结构不需要设计，放一个大JSON，不需要测试流程直接上线、不需要产品设计人员…….但是，太激进了，我们无法相信这个能起到实际效果。更倾向认为，这个是程序员为了个人的懒惰的目的而做的一种宣传。毕竟，这个行业有太多的程序员和太多的退役程序员，他们的号召力太强悍（但程序员有个缺点：术业有专攻，程序员做出的东西，有95%以上都是复杂而没有用途的“技术牛角尖”）

因此我不认同标准规矩的瀑布模式，也不认同疯狂激进的敏捷模式。

去年，领导要求规范化，但是那会儿我们的团队磨合不够，举个例子：写个API接口，六个人有四种完全不同的写法；对于分布式服务，一群人认识不清，只有一个人大概了解的，但是也是一知半解无法说服其他人；对于系统的总体架构，修改频繁，甚至对于一个英文的中文解释都有N多个，“支付渠道、支付通道、支付路由………..”

因此，无法立刻出一个统一的规范标准，唯一的可行之路，就是先实现一个基本可用的版本，然后在实践中探索规范。——其副作用就是：当时很多人认为我们的行为是不规范的。

在这一年中，领导屡屡提及规范化，要求我们做项目要按照标准流程去做。我们也响应领导号召，尽最大努力的增加规范，例如，版本管理流程、DBA执行规范、代码评审规范、代码总结规范、接口文档规范，部门培训规范…………..

但我很担忧有一天我们会成为一个庞大的，繁杂的，无人认识的系统，然后大家散伙各找各妈。

因此我在后半年一直在反思瀑布模式和敏捷模式的使用。

直到前段时间总结了我们的做法，略有所得：

—————————————————————————————————————————————————————————-

如果说：项目的稳定+流程的规范是一个重型的极端，而立刻快速的上线是一个轻型的极端

从这张图上看到：无论是瀑布模式还是敏捷模式，无论是重型项目工程还是轻型项目工程，做的都是相同的东西，仅是需要的努力程度不同。

因此，我很反感那些说“敏捷比瀑布好”的，也很反感那些说“瀑布比敏捷好”的。

我认为，瀑布和敏捷，是相同性质工作的两个极端，而作为项目负责人，是一名老司机的角色，在道路上既不能靠左路边行驶，也不能太靠右边行驶—这容易掉沟里。

项目负责人的职责，是动态的根据需求，调整这辆车在路的位置：

            1、不能掉沟里，让车无法前进—》管理要求太重则负担太重，管理要求太轻则稳定性不足，都会导致项目无法推进

            2、需要满足乘客的要求———-》领导就是乘客，乘客经常说“师父靠一下边，我拍照”，领导经常说，这个不规范，要增加管理要求，或者这个没用的东西给去掉

            3、需要避开前方的障碍———-》开车时，路上会有石头，你要避开，而项目推进时，前方经常有障碍，例如：隔壁友邦系统不给力，前方有技术难点，后方有依赖系统在催。。。。。。

            4、需要选择最近的路线———-》需要选择最近的路线，开车是为了省油。项目负责是为了节省程序员的成本。

            5、、、、、、、、、、

因此，我推荐的方式，是根据环境，根据总体需求，根据团队的目标，选择那些需求要用，那些需求要舍弃，最终目的是：整车人安全到站，大家开开心心回家过年。

如何做到这个目标呢？：

1、凡是引入一个需求，这个需求必须是可以反向去除的

        举反例说明：引入配置管理部的规范，提交SVN和BUG号要绑定才能提交，这个略微有点违反这个思想，因为加上这个功能，那么就永远无法去除了。此类需求一多，则系统会越来越重，并且无法减肥。

        举正例说明：引入了PRE环境测试需求，要求项目上线前才PRE进行测试，这个规范就是可以反向去除的，因为我们在DEV-UAT环境测试完，如果项目紧急，可以直接对UAT封版，UAT测试，UAT回归，UAT验收，直接上线，这种需求就是可增加可删除的。

2、明确我们的目标，我们是用成果说话的，没有成果，一切都没有意义

        举反例说明：考英语四级，努力的考了3次，每天被单词到晚上10点，报各种培训班，订各种资料，阅读各种英文资料，故事可歌可泣听的都哭了………………….然而没考过，这就从一个悲情故事变成了一个可笑的故事。没结果就没有意义。

        举正例说明：高中时，你肯定有一个同学，平日不好好学习，但是考试成绩很好，因此老师各种优待，家长各种宠爱………………….成果比一切都要重要。

3、明确没有什么是必须的，包括：规范、稳定、DBA、总结、文档、接口……….

        如果你认为“XX是必须的”，那你的人生已经失败了一半，因为你没有认识到：“成果是最重要的，而附属的那些东西是不重要的，当然，如果这个成果必须由一个附属的去支撑，那么附属也同样重要”

        举反例说明：隔壁系统，具有各种规范，具有各种的要求，具有各种的管理，一个项目里一个开发三个测试……然而导致项目推诿严重，项目无法推进

        举正例说明：我们系统的初创时期，由于一无所有，因此不需要“僵化流程”，不需要“冗长规范”，并且能扛着领导的“一定要规范”的压力没有增加这些内容，所以项目推进迅速，成果显著，部门绩效极高，高层非常认可。

4、项目负责人一定要有责任心：

        4.1、了解项目各方的需求人：产品需求、领导需求、测试需求、程序员需求、友邻部门需求、各项目干系人的需求

        4.2、分析这些需求哪些是必须的，哪些是可延后实现的，哪些是可以舍弃的

        4.3、仅最大努力，把必须的需求实现，把可延后实现的需求放到同期实现，把舍弃的需求尽量列入计划

        4.4、此时会有个问题：项目负责人的责任心，因为在此情况下，会出现委托人问题，各方要做需求实现，但是项目负责人会为了工作的轻松程度，尽可能的把可延后的需求延后实现。此时需要各方的博弈，最终结果会是各方得到一个平衡，项目成功上线，满足了各方的需求。

                这就是项目负责人的意义：平衡各方需求，把一件事情抹平。同样而言，如果一个项目负责人延后了太多的项目，就会被换掉，这是自然规律。

以上是鄙人狂妄的见解，请不认可的同志们就当是笑谈吧

——————————————————————————

因此说：项目负责人这个工作，是艺术而非技术。但艺术水准是无法衡量的。

人类趋于稳定，不想冒风险，因此我一直致力于成为一个技术人员，因为技术水平是可衡量的。就比如13年初那会儿，会Hadoop就比其他人牛……再比如今年，精通docker就比其他人牛……

这就是为什么很多人喜欢做IT，IT有一条非常稳定的技术路线，沿着路线走，你总会成功的。