项目经理 - 高效的团队讨论
组织者的责任：
明确会议目的，要解决的问题是什么推动会议进程，促使与会者在每一个阶段做合适的事情总结会议，记录要点
会议过程：
理清事实表达直觉和感情从乐观的角度分析问题从悲观的角度分析问题从创意的角度分析问题
会议的结果：
一些共识。这些共识在项目当前里程碑结束之前不必再讨论，也不能改变。一些行动以及行动负责人。一些好主意以及这些主意的负责人。把这些好主意都放在“好主意停车场”上面，以后时机成熟再启动这些想法。
典型用户和场景模板
场景/故事
版权/版本/维护人
1. 背景
a. 典型用户 - 姓名、性别、年龄、职业等
b.用户需求/痛点
c.假设
2. 场景
关于这个场景的文字描述
3. 其他资料 - 相关功能，参考信息等
用例
标题：描述目标
角色：与软件交互的角色，如用户等其他实体，甚至时间
主要成功场景：一系列步骤
步骤：描述每一步的交互
扩展场景：描述一些意外情况
规格说明书 Specification
软件功能说明书 - 黑盒
主要用来说明软件的外部功能和用户交互的情况。
软件技术说明书 - 白盒
又叫设计文档，主要用来说明软件内部的设计规范。
功能说明书
第一，定义好相关的概念
· 用到哪些术语，定义是什么？
· 什么叫“好”，什么叫“这个功能测试完了，可以交付了”？
第二，规范好一些假设
· 目标是什么，不包括什么？
第三，避免一些误解，界定一些边界条件
· 用户数量，输入内容限制，国家/语言，软、硬件环境参数等等。
第四，描述主流的用户/软件交互步骤
· 用户和典型场景是什么？
第五，可能有的副作用
· 有什么副作用，与其他功能的依赖关系？
第六，服务质量说明
如何实践？
记录版本修订的时间和负责人
描述功能验证方式，最好附上测试用例
功能说明书与测试用例、项目任务等相互链接
标记模糊及易变部分，提前做好预案
任何改动事先参考说明书，不应该拍脑袋决定
技术说明书
设计原则
抽象
内聚/耦合/模块化
信息隐藏和封装
界面和实现的分离
错误处理
环境依赖
应对变化的灵活性
对大量数据的处理能力
软件设计与实践
思维导图 有助于了解概念，强化记忆。适用于探索、发散思维的场合（如头脑风暴会议）。实体关系图（Entity Relationship Diagram） ERD适合表示实体之间的静态关系。
ERD与语言词性对照表
ERD词性举例
实体类型普通名词表示一类事物，如银行、客户、书籍等实体专有名词表示一个特定的人或事务，如《十万个为什么》等关系的类型及物动词客户取出存款属性的类型不及物动词利息升高或降低实体的属性形容词红色的苹果关系的属性副词银行暂时提高利息
用例图 Use Case Diagram包括：参与者、系统、用例、信息传递线。表达系统需求。数据流 Data Flow Diagram，分层的数据流能引导设计者全面设计系统的信息处理流程。
有bug
有bug
有bug
成功
有bug
功能需求
复审/设计
详细设计
编写代码
Dev自测
复审
合并/构建
集成测试
更新Spec
debug
完成
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）通知谁信息的接受者，与任务的关系最为间接。
