技术管理系列 小谈软件构建之路

小谈软件构建之路

本课程包含以下内容：简单对软件工程进行回顾，介绍常见开发流程，谈谈风靡互联网公司的敏捷本质，最后谈谈研发绩效考核和工程师的基本素质

为什么要学工程构建

敏感话题996

前阵子996话题这么火，作为程序员，还是应该拿出来说道说道的。
为什么我们互联网行业普遍存在996过？是真的业务发展都这么好吗？真的有那么多客户等着你的新产品用吗？
其实从网上的回答来看，并不是用户需要，而是来自：项目管理混乱，产品规划有问题，公司领导价值观....
大多数人碰到需求变更这种事，除了抱怨产品或客户是个SB，只能闷头苦干。

虽然学好工程构建解决不了领导价值观，但是项目管理和产品规划至少会有很大的改善。我觉得公司创始人和合伙人997也好，007也好那是他们自己的选择，如果员工没有和他们一样他们就会很痛苦。王晓波曾说：人的一切痛苦，本质上都是对自己无能的愤怒! 这些BOSS可能就会开始对标各大公司：你看XXX公司大楼的灯，一直亮到深夜，我们是不是也要向他们学习。当然加班待遇啥的，他们当然不会进行对标的。

相信大部分人如果自己收入没有和公司利益挂钩起来，是很难做到真心实意在996的。每一个人在不同的阶段，工作和生活需要达到的平衡点不同。刚毕业也没谈女朋友，可能会觉得加班挺好的，很充实；逐渐谈了女朋友，下班后的时间那得属于女朋友了；结婚生孩子后，下班后时间那得更多属于家庭了；

我们看生活这两个字，其中生活的生字，包含了工作；工作只是生活的一部分不是吗？当然我们要做个有职业专业素养的员工，什么才是有专业素养后面会谈到这一点。

复利

• 大家看这幅图，你能想到什么? 指数增长？复利
• 工作学习中，能力提升的关键，在于做可以复利的事情
• 没有必要的理论指导，遇到新项目不能举一反三，工作很平庸
• 要知道每个公司每个项目参与的人都是不一样，我们不可能使用一成不变的方式去应对，但是背后也肯定存在不变的东西
• 学习了工程构建，你才能发现软件开发过程中哪些阶段是属于复利的事情，然后不断打磨提升

方法论

不仅仅适用于软件开发，任何的团队协作都可以用到
工程构建不只是软件开发的一种方式，更是一种方法论，可以适用工作生活的方方面面。这个脑洞是不是有点大？相信你从来没有这么思考过。

• 华为任正非公开信：
  全面提升软件工程能力与实践，打造可信的高质量产品

• 产品设计：
  分析（头脑风暴10分钟），设计（根据分析确定最终设计5分钟），开发（把想法画出来，10分钟），发布（完善结果，准备展示5分钟）

• 生活沟通问题：
  睡觉被邻居摇滚音乐吵醒？1确定需求（你要睡觉） 2需求评审（因为你通宵加班？） 3 设计（用什么方法，是抱怨还是获得同情）4 编码（正式沟通）5上线追踪（看效果，无效的话再投诉）

守望先锋的例子

• 先看一个历时3年的项目，大家知道这是什么项目吗？(互动回答下）

• 这个是暴雪的一款第一人称射击游戏守望先锋，花名屁股。为什么有兴趣的自己去了解下
• 守望先锋是2013年立项，大概花了几个月时间做了一个demo版本，只有四个英雄和一张地图
• 2014年的时候，在暴雪嘉年华的时候发布了试玩版，包含12个英雄和4张地图
• 随后在2016年5月，正式发布上线的时候，大约有20个英雄，10张地图

守望先锋团队大概100人，大家觉得多还是少？其实相对这么一款高品质游戏来说，是少的。我们不知道这100人是不是精英中精英(看过他们团队介绍的话，核心几个人都是暴风内部大牛)，但可以肯定的是他们一定采用了很好的开发模型或者说是工程构建方式。提到开发模型，你第一时间想到的是哪个？

瀑布模型诞生与意义

六大流程：

• 问题定义：可行性研究
• 需求分析：需求文档
• 软件设计：设计文档
• 程序编码：源代码
• 软件测试：测试报告
• 运行维护：维护文档

相信大部分人都能说出其中几个流程，但我相信在座不是每一个人都能准确说出这六大流程顺序和相关输出物。
大家知道瀑布模型是什么时候提出的吗？1970年，比我们所有人都大。再它提出之前，软件开发是想怎么开发就怎么开发，基本谈不上协作。随着软件规模扩大，越来越难维护和扩展了。

虽然大家对瀑布模型没有什么好感，但是大家这是一种外部宣传对它的偏见。要知道它还是很有优点的。而且有着划时代的意义：

• 简单可行，切实有效
• 从此诞生了软件生命周期的概念
• 掌握了瀑布模型，你才能真正理解其它模型
• 无论哪个模型，瀑布中的四个环节是不可能少掉的

2000以前都是最主流的开发模型，现在很多大学毕设还是采用这一套的。导师是不是让你从写可行性分析开始？然后是需求分析，设计，编码，答辩？瀑布模型仍然适合很多项目团队，它不是历史的遗物。

一个常见的项目开发计划示例

这个示例项目肯定存在不少的问题，归纳起来大概两大点：

• 需求管控：项目关键要素把控不足
• 竖井效应：整个项目开发流程中肯定产生了竖井效应

项目关键要素

项目关键要素：时间，成本，功能，质量(不能改变)
传统金三角：范围，时间，成本构建出质量；
改良后的容器模型：项目功能 = 时间，质量，成本

• 要提前上线，怎么办？增加成本，投入更多人员
• 添加功能，准时上线怎么办？增加成本，加人和加班
• 不加人？那肯定要延迟上线时间了

• 不能延迟上线？那必须要砍功能了
• 有的人说，我们老板说了：上线时间不能变，也没有额外人员，这个功能客户一定要的，那你得让你的老板知道，如果做到这些，质量需要变形下。

总之，作为一个产品负责人或项目经理，要把控好项目的几个关键要素，拿着金三角或容器模型和BOSS商量解决

竖井效应

• 在整个工程中，存在多处等待情况，导致：工作量不大的需求，交付周期确很长；局部一片繁忙，外部抱怨不断；
• 为什么会有等待？大家关注不积极？其实不是，局部繁忙一般有两个原因：1 在处理其它并发项目；2 为之前不规范埋单

之前提到过瀑布模型有点明显，但是如果项目经理经验不丰富，有几个地方很容易产生竖井效应：

需求分析阶段 ：研发，测试在等待 设计阶段：需求，测试在等待 编码阶段：需求人员在等待 测试阶段：需求，研发在等待

多种开发模型

瀑布模型虽然不错，但是还是存在一些问题，不能适合不同的项目团队，于是逐渐发展出了多种开发模型

• 瀑布：最传统模式，不可逆，文档齐全，步骤分离，最后才输出产品
• 增量：系统划分为不同模块，每个模块进行分析、设计、编码、测试
• 迭代：划分迭代周期，每次交付一个可用版本
• MVP:最小可交付产品，最简单的demo，甚至可以是保真的原型
• MBP:最强最美产品，强调完美和极致（iphone,ipad）
• MSF:微软体系的开发流程标准

不同团队模式

• 一窝蜂模式（业余球队踢球的例子，球在哪人在哪）；
• 主治医生模式（手术台例子，一个主刀医生，多个助手）；
• 明星模式（主治医生极端情况，奇异博士成为超级英雄之前）；
• 社区模式（众人拾柴火焰高，严格代码复审，对众人的水平有要求）；
• 业余剧团模式（学校项目）；
• 特工团队（特殊项目，特别成员）；
• 交响乐模式（大公司稳定项目二次开发，交响乐是分好几个乐章的，每个乐章由非常专业的乐器乐队组成）；
• 官僚模式（多层级项目汇报架构）

敏捷开发

很多小伙伴在心里早就有了疑问，你之前介绍多种开发模型的时候，为什么没有介绍如日中天的敏捷开发？
我听说现在大家都用敏捷开发了，那直接学敏捷开发模型不就行了吗？如果你是个刚入行的小菜鸟，这么想我觉得再正常不过了，如果你在这个行业已经3年以上了，你还有这个想法，那么说明你对工程脱节的太严重了，得好好补补课了，今天是一个很好的切入契机。

我以前工作的时候，在讨论一个战略性项目周期问题时，我提出项目时间太紧，按照容器模型很难兼顾质量和功能齐全。有一位产品总监提议说：那我们采用敏捷开发啊，用了敏捷开发肯定可以。我听后只能无语了，我内心真想问问他，敏捷开发是一个人还是一个团队呢？感觉互联网行业，大部分从业人员对敏捷开发有很大的误解，普通员工不理解可能关系也不大，但如果是一个项目负责人，甚至是产品总监，技术总监都无法正确认识，那将给团队和公司造成多大灾难？

在外行人眼中，敏捷开发是银弹。在你们眼中，敏捷开发是什么？或者说什么是敏捷开发？(交互回答环节）
如果只是提到敏捷开发的一些具体名词或操作：Scrum，不要写文档，站立会，用户故事，测试驱动，小卡片，白板，燃尽图等，可以说都对，但是又不对，为什么这么说？

敏捷宣言的正确打开方式

敏捷宣言中主要包含了一系列的价值观和方法类集合：流程和工具VS个人和交流；完备的文档VS可用的软件；为合同谈判VS与客户合作；执行原定计划VS响应变化

这些方法类和价值观都有价值，只是价值的侧重点不同，说敏捷开发不需要写文档的，相当于在胡说八道。

敏捷三大坑

• 注意敏捷流程只是更强调后者，并不是说前者不重要或者抛弃前者
• 团队素质没达标，强行敏捷的结果就是悲剧，反而更乱更糟糕；如果你的团队已经满足敏捷开发要求，其实不用敏捷也能开发好，正所谓如果都是高手，自然而然就敏捷了
• 拿着敏捷当令箭，我们要采取敏捷开发流程，没有计划，没有文档，开始写代码，随时发牢骚

敏捷和其它开发模型的关系

• 我们假设各个开发模型，其实是散落在一个叫做敏捷度坐标的坐标轴上
• 越靠近左边，敏捷度越低；越靠近右边，敏捷度越高(这个分布只是我个人的理解，不同的人放置的位置可能不同)

• 敏捷开发就像是一个指针，老标识某种开发模型的敏捷度是高还是低。那敏捷度越高越好吗？当然不是，要和你真实的项目和具体团队成员有关。

敏捷之道(敏捷开发总结)

• 1 敏捷宣言不是圣旨，你不要教条主义 - 2敏捷教练时候一个沟通者，不是项目经理
• 2 项目中的矛盾不是全部摆到明处就好，这有好处也有坏处
• 3 复杂的项目，要让一线成员做决定
• 4 创业公司团队其实经常运行在敏捷模式当中，只是没时间论证自己到底有多敏捷
• 5 不要和管理层谈流程，他们只关心结果
• 6 敏捷不是银弹，也没有完美的敏捷

不是一种明确的开发流程，更像是一种思想和价值观，是对其它开发模型的框架性指南
开发流程可能是一种术，而敏捷更像是一种道，你可以在各种不同的开发模式中使用

谈谈研发绩效考核

创业故事警示

加入猪，鸡，鹦鹉三种动物准备创业开一家欧式早餐店：提供三明治（面包，鸡蛋，培根），那么他们分别需要付出什么？

1弄清楚自己在这个项目中的投入级别是什么：猪提供肉（全身心，必修课），鸡提供蛋（兼职参与，选修课），鹦鹉提供咨询（围观下，能说会道，人脉广，很多建议很多点子，不执行）

2你可以在多个项目中做鸡和鹦鹉，但不能在2个项目中做猪（盖茨，小札的学业和事业二选一）

3清楚团队中哪些成员是猪，哪些是鸡，哪些是鹦鹉。一群猪固然好，但无论怎么努力也无法下蛋，一群鸡每天按时上下班，但缺乏斗志，一群鹦鹉每天叽叽喳喳最后只剩一地鸟毛。

4遵循敏捷的团队里，一般有一个原则：重大决定由猪来决定

研发和市场第一线全心投入的猪，坐办公室的鸡，空降来的鹦鹉；写成漂亮PPT鹦鹉，主管流程的鸡，第一线的猪。

行行有本难念的经

各行业对绩效评定都很难，毕竟不是简单的搬砖工作(简单搬砖可能除了数量也有其他考量因素）。
话剧中角色能随意替换吗？
一个强救过很多病人但有的失败了和只强救过几个病人没有失败经历的医生谁绩效好？
一群老师授不同课，有难的课程有简单的课程谁最有效？
一个出版社的编辑出的书，有的叫好有的叫座有点专攻某一领域，可能是作者靠谱，可能是题材好，谁是好编辑？
一群人开发软件，如何评价他们绩效？

研发绩效之代码量

代码量的例子：有两颗果树，春天发芽，夏天开花，秋天结果。大家去摘果子吃，发现果树A的果实比果树B的多且好吃，于是大家都在A果树上采摘，并一起拍照留念。果树B很委屈，它在秋风中摇晃树叶说：但我的树叶是它的三倍呀，大家没有听懂B的抱怨，背着果实走了。冬天来了，树叶落了一地，大家来打扫果园，一个同学说，我去！这颗树怎么这么多叶子！代码量犹如树叶量，当作如是观。

开发人员根据工作量来?工作量又根据什么来衡量？代码量(业务代码和核心算法代码价值一样吗，万一重构了代码，代码量反而少了呢，贡献为负不成。注释算不算，空行算不算，都不算那还有人写注释吗，那是不是把代码都拆成多行写比较好？有现成库函数，我也不用了，再造个轮子堆堆代码量岂不是更好)？

研发绩效多维度考核

工作时间来算？好了，大家都开始白天磨洋工，晚上比谁下班晚了；万一我周末在家一直想着工作的事怎么办，这算工作时间吗？

比资历？赢者通知；大锅饭？劣币驱逐良币；比效率？回到代码量问题，3个臭皮匠真能比的上一个臭皮匠？背靠背评比？分组抱团，也会劣币驱逐良币

好像一切衡量方法都有致命的空子可以钻，很难达到纳什均衡。《人件》一书中说：但是任何一种衡量方法都比完全不量要好。

我们将采用每个岗位实施多维度的考核，岗位不同多维度指标的系数和内容也不同；相同岗位不同级别考核的内容也不同。我认为员工不是公司的成本，更应该是公司的资源，为了公司的资源，多烧点脑，指定点多元化的考核指标，还是很有必要的。

研发人员特性：萝卜和青菜

萝卜快了不洗泥，青菜慢工出细活；萝卜和青菜故事，引以为戒。萝卜快，负责模块多，问题多，干的晚加班多，解决的也多，曝光率高，因为设计复杂导致只有他能维护，演变成有问题找萝卜。青菜慢，因为质量好，修复bug不多，也按时完成了。萝卜青菜各有所爱，看领导喜欢的风格。

我喜欢什么类型？我两种都很喜欢，因为有的项目就是要萝卜去做才好，有些项目真的要交给青菜。但是也不能太萝卜和太青菜，所以作为领导要用一些制度和规范让萝卜慢下来（小强地狱），并科学提升青菜效率。

职业素养

职业素养做事原则

• 1 以解决客户实际问题为目标：大部分开发人员也以自己写了多少代码为骄傲，枝叶繁茂，是不错。单这些代码是否有机结合起来解决客户问题？
• 2 让产品，设计，代码成为你的名片：不要有随便，差不多的念头，经常总结review自己的代码，文档，设计等
• 3 熟悉自己的领域，保持终身学习：精通设计模式，精通开发构建方法（XP SCRUM 精益 瀑布 看板 结构化分析 持续集成 结对编程 TDD），精通工件（UML DFD 结构图 网络图 流程图 决策图）；坚持学习：新知识，新语言，新工具

职业素养说会说yes和no

说不的专业：
能就是能，不能就是不能，不要说试试看
试试看？说明你之前还未尽全力，说明你不诚实，说明不专业
什么时候说不？ 施加压力修改预估进度时，软硬兼施时，连哄带骗时
说是的成本：糟糕的代码，糟糕的作息时间，糟糕的个人品牌形象
越是往上走，越要学会说不；越是团队的核心，越要学会说不；能力越大，责任越大，说不的能力越强；一个人没说不，是一个团队的付出

说是的专业：
1 承诺的三步骤：口头上表示自己将会去做，心里认真对待，真正付诸行动
2 识别假承诺：需要/应当 希望/但愿 让我们
3 真承诺：我将在…之前
4 承诺没兑现：依赖第三方法则，依赖测试，依赖产品，依赖…. ; 仍然全力以赴，提前预警
5 专业人员不会放弃底线：不会不做单元测试，不会让自己不满意的代码上线，不会有差不多就行了的念头

小测验

看看下面项目，我们应该采取哪种开发流程模型？(答案见文末)

• 1 外包项目
• 2 风险很高的项目
• 3 山寨类产品项目
• 4 有个好想法的项目
• 5 已经上线的项目

总结

现代软件构建不是一件简单的事，1个人12个月的活，绝对不是12个人在1个月内能干完的。项目参与人越多，平均每个人的出活速度就越慢，其中复杂性超乎大部分人的想象。

软件工程的根本问题是人的问题，主导软件开发的人必须能够理解高度复杂的东西才行。敏捷开发不是一种开发流程，更不是银弹。它是可以适用在各种开发模型中的一种敏捷度指标，越敏捷对团队成员的要求也越高，所以你敏捷度的高低首先看看你带的是什么样的队伍，当前项目是在什么场景下，你才能选择出正确合适的构建流程。

能管理好大项目，确保项目按时上线，软件产品能够满足可靠性、易用性、安全性、可扩展性的人才都是绝对的帅才。这就好比带兵打仗，你不用说指挥十万人打仗，你能把十万人安全带到战场，不哗变、不闹事、都能吃饱饭就不错了。

布鲁克斯有句名言：好的判断来自经验，而经验来自坏的判断。正所谓一将功成万骨枯，驾驭大型软件工程的能力，只能通过大型软件工程来培养。

小测验答案：1 瀑布模型：明确每一个阶段的验收标准，符合要求才进行下一个步骤。2 迭代模型：划分好产品优先级依次迭代，交付迭代成果后进行风险评估，风险过高时，应及时止损。3 增量模型：把产品划分为不同的模块，先开发核心模块，资源允许的情况下多模块并行开发。4 迭代模型：确定需求边界和风险，描述用户故事，和客户保持对话，迭代交付。5 迭代模型或瀑布模型：需求十分明确就采用瀑布，不是特别明确，就先划分阶段性的任务目标，按大小划分成1-N个迭代周期。