《构建之法》笔记

软件公司 = 软件 + 商业模式
软件 = 程序 + 软件工程
程序 = 算法 + 数据结构

工程的定义
创造性地运用科学原理，设计和实现建筑、机器、装置或生产过程；或者是在实践中使用一个或多个上述实体；或者是实现这些实体的过程

软件工程是什么？
软件工程是把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程。
软件工程包括下列领域：软件需求分析、软件设计、软件构建、软件测试和软件维护。
软件工程和下列的学科相关：计算机科学、计算机工程、 管理学、数学、项目管理学、质量管理、软件人 体工学、系统工程、工业设计和用户界面设计

软件开发过程有什么特别的难题？
1. 复杂性（Complexity）
软件可以说是人类创造的最复杂的系统类型。大型软件（操作系统、办公软件、搜索引擎）有超过百万行的源代码，上万个不同的文件。而软件工程师通常一次只能看到30—80行源代码（相当于显示器的一屏），他们的智力、记忆力和常人差不多。软件的各个模块之间有各种显性或隐性的依赖关系，随着系统的成长和模块的增多，这些关系的数量往往以几何级数的速度增长。
2. 不可见性（Invisibility）
软件工程师能直接看见源代码，但是源代码不是软件本身。软件以机器码的形式高速运行，还可能在几个CPU核上同时运行，工程师是“看”不到自己的源代码如何具体地在用户的机器上被执行的。商用软件出现了错误，工程师可以看到程序在出错的一瞬间留下的一些痕迹（错误代号、大致的目标 代码位置、错误信息），但是几乎无法完整重现到底程序出现了什么问题。
3. 易变性（Changeability）
软件看上去很容易修改，修改软件比修改硬件容易多了。人们自然地期待软件能在下面两种情况下“改变”： 

a) 让软件做新的事情；

b) 让软件适应新的硬件。但是与此同时，正确地修改软件是一件很困难的事情。
4. 服从性（Conformity）
软件不能独立存在，它总是要运行在硬件上面， 它要服从系统中其他组成部分的要求，它还要服从用户的要求、行业系统的要求（例如银行利率 的变化）。
5. 非连续性（Discontinuity）
人们比较容易理解连续的系统：增加输入，就能看到相应输出的增加。但是许多软件系统却没有这样的特性，有时输入上很小的变化，会引起输出上极大的变化。 这些特性的前四个是佛瑞德·布鲁克斯 （FredBrooks Jr.）在No Silver Bullet一文中提到的，第五个特性是瓦茨拉夫·拉里奇（Vaclav Rajlich）提到的
个人开发流程Personal Software Process（PSP）

软件团队的模式
一窝蜂模式
例如小朋友们刚开始踢足球的时候，大家都一窝蜂地去抢球，球在哪里，一堆人就跟到哪里，这样的模式可以叫一窝蜂模式（Chaos Team）。
不能否认，这样的团队也有，只不过他们在这样的模式下存活的时间一般都不长，没有机会让别人很好地观察。一窝蜂模式可能是一个欢乐而随意的模式，但这是一个好的团队形式么？
当然不是。要把一群小朋友培养成一个团队，需要时间

主治医师模式（Chief Programmer Team，Surgical Team）
就像在手术台上那样，有一个主刀医师，其他人（麻醉，护士，器械）各司其职，为主刀医师服务。这样的软件团队中，有首席程序员（Chief Pro-grammer），他/她负责处理主要模块的设计和编码，其他成员从各种角度支持他/她的工作 （后备程序员、系统管理员、工具开发、编程语言专家、业务 专家）。佛瑞德·布鲁克斯 （Frederic BrooksJr.）在主管IBM System360项目时就采用了这种模式。在一些学校里，软件工程的团队模式往往从这一模式退化为“一个学生干活，其余学生跟着打酱油”。

明星模式（Super-star Model）
主治医师模式运用到极点，可以蜕化为明星模式，在这里，明星的光芒盖过了团队其他人的总和，2004年到2012年的“翔之队”就是一个例子。 明星也是人，也会受伤，犯错误，如何让团队的利益最大化，而不是明星的利益最大化？如何让团队的价值在明星陨落之后仍然能够保持？是这个模式要解决的问题。真正有巨大成就的明星都能意识到团队的作用，
迈克尔·乔丹说过，“Talent wins games, team work wins championship.”

社区模式（Community Model)
社区由很多志愿者参与，每个人参与自己感兴趣的项目，贡献力量，大部分人不拿报酬。这种模式的好处是“众人拾柴火焰高”，但是如果大家都只来烤火，不去拾柴；或者捡到的柴火质量太差，最后火也就熄灭了。“社区”并不意味着“随意”，一些成功的社区项目（例如开发和维护 Linux操作系统的社区），都有很严格的代码复审和签入的质量控制

业余剧团模式（Amateur Theater Team）
这样的团队在每一个项目（剧目）中，不同的人会挑选不同的角色。在下一个剧目中，这些人也许会换一个完全不同的角色类型。各人在团队中听从一个中央指挥（导演）的指导和安排。在学生实践项目或培训项目中，这样的事情经常发生。

秘密团队（Skunk Work Team）
一些软件项目在秘密状态下进行，别人不知道他们具体在做什么。苹果公司1980年代在研发 Macin-tosh之后的系统时，就有两三个团队在不同时期进入秘密状态开发。21世纪的一些创业团队也是处 于类似状态。这种模式的好处是：团队内部有极大的自由，没有外界的干扰（不用每周给别人介绍项目进展，听领导的最新指示等等），团队成员有极大的投入。

特工团队（SWAT）
就像电影电视中的特工组《加里森敢死队》等一样，软件行业的一些团队由一些有特殊技能的专业人士组成，负责解决一些棘手而有紧迫性的问题。例如2000年之前，很多公司都需要专业人士去解决Y2K问题。这些团队成员必须了解传统语言和老式系统，才能胜任这样的任务。现在还有 一些专门做网站安全性服务的团队，也属于这一类型。

交响乐团模式（Orchestra)
想象一下交响乐团的演奏，有下面的特点。
家伙多，门类齐全。
各司其职，各自有专门场地，
演奏期间没有聊天、走动等现象。
演奏都靠谱，同时看指挥的。
演奏的都是练习过多次的曲目，重在执行。



当某个软件领域处于稳定成长阶段的时候，众多大型软件公司的开发团队就会采取这种模式，例如微软公司的Office软件，从Office97、Office XP、Office2003、Office2007到Office2011、 Office2013……

爵士乐模式（Jazz Band）
从外行看热闹的角度看，和交响乐团相比，这种模式有以下特点。
不靠谱。他们演奏时都没有谱子。没有现场指挥，平时有编曲起到协调和指导作用（和迈尔斯合作的编曲吉尔·伊文斯 （GilEvans）也是很有造诣的音乐家）。 也有模式，迈尔斯（姑且称之为架构师）先吹出主题，然后他走到一旁抽烟去了，其余人员根据这个主题各自即兴发挥；最后迈尔斯加入，回应主题，像是对曲子的总结。 人数较少。评论家归纳迈尔斯·戴维斯的特点是：
强调个性化的表达，强有力的互动，对变化的内容有创意的回应。这看上去跟“敏捷的开发模式”有点类似。这样的团队模式和上面的“交响乐团模式”在很多方面都对立，但是两种模式都产生了很受欢迎的音乐作品，因此不能简单地说孰优孰劣

功能团队模式（Feature Team)
很多软件公司的团队最后都演变成功能团队，简而言之，就是具备不同能力的同事们平等协作， 共同完成一个功能


在这个功能完成之后，这些人又重新组织，和别的角色一起去完成下一个功能。他们之间没有管理和被管理的关系。大型软件公司里的不少团队都是采用这种模式。
这些功能小组也称为 Feature Crew，小组内的交流比较频繁。约翰· 巴克斯在1955年管理 FORTRAN语言项目时，就用了类似的团队架构。
巴克斯以蜂窝状的架构来组织工作。每个小组都由一到三个人组成，每个小组都是一个有自主权的单元，可以自由选用最有利于他们完成工作的任何技术。但是，每个小组必须与其他小组就编程规范达成一致……

官僚模式（Bureaucratic Model）




这种模式脱胎于大机构的组织架构，几个人报告给一个小头目，几个小头目报告给中头目，依次而上。
这种模式在软件开发中会出问题。因为成员之间不光有技术方面的合作和领导，同时还混进了组织上的领导和被领导关系。
跨组织的合作变得比较困难，因为各自头顶上都有不同的老板。这种模式如果应用不好，最后会变成“老板驱动”的开发流程

开发流程
写了再改模式（Code-and-Fix）
史蒂夫·迈克康奈尔（Steve McConnell）在这里提到了不少开发流程。第一个提到的开发流程 ——Code-and-Fix，看起来和一窝蜂团队模式非常像。



这个流程也有好处，不需要太多其他准备或相关知识，大家上来就写代码，也许就能写出来，写不出来就改，也许能改好。当面临下面的任务时，也许这个方法是有用的。
“只用一次”的程序
“看过了就扔”的原型
一些不实用的演示程序
但是，要写一个有实际用户、解决实际需求的软 件，这个方法的缺点就太大了。要注意的是，许多学校里的软件工程作业的要求符合上面那三点，所以难怪同学们觉得没有必要用其他的开发方法，“写了再改”足矣！

瀑布模型（Waterfall Model）
当软件行业还在年幼的时期，它从别的成熟行业 （硬件设计，建筑工程）借用了不少经验和模 型。在那些“硬”的行业中，产品大多遵循 [分析→ 设计→实现（制造）→销售→维护] 这个流程。 由于在“硬”行业中产品一旦大规模生产，要再返 回去修改时就非常困难，甚至是不可能的。因此 这个模型描述了单向的、不可逆的生产过程












“最终产品直到最后才出现”是很令人头痛的局限 性，考虑这个制造汽车的故事。
你（用户）提出要发动机、车身、车窗、方 向盘、加速踏板、刹车、手刹、座位、车 灯…… 生产商按照瀑布模型流程给你设计、生产， 六个月后交付。 看到样车后…… 你提出—我当初忘了一件小事，要有倒车 灯： 当倒车的时候，倒车灯会亮。
生产商说： 我要重新设计车尾部，加上倒车灯，把车底 拆开，安装线路，修改传动装置把倒车档和 倒车灯联系起来……我得重新开始。 你说：这不是很小的一件事么？这是小事还 是大事？那么，瀑布模型有适用范围么？我 认为有： 如果产品的定义非常稳定，但是产品的正确 性非常重要，需要每一步的验证 产品模块之间的接口、输入和输出能很好地 用形式化的方法定义和验证 使用的技术非常成熟，团队成员都很熟悉这 些技术 负责各个步骤的子团队分属不同的机构，或 在不同的地理位置，不可能做到频繁的交流

瀑布模型的各种变形
1、生鱼片模型




这个模型解决了各个步骤之间分离的缺点，同时 也带来了一些困扰—究竟什么时候上一个阶段会 结束呢？

2、大瀑布带着小瀑布




在这种瀑布群下，要把各个子系统统一到最后做 系统测试（System Testing）的阶段，难度不是 一般的大啊！另外，在这样的开发流程中，用户 只有到了最后才能看到结果，用户真是等不起

渐进交付的流程（Evolutionary Delivery），MVP和MBP
这个流程是史蒂夫·迈克康奈尔（Steve McConnell）在1996年总结的，但是它其实已经 很接近现在大家谈论较多的迭代式开发流程。当 系统的主要需求和架构明确之后，软件团队进入 了一个不断演进的evolution循环中：[开发→发布 →听取反馈→根据反馈做改进]




这个软件什么时候才最后完成呢？下面几个条件
满足一个即可。
时间到了。
钱花光了。
用户满意了（或者很不满意，不再给钱 了）。
在渐进交付的流程中，我们假设一下，当用户看 到第一个版本的时候，他们就对这个产品很不满 意，完全没有任何购买或使用的意愿。在这种情 况下，整个团队为第一版所做的各种投入都浪费 了。这个问题的一个根源是：产品团队得到用户 的反馈太晚了。那么，我们能否让用户更早地给 产品团队反馈？
从2009年开始，一些互联网产品 团队在试验MVP方法：MVP——Minimal Viable Product，最小可行产品，又称为Minimal Feature Set，最小功能集。
具体的做法是：把产 品最核心的功能用最小的成本实现出来（或者描 绘出来），然后快速征求用户意见。例如，一个 社交网站已经有很多用户，都是免费的，产品团 队想设计一个付费的VIP服务，MVP的做法可以 是这样—在目前的用户入口页面中加一个“VIP服 务”的链接，指向一个简单的 介绍页面（用最小成 本做出来）。观察到底有多少用户点击这个链 接。如果点击量太小，那么这个VIP服务就不用 做了。另一个例子，一个团队要打造一个餐饮推荐服务，原来的V1计划包括网站要适配三种浏览 器，餐馆登录和上传数据，手机客户端（安卓和 iOS），以及手机和网站的同步，用户之间的互动，菜谱管理，照片管理，等等。这个计划如果 全部实现，估计要花一年时间，但是在这一年时 间中用户没法提供任何反馈（因为大部分功能都 没能实现好）。如果用MVP的思路，团队会找出 最关键、最小的功能集（用户用iPhone应用能看 到北京市某个区的餐馆推荐），快速实现，三个 月就可以听到用户的反馈。这样是不是会更好？ MVP的指导思想和渐进交付相似，但是它更强调 更早获得用户反馈，为此可以在产品完成之前就发布，它也强调产品的核心价值（产品最区别于 竞争产品的地方），为了突出核心功能，别的辅 助功能可以不考虑或者用别的平台提供的服务来 代替。 正如所有的方法论那样，MVP也有它的适用范围，和它相对应的，是Maximal Beautiful Product（最强最美产品，MBP）的思路，如果 对用户的需求了然于心，或者产品团队比用户更 了解用户的需求，为何不把产品最全、最美的形 态展现出来，一举征服用户？大家可以回顾第一 版的iPhone（2007年）和 iPad（2010），它们 是MVP么？显然不是。如何能做到MBP？这对产品团队有更高的要求

敏捷的流程



敏捷开发原则
1. 尽早并持续地交付有价值的软件以满足顾客需求
2. 敏捷流程欢迎需求的变化，并利用这种变化来 提高用户的竞争优势
3. 经常发布可用的软件，发布间隔可以从几周到几个月，能短则短
4. 业务人员和开发人员在项目开发过程中应该每 天共同工作
5. 以有进取心的人为项目核心，充分支持信任他们
6. 无论团队内外，面对面的交流始终是最有效的 沟通方式
7. 可用的软件是衡量项目进展的主要指标
8. 敏捷流程应能保持可持续的发展。领导、团队 和用户应该能按照目前的步调持续合作下去
9. 只有不断关注技术和设计，才能越来越敏捷
10. 保持简明—尽可能简化工作量的技艺—极为重要
11. 只有能自我管理的团队才能创造优秀的架构、需求和设计
12. 时时总结如何提高团队效率，并付诸行动


敏捷的步骤
第一步：找出完成产品需要做的事情—Product Back-log。
Backlog翻译成“积压的工作”、“待解决的问题”、“产品订单”，都可以。产品负责人主 导大家对于这个Backlog进行增／删／改的工 作。每一项工作的时间估计单位为“天”。

第二步：决定当前的冲刺（Sprint）需要解决的事情—Sprint Backlog。
整个产品的实现被划分为 几个互相联系的冲刺（Sprint）。产品订单上的 任务被进一步细化了，被分解为以小时为单位。 如果一个任务的估计时间太长（如超过16个小 时），那么它就应该被进一步分解。订单上的任 务是团队成员根据自己的情况来认领。团队成员 能主导任务的估计和分配，他们的能动性得到较 大的发挥。

第三步：冲刺（Sprint）。
在冲刺阶段，外部人士不能直接打扰团队成员。一切交流只能通过 Scrum大师（Scrum Master）来完成。这一措施 较好地平衡了“交流”和“集中注意力”的矛盾。有 任何需求的改变都留待冲刺结束后再讨论。 冲刺期间，每天要开一个每日例会（Scrum Meet-ing），团队成员大多站着开会，所以又称每日立会。大家依次报告：
我昨天做了啥
我今天要做啥
我碰到了哪些问题
每日立会强迫每个人向同伴报告进度，迫使大家把问题摆在明面上。同时启动每日构建，让大家每天都能看到一个逐渐完善的版本。用简明的图表展现整个项目的进度，这个图最好放在大家工作的环境中，或者每天传达给 各个成员：图表可以是燃尽图（Burn Down Chart，想象我们把一堆Backlog的木头给烧光）。冲刺阶段是时间驱动的（Time-boxed），时间一到就结束。这个特点看似不起眼，但其实它有效地断了各种延期想法的后路，很高明。

第四步：得到软件的一个增量版本，发布给用户。然后在此基础上又进一步计划增量的新功能和改进

敏捷对团队的要求

敏捷对团队的要求很简单：自主管理（Selfmanag-ing）、自我组织（Self-organizing）、多 功能型（Cross-functional），但是这很难做到。 软件项目的团队各式各样

1. 自主管理：以前领导布置了任务，我们实现就 可以了，现在要自己挑选任务；每次Sprint结束 之后，还要总结不足，提出改进，并且自己要实 施这些改进。“自主管理”不等于“没有管理”。
2. 自我组织：以前做好自己的事情就好了，安心下班。现在每个人要联合起来对项目负责，有人 工作落后了还要帮助他改进，项目缺少某类资源 还要自己顶上去。
3. 多功能型：以前规格说明书由PM来写，测试 由测试人员来做，现在每个人都全面负责，自己 搞定规格说明书，和别人沟通，同时自己搞定测试。
如果你的团队很弱，那么强行把敏捷（或者其他高级方法）套在上面也没有用，也许还会适得其 反，往往需要多次Sprint才能让Scrum走上正轨。 换句话说，如果你的团队已经有这么厉害（自主管理、自我组织、多功能型）的一帮人，那么用不用Scrum都能写好软件