《构建之法》阅读笔记二
这次的阅读笔记是《构建之法》的七到十二章，记录的内容如下：
7实战中的软件工程
7.2 MSF九项基本原则
·推动信息共享与沟通
·为共同的远景工作
·充分授权和信任
·各司其职，对项目负责
·重视商业价值，提供渐进的价值
·保持敏捷，预期和适应变化（预期变化，不是适应变化）
·投资质量
·学习所有经验
·与顾客合作
7.3MSF团队模型
·测试团队要做的事：发现问题和解决问题
7.4MSF过程模型
·阶段：团队在某段时间集中精力做一件事情，团队的重心随阶段的转移而转移
·里程碑：上一阶段的结束，下一阶段的起始。
7.5实战中的软件工程
·注重与实际结合，而不是盲目跟风
·切忌Cargo Cult，否则最终只会导致失败
7.6联系与讨论
软件工程原则：
·使用分阶段的计划管理流程，强调需求分析和抵制随意改变项目计划
·持续检查认证，在早期发现问题
·坚持规范的产品控制--验证过的程序或文档只有通过规范的流程才能修改
·使用现代的编程方法和工具
·确保团队成员能够分阶段、分模块地产生可以测试、可以复审的结果，并对结果负责
·用少而精的人员，减少交流成本，提高效率
·持续地收集数据和反馈，争取通过多个迭代实现流程的改进和整体软件质量的提高
看完这一章，我认为这本书更适合已经踏入工程领域的人阅读，我目前的阶段虽然还不太适合，但对我接下来的学习仍有重要的指导意义。在任何一个项目中，或大或小，都应该遵守那几个原则，减少代码的出错率，降低维护成本。根据课程安排，下学期我就会与人合作完成一个项目，在一个团队中，制作一个项目要有清晰的计划，项目的完成流程，最重要的是与实际结合，切忌货船效应。在项目开发过程中，必不可少的是与人打交道，学会与人交流，了解彼此的需求，对于项目的开发和后期的维护和更新会有很大的帮助。个人方面，写完一部分代码之后，必须进行测试，减少后期代码修改的成本，同样这也是一个自我检测，毕竟错误越早解决越好。
8需求分析
8.1软件需求
·获取和引导需求
·分析和定义需求
·验证需求
·在软件产品的生命周期中管理需求
软件的需求：①产品功能性需求；②对产品开发过程的需求；③非功能性需求；④综合需求
8.2软件产品的利益相关者
·从软件出发，推演出利益相关者，争取每个人的意见，虽不能让人人满意，但尽可能做到最好。
8.3获取用户需求-用户调研
·焦点小组
·深入面谈
·卡片分类
·用户调查问卷
·用户日志研究
·人类学调查
·眼动跟踪研究
·快速原型调研
·A/B测试
8.4竞争性需求分析的矿建
·NABCD模型：需求、做法、好处、竞争、推广
8.5功能的定位和优先级
·杀手功能/外围功能
·必要需求/辅助需求
8.6计划和评估
·目标、估计、决心
·找出估计后面的假设
·提高估计能力的招数
·影响软件成本的因素：产品、平台、人员、项目
8.7分而治之
·WBS产品：保证所有子节点覆盖全部父节点包含的内容；保证各个子结点不要相互覆盖；叶子节点保证足够小，能在一个里程碑中完成；从结果出发构建WBS，而不是从团队的活动出发。
看完这章之后，对于产品的需求明白更深。一个软件的完成，不仅仅来自客户的需求，还有制作者的理解，更有各户将其投入使用后所能得到的效益。客户的需求非常重要，但有时在交流的过程中，客户也不能准确表达自己的需求，所以在制作的过程中，需要不断与客户交流，降低产品的维护成本；其次是制作者的理解，我们或做过或见过考研默契的互动游戏，但是最懂结果大都不理想，软件的最终成型模样有很大一部分原因取决于制作者的理解。客户将产品投入使用之后获得的效益往往是最重要的，一个软件好不好，并不取决于客户的描述和制作者精彩的制作，而是取决于使用它的普通人，举个例子：我装杀毒软件只装一个火绒，而普通人装杀毒软件恨不得装7个加速球组成小金刚。一对比就出来了，真正的好软件需要“傻瓜”都会用。除此之外，还要考虑软件制作和维护的成本，尽可能地降低成本，是一个项目公司真正缺少的。
9项目经理
9.1PM是啥
·product manager：产品经理-正确做产品
·project manager：项目经理-正确做流程
·program manager
9.2微软PM的来历
·交流成本问题：MP（伪代码）、SP（实际代码）
·开发和测试都搞不定的事：与客户交流、了解竞争对手、产品的可用性、团队流程
9.3PM做开发和测试之外的所有事情
·PM的分类：做功能设计的、了解商业和客户、具备经验和知识面以及商业拓展能力的、做驱动流程的、负责软件国际化的、做技术转化的
·PM需要的能力：
1、观察、理解、快速学习能力
2、分析管理能力
3、一定的专业能力
4、自省的能力
·PM最好的要求：过程创新可能超越产品创新，但两个创新并驾齐驱则胜于任何一个。
9.4领导力-高效的团队讨论
·组织者做到：
1、明确会议目的
2、推动会议进程
3、总结会议，记录要点
·思维活动的类型：理清事实、表达直觉和感情、从乐观的角度分析问题、从悲观角度分析问题、从创意角度分析问题、
9.5PM和风险管理
·应对风险的手段：进一步研究、接受、规避、转移、降低、制定应急计划
·风险管理水平的多个层次：①大问题，对风险没有任何准备；②缓和并防止问题，对问题有一定的准备；③预计，预测到问题的发生，有有效准备；④把问题变成机会，能够把问题转化成机会。
读完这章之后，对于项目经理背后的辛酸更加了解。项目经理作为一个沟通程序员和用户的桥梁，需要做的事情以及需要交流的东西有很多，尽管其不需要写代码。项目经理把握着整个团队的前进方向，除却需要专业的知识和技能外，还需要有相匹配的经验和气质。
10典型用户和场景
10.1典型用户和典型场景
·典型用户的价值：从用户角度出发考虑问题
·怎样定义典型用户：软件不是为所有人使用的
·从典型用户到场景
·从场景到任务：UI层、逻辑层、数据库
10.2用例
·用例的基本元素：标题、角色、主要成功场景、步骤、扩展场景
·用例的原则：
1、通过将简单的故事来传递信息
2、保持对全系统的理解
3、关注用户的价值
4、逐步构建整个系统，一次完成一个用例
5、增量开发，逐步构建整个系统
6、适应团队不断变化的需求
10.3规格说明书（spec）
·功能说明书：实践、实践、再实践
·功能说明书的模板：不可盲目套用模板
·技术说明书-设计文档的原则：
1、抽象
2、耦合/内聚/模块化
3、信息隐藏和封装
4、界面和实现的分离
5、如何处理错误情况
6、程序模块对于运行环境、相关模块、输入输出参数有什么假设
7、应对变化的灵活性
8、对大量数据的处理能力
10.4功能驱动的设计
构造总体模型->构造功能列表->制定开发计划->功能设计->实现具体功能
这一章主要讲解典型的用户和场景，在软件开发中，做出来的成品始终不是给所有人用的，就拿人人都用的微信来说，对于老一辈的人来说，他们更喜欢使用电话。除此之外，软件开发满足的是客户的需求，在开发过程中，往往不能按照自己的意愿行事，因为别人并不是开发者。最后，在软件开发过程中，软件如何制作，以及做完之后如何使用，对其进行功能设计也是一个技术活。看完这一章，对于软件如何按计划开发，软件设计文档的书写，以及如何应对典型用户和场景有了新的认识。
11软件设计与实现
11.1分析和设计方法
·需求分析：分清楚关系，解决用户需求
·设计和实现：软件是否解决需求，如何实现信息交换
·测试和发布：软件是否解决客户需求，解决效率如何，方式如何。
11.2图形建模和分析方法
·表达实体和实体之间的关系：思维导图（了解概念、强化记忆）、实体关系图（实体关系）、用例图（UCD）
·表达数据的流动
·表达控制流
·统一的表达方式：UML
11.3其他设计方法
·形式化的方法
·文学化编程
11.4从Spec到实现
·把修改集集成到代码库
11.5开发阶段的日常管理
·闭门造车：学着说“不”、管理信息、与团队交流
·每日构建：构建基本的框架，保证其不倒
·构建大师：让这类人的生活速度慢下来，找出失败原因。
·宽严皆误：严格规则和宽松规则，学会审势
·小强地狱：修复bug
11.6实战中的源代码管理
·软件的质量=程序的质量+软件工程的质量
11.7代码完成
应该写的代码都写了，功能全部实现，但仍有bug待修改。
这一章主要讲的是软件的设计和实现，在软件设计过程中，必不可少的就是画图，使用图形构建出软件的运行路线，软件功能的实现思路，在写软件的工程中，学会管理自己的时间，否则效率将会很低下。拿自己来说，如果在写代码的工程中突然被打断，那么等重新回到状态时，你会看不懂自己写的是什么。软件开发过程中必须将框架搭建好，否则软件很容易崩溃，想要保证软件的质量，必须将功能实现之后，继续修改bug。
12用户体验
12.1用户体验的要素
·用户的第一印象
·从用户的角度考虑问题：用户需要的功能
·软件服务始终要记住用户的选择：用户的选择，使用偏好
·短期刺激和长期影响：在实验室喝可乐和在家喝可乐
·不让用户范简单的错误：高明的设计会替用户省钱
·用户体验和质量：两者之间的重要性不能准确衡量
·情感设计：本能、行为、反思层次的设计
12.2用户体验设计的步骤和目标
·概要设计->行为设计->界面设计
12.3评价标准
·尽快提供可感触的反馈
·系统界面符合用户的现实惯例
·用户有控制权
·一致性和标准化
·适合各种类型的用户
·帮助用户识别、诊断并修复错误
·有必要的提示和帮助文档
12.4贯穿多种设备的用户体验
在不同的设备上，用户的体验如何？在pc端，手机端...用户有和不同的体验。
看完这一章，我觉得还是那句话正确，用户的体验很重要。我们在开发程序的过程中，不能总想着写出多少高级的功能，而是能写出多少实用的功能，用户真正需要的就是我们要实现的功能，除此之外，我们更要明白，开发出来的产品面向的用户是谁？我在上学期写程序时，自己的界面就做的很粗糙，每实现一个功能就得跳转一个界面，比起那些“好看的”界面相差太远，就会导致用户的体验很差。甚至，自己都对它很嫌弃。所以，在开发软件的过程中，必须重视用户的体验，从用户的体验出发，做一个好的软件，在后期逐渐修复bug。