《构建之法》之第8、9、10章读后感

第8章主要介绍了软件需求的类型、利益相关者，获取用户需求分析的常用方法与步骤、竞争性需求分析的框架NABCD,四象限方法以及项目计划和估计的技术。我认为，作为一个软件团队要准确而全面地获取这些需求主要有以下四个步骤：

1. 获取和引导需求。这一步骤也被叫做“需求捕捉”。软件团队需要为用户着想，设身处地，为用户引导出需求。
2. 分析和定义需求。从各个方面获取的需求进行规整，定义需求的内涵从各个角度将需求量化。
3. 验证需求。软件团队要跟利益相关者沟通，通过分析报告、技术原型、用户调查或演示等形式向他们验证软件团队对于这些需求的认知。
4. 在软件产品的生命周期中管理需求。

对软件的需求，也可以从不同角度做以下的划分：

1. 对产品功能性的需求
2. 对产品开发过程的需求
3. 非功能性需求
4. 综合需求

软件产品的利益相关者

很多人或机构都是某个软件的利益相关者，软件团队在分析软件需求时要考虑如下这些利益相关者：

1.  用户（或称最终用户）
2. 顾客（或称客户）
3. 市场分析师
4. 监管机构

 而我在本章中存在问题，若在客户需求中发布调查问卷，那这个问卷应该如何汇编，填写，完善，难度会不会很难

第九章：项目经理

PM指的是项目经理

 Product Manager:产品经理——正确地做产品。

 Project Manager：项目经理——正确地做流程。

Program Manager：微软职位名称。

PM做开发和测试之外的所有事情

PM最大、最独特的贡献是带领团队达成最重要的目标，并保持团队的平衡。

牛人主导的项目，往往会大起大落；PM主导的产品中，"不犯大错“成了一个特点。

PM的能力要求和任务

1. 观察、理解和快速学习能力
2. 分析管理能力
3. 一定的专业能力
4. 自省的能力

第十章：典型用户和场景

 典型用户可包括以下内容：

1. 名字（越自然越好）
2. 年龄（不同年龄和收入的用户有不同的需求）
3. 收入
4. 代表的用户在市场上的比例和重要性（比例大不等同于重要性高，如付费的用户比例较少，但是影响大，所以更重要）
5. 使用这个软件的典型场景
6. 使用本软件/服务的环境
7. 生活/工作情况
8. 知识层次和能力
9. 用户的动机、目的和困难
10. 用户的偏好

 

使用用例的原则：

1. 通过讲简单故事来传递信息
2. 保持对全系统的理解
3. 关注用户的价值
4. 逐步构建整个系统，一次完成一个用例
5. 增量开发，逐步构建整个系统
6. 适应团队不断变化的需求

总结：读完这几章内容，发现软件需求分析很关键，它指引着团队要开发怎样的软件，如果分析错误将会花费工程人员大量的时间纠正项目，并重新工作，加大开发的难度。因此要把握好、准确而全面地获取用户的需求信息。PM做开发和测试之外的所有事情，带领团队达成最重要的目标，并保持团队的平衡，让开发人员专注于技术方面的工作。所以，我觉得PM的改革措施具有历史性意义，值得去借鉴。

我的个人总结：作为scrum master,这次我的工作是做出了关于我们团队的总结，承上启下，为过往做出查漏补缺，并为未来做更好地铺垫，让我们的团队按着我们预想的轨道继续稳稳当当地走下去，然而，对于日常的测试流程、测试任务分配、测试执行、缺陷跟踪、用github协调内部代码的一致性还做得不够好，相关JAVA识方面也需要进一步加 强，在这些方面都需要我们学习。