码迷,mamicode.com
首页 > 其他好文 > 详细

课后作业-阅读任务-阅读笔记-3

时间:2017-10-26 23:22:10      阅读:433      评论:0      收藏:0      [点我收藏+]

标签: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);

第十一章-软件设计与实现

第十二章-用户体验

第十三章-软件测试

课后作业-阅读任务-阅读笔记-3

标签:drive   dev   成本   合作伙伴   故事   变更   规范   安全性   观察   

原文地址:http://www.cnblogs.com/SirL/p/7739456.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!