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

Posted 2020-10-12 L龙先生

第九章-项目经理

　　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）；

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

　　在“需求分析”阶段，我们要搞清楚----在问题领域中的现实世界里，都有哪些实体，如何抽象出我们真正关心的属性，实体之间的关系是什么，在这个基础上，用户的需求是什么，软件如何解决用户的需求；

　　在“设计与实现”阶段，我们要搞清楚----软件是怎么解决这些需求的；

　　在“测试”和“发布”阶段，我们要搞清楚----软件真的解决了这些需求了么？

　　表达实体和实体之间的关系：

　　　　思维导图（Mind Map）；

　　　　实体关系图（Entity Relationship Diagram）；

　　　　Use Case Diagram（UCD）--用例图：

　　　　　　1.参与者（Actor）：表示参与系统运作的外部因素，通常是一个简笔画的小人；

　　　　　　2.系统：通常用一个方框来表示系统的边界。有时也可忽略；

　　　　　　3.用例（Use Case）：表示系统和参与者交互的一次场景，它是一组动作的集成，而不是一个单独的内部元素；

　　　　　　4.信息传递线：用带箭头的线来表示参与者和系统通过相互发送信号或消息进行交互的关联关系；

　　其他设计方法：

　　　　形式化的方法（Formal Method）、文学化编程（Literate Programming）；

　　开发人员的标准工作流程：

　

　　开发阶段的日常管理：

　　　　1.闭门造车（Leave Me Alone）；

　　　　2.每日构建（Daily Build）；

　　　　3.构建大师（Build Master）：

　　　　　　a.负责管理构建服务器；

　　　　　　b.调试构建，负责找错，并分析出错的原因；

　　　　　　c.负责把“构建大师”称号和责任交给下一个导致构建失败的成员；

　　　　　　d.“构建大师”同时向团队的“腐败基金”存入50元，以供大家将来“腐败”之用（此条可选）；

　　　　4.宽严皆误；

　　　　5.小强地狱（Bug Hell）；

第十二章-用户体验

　　用户界面（User Interface UI）、用户体验（User eXperience UX）

　　用户体验的要素：

　　　　1.用户的第一印象：5W1H方法

　　　　　　　　Who：谁是你的目标用户；

　　　　　　　　When：他们会在什么时间使用你的产品；

　　　　　　　　Where：目标用户会在哪里和你的产品交互；

　　　　　　　　What：你的产品是什么？而用户的期待是什么；

　　　　　　　　Why：用户为什么要使用你的产品，他们的动机是什么，在众多竞争产品中，用户为何选择你的产品；

　　　　　　　　How：用户是如何与你的产品发生交互的；

　　　　2.从用户的角度考虑问题；

　　　　3.软件服务始终都要记住用户的选择；

　　　　4.短期刺激和长期影响；

　　　　5.不让用户犯简单的错误；

　　　　6.用户体验和质量；

　　　　7.情感设计

　　　　　　三个层次：

　　　　　　　　本能【Visceral】层次的设计----外形；

　　　　　　　　行为【Behavior】层次的设计----使用的乐趣和效率；

　　　　　　　　反思【Reflective】层次的设计----自我形象、个人满足感、回忆；

　　评价标准：

　　　　对于一个软件的用户界面的评价标准，可参考费茨法则、Nielsen启发式评估十条院子以及其他经验；

　　　　　　1.尽快提供可感触的反馈；

　　　　　　2.系统界面符合用户的现实惯例【Familiarity，Avoid Surprise】；

　　　　　　3.用户有控制权；

　　　　　　4.一致性和标准化；

　　　　　　5.适合各种类型的用户；

　　　　　　6.帮助用户识别、诊断并修复错误；

　　　　　　7.有必要的提示和帮助文档；

第十三章-软件测试

　　基本名词解释及分类：

　　　　Bug：软件的缺陷；

　　　　Test Case：测试用例；

　　　　Test Suite：测试用例集；

　　Bug可分解为：症状【Symptom】：即从用户的角度看，软件出了什么问题；

　　　　　　　　  程序错误【Fault】：即从代码的角度看，代码的什么错误导致了软件的问题；

　　　　　　　　  根本原因【Root Cause】：错误根源，即导致代码错误的根本原因；

　　按测试设计的方法分类：

　　　　黑箱【Black Box】：指的是在设计测试的过程中，把软件系统当作一个“黑箱”，无法了解或使用系统的内部结构及知识；

　　　　白箱【White Box】：指的是在设计测试的过程中，设计者可以“看到”软件系统的内部结构，并使用软件的内部结构和知识来选择测试数据及具体的测试方法；

　　按测试的目的分类：

　　　　功能测试：

　　　　　　Unit Test：单元测试----在最基本的功能 / 参数上验证程序的正确性；

　　　　　　Functional Test：功能测试----验证模块的功能；

　　　　　　Integration Test：集成测试----验证几个互相有依赖关系的模块的功能；

　　　　　　Scenario Test：场景测试----验证几个模块能否完成一个用户场景；

　　　　　　System Test：系统测试----对于整个系统功能的测试；

　　　　　　Alpha / Beta Test：外部软件测试人员（Alpha / Beta测试员）在实际用户环境中对软件进行全面的测试；

　　　　非功能测试【Non-functional Requirement】（服务质量需求【Quality of Service Requirement】）：

　　　　　　Stress / Load Test：眼力测试----测试软件在负载情况下能否正常工作；

　　　　　　Performance Test：效能测试----测试软件的效能；

　　　　　　Accessibility Test：可访问性测试----测试软件是否向残疾用户提供了足够的辅助功能；

　　　　　　Lcalization / Globalization Test：本地化 / 全球化测试；

　　　　　　Compatibility Test：兼容性测试；

　　　　　　Configuration Test：配置测试----测试软件在各种配置下能否正常工作；

　　　　　　Usability Test：易用性测试----测试软件是否好用；

　　　　　　Security Test：软件安全性测试；

　　按测试的时机和作用分类：

　　　　测试“烽火台”、不同的测试方法；

　　各种测试方法：

　　　　1.单元测试和代码覆盖率测试；

　　　　2.构建验证测试【Build Verification Test， BVT】：基本功能能否使用；

　　　　3.验收测试【Acceptance Test】；

　　　　4.“探索式”的测试【Ad hoc Test】；

　　　　5.回归测试【Regression Test】：验证修复的Bug有没有再次出现；

　　　　6.场景 / 集成 / 系统测试：各模块连接是否正常；

　　　　7.伙伴测试【Buddy Test】；

　　　　8.效能测试【Performance Test】：软件在设计负载内能否提供令用户满意的服务质量；

　　　　　　涉及两个概念：1.设计负载；2.令用户满意的服务质量；

　　　　　　现实的环境两方面：1.现实的静态数据；2.现实的动态数据；

　　　　9.压力测试：增加负载的两个方面----1.沿着用户轴延长；2.沿着时间轴延长

　　　　10.内部 / 外部公开测试；

　　　　11.易用性测试；

　　　　12.“小强”大扫荡【Bug Bash】；

第十四章-质量保障

　　软件的质量：

　　　　软件=程序+软件工程；

　　　　软件_质量 = 程序_质量 + 软件工程_质量；

　　　　程序的质量：体现在软件外在功能的质量；

　　　　软件工程的质量：

　　　　　　软件开发过程的可见性【Visibility】;

　　　　　　软件开发过程的风险控制【Risk Management】；

　　　　　　软件内部模块，项目中间阶段的交付质量，项目管理工具的因素；

　　　　　　软件开发成本的控制【Cost Control】；

　　　　　　内部质量指标的完成情况【Internal Benchmarks】；

　　CMMI【Capacity Maturity Model Integrated】：

　　　　一级：初始级（完成级）； 二级：管理级； 三级：明确（定义）级； 四级：量化管理级； 五级：优化级；

　　质量的成本：

　　　　预防【Prevention】；评审【Appraisal】；内部故障【Internal Failure】；外部故障【External Failure】；流程分析改进【Process Enhancement】；提高职业技能【Enhance Professional Skills】；投资软件工具【Invest in Software Tools】；

第十五章-稳定和发布阶段

　　常用名词：

　　　　Alpha：指集成了主要功能的第一个试用版本；

　　　　Beta：功能基本完备，稳定性较Alpha版本高，用户可以在实际工作中小范围使用，可以有多个Beta版本；

　　　　ZBB【Zero Bug Build】：某天的版本要把之前（规定时间内）记录的Bug都解决掉；

　　　　RC【Release Candidate】：发布候选版本，版本间隔时间较短；

　　　　RTM【Release To Manufacturer】：最终发布版本；

　　　　RTW【Release To Web】：和RTM类似；

　　发布之后----事后诸葛亮会议；