《构建之法》阅读笔记二
这次的阅读笔记是《构建之法》的七到十二章，记录的内容如下：
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。
标签：需求,功能,用户,笔记,构建,阅读,软件,团队,PM 来源： https://www.cnblogs.com/jzz-111jy/p/15835727.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。