构建之法读书笔记

项目经理 - 高效的团队讨论

组织者的责任：

• 明确会议目的，要解决的问题是什么
• 推动会议进程，促使与会者在每一个阶段做合适的事情
• 总结会议，记录要点

会议过程：

• 理清事实
• 表达直觉和感情
• 从乐观的角度分析问题
• 从悲观的角度分析问题
• 从创意的角度分析问题

会议的结果：

• 一些共识。这些共识在项目当前里程碑结束之前不必再讨论，也不能改变。
• 一些行动以及行动负责人。
• 一些好主意以及这些主意的负责人。把这些好主意都放在“好主意停车场”上面，以后时机成熟再启动这些想法。

典型用户和场景模板

场景/故事
版权/版本/维护人
1. 背景
	a. 典型用户 - 姓名、性别、年龄、职业等
	b.用户需求/痛点
	c.假设
2. 场景
	关于这个场景的文字描述
3. 其他资料 - 相关功能，参考信息等

用例

标题：描述目标
角色：与软件交互的角色，如用户等其他实体，甚至时间
主要成功场景：一系列步骤
	步骤：描述每一步的交互
扩展场景：描述一些意外情况

规格说明书 Specification

软件功能说明书 - 黑盒
	主要用来说明软件的外部功能和用户交互的情况。
软件技术说明书 - 白盒
	又叫设计文档，主要用来说明软件内部的设计规范。

功能说明书

第一，定义好相关的概念
	· 用到哪些术语，定义是什么？
	· 什么叫“好”，什么叫“这个功能测试完了，可以交付了”？
第二，规范好一些假设
	· 目标是什么，不包括什么？
第三，避免一些误解，界定一些边界条件
	· 用户数量，输入内容限制，国家/语言，软、硬件环境参数等等。
第四，描述主流的用户/软件交互步骤
	· 用户和典型场景是什么？
第五，可能有的副作用
	· 有什么副作用，与其他功能的依赖关系？
第六，服务质量说明

• 如何实践？

记录版本修订的时间和负责人
描述功能验证方式，最好附上测试用例
功能说明书与测试用例、项目任务等相互链接
标记模糊及易变部分，提前做好预案
任何改动事先参考说明书，不应该拍脑袋决定

技术说明书

设计原则

抽象
内聚/耦合/模块化
信息隐藏和封装
界面和实现的分离
错误处理
环境依赖
应对变化的灵活性
对大量数据的处理能力

软件设计与实践

• 思维导图
  有助于了解概念，强化记忆。适用于探索、发散思维的场合（如头脑风暴会议）。
• 实体关系图（Entity Relationship Diagram）
  ERD适合表示实体之间的静态关系。

ERD与语言词性对照表

ERD	词性	举例
实体类型	普通名词	表示一类事物，如银行、客户、书籍等
实体	专有名词	表示一个特定的人或事务，如《十万个为什么》等
关系的类型	及物动词	客户取出存款
属性的类型	不及物动词	利息升高或降低
实体的属性	形容词	红色的苹果
关系的属性	副词	银行暂时提高利息

• 用例图
  Use Case Diagram包括：参与者、系统、用例、信息传递线。表达系统需求。
• 数据流
  Data Flow Diagram，分层的数据流能引导设计者全面设计系统的信息处理流程。

SMART

定义	说明
S=Specific	具体的
M=Measurable	可以衡量的
A=Attainable	可以达到的
R=Relevant	与其他目标具有一定的相关性
T=Time-bound	有明确的截止期限

RASCI

名称	定义	说明
R（R=Responsible）	谁负责	负责牵头完成“A”布置的任务与目标，具有结果导向，对“A”布置的任务与目标的结果负全责。所承担任务与目标与其他部门（或岗位）配合时，负责确定需要的配合部门，确定配合部门的工作内容、工作标准等。“R”负责将其牵头的工作分解给相关的“S”、“C”与“I”。
A（A=Accountable）	谁批准	负责批准与布置任务，具有目标导向，负责确定目标、确定目标牵头者（即R），并评价“R”所承担目标的完成情况。
S：（S=Support）	谁支持	负责配合“R”完成指标的工作，达到既定的目标。对于同一任务，“R”可指定多个“S”。
C：（C=Consulted）	咨询谁	负责为各个相关的角色提供咨询服务。
I：（I=Informed）	通知谁	信息的接受者，与任务的关系最为间接。