软件项目管理01335第二版教材复习知识点总结

复习重点

项目管理：

• 项目管理的概念：项目管理就是以项目为对象的系统管理方法，通过一个特定的柔性组织，对项目进行高效率的计划、组织、指导和控制，不断进行资源的配置和优化，不断与项目各方沟通和协调，努力使项目执行的全过程处于最佳状态，获得最好的结果。
• 项目管理的特征：
  1. 目标性，其结果只可能是一种期望的产品或服务；
  2. 独特性，每一个项目都是唯一的；
  3. 一次性，有确定的起点和终点；
  4. 约束性，每一个项目的资源、成本和时间都是有限的；
  5. 关联性，所开展的活动是密切相互关联的；
  6. 多方面性，一个项目涉及多个方面、多个相关利益者，如委托方、总承包商、分承包商、供应商等；
  7. 不可逆转性，不论结果如何，项目结束了，结果也就确定了。
• 项目管理的对象：3P——人员**、问题、**过程
• 项目管理的成功要素：
  1. 在规定的时间内完成项目。
  2. 项目成本控制在预算之内。
  3. 功能特性达到规格说明书所要求的水平（质量）。
  4. 项目通过客户或用户的验收。
  5. 项目范围变化是最小的或可控的。
  6. 没有干扰或严重影响整个软件组织的主要工作流程。
  7. 没有改变公司文化或改进了公司的文化。
• 项目管理的本质：项目管理的本质，就是在保证质量的前提下，寻求任务、时间和成本三者之间的最佳平衡。
• 项目管理的基本方法：
  1. 阶段化管理：阶段化管理将项目的生命周期（即项目运行的全过程）分若干个阶段，再根据不同阶段所具有的不同特点来进行针对性的管理。
  2. 量化管理：量化管理针对影响项目成功的因素制定指标、收集数据、分析数据，从而完成对项目的控制和优化。
  3. 优化管理：优化管理就是分析项目每部分所蕴涵的知识，不断吸取教训、 总结经验，将知识和实践更好地融合在一起，从而对项目计划、实施办法等进行优化，获得项目的最佳效益。
• 项目的生命周期：
  • 项目生命周期划分为 3个基本的阶段——计划、实施监控和总结。
  • PMBOK项目生命周期分为：启动、计划、执行、控制、结束
  • 详细的生命周期：
    1. 项目准备和启动阶段：收集信息进行可行性分析，通过可行性分析后提交项目申请书
    2. 项目计划阶段：主要任务有工作量估算、 资源分配、风险识别和计划书的编制等。
    3. 项目实施和监控阶段：项目计划的执行，对执行过程进行检验
    4. 项目验收和总结阶段：安排项目验收，并进行项目决算。
• 项目管理知识体系：
  • PMBOK：PMBOK将软件开发划分为"启动、计划、执行、控制和结束"5 个过程，每个管理过程包含了输入、输出、所需工具和技术，通过相应的输入和输出将各个过程联系在一起，构成完整的项目管理活动过程。PMBOK2000根据过程的重要性，将项目管理过程分为核心过程和辅助过程两类，共有39个过程。核心过程（共17个）辅助过程（共22个）
  • PRINCE2：受控环境中的项目，是组织、管理和控制项目的方法，强调通过管理方法使项目环境得到有效控制。基于过程的 、结构化的项目管理方法。
    • 管理要素（8类）：组织、计划、控制、项目阶段、风险管理、在项目环境中的质量、配置管理以及变化控制
  • WWPMM：IBM公司早期的项目管理方法主要有应用开发项目的方法论、 ERP软件包实施方法论、集成产品研发项目方法论等。
• 软件项目管理与其他项目管理的区别：
  1. 软件项目是设计型项目
  2. 软件过程模型
  3. 需求变化频繁
  4. 难以估算工作量
  5. 主要的成本是人力成本
  6. 以人为本的管理
• 软件项目管理的目标：最小的代价（成本和资源）最大程度地满足软件用户或客户的需求和期望，也就是协调好质量、任务、 成本和进度等要素相互之间的冲突，获取平衡。
• 软件项目管理的范围：
• 软件项目的分类：
  1. 按规模划分比较简单，可分为大型项目、中小型项目等。
  2. 按软件开发模式划分，可分为组织内部使用的软件项目、直接为用户开发的外部项目和软件外包项目。
  3. 按产品不同的交付类型可分为产品型项目、一次型项目。
  4. 按软件商业模式划分，可分为软件产品销售、在线服务 两种模式。
  5. 按软件发布方式可分为新项目、重复项目（旧项目）。
  6. 按项目待开发的产品进行分类，如COCOMO模型中，可分为组织型、嵌入型和半独立型。
  7. 按系统架构划分，可分为 B/S 结构、 C/S 结构，也可分为集中式系统和分布式系统。
  8. 按技术划分，可分为Web应用、客户端应用、系统平台软件等类型。

项目准备和启动：

• 项目建议书的作用：项目建议书就是项目的立项申请报告，重点是向有关的投资方或上级阐述立项的必要性。

• 项目建议书的组成部分（内容）：

  1. 项目的背景。
  2. 项目的意义和必要性。
  3. 项目产品或服务的市场预测。
  4. 项目规模和期限。
  5. 项目建设必需的条件，已具备和尚不具备的条件的分析。
  6. 投资估算和资金筹措的设想。
  7. 市场前景及经济效益的初步分析。
  8. 其他需要说明的情况。

• 软件项目投标的流程和关键要素：

  1. 第1个阶段是参加竞标的供应商在规定的时间内提交标书。标书一般包括项目需求分析、可行性研究方案和相关的财务预算。
  2. 第2个阶段是需求方（客户）对标书进行评估。 在评估之前需要制定相应的评估标准，以确保我们的评估过程是公平公正的。我们应该根据实际需要来制定标准，如从需求满足、技术能力、管理方案和财务预算等多方面来考虑。

• 项目可行性分析的方法和步骤：

  • 成本效益分析方法：回收期分析法、净现值分析法。

  • 技术及风险分析方法：

    • 技术分析★★：技术分析是要通过对技术设计方案或者演示模型的比较和分析，判断其技术的成熟性和适用性。(常用:专家评定)
    • 风险分析★★：风险分析是对项目分别进行内部和外部的风险评估，主要对市场风险、技术风险、财务风险、组织风险、法律风险、经济及社会风险等风险因素进行定性和定量的分析，从而为项目决策提供依据。（常用: 定量分析法决策树）

• 软件开发模型及其特点：

  • 瀑布模型：

    • 概念：瀑布模型将软件生命周期划分为软件计划、需求分析和定义、 软件设计、软件实现、软件测试、软件运行和维护这6个阶段， 规定了它们自上而下、相互衔接的固定次序，如同瀑布流水逐级下落。
    • 特点：
      • 由于开发模型呈线性，所以当开发成果尚未经过测试时，用户无法看到软件的效果。这样软件与用户见面的时间间隔较长，也增加了一定的风险。
      • 在软件开发前期未发现的错误传到后面的开发活动中时，可能会扩散，进而可能会造成整个软件项目开发失败。
      • 在软件需求分析阶段，完全确定用户的所有需求是比较困难的，甚至可以说是不太可能的。所以对于需求经常变化的项目不适用。

  • 快速原型实现模型：

    • 概念：快速原型法其实是对瀑布模型的改进，侧重需求的快速挖掘。其第一步是建造一个快速可实际运行的系统初步原型，实现客户或用户与系统的交互，对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。
    • 特点：
      1. 开发工具先进，开发效率高，使总的开发费用降低，时间缩短；
      2. 开发人员与用户的直观交流，能及早暴露系统实施后潜在的一些问题；
      3. 原型系统可作为培训环境，有利于用户培训和开发同步。

  • 从增量模型到敏捷方法：适用范围（不能事先确定系统的所有需求）

    • 增量模型★★★：该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。

      • 特点★★★：引入了增量包的概念，无须等到所有需求都出来，只要某个需求的增量包出来即可进行开发。

    • 敏捷开发★★★：敏捷开发是一种思想或方法论，就是通过不断迭代开发和增量发布，最终交付符合用户价值的产品。

      • 极限编程：极限编程XP，是一种软件工程方法学，是敏捷软件开发中最富有成效的几种方法学之一， 基本思想是“沟通、简单、反馈、勇气”。极限编程和传统方法学的本质不同在于它更强调可适应性而不是可预测性。

        • XP的特点：快速反馈、假设简单、增量变化、包容变化

      • 行为驱动开发：行为驱动开发BDD是一种敏捷软件开发的技术，它鼓励软件项目中的开发者、 QA和非技术人员或商业参与者之间的协作。

      • 功能驱动开发：功能驱动开发FDD 是由是一个模型驱动的快速迭代开发过程，它强调的是简化、 实用、易于被开发团队接受，适用于需求经常变动的项目。（针对中小型企业）

        • 开发过程：1. 开发一个全局的模型 2. 建立功能列表 3. 依据功能制定计划 4. 依据功能进行设计和实现

      • 敏捷开发模型Scrum：Scrum将软件开发团队比拟成橄榄球队，有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，高度自我管理意识， 紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝向目标有明确的推进。

        • 五大价值观：1. 承诺 2. 关注 3.公开 4. 尊重 5. 勇气
        • 三种角色：1. 产品负责人 2. Scrum Master 3. 开发人员
        • 三个工件：产品订单、迭代订单、迭代燃尽图
        • 五个活动：计划会、每日立会、评审会、回顾会、迭代

• 软件项目的可行性影响因素：经济可行性、技术可行性、风险和不确定性

• 软件项目启动动员会的目标和内容：

  • 目标：鼓舞士气，建立统一的目标
  • 内容：确定参会者、确定会议时间和地点、确定会议议程、发送会议邀请给参会者、确定会议主持、确定会议记录人员、其他准备（会议布置、硬件设施的准备、是否需要订餐等）

• 项目的可行性分析和风险评估：

  • 可行性分析的前提：首先要了解客户的需求和想要达到的目标。需求分析包括以下内容

    • 当前业务流程分析。

    • 主要功能点需求分析。

    • 系统的非功能需求分析，如性能需求、环境需求和安全需求分析等。

    • 对一些限制条件的分析，如经费来源和使用的限制，软件开发周期的限制等。

    • 需求的优先次序。

• 有效组织软件团队并分配人员角色：

  • 软件项目的组织结构类型：职能型、纯项目型和矩阵型。

    1. 职能型：在职能型组织里，一般没有项目经理，项目功能都是在本职能部门内部实现再递交到下一个部门。

       适用于项目规模小、专业面单一、以技术为重点的项目

    2. 纯项目型：在这种组织形式中，以顶目经理为核心构造一个完整的项目组。

       适用于大型的、重要的、复杂的项目（一般会采用的类型）

    3. 矩阵型：结合了职能型和纯项目型的优势，项目内的成员受项目经理和职能经理双重领导。

       适用于项目周期短有需要多个只能部分门参与的项目

  • 软件项目的组织架构：

    1. 项目总监： 项目管理最高决策人，对项目的总体方向进行决策和跟踪。
    2. 项目经理： 项目经理直接报告给项目总监，负责完成项目的具体管理，是项目综合管理的焦点，是客户高层和部门沟通的中心。
    3. 业务组： 完成软件项目的需求任务小组。
    4. 架构组： 负责建立和涉及系统的总体架构。
    5. 开发组： 负责完成系统的详细设计和编码任务。
    6. 测试组： 负责计划和实施对软件的测试，以确定软件产品满足其需求。
    7. 质量组： 负责计划和实施项目的质量保证活动
    8. 配置组： 负责计划、协调、实施和维护项目的正规配置管理活动。

  • 项目经理的能力：自身修养、管理能力、技术能力

  • QA与QC

    • QC质量控制者。检验产品的质量，保证产品符合客户的需求，是产品质量检查者。（测试组成员，关注的是产品）
    • QA质量保证者。通过建立和维持质量管理体系来确保产品质量没有问题，是过程质量审计者。（质量组成员，关注的是软件产品质量保证体系）

项目计划：

• 项目计划的概念：计划是事先确定项目的目标和实现目标所需要的原则、方法、 步骤和手段等完整方案的管理活动。其目的是制定一套软件项目实施及管理的解决方案。
• 项目计划的内容：
  1. 目标：在特定的时期内所要达到的期望结果。
  2. 策略：为了达到或超过目标所采取的方法和措施，包括如何做出决策和组织行为的总体指导。
  3. 流程：执行政策的具体方法和步骤，包括里程碑设置、沟通渠道、问题报告机制等。
  4. 标准：项目过程和产品所要遵守的规定、规范和要求，以及对个人或团体绩效所定义的、可接受的标准。
  5. 质量：对软件项目输出成果的要求，包括阶段性产品和最终产品的质量需求。
  6. 进度安排：事先安排的个人或团体活动、任务或事件的开始时间和结束时间。
  7. 预算：为了达到或超过目标所需要的开支，为将来的成本控制建立依据。
  8. 资源：组织结构、人员数量和角色的确认，包括各个角色的责任和义务，人员之间工作配合的要求。
  9. 风险：对项目成功构成的威胁或负面影响因素，影响大小或损失，以及相对应的风险防范和处理措施。
  10. 配置管理：包括软硬件配置项的定义、基线建立、版本控制和变更控制等工作内容。
• 项目计划的方法：
  • 滚动计划方法：滚动计划方法是一种动态编制计划的方法，它是按照“近细远粗”的原则制定一定时期内的计划，然后按照计划的执行情况和环境变化，调整和修订未来的计划，并逐期向后移动，把短期计划和中期计划结合起来的一种计划方法。
    • 滚动计划方法的特点：
      • 分而治之（divide and conquer），一般将整个软件开发生命周期分为多个阶段，针对不同的阶段制定不同的计划。越接近的阶段，计划越详细；越远的阶段，计划越粗糙。
      • 逐步求精 （scalability in granularity），最近的一期计划为实施计划，后面的各期计划为预测计划，随着时间的推移，预测计划逐步变成实施计划。
      • 动态规划（dynamic programming），以计划的“变（调整）” 来主动适应用户需求和软件开发环境的变化，即“以变应变”。
      • 和谐过渡（harmonious transition），可以使项目中短期计划随时间的推移不断更新；可以解决生产的连续性与计划的阶段性之间的矛盾。
    • 软件研发中的滚动计划：
      • 研发计划可以分为五个层次
        1. 产品愿景（Vision），相当于产品最终要实现的目标，是一个长期努力的目标，可以理解为商业战略上的目标。
        2. 产品路线图（Roadmap）：是一个中长期的产品规划，产品路线图可以考虑最近3-5年。通过这个路线图，分阶段来实现上述的产品愿景。
        3. 发布计划（Release Planning）：短期（如一年）产品发布计划，根据产品路线图，通过发布计划实现其第一个关键的里程碑。
        4. 迭代计划（Sprint Planning）：根据发布计划，来规划当前迭代要完成的目标和住务，包括具体的人员和进度安排。迭代周期一般为一周到四周，一个发布计划可能涵盖十几个迭代， 体现在完整的产品需求列表（product backlog）中，而迭代计划就是要完成具体的任务以实现有限的用户故事，体现在迭代任务列表（sprint backlog）中。
        5. 每日计划（Daily Planning）：就是第2章介绍的Scrum站立会，每个人向团队汇报三个问题，其中一个问题就是：今天要做什么？回答这个问题，就是给出今天的工作计划。
  • WBS方法：工作分解结构方法（WBS）是一种将复杂的问题分解为简单的问题，然后再根据分解的结果进行计划的方法。WBS方法以可交付成果为导向，对项目要素或整个工作范围进行分解、逐层推进，每向下分解一层就能对项目工作有更详细的了解和定义，从而掌握项目的全部细节，有利于做出相对准确的计划。WBS方法还可以看作结构化的设计工具，以描述项目所必须完成的各项工作以及这些工作之间的相互联系。
    • 原则和要求：WBS最低层次的项目可交付成果称为工作包， 工作包的定义应考虑80小时法则或两周法则，即任何工作包的完成时间应当不超过80小时，即不超过两周。通过这种定期检查的方法，可以控制项目的变化。
    • 创建WBS的步骤
      1. 分解工作任务。根据项目的特点，选择合适的方式，将项目工作逐步分解合适的粒度。
      2. 定义各项活动/任务之间的依赖关系。活动之间的依赖关系决定了活动的优先级，也确定了每一项活动所需的输入、输出关系，是将来完成项目关键路径的必要条件。
      3. 安排进度和资源。根据所分解的工作任务以及它们之间的依赖关系，就比较容易确定和安排各项任务所需的时间和资源。
    • 创建WBS的方法：创建WBS可以用自上而下、自下而上、类比、归纳等方法， 而最常用的是自上而下的方法。
  • 网络计划技术：网络计划方法是一种应用网络模型直观地表示软件开发众多工作（工序）之间的逻辑关系与时间关系，对完成软件工程项目所需时间、费用、资源进行求解和优化的计划方法，其基本类型是关键路线法\计划评审技术（CPM/PERT）。网络计划方法一般是建立在WBS方法之上，先分解，才能优化。
• 项目计划的原则：
  1. 目标性原则。计划必须以目标为导向，服务于目标。制定计划前，一定要清楚目标；
  2. 预防性原则。风险控制是软件项目计划的核心工作，所有计划工作始终要考虑如何降低项目风险。风险控制最有效、代价最小的办法就是风险预防。
  3. 客观性原则。知己知彼，收集各方面的信息，充分和客户、 相关利益人、项目组人员等进行沟通，了解事实和真相，制定切实可行的计划。
  4. 系统性原则。各个子计划不是孤立存在的，而是彼此之间紧密相关的。
  5. 适应性原则。计划是一个过程，而不只是一个文档，根据情况发生的变化，对计划进行调整也是必要的。
• 项目计划制定的原理：根据软件计划的内容、方法、过程弄清楚项目计划的输入，按照项目的流程进行制定。
• 项目计划制定的基本概念：
  1. 确定项目范围：简单地说就是项目做什么，哪些做哪些不做。
  2. 策略制定：根据范围、时间、成本三者时间的平衡来制定策略
  3. 资源计划：通过分析和识别项目的资源需求，确定出项目需要投入的资源。软件项目资源可分为3类——人力、可复用的软构件或组件、软硬件环境。（人力资源是最重要的资源）
  4. 进度计划：说明项目中各项工作的执行顺序、开始时间、完成时间及相互依赖衔接关系的计划。（原则：以目标为导向，考虑进度的影响因素，留有余地，一般按不利的情况来决定，而不要过于乐观，导致项目计划的失败。）
  5. 成本计划：将各个活动或工作包的估算成本汇总成总预算，再根据具体情况将费用计划分配到各个活动或工作包上去， 从而确立测量项目绩效的总体成本基准。
  6. 风险计划：风险计划，更准确地说是风险对策计划。风险对策计划是为了降低项目风险的损害而分析风险、制定风险应对策略方案的过程，包括识别风险、评估风险或量化风险、编制风险应对策略方案等过程。
  7. 质量计划：质量计划是说明项目组如何具体执行组织的质量方针，确定哪些质量标准适合该项目，并决定如何达到这些标准的过程，即通过策划各种质量相关活动来保证项目达到预期的质量目标，而质量目标是由用户需求和商业目标来决定的。项目质量计划包括质量控制、质量保证和质量管理的计划。

项目估算：

• 项目估算的基本内容：

  1. 规模估算：以代码行数、功能点数、对象点或特征点数等来对软件项目所开发的产品进行估算。软件规模估算是工作量估算、进度估算的基础。

  2. 工作量估算：将任务分解并结合人力资源水平来估算，合理地分配研发资源和人力，获得最高的效率比。工作量估算是在软件规模估算和生产率估算的基础上进行的。一般根据历史数据和软件规模估算的结果进行估算。

  3. 进度估算：通过任务分解、 工作量估算和有效资源分配等对项目可能实施的进度给出正确的评估。

  4. 风险估算：一般通过 “风险发生的概率”和“风险发生后所带来的损失”来评估风险。

  5. 其他估算：如需求稳定性或需求稳定因子、资源利用效率、文档复审水平、问题解决能力代码动态增长等。

• 项目估算的概念：项目估算是针对软件开发项目的规模、工作量、成本、进度等进行估算，这些估算是发生在项目实施之前，即在计划过程中完成。项目估算是基于历史数据、经验和一定的方法来完成的， 由项目的目标、工作范围、产品规模、业务逻辑和采用的技术等决定。

• 软件规模估算：

  • 德尔菲法：德尔菲法是一种专家评估技术，适用于在没有或没有足够历史数据的情况下，来评定软件采用不同的技术或新技术所带来的差异，但专家的水平及对项目的理解程度是工作中的关键点。

  • 代码行估算方法：代码行（LOC）估算方法是最基本、最简单的软件规模估算方法，应用比较普遍。LOC指所有可执行的源代码行数，包括可交付的工作控制语言语句、数据定义、数据类型声明、等价声明、输入/输出格式类型声明等。

  • 功能点分析方法：功能点分析法（FPA）是在需求分析阶段基于系统功能的一种规模估算方法，是基于应用软件的外部、内部特性以及软件性能的一种间接的规模测量，近几年已经在应用领域被认为是主要的软件规模估算方法之一。

    功能点分析的计数就是依据标准计算出的系统中所含每一种元素的数目。

    • 外部输入数
    • 外部输出数
    • 内部逻辑文件
    • 外部接口文件
    • 外部查询数

  • 标准构件法：软件由若干不同的“标准构件”组成，这些构件对于一个特定的应用领域而言是通用的。

  • 综合讨论：

    从估算方法来看，软件规模估算主要采用分解、对比和经验等各类方法，但更多的时候是将这些方法结合起来使用。分解的方法包括纵向分解和横向分解。

    • 纵向分解是在时间轴上对项目进行分解，也就是将整个项目过程分解为子过程（阶段），然后再分解为更小的活动或任务。纵向分解方法是基于过程的估算方法。
    • 横向分解是针对软件产品（或系统）来进行分解，将产品进行模块、组件或功能方面的分解，包括WBS方法、功能点方法和代码行方法等。

• 项目工作量估算：

  • COCOMO方法：构造性成本模型COCOMO方法是一种精确、易于使用的基于模型的成本估算方法。
    • 该模型按其详细程度分为3级。
      1. 基本COCOMO，是一个静态单变量模型，它用一个以已估算出来的源代码行数（LOC）为自变量的函数来计算软件开发工作量。
      2. 中间COCOMO，在用LOC为自变量的函数计算软件开发工作量的基础上，再用涉及产品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算。
      3. 详细COCOMO，包括中间COCOMO的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑对软件工程过程中分析、设计等各步骤的影响。
    • 在该模型中使用的基本量有以下几个
      • 源指令条数（DSI），定义为代码行数，包括除注释行以外的全部代码。若一行有两个语句，则算做一条指令。KDSI即为千代码行数。
      • MM（估算单位人月）表示开发工作量。
      • TDEV（估算单位为月）表示开发进度，由工作量决定。
    • 影响软件工作量的因素：
      1. 产品因素，包括软件可靠性、数据库规模、产品复杂性。
      2. 硬件因素，包括执行时间限制、存储限制、虚拟机易变性、环境周转时间。
      3. 人的因素，包括分析员能力、应用领域实际经验、程序员能力、虚拟机使用经验、程序语言使用经验。
      4. 项目因素，包括现代程序设计技术、软件工具的使用、 开发进度限制。
  • 多变量模型：1978年Putnam提出的模型是一种动态多变量模型，它假设了在软件开发项目的整个生命周期中的一个特定的工作量分布，该模型是根据4000多个软件项目的历史数据统计推导出来的。
  • 基于用例的工作量估计：用例在UML中被定义为“一个系统可以执行的动作序列的说明”，其中这些动作与系统参与者进行交互。
  • IBM RMC 估算方法：RMC（Rational Method Composer）的工作量估算功能采用的是定量影响因子估算方法和自底向上估算模式，让项目经理或者过程工程师对项目的任务、活动、阶段、子项目、项目等进行自底向上的层层估算。
    • 估算模型：
      • 用例估算模型：使用用例的数量和复杂度来估算工作量。它包含的估算因子可能有复杂用例、 简单用例等。
      • 多因素估算模型：使用一个项目的多个方面来估算工作量。它包含的估算因子可能有业务领域、平台、类、用例等。
  • 扑克牌估算方法：团队中三、四个人坐在一起，针对某个任务进行估算，将估算的结果通过特制的扑克牌表示出来，即选出代表自己估算值的纸牌，然后根据所出牌的数字（个人估算结果）进行比对，差异最大的两个人需要说明估算的理由、依据等，其它成员也可以补充发言。然后，再出牌，再沟通，直到这几个估算结果基本一致为止，这个一致的结果就是该任务工作量的估算结果。在实际工作中，可能很难达到完全一致，所以只要到了比较接近时（如最大差值不超过5个点）或进行了4轮出牌（估算）， 就可以终止该条目的估算，取大家估算值的平均值就可以了。
  • 不同场景的估算法：
    1. 合同签订之前：合同未签订时，了解的需求比较有限，只能了解到项目的总体需求，如开发什么样的系统、大概有多少用户等。通过估算项目的工作量，可以了解开发的成本，从而给出合理的报价。
    2. 基于WBS估算的多维验证：当我们获得类似项目的历史数据、软件生命周期的生产率数据（含管理工作量）和详细需求时，就可以从不同的路径来估算工作量，获得多个结果，这些结果可以互相印证，以发现估算过程中的不合理之处，使估算更准确。
    3. 需求变更的工作量估计：软件需求经常发生变化，而在需求变更控制时，也要提交需求变更所带来的工作量，也就是要求为需求变更进行工作量估算。这种情景也经常碰到，有必要在这里进行讨论。需求变更常常发生在设计、编码阶段，这里以编码阶段发生需求变化的情景为例来完成工作量的估算。

• 项目估算基本方法：

  • 分解方法。采用“分而治之”的策略，对软件项目进行分解，将复杂问题转化为简单的问题，将整个项目分解成若干主要的功能及相关的软件工程活动，然后针对简单项（单个功能或单个活动）采用逐步求精的方式进行估算，最后通过累加获得整体的估算结果。
  • 算术模型法，通过估算模型 （即带有多个变量的函数）来估算，如COCOMO模型、功能点分析、特征点、对象点、Bang估算、模糊逻辑、标准构件法以及IBM定量影响因子估算模型等。
  • 专家判断（Expert judgment）或经验法，如德尔菲法 （Delphi technique）。估算的人应有专门知识和丰富的经验， 据此提出一个近似的数字。但这种方法的可靠性和准确度都比较低，适合于快速拿出一个初步估算，而不适合进行详细的估算。
  • 比例法是比较科学的一种传统估算方法，是基于类比的估算技术，根据过去类似的项目，直接进行类比获得当前项目的估算结果。

• 资源估算的方法：

  1. 根据WBS进行估算：根据WBS的分解结果来估算资源，主要是一些独立的工作应该由独立的人员去完成，而减少人员沟通成本，减少人员之间的依赖性，并使人员的经验和特长得到发挥，力求达到最高的工作效率。
  2. 由工作量和开发周期来估算：由工作量和开发周期来估算所需的人力资源，简单的估算公式如下：人员数量（人）= 工作量估算（人日）/ 工期估算（日）

• 工期估算方法：专家经验估算法和基于历史数据的类比法。当项目获得足够信息时，采用类比法比较好， 而当项目获得的信息有限，难以采用类比方法时，可以采用专家估算法。

  当我们面临有高度不确定性的任务时，我们可以采用三点估算法来进行工期估算。三点估算法就是对每项工作的工期给出3 种预估值——最可能时间、最乐观时间和最悲观时间，然后加权平均计算出其计划时间。

  • 最可能时间——T可能：根据以往的直接经验和间接经验， 这项工作最有可能用多少时间完成。
  • 最乐观时间——T乐观：当一切条件都顺利时该项工作所需时间。
  • 最悲观时间——T悲观：在最不利条件（各项不利因素都发生）下，该项工作需要的时间。

  ​ 则计划时间的计算公式如下：计划时间=（T乐观+ 4 * T可能＋「悲观）/ 6

• 特场景下的估算：

  多数情况下，可能会由工作量和进度来估算人力资源，但还是会有根据工作量和人力资源来估算进度的时候。当我们有了工作量估算之后，可以简单地利用下面的公式获得工期估算。

  工期估算（日）=工作量估算（人日）/人员数量（人）

项目进度和成本管理：

• 标识项目活动的概念：标识项目活动就是把项目的工作量分解为易管理的具体任务， 而每一项任务都要有明确的时间和资源的限制，它是项目进度表编制的基础。

• 确定项目活动的次序：

  1. (确定活动中的依赖关系)确定各个活动之间的相互依赖关系。项目活动之间的依赖关系就是指活动在时间上的逻辑顺序。
  2. (确定项目排序)项目网络图是显示活动顺序的首选方法。创建项目网络图通常有两种常用的方法：前导图法和箭线图法。
  3. (确定关键路径及活动)关键路径和关键活动的确定：在项目网络中会有若干条网络路线，对比各网络路线的累加工期，就会发现通常有一条路线的时间最长。这条路线决定着项目的工期时间，称为关键路径。位于关键路径上的活动就是关键项目活动。

• 活动缓冲期的计算：计算出活动的缓冲期是在标识出关键路径和关键活动之后进行的重要任务，即在不导致项目预估工期延迟的情况下，各个活动可以有多少时间的延迟。因为项目的预估工期是关键路径上的各个关键活动所需时间之和，任何关键活动的延迟都会导致项目工期的延期，所以关键活动的缓冲期都是0。

• 压缩工期：

  • 压缩工期的概念：只有使关键路径的工期缩短，整个项目才可以提前结束。
  • 压缩关键路径：压缩关键路径的工期是指在现有的资源、成本和任务不变的前提下，针对关键路径进行优化，结合资源、成本、时间和活动的可调度性等因素对整个计划进行调整，直到关键路径所用的时间不能再压缩为止，得到最佳时间进度计划。
  • 例如在编码实现的阶段，服务器资源的利用上适合其他项目组共享的有五天的冲突时间，而项目的测试组同时又有两台测试服务器限制测试使用到编码结束，那么编码小组完全可以通过项目经理进行协调把项目小组的服务器借来五天来规避与其他项目组的冲突，这样下来编码实现就可以缩短五天整个项目的周期可以减少到48天。

• 关键路径分析：关键路径分析是在项目进度管理中应用最为广泛的网络技术之一，它借助网络图和各活动所需时间来估算项目的总工期。通过应用关键路径法对网络图进行分析和运算，就可为进度管理工作指明方向，为项目经理提供决策依据，从而保证项目在预算范围内如期完成。

• 关键路径和关键活动的确定：在项目网络中会有若干条网络路线，对比各网络路线的累加工期，就会发现通常有一条路线的时间最长。这条路线决定着项目的工期时间，称为关键路径。位于关键路径上的活动就是关键项目活动。

• 里程碑的概念：在制定项目进度计划时，在进度时间表上设立一些重要的时间检查点，这样一来，就可以在项目执行过程中利用这些重要的时间检查点来对项目的进程进行检查和控制。这些重要的时间检查点被称作项目的里程碑。里程碑一般是项目中完成阶段性工作的标志，标志着上一个阶段结束、下一个阶段开始，将一个过程性的任务用一个结论性的标志来描述，明确任务的起止点。

• 里程碑的建立方法：

  1. 设立合理的里程碑检查点
  2. 制定里程碑的完成目标
  3. 明确里程碑的验证标准
  4. 确认里程碑的利益相关人
  5. 标识里程碑的进度百分比

• 里程碑的管理：

  1. 重点关注。里程碑通常代表项目工作中一个重要阶段的完成，不仅仅是项目经理要高度关注，所有的项目干系人都应该意识到它的重要性。
  2. 提前定期检查。里程碑内设有一些检查点，可以通过负责人定义报告的方式进行监控，以便提前发现问题，使问题及时得到解决。
  3. 及时总结。每到一个里程碑结束的时候，都应该及时对前阶段工作进行小结，吸取教训， 获取经验，从而改进下一阶段的工作。总结不可形式化，要做到切实有效。

• 进度编制方法：常用的制定进度计划的方法有关键路径法（CPM）、计划评审技术（PERT）法、甘特图（GANNT）法和表格表示法。

  • PERT法：计划评审技术PERT，其理论基础是假设项目持续时间以及整个项目完成时间是随机的，且服从某种概率分布。PERT可以估计整个项目在某个时间内完成的概率。各个项目活动的完成时间按3种不同情况估计

    1. 乐观时间（optimistic time）——在任何事情都顺利的情况下，完成某项工作的时间。
    2. 最可能时间（most likely time）——在正常情况下， 完成某项工作的时间。
    3. 悲观时间（pessimistic time） 在最不利的情况下， 完成某项工作的时间。
    • 原理：CPM和PERT是独立发展起来的计划方法，但它们都利用网络图来描述项目中各项活动的进度和它们之间的相互关系，因此都被称为网络计划技术。
      • CPM被称为肯定型网络计划技术，它以经验数据为基础来确定各项工作的时间，并以缩短时间、提高投资效益为目的。
      • PERT被称为非肯定型网络计划技术，它把各项工作的时间作为随机变量来处理，并能指出缩短时间、节约费用的关键所在。
    • 大型项目的工期估算和进度控制非常复杂，往往需要将CPM和PERT结合使用，用CPM求出关键路径，再对关键路径上的各个活动用PERT估算出期望和方差，最后得出项目在某一时间段内完成的概率。

  • 甘特图法：用水平线段来描述把任务分解成子任务的过程，以及每个子任务的进度安排

  • 表格表示法：用表格来表示各个活动历时和相互之间的依赖关系。适用于小型项目，因项目各项活动之间的关系都要在表格中表示出来，不够直观，大型的项目有大量活动，看起来就比较混乱，不便于管理。

• 进度计划编制的策略：

  1. 重视与客户的沟通

  2. 进度计划最好按需制定

  3. 项目组成员共同参与制定项目进度计划

  4. 任务分解与并行化

  5. 任务、人力资源、时间分配要与进度相协调

  6. 项目的工作安排一定要责任到人

  7. 工作量分布要合理

  8. 充分利用一些历史数据

  9. 考虑相关风险，计划意外事故缓冲时间

  10. 制定和使用进度计划检查清单

• 软件项目进度控制：软件项目的进度不是等到有了详细的进度计划才开始监督和控制的，而应该从项目开始启动那一刻就开始，并贯穿整个项目生命周期，根据其各个发展阶段（启动、计划、执行、收尾等） 的不同关注点来实施进度控制。

  1. 项目阶段情况汇报与计划：模块、小组和项目负责人按照预定的每个阶段结束点定期与项目成员和其他相关人员进行充分沟通，然后向相关上级和管理部门提交一份书面的项目阶段工作汇报与计划

  2. 定期和不定期的项目进度检查：随时检查并掌握项目实际进度信息，不断地进行总结分析，逐步提高计划编制、项目管理和进度控制水平。问题越早发现就越容易纠正，造成的影响和损失就越小。

  3. 制定适当的进度控制流程：一个软件企业或者一个软件部门，如果经常开发同类产品或者使用相似的软件开发周期等，那么就可以根据经验和业务流程制定一个规范的进度控制模板，如阶段性检查列表 （checklist），走查（walkthrough），在以后的项目管理中， 就可以直接拿来使用。

  4. 调整各种项目目标之间的平衡：如果经过评估确定项目确实已无法控制，就应当下定决心以牺牲某一项或者一些次要目标为代价，来保住项目最重要的那些目标，避免更大的损失或彻底的失败。应在各种项目目标中进行分析和考量，最终确定一个最合适的解决方案，用最小的代价赢得项目的成功。

     项目的进度管理并不是一个静态的过程，项目的实施与项目的计划是互动的，在项目进度的管理和控制过程中，需要不断调度、协调，保证项目的均衡发展，实现项目整体的动态平衡。

项目质量管理：

• 质量管理的含义：软件质量是软件开发个阶段质量的综合反应，每个环节都可能带来产品的质量问题，因此软件的质量管理贯穿整个软件开发周期。

• 质量管理水平：

  1. 检查，通过检验保证产品的质量，符合规格的软件产品为合格品，不符合规格的产品为次品，次品不能出售。（早期的软件质量控制）
  2. 保证，质量目标通过软件开发部门来实现，开始定义软件质量目标、质量计划，保证软件开发流程的合理性、流畅性和稳定性。（初期软件质量保证）
  3. 预防，软件质量以预防为主，以过程管理为重，把质量的保证工作重点放在过程管理上（成熟的“软件质量保证”）
  4. 完美，以客户为中心，贯穿于软件开发生存期全过程（全面软件质量管理）

• 质量管理支持：

  1. 基础设施，包括质量文化、开发环境和标准体系等；
  2. 方法层次，如采用的开发模型、开发流程等；
  3. 技术层次，包括开发技术的成熟度、开发工具、自动化测试水平等。

• 项目质量的组织保证概念：软件项目质量管理，首先要在组织上得到保证，才能得到最终的落实。

• 组织保证中的结构：

  1. 管理层：管理层具有很强的“质量第一”的意识，能制定有利于保证和提高质量的正确的策略和方针，在整个组织中营造良好的质量文化。

  2. SQA组：软件质量保证组主要是从流程上对软件的质量进行跟踪、控制和改进，即监督项目按已定义的流程进行，并符合已定义的相关标准。例如，要求项目组在开发过程中及时建立相关的文档，以及任何需求变更都要经过变更控制流程，批准之后还要进行配置项修改等。SQA组在职能划分上独立于项目组，但监督项目组的各项活动。

  3. 测试组：软件测试组负责对软件产品进行全面的测试，包括需求评审、设计评审、功能测试、性能测试、安全性测试等， 从中找出所存在的缺陷。（面向产品）

  4. SEPG组：软件工程过程组通常由软件专家组成，在软件开发组织中领导和协调过程改进的小组。其主要任务是推动企业所应用的过程的定义、维护和改进。和SQA相比，SEPG类似于一个 “立法”机构，而SQA则类似于一个“监督”机构。SPEG一般负责组织的过程定义，但也可以帮助项目进行过程剪裁，从而使项目流程更有效。

• 质量计划的内容：

  1. 计划的目的和范围。
  2. 该质量计划参考的文件列表。
  3. 质量目标，
  4. 质量的任务
  5. 参与质量管理的相关人员及其责任
  6. 为项目的一些关键文档提出要求
  7. 重申适合项目的相关标准
  8. 评审的流程和标准
  9. 配置管理要求
  10. 问题报告和处理系统
  11. 采用的质量控制工具、技术和方法等。

• 质量计划制定的步骤：

  1. 了解项目的基本概况，收集项目有关资料；
  2. 确定项目的质量目标；
  3. 确定围绕质量目标的工作任务；
  4. 明确项目质量管理组织机构；
  5. 制定项目质量控制程序；
  6. 项目质量计划的评审。

• 如何制定有效的质量计划：质量计划是针对具体的软件开发制定的，总体过程也经历4个阶段：**计划的编制、实施、检查调整和总结。**制定质量计划的主要方法有以下几种：利益/成本分析、基准、流程图、试验设计。

• 质量计划的实施和控制：

  1. 项目实施过程中对各个关键点进行质量评估。
  2. 在质量计划实施过程中，设置检查点验证点对阶段性的成果进行评审和完成质量评估，以确定项目阶段性成果是否达到所设定的质量标准。
  3. 项目收尾阶段需要检查项目文件资料的完备性， 包括评审会议记录测试报告等同时对项目进行总结。

• 软件评审的方法和技术：

  1. 互为复审：在软件团队里，容易形成一对一的伙伴合作关系，从而相互审查对方的工作成果，帮助对方找出问题。
  2. 走查：走查主要强调对评审的对象要从头到尾检查一遍，比上面的互为复审要求更严格一些，从而保证其评审的范围全面，达到预期效果。
  3. 会议审查：它的过程一般包含了制定计划、准备和组织会议、跟踪和分析结果等。
  4. 检查表：在实际的评审过程中不仅要采用合适的评审方法，还需要选择合适的评审技术。
  5. 其他技术：场景分析技术多用于需求文档评审，按照用户使用场景对产品/文档进行评审，如扮演不同的用户角色，模拟用户的行为， 联想到更多的应用场景。

• 软件质量评审的角色和责任：

  1. 项目经理：协助质量保证人员、测试组长等的工作，进行全程的质量跟踪，及时向质量保证人员报告质量问题，将有关质量的改进措施及时在项目组传达，并负责其实施。
  2. 质量保证人员：对整个开发和测试过程进行质量控制，负责质量计划的制定和其实施的监控，组织所要求的各类评审会议等
  3. 系统分析员：负责需求评审的组织和实施，保证需求定义符合相关规范
  4. 架构师：开发组负责人，负责设计的评审等质量保证工作
  5. 编程人员：负责详细设计、编程和单元测试
  6. 测试组组长：参与需求、设计等评审会议，制定测试计划，组织测试计划和测试用例的评审，执行测试的质量跟踪
  7. 测试人员：编写测试用例，并参与评审
  8. 文档编写人员：审查相关文档是否采用了最新的模板，是否符合文档规范的要求

• 软件评审过程及评审注意事项：

  • 评审过程：
    1. 会议准备：要选经验丰富、技术能力强、工作认真负责的人来担任评审组长， 但为了保证评审的公平、公正，通常选派的评审组长不能和作者有密切关系，以避免评审组长不能保持客观性。
    2. 召开会议：评审会议是评审活动的核心，所有与会者都需要仔细检查评审内容，提出可能的缺陷和问题，并记录在评审表格中。会议开始前，每一位评审人员都要做好充分的准备。如果认为某些评审员并没有为该次会议做好准备，评审组长有权也应该中止该次会议，并重新安排会议时间。
    3. 评审决议：在会议最后，评审小组就评审内容进行最后讨论，形成评审结论。评审结论可以是接受（通过）、有条件接受、不能接受和评审未完成（继续评审）。评审会议结束之后，评审小组提交相应的评审结果，如问题列表、 会议记录、评审报告或评审决议、签名表等。
    4. 问题跟踪：审会议上发现的问题，需要进行修订。评审组长或协调人员要对修订情况进行跟踪，验证作者是否恰当地解决了评审会上所列出的问题，并决定是否需要再次召开评审会议。对于评审结果是“有条件接受” 的情况时，作者也需要对产品进行修改，并将修改后的产品发给所有的评审组成员，获得确认。所有问题被解决、修正工作得到确认，评审才算结束。
  • 注意事项：

    1. 明确自己的角色和责任。

    2. 熟悉评审内容，为评审做好准备，做细做到位。

    3. 在评审会上关注问题，针对问题阐述观点，而不是针对个人。

    4. 可以分别讨论主要的问题和次要的问题。

    5. 在会议前或者会议后可以就存在的问题提出自己的建设性的意见。

    6. 提高自己的沟通能力，采取适当的、灵活的表述方式。

    7. 对发现的问题，要跟踪到底。

• 评审方法及如何有效地组织评审：

  1. 分层评审方法：采用分层次评审的方法，是先总体，后细节，一开始不要陷入一些细节，而是按从高层次向低层次推进的方法来完成评审。高层次评审：主要从产品功能逻辑去分析，检查功能之间衔接是否平滑、功能之间有没有冲突；低层次评审：可以建立一个详细的检查表逐项检查，包括是否存在一些含糊的描述，如“要求较高的性能”“多数情况下要支持用户的自定义”等。

  2. 分类评审方法：需求往往由于来源不同，而属于不同的范畴，所以需求的评审也可以按照业务需求、功能需求、非功能需求、用户操作性需求等进行分类评审。例如可按以下几类需求进行评审：业务目标、功能性需求、操作性需求。

  3. 分阶段评审方法：在需求形成的过程中，最好采用分阶段评审方法进行多次评审，而不是在需求最终形成后只进行一次评审。分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审，降低了需求分析返工的风险，提高了评审的质量。

• 缺陷预防的方法：

  1. 从流程上进行控制，避免缺陷的引入，也就是定义或制定规范的、行之有效的开发流程来减少缺陷。例如，加强软件的各种评审活动，包括需求规格说明书评审、设计评审、代码评审和测试用例评审等，对每一个环节都进行把关，杜绝缺陷，保证每一个环节的质量，最后就能保证整体产品的质量。
  2. 采用有效的工作方法和技巧来减少缺陷，即提高软件工程师的设计能力、编码能力和测试能力，使每个工程师采用有效的方法和手段进行工作，有效地提高个体和团队的工作质量，最终提高产品的质量。

• 测试驱动开发的过程：

• 缺陷趋势分析及分布分析：

  1. 缺陷趋势分析：缺陷趋势分析，就是针对缺陷数目随时间而不断变化的趋势进行分析，了解缺陷的发现或修正的过程是否符合期望的规律性， 而没有出现异常现象。这需要统计每天的缺陷发现和修订情况。总的发展趋势图用来分析总的项目情况非常有效。通过分析，可以发现测试或开发过程中存在的问题，从而及时地采取措施进行调整。

  2. 缺陷分布分析：缺陷趋势分析是从时间纵向来进行分析，而缺陷分布分析是横向分析，即针对缺陷在功能模块、缺陷类型、缺陷产生原因等不同方面的分布情况。缺陷分布图直观地反映了缺陷在不同地方的分布密度，有利于对缺陷进行进一步的深入分析。通过缺陷分布图可以很容易找出缺陷主要集中在什么地方，从而可以对该区域的缺陷仔细分析，在以后的项目中采取相应的措施来避免类似的缺陷。

     缺陷分布分析只是分析的第1步。它只不过提供了主要影响产品质量的是哪些模块，其信息不足以给出更深层次的原因。需要针对这些高危模块进一步仔细地分析，识别缺陷产生的根源。

• 鱼骨图（应用）：为了更好地分析缺陷的根本原因，需要对上一节的数据进行更详细的分析，这时经常采用鱼骨图法。鱼骨图又称为因果分析图，它是分析和影响事物质量形成的诸要素间因果关系的一种分析图，因为其形状像鱼骨，所以俗称鱼骨图。使用鱼骨图主要有如下3个优点。

  • 可以更全面地探讨各种类别的原因。
  • 鼓励通过自由讨论发挥大家的创造性。
  • 提供问题与各类原因之间关系的直观表示。

• 质量度量要素：

  1. 数据：数据是关于事物或事项的记录，是科学研究最重要的基础。由于数据的客观性，它被用于许多场合。研究数据就是对数据进行采集、分类、录入、储存、统计分析、统计检验等一系列活动。
  2. 图表：仅仅拥有数据还不能直观地进行表现和沟通，而图表可以清晰地反映出复杂的逻辑关系，具有直观清晰的特点。
  3. 模型：模型是为了某种特定的目的而对研究对象和认识对象所作的一种简化的描述或模拟，表示对现实的一种假设，说明相关变量之间的关系，可作为分析、评估和预测的工具。

• 质量度量的作用：质量提供了对项目进度评估、质量状况的洞察力和用于决策的有关数据。可以帮助决策者通过积极的方法来管理软件项目中与生俱来的关键问题。

• 基于缺陷的质量度量（如何对缺陷进行质量度量）应用：

  • 代码质量：代码质量 = （Wtp +Wf）/ KCSI

    • Wtp：测试过程中（正式发布产品之前）发现的缺陷的权重
    • Wf：产品发布之后发现的缺陷的权重
    • KCSI：新增加的和修改的千行代码数

  • 产品质量：产品质量 = Wf / KCSI

    • Wf：产品发布后发现的缺陷的权重；
    • KCSI ：新增加的和修改的千行代码数。

    一般希望能将此比重控制在5%以内

  • 测试有效性：Wt / (Wtp + Wf) * 100%

    • Wt：在整个产品中由测试小组发现的所有缺陷的权重
    • Wtp：在测试过程中（正式发布产品之前）发现的缺陷的权重；
    • Wf：产品发布之后发现的缺陷的权重。

• 过程质量度量：

  • 过程缺陷密度：过程缺陷密度（ DIPF） 是一种度量标准，可以用来判定过程产品的质量以及检验过程的执行程度。DIPF可以表示如下。

    DIPF = Dn（某阶段或整个项目被发现的缺陷数） / Sp （被测试的软件产品规模（如代码行数、功能点数或对象数等））

  • 整体缺陷清除率： 无论是从项目进展还是从产品质量看，缺陷被清除的程度能反映出项目组在质量上的工作表现，以及待发布的产品质量。开发周期里大量的严重缺陷没有被清除，完全有可能阻止测试的进行，也必然直接影响软件过程的质量和性能。我们可以引入缺陷清除率（Defect Removal Efficiency， DRE）进行度量，DRE可以有如下定义。

    DRE = 开发阶段清除的缺陷数 / 产品中潜伏的缺陷数 * 100%

  • 阶段性缺陷清除率：众所周知，清除软件缺陷的难易程度在各个阶段也是不同的。需求错误、规格说明、设计问题及错误修改相对困难些。为了做好质量管理工作，跟踪开发周期所有阶段中的缺陷， 有必要监控阶段性缺陷清除率。因为编程缺陷中的很大比例是同设计问题有关的，进行正式评审或功能验证以增强前期过程的缺陷清除率有助于减少缺陷的注入。基于阶段的缺陷清除模型能够反映项目的缺陷清除能力。

  • 缺陷到达模式：产品的缺陷密度或者测试阶段的缺陷率是概括性指标，而缺陷到达模式可以提供更多的过程信息。例如，两个正在开发的软件产品，其缺陷密度是一样的，但其质量差异可能较大，原因就是缺陷到达的模式不一样。测试团队越成熟，峰值到达得越早， 有时可以在第一周末或第二周就达到峰值。这个峰值的数值取决于代码质量，测试用例的设计质量和测试执行的策略、水平等， 多数情况下，可以根据基线（或历史数据）推得。

• 缺陷移除和预防：

  1. 数据记录和分析： 工程师在发现和修订缺陷时记录下相关的数据，然后对这些数据进行检查，并找出缺陷的产生原因，最后制定相应的流程来消除这些产生缺陷的因素。
  2. 有效地设计： 为了完成一个设计工程师，必须对产品彻底的理解，这不仅能更好地完成设计，而且能避免产生错误
  3. 彻底地设计： 这实际上是第二种预防方法的结果有了更完善彻底的设计可以减少编码时间，而且还可以减少缺陷的引入。

项目风险管理：

• 项目风险带来的警示：风险发现的越早，成本就越小。

• 项目风险表达式：

• 降低风险的思路：

• 项目风险的定义：项目风险是指潜在的预算、进度、人力（工作人员和组织）、 资源、客户、需求等方面的问题及其对软件项目的影响。每个项目经理都知道风险是项目所无法避免的，无论怎么计划都不能完全消除风险，或者说不能控制偶然事件。但是，正是因为这种不确定性，风险的识别才显得更为重要。

• 项目风险的特点：

• 风险管理的定义和涵义：项目风险管理是指对项目风险从识别到分析直至采取应对措施等的一系列过程，包括风险识别、风险量化、岚险对策和风险监控等，从而将积极因素所产生的影响最大化并使消极因素产生的影响最小化，或者说达到消除风险、回避风险和缓解风险的目的。对项目进行风险管理，就可以最大限度地减少风险的发生。

• 项目风险管理的内容、过程及基本应对措施：

  1. 风险管理的内容包含：风险识别、风险评估、风险计划、风险应对
  2. 风险应对措施包括：规避、减轻、转移、接受。

• 风险管理模型：

  • Boehm模型：Boehm认为，软件风险管理是将影响项目成功的风险形式化为一组易用的原则和实践的集合，在风险成为软件项目返工的主要因素并由此威胁到项目的成功运作前，识别、描述并消除这些风险项。
  • CMU/SEI模型：卡耐基-梅隆大学软件工程研究所（CMU/ SEI）的持续风险管理模型（ContinuousRisk Management。 CRM），要求在项目生命期的所有阶段都关注风险识别和管理，将风险管理划分为5个部分—风险识别、分析、计划、跟踪和控制，并强调风险管理的各个组成部分的沟通，将沟通视为风险管理的核心，不断地评估可能造成恶劣后果的因素，决定最迫切需要处理的风险，实现控制风险的策略，评测并确保风险策略实施的有效性。
  • MSF风险管理模型：MSF（Microsoft Solutions Framework） 强调风险管理必须是主动的、规范的，是不可缺少的管理过程，应持续评估、监控和管理风险，直到风险被处理或消除。MSF风险管理模型，强调风险知识库、掌控风险列表和学习。
  • Riskit模型：美国马里兰大学的Kontio教授提出了Riskit模型，该模型为风险管理的各项活动都提供了详细的活动执行模板，包括活动描述、责任、资源、进入/退出标准、输入/输出方法和工具等。

• 软件风险因素： 潜在的预算、 进度、 人力、资源、客户需求等方面的问题及其对软件项目的影响。

• 风险的分类：

  1. 组织和管理风险
  2. 需求风险
  3. 合同风险
  4. 项目计划方面的风险
  5. 设计和实施的风险
  6. 人员风险
  7. 过程风险
  8. 质量风险

• 风险识别的输入：产品说明、计划输出和历史资料等

• 风险识别的方法和工具：风险的识别有多种方法，包括面谈、头脑风暴会议、调查表、 风险检查列表、风险库（包括历史资料）等，最常用的方法是头脑风暴会议、风险检查列表和风险库等，而对产品和技术的风险， 则要借助于WBS（工作分解结构）方法来识别。

  1. 头脑风暴会议：头脑风暴会议是一种自由、即兴发言的会议，邀请项目成员、 外聘专家、客户等各方人员组成小组，尽可能想象各种情况，每个人根据经验尽量列出所有可能的风险因素。最后，将大家提出来的风险过一遍，归纳、总结就可能得出一个非常完整的项目风险列表。

  2. 风险库：通过阅读类似项目的历史资料能了解可能出现的问题。根据历史经验进行总结，通过调查问卷方式可以判别项目的整体风险和风险的类型。

  3. 检查表：检查表是一个非常重要的、有效的风险识别工具，将可能出现的问题列出清单，可以对照检查潜在的风险。项目组可以根据以往类似的项目和积累的其他风险管理的知识和信息，开发和编制项目的风险检查表。检查表的好处是使风险识别过程短平快， 提高了效率，但是其风险识别的质量在于所开发的风险检查表的质量。对于单个或特定的一个项目，开发风险检查表是不实际的。

• 如何更好地识别风险：需要从以下几个方面进行分析和改进。

  1. 项目的前提、假设和制约因素；

  2. 可与本项目类比的先例。

• 风险度量的内容：风险度量内容包括风险发生的可能性大小、风险发生时间、 风险发生后其结果影响范围和严重程度等。

  1. 风险发生的可能性度量：项目风险度量的首要任务是分析和估计项目风险发生的概率， 即项目风险产生的可能性。一个项目风险的发生概率越高，给项目带来损失的可能性就越大，这就要求我们更加关注，更好地控制这类风险，所以项目风险可能性度量是项目风险评估的不可缺少的内容。
  2. 风险发生后果度量：项目风险后果是指项目风险发生后可能给项目带来的损失大小或对项目成功负面影响的程度。例如，某项目风险发生的后果十分严重，即使项目风险可能性不大，也不能忽视，要小心防范， 一旦这种风险发生可能会直接导致整个项目失败。
  3. 风险影响范围度量：项目风险影响范围是指项目风险可能影响到项目的哪些方面和工作。如果风险的影响范围很大，一旦发生，项目的许多工作会受到影响，可能会造成整个项目管理的混乱。对影响范围大的风险，即使后果不大或可能性不大，也需要防范，并考虑如何缩小其影响范围，或者制定措施，一旦这类风险发生，将其影响范围控制在局部内，使之不扩散到其他方面。
  4. 风险发生时间度量：项目风险可能在哪个阶段或什么时间发生，也是项目管理者比较关注的一个点。知道风险可能发生的时间，风险控制会更有效，能做到恰到好处。例如，人员离职的风险对项目影响比较大， 一旦知道有这种风险，就需要及时和当事人进行沟通，了解他或她什么时候可能会离开，就要做好相应的工作交接准备。当然， 通过对其思想工作和薪酬调整，设法挽留项目关键人员，消除风险是上策。

• 风险分析技术：

  1. 情景分析和专家决策方法：情景分析，一般通过主观判断什么地方可能会出错、出错的可能性有多大。给定这些变量的主观判断，使用主观的成本收益思考过程能做出“接受、或缓解、或转移、或消除风险”的评价。尽管风险没有被量化，但是在多数情况下，基于经验判断是比较可靠的。如果是借助专家的经验，风险评估的结果更为可靠。
  2. 损失期望值法：这种方法是量化的方法，有时也称评分矩阵，一般应用于小项目。这种方法首先要分析和估计项目风险概率和项目风险可能带来的损失大小，然后将二者相乘求出项目风险的损失预估值， 并使用这个预估值去度量项目风险。可以将风险发生概率用百分比（0~100%）表示，而给项目带来的损失用估计成本（货币） 表示，然后找出那些“概率X估计成本”乘积大的事件。
  3. 模拟仿真法：模拟仿真法是用数学模拟或者系统法模型去分析和度量项目风险的方法，通过不断调整参数、不断模拟，可以得到仿真计算的统计分布结果，由此作为项目风险度量的结果。模拟仿真法一般应用在大规模或复杂项目的风险度量上，可用来度量各种可量化的项目风险，包括项目工期风险和成本风险等。由于项目时间和成本的风险都是项目风险管理的重点，所以，模拟仿真法在项目风险度量中应用较为广泛。
  4. 风险评审技术：风险评审技术（VERT）是为了适应某些有高度不确定性和风险性的决策问题而开发的一种网络仿真系统。在20世纪80年代初期，VERT首先在美国大型系统研制计划和评估中得到应用。VERT 在本质上仍属于随机网络仿真技术，它按照工程项目和研制项目的实施过程，建立对应的随机网络模型。VERT根据每项活动或任务的性质，在网络节点上设置多种输入和输出逻辑功能，使网络模型能够充分反映实际过程的逻辑关系和随机约束。
  5. 敏感性分析法：敏感性分析法是指从众多不确定性因素中找出对项目目标 （进度、成本和质量等）有重要影响的敏感性因素，并分析、测算其对项目目标的影响程度和敏感性程度，进而判断项目承受风险能力的一种不确定性分析方法。根据不确定性因素每次变动数目的多少，敏感性分析法分为单因素敏感性分析法和多因素敏感性分析法，如单因素敏感性分析法，每次只变动一个因素而其他因素保持不变。

• 风险应对的方法：风险事件发生得越早，造成的损失也就越小。

  1. 避免风险的最好方法是不继续执行项目。一定要判断是否值得承担这么多风险来取得项目的收益。

  2. 让最有能力控制风险的一方负责承担风险是比较明智的。

  3. 应该尽量把风险分配给那些受风险影响最小的项目参与者。

• 风险监控的过程及措施：风险监控中一些常见的有效措施有以下几种。

  1. **建立并及时更新项目风险列表及风险排序。**项目管理人员应随时关注关键风险相关因素的变化情况，及时决定何时采用何种风险应对措施。
  2. **风险应对审计，**保证风险应对计划的执行并评估风险应对计划执行效果，包括项目周期性回顾、绩效评估等。
  3. 对突发的风险或“接受”的风险采取适当的应变措施。
  4. 建立报告机制*，及时将项目中存在的问题反映到项目经理或项目管理层。**
  5. 定期召集项目干系人召开项目会议**，对风险状况进行评估，并通过各方面对项目实施的反应来发现新风险。**
  6. 更新相关数据库**，如风险识别检查表，以利于今后类似项目的实施。**
  7. 引入第三方咨询，定期对项目进行质量检查，以防范大的风险。

• 风险管理的高级技术：

  • 蒙特卡罗法：蒙特卡罗方法是一种随机模拟方法，更准确地说，是一种有效的统计实验计算法。目前，蒙特卡罗方法是项目风险管理中的常规方法，它通过设计概率模型，使其参数恰好重合于所需计算的量；同时，可以通过实验，用统计方法求出这些参数的估计值， 把这些估计值作为待求的量的近似值。从理论上来说，蒙特卡罗方法简单，不需要复杂的数学推导和演算过程，但需要大量的实验，实验次数越多，所得到的结果就越精确。

  • SWOT 分析法：SWOT分析法就是将调查所掌控的各种因素（内部因素和外部因素），根据其轻重缓急或影响程度等进行排序，构造成矩阵， 更直观地进行对比分析。因为矩阵由4种因素构成，即S代表优势、 W代表弱势、0代表机会、T代表威胁，所以这个矩阵称为SWOT矩阵。在此过程中，应将那些对项目有直接的、重要的或严重的、 范围广的影响因素优先排列出来，而将那些间接的、次要的、范围小的影响因素排列在后面。

    在完成环境因素分析和SWOT矩阵的构造后，便可以制定出相应的风险应对计划了。制定风险计划的基本思路是：发挥优势因素，克服弱势因素，利用机会因素，化解威胁因素；考虑过去， 立足当前，着眼未来。运用系统分析的综合分析方法，可以将排列与考虑的各种环境因素相互匹配起来加以组合，得出可选择的对策。这些对策包括以下几种。

    • 最小与最小对策（WT对策），着重考虑弱点因素和威胁因素，努力使这些因素的影响降到最小。
    • 最小与最大对策（WO对策），着重考虑弱点因素和机会因素，努力使弱点趋于最小，使机会趋于最大。
    • 最大与最小对策（ST对策），着重考虑优势因素和威胁因素，努力使优势因素趋于最大，使威胁因素趋于最小。
    • 最大与最大对策（SO对策），着重考虑优势因素和机会因素，努力使这两种因素都趋于最大。

  • 关键链技术：

    进度计划一般基于工作分解结构之上，通过各个具体工作的时间估计来构建计划网络，并应用 VERT 技术、蒙特卡罗模拟法等来获得工期的概率分布，以此来估计进度风险。1997年， Goldratt将约束集理论（Theory of Constraints， TOC）应用于项目管理领域，提出了关键链项目管理（Critical Chain Project Management， CCPM）方法，是项目管理领域自发明关键路线法（CPM）和计划评审技术（PERT）以来最重要的进展之一。

    CCPM用关键链代替了PERT/CPM中的关键路径，不仅考虑了不同工作的执行时间之间前后关系的约束（各任务的紧前关系）， 而且还考虑了不同工作之间的资源冲突。关键链是制约整个项目周期的一个工作序列。关键链管理方法标识了资源约束和资源瓶颈，有利于项目过程资源的配置，降低因资源而引起的进度风险。基于关键链的项目管理方法特别适合于有高度不确定性的环境， 如全新的软件开发项目。

    Goldratt认为在 PERT 工期估计中包含了大部分的缓冲时间， 而缓冲时间并不能保证项目的按时完成。因此他将工作可能完成的时间的50%作为工作工期的估计，并以此建立工作网络图。根据工作间的资源制约关系，修改网络图，确定关键链。然后通过为关键链和非关键链分别设置项目缓冲（Project Buffer）和输入缓冲（Feeding Buffer），来消除项目中不确定因素对项目执行计划的影响，控制进度风险，保证整个项目按时完成。

    基于关键链技术的软件项目进度风险管理方法，一般会采用下列步骤。

    （1）首先对项目进行工作分解，估计理想工作条件下各工作的执行时间以及人力资源分配，建立工作节点网络图。

    （2）考虑人力资源的约束，确定工作节点网络图中的关键链。

    （3）采用技术风险评估技术（如风险量=风险概率X风险时间），对每项工作进行风险分析。

    （4）在此基础上，为关键链配置项目缓冲，为非关键链配置输入缓冲。

    （5）在项目进行过程中，通过对缓冲区的监控，进行计划风险的管理。

  • VERT 技术风险分析：VERT技术是在PERT（计划评审技术）、GERT（图形评审技术） 的基础上发展起来的，包括风险信息系统的成本分析法（RISCA）和全面风险评估成本风险网络（TRACANET）。RISCA和TRACANET 是在网络数学分析器（MATHNET）、网络统计分析器 (STATNET) 和网络求解分析器（SNA）等基础之上开发出来的，其中MATHNET 可以把离散事件活动、活动时间和费用综合起来构成一个概率特征进行计算和分析。

项目团队与干系人：

• 制度建立与执行：

  1. 对于异地同时开发的项目，一定要事先统一好代码检入 （check in）的时间，否则进行日常构建（build）的时候，很容易因为不同步的问题造成失败。
  2. 在项目计划制定过程中由团队成员参加，建立一套用于发现和处理冲突的基本准则，如麦肯锡解决问题的“七步法”。
  3. 根据项目开发经营模式或者项目特点总结出可供参考的过程模型，如微软软件开发解决方案框架（MSF）、IBM统一过程模型（RUP）等。
  4. 对于规模大或复杂的项目，建立监督、控制委员会，以便项目协调管理和统一决策。
  5. 建立统一格式的项目各类模板，有利于整体管理和后期分析，如需求文档模板、设计文档模板、用户手册模板和工作报告模板等。
  6. 对于系列项目或者类似项目建立不同项目阶段的任务检查清单，以便确保项目质量。
  7. **控制代码质量管理，**比如：单元测试覆盖率，静态代码扫描分析，代码审查等管理。
  8. **测试用例管理，**测试用例从设计、运行到存档最好规范起来，形成项目的知识沉淀。
  9. 缺陷管理，缺陷通常都会经历从发现、解决到关闭的过程。但是会有些特例，有些缺陷不能重现，有些缺陷暂时没办法解决， 有些缺陷是目前业界的难题等，这样就需要把这些暂时处理不了的缺陷管理起来。

• 目标和分工管理：

  1. 首先，要考虑设置团队短期和长期的目标。
  2. 其次，把目标通过合理的手段进行分解，制定详细计划，执行、评估和反馈，不断地把团队的目标标准化，清晰化，加快目标的实现过程。
  3. 再次，要为团队成员设定个人目标。
  4. 最后，有了目标体系，还要有合理的工作分工才能高效、高质量地完成任务。

• 激励的步骤及技巧：

  1. 分析激励。不管是针对个体还是针对团队，要产生好的效果，首先必须深入分析他们的需求和期望。

  2. 创建激励环境。良好的环境可以帮助员工发挥最大的潜能，善于运用激励的领导者可以帮助员工超越过去，创造更大的成绩。

  3. 实现激励。对于有成就的员工要实施奖励。有成就的员工包括有进步的，工作表现好的，达到目标的，帮助他人的等， 凡是有助于团队建设和项目发展的都应该给予相应的奖励。

     激励之所以是一门艺术，就是因为组成团队的每个人都各不相同，那么他们的需求和期望也就各不相同。经理要在不同时期， 针对不同成员，发挥聪明才智，不断摸索、运用不同的激励方法和技巧给部下加油。

• 团队生命周期：团队的发展一般都会经过形成期、震荡期、规范期、成熟期和重组期这5个典型阶段。

• 用七步法解决实际问题（应用）

• 知识的横向、纵向传递：

  • 纵向传递：纵向传递是指软件产品和技术知识从需求分析阶段到设计阶段、 从设计阶段到编程阶段、从开发阶段到维护阶段、从产品上一个版本到当前版本的知识传递过程。纵向传递是一个具有很强时间顺序性的接力过程，是任何一个开发团队都必须面对的过程问题。在软件成为成品之前，知识的主要载体是文档和模型，即常称的工件 (artifact) 。
  • 横向传递：横向传递是指软件产品和技术知识在不同团队之间的传递过程， 包括不同工种的团队（市场人员、产品设计人员、编程人员、测试人员、技术支持人员）之间、不同产品线的开发团队之间、不同知识领域之间、新老员工之间等的知识传递过程。可以说，横向传递是一个实时性的过程。

• 知识传递的有效方法：

  • 无论是纵向传递还是横向传递，保证知识传递的有效性、及时性、正确性和完整性是必要的。因此应建立一套知识传递的流程、 方法来帮助实现这些目标。另外，对于一些重要信息建立正规的文档是非常必要的。
  • 使用统一的语言（如UML）来描述领域知识、设计模型和程序实现等，能使大家对同样的一个问题有同样的认识，减少知识传递的难度和成本。在引入原型开发方法、迭代开发、敏捷开发过程模式后，软件产品的开发是在不断演进的，软件团队人员可以通过这个演进的过程不断吸收领域知识，进行知识转换和传递，知识传递过程就会变得相对容易。另外，建立良好的反馈机制（如阶段目标的设定和审查就是很好的反馈方式）、文档管理系统、知识库（如 Wiki） 和论坛等，都会有助于知识的共享、传递和积累。

• 如何重视、加强培训：培训是知识传递和转移的最主要的手段，同时也是学习技能和培养良好工作态度的重要途径。

• 如何确保知识经验共享：

  1. 企业角度：
     1. 首先要提倡和强调知识经验共享的重要性。
     2. 其次要确立正确而鼓舞人心的知识管理愿景和战略目标。
     3. 再次要建立指导监督团队，来提供足够的推动力。
     4. 最后要激励知识共享的贡献者。
  2. 个人角度
     1. 要做到无私奉献，无偿分享。
     2. 要积极参与知识的分享和讨论，在讨论中不断学习、 相互提高，真正实现从知识到能力的跨越。

• 绩效管理的定义：绩效管理是一个持续的交流过程，该过程由员工和他/她的主管之间达成的协议来保证完成，并在协议中对下面的问题有明确的要求和规定。

  1. 明确期望员工完成的实质性的工作职责。

  2. 明确员工的工作对公司实现目标的影响。

  3. 以明确的条款说明“工作完成得好”是什么意思。

  4. 员工和主管之间应如何努力以维持、完善和提高员工的绩效。

  5. 工作绩效如何衡量。

  6. 指明影响绩效的障碍并排除之。

• 绩效管理存在的问题：

  1. 理念错误：很多员工认为绩效管理是人力资源和经理的事，与自己无关。反正自己是被考核的对象，只要按照规定和制度做事就好了。

  2. 将绩效考核等同于绩效管理：在前面的概念中已经说了，绩效管理是一个计划、辅导、实施、评价、反馈的持续循环的过程。

  3. 过于强调量化：软件产品开发主要是一项智力活动，而其活动成果又是抽象的、知识性的产品，方方面面都要求量化是比较困难的。

  4. 缺少绩效反馈流程：认为绩效考核是人事的职责，从上到下执行，缺少绩效反馈流程，导致项目组成员情绪很大，项目结果每况愈下。

  5. 不注重沟通：许多管理活动失败都是因为沟通出现了问题，沟通在整个项目管理中起着决定性的作用，当然对于绩效管理也不例外。制定

  6. 目标不清晰，持续性较差：对于软件企业来讲，外部环境变化太快（市场方向变化、技术变化、人们需求的不断提升等），导致一些软件企业对未来的发展方向比较模糊，没有明确的目标和自己核心的价值观。

  7. 管理方式千篇一律：每个人都是独一无二的，所以要避免千篇一律的管理方式， 实行个性化管理。每个人都有不同的个人特质，如不同的价值取向、不同的文化背景、不同的成就动机、不同的压力感知程度等等，管理者需要根据每个人的不同特质采取相应的管理方法，实现对员工的“私人定制式管理”，以使其能充分发挥知识和能力。

     员工管理常见的几种方式：

     • 管过程，即全流程监控，适用于生产型员工和新员工。
     • 管结果，即结果导向，适用于知识技术型员工和资深员工。
     • 管方向，即把控主线和底线，适用于有一定能力的管理型员工。
     • 管愿景，即价值观的引导和管理，适合有丰富经验的综合型员工。

  8. 不能有效利用评估结果：大部分软件企业对于评估结果只有两招：物质奖励和晋升。

• 如何做好软件绩效管理：

  1. 绩效管理工作前期调查：这一环节是绩效管理的前提。在制定计划之前，要先明确企业的经营发展战略、组织结构、工作流程、岗位设置、企业文化等方面的信息。掌握这些信息对后面如何计划有很大的帮助。

  2. 绩效计划的制定：这里包括两个方面，一是团队整体绩效计划，二是团队成员个人绩效计划。这两个方面的计划是分别进行的，但不管是团队还是个人的绩效管理计划，都应针对其发展目标如何实现，如何执行绩效管理做出深入细致的规划，保证个个环节都有监控和负责的人，这样可以确保整个绩效管理过程是可以追踪和衡量的， 对绩效管理整个方案的实施将大有裨益。计划没有一成不变的， 在实施的过程中要不断地调整和改善。

     绩效管理计划制定结束后应该确定出几个方面的内容：绩效目标、绩效实施计划方案、绩效实施时间或者周期、绩效管理追踪与辅导方法和绩效衡量标准等。

  3. 绩效辅导实施：在绩效计划实施的过程中，管理层要通过有效的沟通不断地对团队及其成员实施绩效辅导，并在取得或偏离阶段性目标的过程中给予适当的激励或纠正，使整个计划的实施不偏离中心轨道。还有一点比较重要，就是沟通过程中要提倡创新意识。随着社会的快速发展，创新越来越重要。想要在纷繁多变的市场经济环境中寻找发展和机会，没有创新是不可能实现的。

  4. 绩效考核评价：绩效实施结束后不管有没有达到预期目标，都要进行评价。管理层通过合理的分析，把绩效目标和实际所做的工作进行对比， 尽量客观地为被评估者指出优点及有待改进的地方。在员工和团队整体考核评价的基础上再进行分析，为绩效目标提出更有效的改善建议和可执行的工作计划。

  5. 绩效反馈和绩效目标的提升：任何流程的执行其反馈环节都值得重视。通过反馈可以掌握单方面看不到的信息和状况，再通过有效的沟通和讨论使其流程和制度更加完善，从而提高个人和整体的绩效。反馈的渠道可以多种多样，时间也没有限制，可以贯穿整个绩效流程中。但这里要强调的是，对于考核评价的结果一定要与被评估人进行绩效面谈，通过有效的沟通技巧让被评估人了解他在工作中的优缺点， 并一起分析制定下一阶段的发展规划。

• 软件团队绩效考核方法讨论：

  1. 定性指标

     • 工作态度，如责任心、敬业精神、工作热情等。

     • 工作氛围，如团队士气如何，精神状态如何。

     • 工作经验，如工作方法高效与否，知识的传递正确、及时与否。

     • 团队合作能力，沟通是否通畅，是否能及时处理矛盾。

     • 应变能力，对于变更的控制、计划、实施和监督的效果如何。

     • 处理问题能力，对于出现的问题，能否及时，正确地解决。

  2. 定量指标

     • 工作量，如完成产品的功能点数量、人员实际工作天数。
     • 工作效率，对比前面版本工作效率是否提高，或者和项目初期制定的相关度量来对比，如每天执行的测试案例数量、每天完成的代码行数/功能点数和每天发现的缺陷数量等。
     • 工作质量，通过项目相关工作度量来对比，如每天/每一千行/每个功能点的缺陷率、回归缺陷率和客户满意度反馈等。
     • 按时完成，是否每个里程碑都能按时完成等。

• 如何识别干系人：我们要在项目之初尽早识别出这些人和组织，因为从项目一开始就要和他们建立充分的沟通以确保项目正常运行。所以也可以说识别项目干系人是沟通的基础。可以通过头脑风暴法识别， 也可以利用之前项目的存档文件把相关干系人列出来。仔细思考哪些是可能影响到项目，或者项目可能影响到的人和组织。

• 分析了解干系人：这个阶段就是要确定项目利益干系人的需求和期望并做出分析。在各种干系人分析方法中，最常用的主要有影响力/利益矩阵、SWOT分析法等。

  1. 影响力/利益矩阵：根据相关利益人的影响力及其与项目的利益水平进行分类。我们可以通过影响力/利益矩阵来决定与各相关利益人分别构建什么样的关系。

  （2） SWOT分析法：这是一个由麦肯锡咨询公司提出的、常用的分析方法，包括分析优势、劣势、 机会和威胁。

• 管理干系人期望

  • 核心干系人：定期的全方位项目交流，包括项目组例会、与项目管理部门的沟通会议、项目关键里程碑会议总结等。
  • 重要干系人：关键里程碑的前期评审会议，定期的项目状态和信息发布，定期收集反馈等。
  • 非核心干系人：不定期，非正式的沟通是必要的。保持良好的合作关系。比如项目紧，需要加班，那么就需要行政部分提供加班餐和班车等服务。

项目监督和控制

• 过程度量的内容：

  1. 软件过程能力度量：CMM/GMMI 是对软件过程能力最好的诠释，软件过程能力通过 GMM的18个关键过程域或CMMI的24个过程域体现出来。
  2. 软件过程性能的度量：软件过程性能的度量分为4部分：过程质量度量、过程效率度量、过程成本度量和过程稳定性度量。进一步划分后，软件过程性能的度量包括软件产品和服务质量、过程依赖性、过程稳定性、过程生产率、时间和进度、资源和费用、技术水平等。
  3. 过程效率度量和质量度量的有机结合：软件开发过程的度量，往往将过程效率和过程质量结合起来进行度量及度量分析，以获得过程性能的最优平衡。

• 过程度量的流程和阶段：

  1. **识别目标和度量描述。**根据各个项目的不同要求，分析出度量的工作目标，并根据其优先级和可行性，得到度量活动的工作目标列表，并由管理者审核确认。根据度量的目标，通过文字、 流程图或计算公式等来描述度量活动。
  2. **定义度量过程。**根据各个度量目标，分别定义其要素、 度量活动的角色、数据收集过程、数据格式和存储方式、度量数据分析反馈过程、环境支持体系等。
  3. **搜集数据。**根据度量过程的定义，接受有关方面提供的数据，主动采集数据，或通过信息系统自动收集数据，并按指定的方式审查和存储。
  4. **数据分析与反馈。**根据数据收集结果，按照已定义的分析方法、有效的数学工具进行数据分析，并做出合理的解释，完成规定格式的图表，将分析报告反馈给项目经理、相关的管理者和项目组。
  5. **过程改进。**对于软件开发过程而言，根据度量的分析报告，可以获得对软件过程改进的建设性建议，管理者可以基于度量数据做出决策。

• 过程度量的方法：

  1. 指定基限，即上限（Upper Limit，UL）和下限 （Lower Limit， LL) 。
  2. 平均期望值，即均值（Average Value， AV)

• 过程度量定义的规则：

  1. 制定度量参数时应尽可能考虑组织的受用性和通用性。
  2. 度量的目标是改进软件开发过程，提高质量和效率。
  3. 避免度量指标太多或者太少。
  4. 利用专门的系统或者用专人进行统计度量工作。
  5. 为收集数据和制定度量标准的个人及小组提供定期的反馈。
  6. 对于新的度量参数要增加试运行环节，在正式应用时应尽可能确保度量参数的合理性。
  7. 在度量方面要遵循灵活性原则。

• 数据收集的方式：被动接收和主动收集。

  1. 被动接收：被动接收是指项目成员按规定/要求发出项目的相关数据信息，之后由项目经理或者项目组长进行整理和分析。目前，比较常见的方式是日报、周报和月报，就是要求项目成员在每天/每周每月对自己的相关项目工作信息进行自我总结和归纳，然后发给项目经理及项目组主要成员等指定人员。
  2. 主动收集：被动地收集信息是不足够的。因为有些问题可能会被隐藏起来，所以需要主动地收集信息，随时掌握项目状流，这对项目的监控会很有帮助。项目组长/负责人/经理应该通过各种手段主动地进行数据的收集。

• 如何确保数据质量：针对数据的质量需要注意以下几点。

  1. 数据的真实性：只有真实的数据才能反映真实的情况，才能给出真实的依据， 基于真实数据的分析才更可靠，才能帮助我们做出正确的决策。 所以收集的数据应该通过筛查，才能保证其数据的真实性。
  2. 数据的及时性：在软件开发过程中，有些数据是要求及时收集的，如果不能及时上报这些数据并解决数据所反映的问题，将会对软件项目的进度，甚至质量、成本造成很大的威胁。例如，在分析需求的时候，明知道在现阶段是不可能完成某个需求的实现的，但抱着试试看的态度，没有及时向用户说明，结果导致在项目开发后期才向客户表明需求不能实现。
  3. 数据的有效性：有效的数据才有分析的价值。确保数据的有效性取决于管理规范和成员的积极配合。不管是项目的开始、进行中还是结束， 都要不时地对员工进行相关管理、素质提高等相关方面的培训。这样在提高员工能力的同时，管理理念/相关规范也会深入人心。那么员工就容易识别和上报有效的数据信息，这样提高了数据分析的可信度，同时也减小了筛选数据的人员的工作量。

• 全程可视化的概念：可视化管理可以使管理任务 “化繁为简”，监控起来**“一目了然**”。

• 全程可视化的内容：

  1. 项目前期调查时期：在这个阶段项目还没最终确定是否要做，我们所关注的是可行性分析的结果。对于技术上没把握的，或者复杂用户界面的项目最好采用原型设计方法。通过可行性原型或者一些模拟技术来实现可视化，让大家清楚技术难度和可实现性。

  2. 项目启动时期：在项目刚刚启动的时候，确定组织结构是可视化的首要任务。通过组织结构图，项目组成员可以清楚地知道项目涉及到哪几个不同的组和不同的人员。这样便于人员之间的相互联系。

  3. 项目计划时期：在项目计划时期，工作任务分解及任务之间相互关系的可视化是非常必要的。尤其是活动之间相互的依赖关系，表格图形有助于提高项目计划的可视性，如WBS图表就是经常使用的可视化的计划图表。

  4. 项目执行时期：在项目的执行时期，最重要的信息就是项目进度如何，计划完成多少工作，实际完成了多少工作，项目是否可以按计划保质保量地完成等。项目经理在项目执行的过程中会不断地收集各个参与小组的进度和相关数据，经过汇总来分析出项目的进度、质量、风险、资源等情况。项目经理会根据不同的情况来选择适合的可视化方法来呈现项目的进展信息。

  5. 项目收尾总结时期

     在这个时期，由于项目接近尾声，紧张的工作终于可以告一段落，是时候把大家的成绩和不足好好总结一下了。把这些信息分析完之后，最好用表格、图形、Powerpoint文件等可视化形式呈现给大家，如可以用柱状图来显示项目总体缺陷的不同级别所占百分比。

  6. 项目后期维护时期

     软件后期维护的可视化主要是针对维护过程中遇到的问题进行汇总和分析，最后将汇总的数据转换成图形或者表格之类的可视化结果。例如，做一个分类分析，把维护工作分成几个不同种类：纠错性维护、适应性维护、预防性维护和完善性维护等，之后对这个分类所占的工作比重进行分析，如图9-10所示。这样就可以知道项目以后开发的努力方向。

• 进度可视化的几种监控方法：

  1. 甘特图：甘特图不仅是制定进度计划的工具，还是进度监控可视化的好帮手。
  2. 延迟图：延迟图其实是由甘特图演变而来的，它注重强调每个活动的相对进度情况。这种图对于那些没有按计划完成进度的活动，提供了更加醒目的可视化显示，如图9-12所示，其中虚线就是延迟线。
  3. 时间线：如果想简单、清楚地展示项目整体进度（客户和有些利益相关人只关心项目的整体进展情况），那么可以选用时间线表示法，如图9-13所示。你一眼就可以看出项目进展到哪一步，进度完成百分比是多少。但是这个表示法的前提是项目的前期规划要尽量做得精确，能比较准确估计里程碑和检查点占总进度的完成百分比。并且随着项目的进展和变化，要不断地调整和完善后面的计划。
  4. 计划与实际对比图：在软件项目的监督和控制过程中，经常会将收集到的项目实际进展信息与进度基准计划做比较，来判断项目是否偏离正常的轨道。要使项目尽可能早地回到正确的轨道上来，就要在对比的过程中及时找出偏差，纠正错误，解决问题。图9-14是某软件执行期某时间点的计划与实际对比进度曲线图。
  5. 燃尽图：燃尽图 （burn down chart）是在项目完成之前，对需要完成的工作的一种可视化表示。燃尽图有一个Y轴（工作）和X轴 （时间）。该图表有一个45度向下的直线，理想状况是，剩余工作量会沿着这条直线“烧尽”至零。现实情况会因项目而异。燃尽图向大家提供工作进展的一个公共视图。可以根据每天的进展来及时控制项目的偏离度。燃尽图常常用于敏捷编程。
  6. 其他进度可视化方法：结合实际工作经验，还有一些非正规、非主流的可视化方法介绍给大家。这些方法对于日常监督和控制项目也起到了很重要的作用。

• 数据分析的阶段：

• 数据分析的方法：

  • 老七种工具，即排列图、因果图、分层法、调查表、散步图、直方图、控制图。

  • 新七种工具，即关联图、系统图、矩阵图、KJ法、计划评审技术、PDPC法、矩阵数据图。

• 运用关联图法进行数据分析：在分析数据信息的时候，特别要注意数据之间的关联性。如果众多因素交织在一起，就可以使用关联图法来分析。它将众多的影响因素以一种较简单的图形来表示。这样易于抓住主要矛盾、 把握问题的关键，这点很重要。就如同牵牛理论：牧童的力气很小，但却能牵着牛走。找出关键问题后，就可以进一步集思广益， 找出解决问题的方法。

• 优先级设定与处理：

  1. 多项目并行优先级处理：在一个软件企业中，多项目并行运作是常有的事。而且每个客户都希望自己的项目可以最早完成，这在现实中是不可能的。 那么公司的领导层要站在全局的角度来处理项目的优先级，管理的重点在于评估好项目的优先级，然后协调各个并行项目之间的资源，从而获得最大收益或最佳投入产出比。

  2. 任务和问题优先级处理：不管是项目经理、项目负责人还是项目成员，在整个项目进行中。都会遭遇到任务或者问题解决的优先级控制问题。针对任务来说，

     常见的几种高优先级的任务有以下几方面。

     • 核心功能或核心模块的任务。

     • 关键路径上的任务。

     • 有相互依赖关系的前导任务。

     • 不是关键路径上的，但是没有任何缓冲期的任务。

     • 依赖外界因素的任务，如软件产品要和其他公司的硬件产品做集成，其接口任务是决定整个软件产品是否成功的关键。

     • 优先级高的项目任务，比如：有的工程师同时工作在几个项目上，由于没有分身术，当然要先完成优先级高的任务。根据经验表明，一个人最好集中在一个项目上，这样效率最高。但是现实往往有些偏离。遇到类似状况，要学会及时正确的处理。

     针对问题来说，以下几种常见情况属于高优先级。

     • 影响范围大的问题，如某些软、硬件环境问题，一旦出现就会阻碍开发和测试人员的正常工作。

     • 阻碍进度的问题，例如，某个模块的设计不合理，导致相关的其他模块不能完成接口的编码，阻碍了编码进度；某个缺陷的产生导致整个模块不能进行测试，阻碍了测试进度。

     • 严重影响项目质量的问题。

     • 客户发现的严重问题，有些项目在正式发布之前，会邀请客户进行Beta或者体验性测试。这样做，一方面可以避免严重问题影响项目验收；另一方面可以提高客户满意度。

     • Scrum模式下，项目负责人（Product Owner）接收完成用户故事时候发现的严重问题。这类问题如果不及时解决，可能就影响用户故事的完成，进而影响到迭代和版本发布。

  3. 协调工作优先级处理：也许当前项目团队就是由跨部门、跨区域或跨国界的人员组合而成的，也许只是单一的团队内部成员的组合，不管我们身处何方，都要处理好协作关系。一项基本原则是在同样的时间紧迫程度的条件下，他人的问题需要优先解决，因为你的协助是解决他人问题的前提，如同前导任务，有依赖关系。自己的问题自己可以随时解决，没有什么依赖条件。

• 缺陷优先级和严重性：

  • 缺陷的严重性一般被定义为5个级别。

    • A类：致命错误，如死循环，导致数据库发生死锁，严重的数值计算错误。

    • B类：严重错误，如功能不符，程序接口错误。

    • C类：一般性错误，如界面错误，打印内容、格式错误。

    • D类：较小错误，如显示格式不规范，长时间操作未给用户进度提示。

    • E类：建议性问题（非缺陷）。

  • 缺陷的优先级一般被分为4个级别。

    1. 最高优先级，立即修复，否则阻碍进一步测试。例如，软件的主要功能错误或者造成软件崩溃，数据丢失的缺陷。

    2. 较高优先级，在产品发布之前必须修复。例如，影响软件功能和性能的一般缺陷。

    3. 一般优先级，如果时间允许就修复。例如，本地化软件的某些字符没有翻译或者翻译不准确的缺陷。

    4. **低优先级，可能会修复，但是不影响正常发布。**例如，对软件的质量影响非常轻微或出现几率很低的缺陷。

• 变更控制流程：

  1. 变更提交：在提交阶段，要对变更请求进行记录。根据请求起源和收集信息类型的不同，可以分为新功能、功能增强、缺陷修正等不同类型的请求。
  2. 变更接收：项目必须建立变更请求的接收和跟踪机制，包括指定接收人和处理变更请求的负责人，确认变更请求。变更接收时，需要检查变更请求的内容是否清晰、完整、正确，并确定变更请求的类型，分配唯一的标识符，记录在案等。
  3. 变更评估：首先浏览所有新提交的变更请求，详细了解每个请求的特征， 确定变更的优先级、影响范围和所需的工作量，为下一步决策提供足够的数据信息。不同的请求类型，其评估方法和流程是有区别的，如缺陷请求评估，首先是再现当前的缺陷，然后评估缺陷的严重程度。
  4. 变更决策：根据评估结果（如工作量估计数据、资源需求、紧迫程度） 来做出决策，即决定批准请求还是拒绝请求，或者决定在当前版本还是推迟到将来某个版本上实现请求。自然，不同的请求，其决策的影响因素是不一样的，如功能增强的决策因素主要考虑竞争对手的产品功能、自己产品的竞争力、符合哪些客户的期望等， 而缺陷处理的决策会受时间的影响，在开发周期的早期，绝大部分的缺陷都应得到修正，而在后期，会经过多方正式会审来决定。
  5. 变更实施与验证：在变更请求批准后，就开始实施和验证。对新功能、功能增强等请求的实施，往往需要与其他变更结合起来一起控制，如设计的相应变更、费用的相应变更、进度的相应变更等。变更请求还涉及到相应的文档更新，即要保持文档和功能特性的同步，避免给后续项目管理带来麻烦。

• 变更控制策略：

  1. 变更预防：事后控制不如事中控制，事中控制不如事前控制。不能仅仅靠流程来控制变更，更应该防患于未然，做好事前的预防是很必要的。
  2. 变更控制委员会：作为变更管理的一个核心控制机制，变更控制委员会 (Change Control Board， CCB) 起着决策和管理的作用。
  3. 变更执行管理：在实践中很多开发团队虽然组成了CCB并有一定的处理流程， 却往往忽视了对于变更执行的管理。而变更实施的好坏依然对项目有很大的影响。对于批准的变更，要建立一个变更任务列表， 和对待其他常规任务一样管理和监控，直到完成。
  4. 变更适应——敏捷开发：软件业一直喧嚣了多年的“敏捷开发”，就是想使软件开发更适应需求变化，使开发团队能力提高，反应越敏捷就越能适应变化。现阶段一些技术和理念可以帮助项目更好地适应变化。
  5. 变更经验收集与总结：在管理和跟踪变更的同时，应该把各种变更的原因、方法和经验教训都记录下来。在项目结束后及时总结，形成变更控制更有效的方法，为今后的项目提供有价值的参考。

• 如何进行合同履行控制

  1. 制定科学完整的合同管理制度：国际最佳做法是企业事先制定完备的合同管理制度。这是做好合同履行控制的前提。软件企业应当根据自己的业务特点制定一套常用的合同范本，确定常见的法律风险种类并规定相应的合同条款加以管理，如企业在某些重大问题上的风险承受级别。
  2. 制定合理完善的合同履行控制系统：对于合同履行采用专人负责、一合同一档案、履行合同的相关审查、定期汇报、法律部门监督等方式，来加强对合同履行过程的控制，保证合同履行严格按照合同约定的方式及合同要求的流程进行。
  3. 加强合同变更的管理：我们知道，在软件开发过程中，需求变更是最常见的。而需求变更的结果往往会引起合同条款的改变。当需要改变或者添加合同条款时，应遵照企业的变更控制流程进行变更的提交、审核和批准，最后更改合同，双方签字，合同正式生效后进行相关的变更实施。
  4. 强化企业法律顾问的职责：对于法律顾问的工作范围，企业往往注重于起草、签订一份完备的合同或者打赢一场诉讼，而忽视了企业法律顾问在合同履行过程中的监督作用，这就使企业浪费了一块宝贵的法律资源。
  5. 组织企业职工的法律培训：企业合同的最终履行要靠企业员工去完成，所以对企业员工的法律知识培训是不可缺少的，特别是对项目/产品/开发测试经理们的培训尤其重要。对企业员工的培训主要注重两个方面。
     1. 加强对员工的企业内部合同履行控制系统的培训
     2. 加强对员工的法律意识及基础法律知识的培训，

项目收尾

• 项目验收前提：

  1. **完成合同要求的全部内容。**即软件开发已经完成，并全部解决了已知的软件缺陷。
  2. 完成软件系统测试，包括单元测试、集成测试、功能测试和性能测试等，并出具相关的测试报告。
  3. 各项文档、代码和报告的审查全部完成，包括软件需求说明书审查、概要设计审查、详细设计审查、所有关键模块的代码审查、所有的测试脚本代码审查、对单元、集成、系统测试计划和报告的审查。
  4. 准备好相关的开发文档和产品文档。
  5. 验收测试计划准备好，并通过评审和批准。
  6. 准备好其他验收资料，如变更记录控制文档、验收审核表等。
  7. 软件问题处理流程已经就绪。
  8. 准备好软件安装和验收测试环境。
  9. 与客户确认验收流程。
  10. 完成合同或合同附件规定的其他验收内容。

• 项目验收内容：

• 项目验收流程：

  1. 准备验收材料并提交验收申请
  2. 初审
  3. 成立验收委员会
  4. 复审（验收测试）
  5. 验收合格，项目移交

• 项目验收报告：正规的验收报告应该包括项目的基本情况审核、进度审核、变更审核、投资结算审核、验收计划、情况汇总和最后的验收结论等。

• 项目总结目的和意义：

  1. 分享经验。项目结束后，项目团队成员在一起分享一下经验和体会，不仅有助于团队建设，还有助于知识和经验的共享和积累。
  2. 避免犯相同的错误。“无法从失败中吸取教训是最大的失败”，但是软件项目的执行和管理常常犯重复性的错误。这就需要我们更加重视通过事后总结，分析错误的根源，找到可改进或者可修正的方法，防止发生重复性错误。比如阻碍项目进展的问题（Block issue），项目的缺陷（defect）分析，没有按计划完成的用户故事分析等。
  3. 提出合理性建议。针对软件项目的完成结果和存在的一些问题，提出可行性的合理化建议是非常必要的。不管哪一方面的建议，都对将来的项目管理改进有很好的帮助。
  4. 提升项目流程的改进。任何项目都不能简单套用已有的项目流程，通过实践才能发现哪些方面推进项目正常运行，哪些方面阻碍项目正常运行。如果做项目的时候，由于时间有限没办法深入思考这类问题，现在是时候静下来想想是否我们的流程有哪些方面的不足，要如何改进。
  5. 激励项目团队成员。做任何事情都应该有始有终，软件项目以人为本的思想，更决定了要重视肯定项目组成员为项目做出的成绩。嘉奖成绩优异者，不仅可以鼓励个人，也可以激励团队其他成员积极努力地工作。
  6. 最佳实践的积累。项目是流程、方法等具体实践的主要途径，通过项目的检验，良好的实践得以传递，这些最佳实践是公司宝贵的财富，有助于提高公司的生产力水平，也能为后续的项目提供可参考的实践依据。

• 项目总结会议及总结报告

  1. 项目回顾

  2. 软件度量结果分析

  3. 经验、体会分享

  4. 改进和建议方案讨论

  5. 嘉奖和庆祝

  总结报告不同于其他报告，其格式无关紧要，重要的是要真实地记录项目的历史信息和会议讨论的结果，包括下面几方面的内容。

  1. 项目整体信息回顾、度量结果分析。
  2. 做得好的方面。
  3. 做得差的方面。
  4. 改进方案和建议，包括要采取的措施和责任人。
  5. 寻求帮助信息（就是需要上级领导关注并给予支持和帮助的方面，如硬件设施需要购买，工作环境的改善等）。