《构建之法》 读书笔记（5）

      项目经理

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

      典型用户和场景

      光看用户的表面语言或行动还是不够的。我们还要找到用户语言或行动背后的动机！不能光根据用户的语言就匆忙做决定。典型用户不再是一个抽象的概念，而应该是一个活生生的人。一个典型用户描述了一组用户的典型技巧、能力、需要、想法、工作习惯和工作环境。在设计软件的过程中，我们往往会以自己使用产品的习惯对软件行业的熟悉程度出发设计，忘记了我们的软件是给千千万万个不那么会用电脑的人使用的。在这种情况下，搞一个“典型用户”会强迫我们在考虑问题时从用户的角度出发。典型用户可以包括以下内容：1.名字2.年龄3.收入4.代表的用户在市场上的比例和重要性5.使用这个软件的典型场景6.使用本软件/服务的环境7.生活/工作情况8.知识层次和能力9.用户的动机、目的和困难10.用户的偏好

从典型用户到场景

有了典型用户之后，我们还得决定每一个典型用户的目标，他使用系统想要达到什么目的。对于每一个目标，列出达到目标所必须经历的过程，这就是场景，也可以叫故事。注意，有些场景描述了成功的结果，有些场景描述了失败的结果。用户和系统有成百上千中可能的交互情况，写场景时要有针对性。场景之间如何区分呢，这就要求我们找到这个场景的特殊之处，对于共同的流程可以一笔带过，重点描述场景中特殊的因素。把场景组织成一个故事，这样就能把一个完整的用户与文件系统交互的流程记录下来，以后进行产品演示或验收都可以以此为基础。

从场景到任务

不同的任务会把一个场景编织起来，虽然有多个开发者参与这项工作，但是应该有一个开发者对整个场景负责。得到开发任务后，我们就可以创建和分配测试任务。

用例，和典型人物、典型场景的方法类似，用例也是很常用的需求分析工具。规格说明书，功能说明书从用户的角度描述软件产品的功能、输入、输出、界面、功能的边界问题、功能的效率国际化、本地化、异常情况等，不涉及软件内部的实现细节。功能说明书的模板1.spec的目标是什么，spec的目标不包括什么？2.spec的用户和典型场景是什么？3.spec用到了哪些术语，它们的定义是什么？4.用户是如何使用软件的功能的？5.各种边界条件是什么，软件功能应该怎样随之变化——这边界条件多了去了：用户数量的变化，输入内容的上限下限，不同国家/地区/文化/语言/硬件/软件版本/环境参数……6.功能有什么副作用，对于其他功能有什么显性或隐性的依赖关系？7.什么叫“好”，什么叫“这个功能测试完了，可以交付了”？8.软件发布出去之后，有哪些项目目标相关的数据可以收集，怎么在实现阶段就能把数据收集的工作准备好？

 

个人感受：

总认为开发一个程序一上来就可以写代码了。但很多事情在开始的时候都要做很多的准备。

在书中，说在编写代码之前，需要有很多准备，比如书写典型用户典型场景，程序写完以后还有，技术说明书又叫设计文档，它用于描述开发者如何去实现某一功能，或相互联系的一组功能。设计文档应该说明工程师的设计是如何体现下列原则的。第一步：构造总体模型，第二步：构造功能列表，第三步：制定开发计划，第四步：功能设计阶段，第五步：实现具体功能

 

 以后用户在描述软件概要的时候，光看用户的表面语言或行动还是不够的。我们还要找到用户语言或行动背后的动机！