标签：drive dev 成本 合作伙伴 故事 变更 规范 安全性 观察
第九章-项目经理
PM：Product Manager-产品经理，正确地做产品；
Project Manager-项目经理，正确地做流程；
Program Manager-微软的职位名称，负责除产品开发和测试之外的所有事情；
Program Manager - Project Manager:
Keep the Balance: Time / Resource / Feature 大部分优秀团队：多，快，但不省；多，省，但不快；快，省，但不多；
PM和风险管理：
风险的类别 风险的来源
人员 客户，最终用户，利益关系人，项目成员，合作伙伴
流程 项目的预算，成本，需求
技术 开发和测试工具，平台，安全性，发布产品的技术，与我们产品相关的技术
环境 法律，法规，市场竞争环境，经济情况，技术大趋势，商业模式，自然界
风险管理的水平层次：
第一层次：啊呀！大问题（Crisis）；
第二层次：缓和（Mitigation）并防止问题（Prevention）；
第三层次：预计（Anticipation）；
第四层次：把问题变为机会（Opportunity）；
PM的能力要求和任务：
1.观察、理解和快速学习能力；
2.分析管理能力----四种情况：重要且紧急，重要但不紧急，不重要但紧急，不重要也不紧急；
3.一定的专业能力；
4.自省的能力；
PM在项目中具体任务：
1.带领团队形成团队的目标/远景，把抽象的目标转化为可执行的、具体的、优美的设计；
2.管理软件的具体功能的生命周期（需求 / 设想 / 设计 / 实现 / 测试 / 修改 / 发布 / 升级 / 迁移 / 淘汰）；
3.创建并维护软件的规格说明书，让它成为开发 / 测试人员及时准确的指导，而不是障碍；
4.代表客户和用户的利益，主动收集用户反馈，预期用户新的需求。协调并决定各种需求的优先级；
5.分析并带领其他成员对缺陷 / 变更需求形成的一致意见，并确保实施；
6.带领其他成员确保项目保持功能 / 时间 / 资源的合理平衡，跟踪项目进展，确保团队发布令客户满意的软件；
7.收集团队项目管理和软件工程的各种数据，客观分析项目实施过程中的优缺点，推动项目成员的持续改进，从而提振士气；
著名用户体验专家比尔·巴克斯顿在总结自己几十年的经验时说：
过程创新可能超越产品创新，但两个创新并驾齐驱则胜于任何一个；
第十章-典型用户和场景
典型用户（Persona）：特征--往往描述了一组用户的典型技巧、能力、需要、想法、工作习惯和工作环境；
定义典型用户：定义用户的角色，若用户有不同的安全需求，切记要定义不同的角色来适应这些需求；
受欢迎的典型用户----指那些按设计者的期望使用系统的用户；
不受欢迎的典型用户----指那些有不正当目的的用户（这些用户也许在别的系统中是受欢迎的）；
典型用户的模板可以包括：名字、年龄和收入、代表的用户在市场上的比例和重要性（比例大不等同于重要性高）、使用这个软件的典型场景（Scenario）、使用本软件 / 服务的环境、生活 / 工作的情况、知识层次和能力、用户的动机、目的和困难、用户的偏好；
eg：我们的软件并不是为所有人服务的；
用例（Use Case）：常用的需求分析工具；
基本元素：标题--描述这个用例要达到的目标；
角色（Actor）--和软件系统交互的角色；
主要成功场景（Main Success Scenario）-- 一系列步骤描述角色是怎样和系统交互，从而达到目标的；
步骤--描述每一步的交互
扩展场景（Extension）--描述一些扩展的交互；
使用Use Case的原则：
1.通过讲简单的故事来传递信息；
2.保持对全系统的理解；
3.关注用户的价值；
4.逐步构建整个系统，一次完成一个用例；
5.增量开发，逐步构建整个系统；
6.适应团队不断变化的需求；
Use Case方法论的理念和敏捷、MSF大致相仿；它对细节的要求和典型人物、场景有很多相似之处，这些方法也有其局限性：
1.故事 / 人物 / 场景非常适合交互式的系统，但是对于其他类型的需求（算法，速度，扩展性，安全性，以及和系统技术相关的需求）则不适用；
2.故事的粒度没有统一的标准，和每个具体项目有关。初学者比较难以掌控。
3.如果软件的关键在于用户体验的细节，那么把这些UI的细节嵌入到每个故事中并仍然保持故事的简明性是一个难题；有的团队把目前的技术扩展为Use Case Storyboard，当一个简明的故事加上很多附加说明和图画的时候，这事实上就成为了功能说明书（Functional Specification），以及各种帮助建模的图形工具；
规格说明书（Specification）： 简称Spec分为以下两种
1.软件功能说明书（Functional Spec），主要用来说明软件的外部功能和用户的交互情况【把软件当做一个黑盒子】；
2.软件技术说明书（Technical Spec），又叫设计文档（Design Doc），主要用来说明软件内部的设计规范（把软件当作一个透明的箱子）；
功能说明书：从用户的角度描述软件产品的功能、输入、输出、界面、功能的边界问题、功能的效率（对用户而言）、国际化、本地化、异常情况等，不涉及软件内部的实现细节；
第一，定义好相关的概念；
第二，规范好一些假设（Assumptions）；
第三，避免一些误解，界定一些边界条件；
第四，描述主流的用户 / 软件交互步骤；
第五，一些好的功能还会有副作用；
第六，服务质量的说明；
写好Spec的秘诀----实践，实践，再实践；Spec的最大敌人----乏味；Spec的另一个敌人----时间；
功能说明书的模板：
1.Spec的目标是什么，Spec的目标不包括什么？
2.Spec的用户和典型场景是什么？
3.Spec用到了哪些术语，它们的定义是什么？
4.用户是如何使用软件的功能的？
5.各种边界条件是什么？
6.功能有什么副作用，对于其他功能有什么显性或隐性的依赖关系？
7.什么叫“好”，什么叫“这个功能测试完了，可以交付了”？
8.软件发布出去之后，有哪些和项目目标相关的数据可采集？怎么在实现阶段就能把数据收集的工作准备好？
技术说明书：又称设计文档
应该说明工程师的设计是如何体现下列原则的：
1.抽象（Abstraction）；
2.内聚 / 耦合 / 模块化（Cohesion，Coupling，Modularization）；
3.信息隐藏和封装（Information Hiding，Encapsulation）；
4.界面和实现的分离（Separation of Interface and Implementation）；
5.如何处理错误情况（Error Handling）；
6.程序模块对于运行环境、相关模块、输入输出参数有什么假设？这些假设和相关的人员验证过么？
7.应对变化的灵活性（Adapt to Change）；
8.对大量数据的处理能力（Scalability）；
功能驱动的设计（Feature Driven Design FDD）----构成步骤：
1.构造总体模型（Develop an Overall Model）；
2.构造功能列表（Build a Feature List）；
3.制定开发计划（Plan by Feature）；
4.功能设计阶段（Design by Feature）；
5.实现具体功能（Build by Feature）；
第十一章-软件设计与实现
第十二章-用户体验
第十三章-软件测试
标签：drive dev 成本 合作伙伴 故事 变更 规范 安全性 观察
原文地址：http://www.cnblogs.com/SirL/p/7739456.html
