人—流程—项目

以上是软件开发过程中的三元组。 也就是说，软件项目的成功，这三个要素，缺一不可。每个要素的取值从0~1。如果有一个为0，那么总体就为0。这是个很简单的数学公式，但是当我看到前面的诊断的时候，有一种豁然开朗的感觉。这么简单的事情，为什么还是在执行的过程中想不通？可能就是人的问题。



在这个三元组中，人就是软件开发过程中的所有角色，流程就代表管理。这里面最重要的就是管理，占到因素的64%。技术只占了1/5，人员的问题占10%。从这里可以看出，为什么大家为什么这么多年来一直重视软件工程，或者说项目管理，关键还是在管上，那么现在软件的项目管理究竟在64%的份额中，占到了多少呢？是不是有了很大的贡献呢？现在还不好说，估计是不太好，如果有那么一点好的话，也不至于，到现在依然还是在探讨这个问题。



关于敏捷开发

敏捷方法体系包括结对编程（1975年）、Scrum（1995年）、水晶方法（Crystal Clear）（1996年）、极限编程（Extreme Programming, XP,1996年）、自适应软件开发（Adaptive Software Development, ASD）以及动态软件开发方法（Dynamic Systems Development Method, DSDM,1995年）等。



对于敏捷，相信大家都不陌生。从上述的叙述来看，流派很多，方法各异。从目前我的工程实践来讲，我接触的是 Scrum方法，还有听过 XP、极限编程。也读过一点敏捷宣言，真正的系统的来实践敏捷，还是从 Scrum 开始，说起来是2015年的事情了。之于我来讲 Scrum 几乎就等价于敏捷，我对之了解很多，也亲身的去实践了一些方法。有句话，大家都听说过，『在中国，至今也没有一个完全进行敏捷开发的公司』。所以，提起敏捷来，CXO 们大多都挺反感的，尤其是没有亲身实践过，还在坚持 X-理论模型来进行团队管理的人，当然也有从传统行业出来的，没有软件研发背景的人，都会觉得敏捷很不靠谱，不如控制、指挥来的有效果。



毛主席说：『没有调查，就没有发言权』。实践出真知，是检验真理的唯一标准。爱因斯坦也同样说过，如果一个人不敢失败，那就永远没有创新。对于敏捷开发，如果要实践，必然会因为没有人指导（小公司大体都是摸着石头过河），而走一些弯路，可是这些弯路，对于小公司来讲，就是不可承受之轻了。对于大公司来讲，也许在实践，但是又不是纯粹的来做。从敏捷的流派来讲，都有那么多，眼花。从取其精华的角度来讲，我们会组合起来用，结果大多数是用不好，画虎不成反类犬。就拿结对编程，这是敏捷中很推宠的实践，可是，有哪个公司会让两个人写一段代码呢？一定会认为，这是在降低生产力呀，两个人只有一个人干活，怎么可能？！而且，我们的开发人员也有充足的自信，怎么用得着，我自己一个人就可以顶10个人了，还要别人来啰嗦我？科学，离我们真的是太遥远了，因为我们不信，导致我们在管理过程中也不敢去采用这些实践。

关于项目时间进度的估算



大多数软件项目都因缺乏合理的时间进度而失败，这个原因比其他所有因素加起来的影响还大。导致这种灾难的这个原因为什么如此普遍呢？



首先，我们对估算技术缺乏有效的研究，更严肃地说，它反映了一种悄无声息但却相当不真实的假设——一切都将运作良好。



其次，我们的估算技术错误地将进度与工作量相互混淆，隐含地假设人和月可以互换。



第三，由于对自己的估算缺乏信心，软件经理往往缺乏足够耐心持续地进行估算。



第四，对进度缺乏监控。其他工程领域中经过验证的跟踪技术和常规监督程序，在软件工程中常常被认为是全新的事物。



第五，当认识到进度出现滞后时，本能（以及传统）的反应是增加人力。“这就像使用汽油灭火一样，会使事情变得越来越糟。越来越大的火势势必需要更多的汽油，从而进入一个注定会导致灾难的无限循环之中。”



在几乎40年后的今天，布鲁克斯所列的第五个原因几乎仍然在传统软件开发方法中普遍发生。显然，这不是解决进度延误问题的最好办法，但在没有合理判断的情况下，它往往又是首选解决方案。现代软件成本与进度估算技术至少比布鲁克斯做出评价的那个时代要好很多，而乐观主义仍然是被广泛使用的管理工具。



当估算出来的成本和进度数据不是我们所希望的结果时，我们可以简单地修改估算工具中成本与进度估算算法的输入参数，进而得到我们想要的估算结果。这就是为什么那么多的项目成本超支、进度延误，而我们总是把失败的责任归咎于项目本身，却不是我们的估算。在开发管理上也是如此。



相信在软件开发过程中，这样的事情是一直发生的，尤其是在 B 端软件项目开发的过程中尤其如此。因为 B 端项目 的软件开发，要么项目是从0到1，要么是定制化，需要在原来的项目上做一些改动，这些改动有的『大』，有的『小』。遇到这些情况的时候，首要的，就是估算，软件项目究竟要花多少时间来完成。因为甲方爸爸是有时间限制的，我们在承担建设任务的时候也有项目的成本估算的。这都是再正常不过的事情了，可是还有一个因素，那就是赚钱。不论在任何情况下，都觉得软件研发人员评估出来的工时，是有问题的，都是注水了的。而且，软件研发人员，在评估工时的时候，都是很乐观的，假设一些都会很顺利的进行，这就是典型的挖坑给自己。造成这样的结果，原因各有不同，其实大多数压力都来源于管理层，当研发人员按着自己的内心估计（都是很乐观），给出时间长度的时候，管理者认为，这是有水份的，那我就要求一下。好，研发人员理解，看来是不接受，那我就压缩时间吧，想想也许是可以的，加加班，996一下。其实，这样的想法，在第一次估计任务的时候已经做过了，可是这次再做一次，估计是下了狠心的，出来的结果，可想而知。自然会出现第五条的状况，到了项目快延期的时候，管理层说，是不是现在缺人？如果缺人我给你加人。可是这时候再加进来的人，一，没有时间了解项目，对于业务状况不熟悉，二，产生了沟通成本，犹若抱薪救火。而且，这是理想情况下，有合适的人，如果没有，现在就招聘，来的及么？



所以软件项目的排期，都是工期压缩后的结果，想不延期都难。



相信，不同的人，看到上面 Brooks 的五个原因，都有不同的想法，都能就自己的公司的现状，或多或少的讲几句。可是，对于承担软件研发任务的我们来讲，不能只讲原因，不想办法。有的人说，如果公司的背景不好，根本就是不适合软件研发，一言堂的命令式管理，那还是早走，我就遇到过这样的公司，无论做什么事，都要发红头文件，对于软件项目管理，只有命令。如果，有那么一点可能，可以尝试的话，对于软件过程的改进，也要采取温柔的态度开始，因为改革就会遇到阻碍，特别是会遇到自认为有经验的人的阻碍。



还有更可怕的，一直睡在过去的知识结构中的人，没有知识更新，打着新的思想的旗子，做着过去的事情，害人不浅的也大有人在。如果短时间改变不了现状，那就多观察一下团队运行状况，适时的做出自己能做的事情，这对于整个研发团队来讲也是有益的。



今天，就说这么多。在下一节，会介绍影响项目质量的要素：技术、沟通、管理。也会提到著名的霍桑实验。关于软件开发，可说的事情就随着书的进展展开吧，就像坐在桌子边，边吃茶，边聊天。



其实，软件开发，最重要的就是有机会去实践，经过实践，不断的去验证自己的想法，团队的环境很重要，如果没有机会，你纵有神策也难于实施。软件开发过程，不存在争斗，也是可以顺利的做好的，我一直相信这一点。可是现在遍布程序界的，都是软件研发过程中，各种角色的怼，甩锅，都练的神功盖世了。我不知道为什么大家还在乐在其中，难道这是一种很好的现象么？