构建之法阅读笔记之四

构建之法阅读笔记二

第七章 MSF

微软公司中关于软件开发的思想和宣言有一个方法论——微软解决方案框架（Microsoft Solution Framework，MSF），也就是微软推荐的软件开发方法

7.2 MSF 基本原则

1. 推动信息共享与沟通（Foster open communications）

2. 为共同的远景而工作（Work toward a shared vision）

“共同的远景” 是指产品的远景。我们做一个产品，不管是应用软件、行业软件，还是通用软件，要明确项目的目标是什么。

• 这个目标必须是明确的，没有二义性；
• 这个目标不是当前就能达到，必须是通过努力才能达到的；

3. 充分授权和信任（Empower team members）

这一点的关键是 “授权” 这个词，授权（Empower）有两个意思：

• 给某人权力和权威
• 给予某人更多自信和自尊在一个高效的团队中，所有的成员都应该能得到充分的授权，他们有权在职权范围内按照自己的承诺完成任务，同时，他们也充分信任其他同事能实现各自的承诺。类似地，团队的顾客（包括内部和外部的顾客）也认为团队能兑现承诺，并进行相应的规划

充分授权的管理方式是 MSF 的核心观念之一。MSF 团队模型就是建立在以下两个原则上的：

• 平等协作—成员之间、团队之间是平等协作的关系
• 充分授权给团队和成员

这就是为什么 MSF 团队模型是网状，而不是层次结构。这样做有什么好处？好处有两点：

• 被授权的人会承担起自己对项目的责任，同时也期望同事们也同样对项目负责
• MSF 提倡自下而上的计划，每个人有充分的权力估计并决定自己的任务需要多长时间，而不是上级交给的时间，这意味着让真正做这件事的人按照自己的估计去完成任务。这样做的结果是啥？是人人都会支持项目的计划和时间表，因为这个时间表是每个人自下而上订出来的
• 充分授权在 MSF 团队模型的另一个含义是：信任，鼓励团队成员成长，每人都可以在某一时段。

4. 各司其职，对项目共同负责（Establish clear accountability and shared responsibility）

在项目进展的过程中，对于每一项任务，每个人都要明确以下几点。

• Who：谁负责
• What：做什么，具体的执行方案，什么叫做 “做好了”
• When：什么时候开始，什么时候结束
• Why：为什么是这样安排（和项目的远景是否吻合），在什么情况下可以变更？

与 “信息共享与沟通” 原则相呼应，这样的安排能让所有人都明确自己的职责，同时有“大局观”—知道别人在做什么，为什么，以及整个项目的目标

5. 交付增量的价值（Deliver incremental value）
现在的软件产业，特别是和互联网相关的产业，变化非常快，用户希望产品团队经常提供更新，以适应新的需求。我们要保证在两个方面保证客户的利益：

• 我们提供的新版本对用户真的有价值
• 和客户商讨一个最优的新版本的发布频率

6. 保持敏捷，预期和适应变化（Stay agile, expect and adapt change）

软件工程，唯一不变的是变化。所以干脆别幻想客户的需求会在第一时刻很明确，然后保持不会变。要注意，我们是预期变化，不是期望变化

除开外部原因，团队内部也在变化，我们对技术的掌握每天都在提高，原来认为不可能的事可能变得容易。我们对客观世界和软件系统的了解每天都在深化，原来觉得没问题的小细节忽然成了大问题。甚至原来一起打拼的同事忽然要离开…… 这些都要求我们团队保持敏捷的身段

7. 投资质量（Invest in quality）

对质量的重视，引起对质量的投资，引起对人、过程和工具的投资。

• 投资要讲效率
• 投资要讲时机
• 投资是长期的

8. 学习所有的经验（Learn from all experiences）
在学习过去的经验的同时，也要避免让过去的经验妨碍解决现在的问题
这一原则有两个含义——

• 把经验总结出来
• 分享经验

MSF 在每一个里程碑结束时都要做一个 “里程碑回顾”，这个回顾不必等到整个项目结束才做。这样做的好处是，大家对最近的成败都记忆犹新，能提供比较准确和全面的反馈；如果发现了错误，可以马上研究解决办法，在下一个里程碑中通过实践来验证。另外，一些好的做法可以及时得到总结和推广。

在项目结束时，MSF 推荐请团队以外的专家来主持召开 “事后诸葛亮”会，这样的专家会比较系统地总结团队的成功经验和失败教训，同时也客观评价团队的一些特性和团队的开发过程管理，这样能促使团队成员以客观、向前看、解决问题的心态来参加 “事后诸葛亮” 会，避免主观臆断或相互指责。

9. 与顾客合作（Partner with internal and external customers）

第八章 需求分析

8.1 软件需求

①获取和引导需求：软件团队需要找到软件的利益相关者，了解和挖掘他们对软件的需求，引导他们表达出对软件的需求；需求还可以来自各种管理机构；需求不仅来自外界，还可以来自软件企业本身；需求还可以来自技术团队本身；有些需求的目的是要更好地了解用户的行为和需求。

②分析和定义需求

③验证需求

④在软件产品的生命周期中管理需求

8.2 软件产品的利益相关者

8.3 获取用户需求——用户调查

几种常用的用户调研方法：焦点小组、深入面谈、卡片分类、用户调查问卷、用户日志研究、人类学调查、眼动追踪研究、快速原型调研、A/B 测试

8.4 竞争性需求分析的框架——NABCD 模型

1. N（Need，需求）

你的创意解决了用户的什么需求？这个需求可以是明确的、公开的（例如：希望能上网玩三国杀）也可能是说不清道不明的，例如——以前没人说：嗯，如果我能找到这样一个网站，我可以去偷菜，就好了…… 我们要充分了解用户的痛苦，他们对已有软件、服务不满意的地方。

2. A（Approach，做法）

好，你找到了需求，下一步怎么办，得看看你有什么招数，特别是独特的招数，来解决用户的痛苦。你不能说我会 C++，所以我一定可以写好这个软件。你得有独特的办法，例如，有人脸识别技术，会做超大规模的数据处理。那你（你的团队）会什么呢？只会冒泡排序？这些招数不光是技术上的，也可以是商业模式上的（例如，我们第一个做众包的服务）、地域的（例如，我们对本市的公交线路很熟）、人脉的（例如，我们认识很多大学生）、行业的（例如，我们有地图测绘行业的资质），或者是成本上的（例如，我们能找到更便宜的资源来维护网站）。

3. B（Benefit，好处）

这时候你已经有了独特的做法，那你这个产品 / 服务会给客户 / 用户带来什么好处呢？如果用户已经有一个解决方案（例如用户已经在用 QQ 聊天），那你的新的聊天软件具体有哪些好处，能让用户离开现有产品，使用你的产品呢？这还有一个用户迁移成本的问题——用户要花费多少精力、时间、金钱才能得到你的产品的好处？如果你要求用户必须有 8GB 内存、最好的显卡、10Mbps 以上的宽带连接，才能使用你的 “更好的” 视频聊天工具，那么会有多少用户愿意支付这个成本呢？

4. C（Competitors，竞争）

竞争对手也没有闲着，这个市场有多大，目前有多少竞争者在瓜分，你了解么？你的产品如果不是最先进入某个市场的，你还能赢么？先进入市场的产品，有所谓的先发优势（FirstMover Advantage，FMA），当然也有劣势。后面进入市场的产品，有种种不利的因素，但是也有后发优势（Second Mover Advantage，SMA）。

5. D（Delivery，推广）

在实际项目中经历多次的 NABC 之后，许多人意识到这个框架还应该加一个元素 D：Delivery。怎样把你的创新产品交到用户的手中？例一，你想到了一个好主意，建一个比 hao123 更好的导航页面！我们姑且认为 NABC 都没问题，那如何把这么好、这么简单的产品交到（Deliver）用户手中呢？例二，你想到了一个手机的应用，NABC 都不错，那如何把产品交到千万个用户手中呢？

8.5 功能的定位和优先级

杀手功能、外围功能、必要需求、辅助需求

我们以一个英汉词典软件为例子来说明。

杀手功能：OCR 文字识别技术，可以在屏幕上取词解释，拥有独家权威词典，等等

外围功能：良好的界面设计，在各个平台上都能运行

必要需求：单词短语释义的准确性（如果达不到这一点，用户就不会来使用）

辅助需求：可以做各种皮肤（这也许能让一些用户更喜欢这个软件，但不是决定因素）

这四个象限能让软件团队清楚地看到自己感兴趣的功能处于什么地位，有了这些分析，我们就可以决定怎么处理不同类型的功能。 重要的是，不要把资源平摊到所有象限中，而是倾斜到可以产生差异化和独特用户价值的地方。

8.7 分而治之（Work Breakdown Structure）

一个团队项目要在一段时间内完成诸多任务，满足用户的需求，实现团队的目标，同时还希望项目能维持良好的技术架构，以便持续开发，千头万绪，从哪里入手？WBS 就是一个例子

WBS 通常从最终的产品开始，一层一层往下，把大型交付件（Deliverable）分割为小型、具体的交付件。这样的分割可以持续下去，直到 WBS 的使用者（开发团队、接收方）达到共识。从数据结构方面来看，WBS 分割的结果是一棵树。所有子节点都最终有一个根节点。每个节点描述的是要交付的产品或文档，而不是开发团队的努力或花费（各个叶节点的成本可以作为次节点的属性展现出来）。做好 WBS 的几个要点：

• 保证所有子节点覆盖了全部父节点包含的内容
• 保证各个子节点不要相互覆盖

叶子节点要保证足够小，能在一个里程碑中完成。在通常的软件项目中，叶节点的成本最好不要超过两周。如果团队成员从常理出发，认为叶节点不宜再分下去，那就可以停止

从结果（Outcome）出发构建 WBS，而不是从团队的活动（Action）出发

第九章 项目经理

9.1PM 是啥

软件团队里除了能写代码、测试代码和画图做设计的成员，还有一类角色，不做上面这些事情但也很重要，我们叫他们项目经理——PM

PM 的 M 就是 Manager，但是 P 有这几种：Product Manager、Project Manager、Program Manager，在不同的行业和公司，他们的作用各不相同。接下来介绍的是项目经理——Program Manager

• Product Manager：产品经理——正确地做产品
• Project Manager：项目经理——正确地做流程
• Program Manager：微软的职位名称
  微软产品团队三足鼎立的角色分配就是 PM、开发、测试。PM 负责除产品开发和测试之外的所有事情。从某种意义上说，是前面两种角色的综合。微软通常有专门的产品策划（Product Planner），他们和市场部门的专职人员一起，负责产品的长期发展和市场推广

9.4 PM 的能力要求和任务

能力要求：

1. 观察、理解和快速学习能力——PM 要能够在一个新的领域中很快上手

2. 分析管理能力
每天项目中发生的事情千头万绪，PM 要能够分析出重点，找到优先级，做判断、做决定…… 一个项目和一个人一样，每天都会碰到各种问题：

• 重要而紧急的

• • 网站崩了！
  • 程序员小飞突然提出离职！

• 重要而不紧急的

• • 按照流量和内容的发展趋势，三个月后，目前的架构似乎撑不住，但是现在还凑合……
  • 程序员们都不写文档，他们三个月前说等忙过之后会写的，但是……

• 不重要而紧急的

• • 老板的老板问到了项目的进度！要写一个 PPT，向若干人征求意见，并及时得到反馈

• 不重要且不紧急的

• • 领导想召开全公司大会，要表演节目……

3. 一定的专业能力
如果一定要说专业能力的话，PM 的专业就是理解和表达，你能否理解不同人的心理、需求和言外之意？你能否借助文字、图表、草图，甚至代码来清晰准确地表达自己的想法？PM 通常也能写代码，能玩转 Excel、PPT、Visio、甘特图，会 PS，有文字功底，写的博客有人爱读，反正，总得有几招绝活吧！不用说还要有大量的阅读，对 IT 行业、用户心理、社会都要有广泛的了解

4. 自省的能力
一个 PM 做第一个项目时可以拍脑袋定工期，拍胸脯打包票，最后拍屁股走人（谁没年轻过呢），但是失败之后要有自省和自我改进的能力

第十章 典型用户和场景

10.1 典型用户和典型场景

①怎样定义典型用户？

我们首先要定义用户的角色。正如戏剧中有正面和反面的角色，软件系统中也有受欢迎的和不受欢迎的典型用户。

• 受欢迎的典型用户——指那些按设计者的期望使用系统的用户，如 “网站的购物者”
• 不受欢迎的典型用户——指那些有不正当目的的用户，如在一个房地产业主论坛中滥发房屋中介广告的用户——这些用户也许在别的系统中（如房屋中介论坛）是受欢迎的

典型用户只是我们的设想，还要和这些典型用户的代表交流，理解用户，理解他们的工作方式和需要。然后再修改，细化典型用户

②从典型用户到场景

有了典型用户之后，我们还得决定每一个典型用户的目标——他 / 她使用系统想要达到什么目的。对于每一个目标，列出达到目标所必须经历的过程，这就是场景，也可以叫故事。注意，有些场景描述了成功的结果，有些场景描述了失败的结果。用户和系统有成百上千种可能的交互情况，写场景时要有针对性。

③场景怎么写？

• 首先针对每一个场景，设计一个场景入口（描述场景如何开始）
• 接着描述典型用户在这个场景中所处的内部和外部环境（内部环境指心理因素等）
• 然后给场景划分优先级，按优先级排序写场景

④场景之间如何区分呢？

• 找到这个场景的特殊之处，对于共同的流程可以一笔带过，重点描述场景中特殊的因素
• 把场景组织成一个故事，这样就能把一个完整的用户与系统交互的流程记录下来，以后进行产品演示或验收都可以以此为基础

10.2 用例

和典型人物、典型场景的方法类似，用例（UseCase）也是很常用的需求分析工具。用例有这样一些 基本元素：

• 标题：描述这个用例要达到的目标
• 角色（Actor）：和软件系统交互的角色，例如用户，其他实体，甚至时间（在描述一些和时间相关的场景时有用）
• 主要成功场景（Main Success Scenario）：一系列步骤描述角色是怎样和系统交互，从而达到目标的
• 步骤（Step）：描述每一步的交互（例如一套正常的 ATM 取款流程）
• 扩展场景（Extension）：描述一些扩展的交互，例如一些意外情况（例如取款时账户余额不足）

10.3 规格说明书（Spec）

①规格说明书（Specification）简称 Spec，分为以下两种：

1. 软件功能说明书（Functional Spec），主要用来说明软件的外部功能和用户的交互情况（把软件当作一个黑盒子）

2. 软件技术说明书（Technical Spec），又叫设计文档（Design Doc），主要用来说明软件内部的设计规范（把软件当作一个透明的箱子）

②写好一个 Spec

第一，定义好相关的概念

第二，规范好一些假设（Assumptions）

第三，避免一些误解，界定一些边界条件

第四，描述主流的用户 / 软件交互步骤

第五，一些好的功能还会有副作用

第六，服务质量的说明

第十一章 软件设计与实现

11.2 图形建模和分析方法

思维导图、实体关系图、Use Case Diagram

11.3 其他设计方法

形式化的方法、文学化编程

11.5 开发阶段的日常管理

第十二章 用户体验

12.1 用户体验的要素

用户的第一印象

从用户的角度考虑问题

软件服务始终都要记住用户的选择（长期的使用只会使软件更好用）

短期刺激 长期影响

不让用户犯简单的错误

注重用户体验和质量

情感设计

12.3 评价标准

对于一个软件的用户界面，我们有没有什么评价标准呢？可以参考费茨法则（Fitts law）、Nielsen 启发式评估十条原则以及其他经验。下面是邹欣老师在自身实践的基础上总结的一些原则：

1. 尽快提供可感触的反馈系统状态

2. 系统界面符合用户的现实惯例（Familiarity，Avoid Surprise）

与用户沟通，软件系统要使用用户语言而不是开发者语言，所用的概念要贴近生活实际，而不是用学术概念或开发者的概念。我们说的生活实际，最好是目标用户的实际生活体验。

3. 用户有控制权

操作失误可回退，要让用户可以退出软件（很多软件都没有退出菜单，这是导致用户反感的一大原因）。用户可以定制显示信息的多少，还可以定制常用的设置。

4. 一致性和标准化

在软件中，对同一事物和同类操作的表示用语，各处要保持一致。例如，某词典软件有 “帮助用户收集生词并且背诵生词” 的功能。这个功能要有明确一致的称呼，不能混杂着叫“单词本”、“生词本”、“Word List”、“Word Book”、“单词文件”…… 等等。

5. 适合各种类型的用户

6. 帮助用户识别、诊断并修复错误

7. 有必要的提示和帮助文档

不需要文档，用户就能使用自如，当然更好，必要时还可以提供在线帮助。如果软件和用户的工作相关（而不是简单的游戏），那么基本的提示和帮助文档还是很有必要的，而且也要提供便利的检索功能。文档要从用户的角度出发描述具体步骤，并且不要太冗长。

第十三章 软件测试

13.1 名词解释

Bug ：软件的缺陷

Test Case ：测试用例。测试用例描述了一个完整的测试过程，包括测试环境、输入、期望的结果等

Test Suite ：测试用例集。即一组相关的测试用例

13.2 Bug 解释与实例

①Bug 可以分解为：症状（Symptom）、程序错误（Fault）、根本原因（Root Cause）

症状：即从用户的角度看，软件出了什么问题

程序错误：即从代码的角度看，代码的什么错误导致了软件的问题

根本原因：错误根源，即导致代码错误的根本原因

②Bug 例子

症状：用户报告，一个 windows 应用程序有时会有在启动时报错，继而不能运行

程序错误：有时候一个子窗口的 handle 有空，导致程序访问了非法内存地址，此为代码错误

根本原因：代码并没有确保创建子窗口，因此子窗口的 handle 变量有时会在访问时处于未赋值状态（为空），导致出现代码错误

13.3 测试方法

①黑箱：指的是设计测试的过程中，把软件系统当做一个 “黑箱”，无法了解或使用系统的内部结构及知识。一个更准确的说法是行为测试设计，即从软件的行为，而不是从内部结构出发来设计测试

②白箱子：指的是在设计测试的过程中，设计者可以 “看到” 软件系统的内部结构，并使用软件的内部结构及知识来选择测试数据及具体的测试方法。

第十四章 质量保障

14.1 软件质量

软件 = 程序 + 软件工程

软件（质量） = 程序（质量） + 软件工程（质量）

14.2 软件质量的保障与软件的测试

软件测试：运用一定的流程和工具，验证软件能实现预先设计的功能和特性，工作的流程和结果通常是可量化的

软件质量的保障工作：软件团队为了让软件达到事先定义的质量标准而进行的所有活动，包括测试工作

第十五章 稳定和发布阶段

15.1 从代码完成到发布

第一步：开发者提交参加会诊的 Bug 和修改方案，以及伙伴测试结果。开发者必须向与会者报告的是：

• Bug 是什么
• 危害是什么，如果不修复，有何后果
• 用户会有什么变通办法
• 是否经过代码复审，是否经过伙伴测试

第二步：会议决定是否同意修改方案
决定哪些缺陷必须现在就进行修复，哪些可以推迟到下一个里程碑。会诊应该对每一个修复选择下列处理方式。

• Must——必须修复，缺陷很严重，修复方案可行，相关的测试都通过
• More Info——需要更多的信息
• No——不能接受，可能是推到下一个里程碑，可能是提出的解决方案不符合要求
• Like——可能，不一定必须修复，但是解决方案相对比较安全。在更复杂的项目中，可以考虑引入这一个中间的状态 “Like”（在相对简单的系统中，这个选项可以不用）。如果在今天的会诊中有“Must”，那么处于待命状态的“Like” 修复就可以一起集成到代码库中。如果没有 “Must” 级别的修复，那么 “Like” 级别的修复就只能处于 “待命” 状态，直到以后出现了 “Must” 级别的修复为止

第十六章 IT 行业的创新

影响产品竞争的各种因素

• 产品行业的因素
  这是影响产品发展的最重要的因素，2012 年流传着一句俗话——“站在风口上，连猪都可以飞起来”，就是说明产业发展的成长期（竞争产品少，市场空间大，用户容忍度强）能给产品提供巨大的助力。相反，如果是在一个产业的衰落期进入这个产业（例如，在 2008 年做小灵通手机业务，在 2013 年进军网络团购市场，等等），那么就会面临巨大的发展阻力。
• 公司和市场因素
  公司在目前目标用户中的品牌号召力如何？公司的现有市场能力如何？现有的市场能力能帮助打开新的领域么？从传统的产品开发角度来看，“市场”总是在产品之后才出现，而且和 “产品开发” 似乎没有直接的联系。但是从长期来看，产品的质量就是最有效的市场能力，产品经理往往就是市场经理。
• 团队执行因素
  根据产品特性的不同（基础软件、企业管理软件、行业通用软件、办公软件、互联网服务软件、移动应用软件等），商业模式不同，团队的战略也会不一样。在正确的时间，有正确的产品，却执行了错误的策略，或者不能做出决定，那么产品也会失败。执行力的一个有效衡量标准是一个决定需要多少次会议才能达成。一些团队对市场展现的机会往往陷入过度的分析和评价，力争要弄清所有情况再动手，最后的结果是动不了手。这是 “分析麻痹”（Analysis Paralysis）。
• 产品的价值因素
  产品给用户带来什么价值，这是和 “软件工程” 最相关的内容。考虑新产品或产品的新功能时，团队要问：我们给用户带来了什么价值，这个产品是提供了独家的价值，还是 “人有我也有” 的价值？这个价值足以让本产品和目前市场上已有的产品区分开么？我们怎么能进一步放大产品差异性？让我们越来越领先，或者让用户觉得我们很领先？我们是否在非差异化功能上花费了太多时间和资源？

第十七章 人、绩效和职业道德

①RASCI 模型

R：Responsible，负责把具体事情做好

A：Accountable，对任务负全责，有批准的权利

S：Support，对任务提供支持，辅助任务的完成

C：Consulted，咨询，拥有完成项目所需的信息或能力的角色

I：Informed，知会者，应该事后及时通知结果的角色

②团队合作的阶段：

（1）萌芽阶段，就像小苗破土而出，柔弱但充满希望

（2）磨合阶段，就像一个人的青少年时期，充满了对个人、同伴和团队的疑惑和冲突

（3）规范阶段，从磨合阶段毕业，进入规范阶段的团队，成员们意识到光争吵时没有用的，大家还是要协同作战

（4）创造阶段，经历了萌芽、磨合、规范阶段，现在团队终于可以创造一些有意义的东西

③不管从事哪一个职业，不管你是属于哪个岗位上的，都必须具有职业道德，软件工程师同样也需要

后记和个人感想

这本书的作者邹欣老师在微软公司工作，他在整本书中把对软件构建的方方面面都写得很清楚，包括需求，设计，开发，测试，项目管理...... 甚至国内很多公司都无法做到像书中说的流程那么全面和到位。作者的思路很清晰，文字也很有趣，让人欲罢不能。全书都有很大的参考价值，至少对于我目前这样的状态的程序员来说，了解自己要怎么做，做的方向比要做什么更重要，本书提供了很多建议和方法，比如 PSP（Person Software Process，在我看这本书之前，完全没有听说过 PSP 这个东西，），也由此了解到作为一个软件工程师，任务清单里面不仅只有要编好程这一项而已，还有计划，需求，测试，评估工作量等能力需要刻意培养。

这本书最具特色的一个地方是把很多生涩难懂的概念用学生之间对话的诙谐幽默、生动风趣的场景来展现了出来，甚至还加入了一些电影中的经典台词、一些足球术语和篮球明星的专属名词，让我这个电影迷足球迷篮球迷一边读一边大呼过瘾，更开心的是学习到了很多知识，尤其是在软件工程项目开发过程中的许多技巧和需要注意的问题。例如在第五章讲解软件团队模式的时候用足球队的守门员、前锋、中场和后卫来类比，非常容易理解，不仅有趣而且易懂；再比如在第八章的需求分析中的人类学调查的讲解中，利用一个软件工程课上的同学的顿悟生动形象地讲解了人类学调查这个晦涩难懂的知识点。这本书还创造了很多有趣的人物形象：老成的项目带头人阿超、知识总是马马虎虎掌握的果冻、爱好丰富的小飞和产品经理小李，每个人物都很饱满，读这本书的时候也很容易让我这个读者产生代入感，读起来自然又快又让我印象深刻。

书中让我最茅塞顿开的地方是第二章的个人技术和流程以及软件工程师的成长，改变了我长期以来对我这个专业发展方向的很多困惑和误解，我一直觉得我作为一个程序员只要学如何写代码，顶多把数据结构和算法掌握清楚、操作系统和计算机网络的知识学习扎实，会写前端会折腾数据库就可以了，其他的能不了解就不用了解。我对于职业规划还一直还停留在学好算法计算机基础就可以进大公司的非常低级的想法层面上，读了这本书之后我才明白自己其实离一个优秀的程序员还差得很远，虽然我一直在努力为实现进入大公司成为优秀的软件工程师这一目标而努力，但是其实努力得还远远不够，而且光局限自己把代码写好是远远不够的，团队协作、小组敏捷开发、迭代会议、单元测试和代码复审这些部分都是我之前完全不了解的，而在我读完以后更有针对性和方法来实现自己的目标，开始关注踏实的学习和提升自己，并更加注意和身边的同学合作写代码并和自己身边的同学一起互相学习，这也提示我这样的初级软件工程师要如何让自己成长起来。

另外，我们这学期除了学习软件工程的理论外也在做一个团队项目，而我正是我们整个项目的 Program Manager。这本书中所介绍的 NACBD 模型、分而治之方法、敏捷开发小组会议和燃尽图、结对编程这些方面的知识点和技巧我们都很好地应用到了自己的项目开发的整个过程之中去。我们每个人小组成员都利用 NACBD 模型在组内会议中分析了自己所想要用的一款软件，通过对比我们最终决定做一个桌面应用软件；我们通过分而治之的方法，利用 WBS 图拆分我们的需求，然后利用甘特图，结合每个组员的承诺工作时间把所要实现的所有功能具体化到每一天每一小时；我们在冲刺阶段采用了结对编程的方法，而且还实现了敏捷开发，并完成了至少 2 天一次的冲刺会议，每个人汇报自己的工作并展望第二天要做的事情，然后完善燃尽图；而且我们团队利用码云托管平台来管理代码，每个人做自己的模块，并保证一天至少 merge 一次所有人的分支，大大提升了团队协作的效率，每个人都完成了什么工作也是一目了然。可以说《构建之法》这本书对我们的团队的整个开发进展阶段都具有相当强的指导意义，也算是我们进行正式软件开发项目的一本入门引导手册了。

最后，《构建之法》的正文以及练习与讨论中有大量有价值的引用，这些内容可以让我们了解更多更广的知识，练习中大量的习题如果都能够独立思考并想办法解决的话，对我们的实际动手能力会有很大提升。

总之，这是一本值得反复阅读的技术书、一本可以教会我们怎样去做好一名合格软件工程师的书、一本无论是对在校学生还是一线软件工程师都会受益的书、一本很适合阅读并且反复阅读的书。很感谢何老师在软件工程这门课上为我们推荐了这么一本好书。