本笔记的编写基于教材《敏捷软件开发项目管理与实践》——以 Azure DevOps Server 软件开发为例

1. 软件工程概述

1.1 背景

  • 是在1968年召开的一个讨论“软件危机”问题的会议上首次提出的。
  • 软件工程：研究和应用如何以系统性的、规划性的、可定量的过程化方法去开发和维护软件；如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。涵盖了软件生命周期的各个方面，从初始的构想到运行和维护。
  • 专业历史：1970年末期，美国制定研究生教育计划时采纳了IEEE/CS提出的、制定软件工程教程的建议，为软件工程教育打下了基础。
  • 软件工程关注开发和交付有用的软件实践，计算机科学关注理论和基础。

1.2 何为软件？

  • 软件是计算机程序、规程以及可能的相关文档和运行计算机系统需要的数据。
  • 软件包含计算机程序、规程、文档和软件系统运行所必需的数据四个部分。

1.3 软硬件失效

image-anwu.png

1.4 软件的四个本质特性

一致性、复杂性、不可见性和可变性。

1.4.1 一致性

  1. 软件不能独立存在，要依附于一定的环境（如硬件、网络、以及其他软件） 。
  2. 软件必须遵循从人为的惯例并适应已有的技术和系统。
  3. 软件需要随从接口不同而变化，随着时间推移而变化，而这些变化是不同人设计的结果。

1.4.2 复杂性

  1. 对于软件复杂的需求导致了软件的复杂性。

1.4.3 可变性

  1. 软件的变化（随时间推移）对其失效率的影响， 软件的可变性体现在软件本身的升级，功能的变化等。

1.4.4 不可见性

  1. 软件是一种“看不见、摸不着”的逻辑实体、不具有空间的形体特征 。
  2. 开发人员可以直接看到程序源代码，但是源代码本身并不是软件本身 。
  3. 软件是以机器代码的形式运行，但是开发人员无法看到源代码是如何运行的。

1.5 软件的三个特征

只能开发、无磨损、不能组装。

1.5.1 只能开发

软件是开发产生的，而不是传统方法制造出来的。

1.5.2 无磨损

软件不会像硬件一样有磨损；软件只会过时，不会磨损。

1.5.3 不能组装

很多软件不能通过已有构件组装，只能自己自定义开发。

1.6 软件质量体系之CMMI

  • “CMM，全称为Capability Maturity Model for Software，缩写为SW_CMM，即“软件能力成熟度模型”，是对组织软件过程的描述，核心内容是将软件开发视为一个过程，并且根据相应的原则对于软件开发进行相应的监控和研究。是一个将软件不断从混乱走向成熟的规范化过程的一个框架。CMM自从1987年开始实施以来，已经成为软件业权威的评估认证体系。
  • CMMI认证简称软件能力成熟度集成模型，是鉴定企业在开发流程化和质量管理上的国际通行标准，是一套包括多个学科、可扩充的模型系列，其前身主要包括4个成熟度模型：
    • 面向软件开发的SW-CMM
    • 面向系统工程的SE-CMM
    • 面向产品集成的IPD-CMM
    • 涉及外购协作的SS-CMM

1.6.1 分级

  1. 不完整（第0级）：无计划则未知，可能完成或无法完成工作。
  2. 初步（第1级）：不可预测且被动，可能完成工作但通常会延期且超预算。
  3. 管理（第2级）：实施项目管理，项目得到规划、执行、度量和控制。
  4. 定义（第3级）：主动而不是被动。组织标准为项目计划和投资组合提供了指导。
  5. 量化管理（第4级）：可衡量且可控制，组织以数据为导向，提出量化的性能改进目标，这些目标是可预测且一致的，可以满足内部利益相关者的需求。
  6. 优化（第5级）：稳定且灵活，组织专注于持续改进。并致力于转变和应对于机遇和变化。组织的稳定性为敏捷与创新提供了一个平台。
## 能力实践组等级演进表 ##
PGL 特征 基本要求
五级 持续优化级(Optimizing) - 在四级基础之上（即包含所有四级实践）- 应用统计方法或其他量化技术来识别影响过程输出结果的一般原因， 优化、提升过程性能以更好地支持组织业务目标的达成
四级 定量管理级(QuantitivelyManaged) - 在三级基础之上（即包含所有三级实践）- 应用统计方法或其他量化技术识别并消除引发过程性能波动的特殊原因， 提升过程稳定性和对过程输出结果的预测能力
三级 已定义级(Defined) - 在二级基础之上（即包含所有二级实践）- 有横跨多个项目或部门的标准流程定义和相应的裁剪规范- 项目或团队持续使用和贡献组织过程资产
二级 已管理级(Managed) - 有满足能力全部意图和价值的实践集，支持能力相关过程定义所需- 定义的过程具有明显的可重复特征- 识别项目或团队的各类目标，管控针对目标的进度以及偏差
一级 初始级(Initial) - 有满足能力意图和价值的初步方法- 尚没有完整的、系统的实践集以充分支持能力所包含的意图和价值

1.7 软件工程惯用模型

1.7.1瀑布模型（Waterfall Model）*

又被称为经典生命周期（classic life cycle），它提出了一个系统的、顺序的软件开发方法。

  • 技术特点：简单、分阶段，阶段间存在因果关系，各个阶段完成后都有评审，允许反馈，用户参与度较低，要求预先确定需求。
  • 适用范围：愿景/战略和技术上都没有不确定性，项目 需求明确，能够实现完全一致性和确定性的产品或项目。
  • 优点：
    1. 归因于具有清晰的最后期限的严格的模型，易于管理。
    2. 简单，容易理解和使用。
    3. 每个阶段只跑一次，没有重复，允许在每个阶段的结束时进行彻底的QA
    4. 对于需求固定的小项目，效果很好。
  • 缺点：
    1. 一旦进入测试再去变更产品，是很困难的，代价昂贵。
    2. 风险等级较高（在计划阶段进行风险管理）。
    3. 对于需求会变更的项目，不太好。
    4. 直到软件生命周期后期阶段才有完整的产品。
    5. 不适合于复杂、用户需求不确定的项目。

IMG_20240920_145327.jpg

1.7.2 敏捷模型（Agile Development）***

敏捷模型是一种轻量、高效、低风险、更强调团队协作和沟通的开发方式，适合于中小型开发团队，客户需求模糊或多变。

  • 优缺点

    • 优点：敏捷开发的高适应性，以人为本的特性，和轻量型的开发方法即以测试驱动取代了以文档驱动。
    • 缺点：与传统开发方式相比，敏捷开发的最主要的劣势在于敏捷开发欢迎新的需求，而在每次新的需求产生时都可能引起整个系统的大幅度的修改。

ff566cb96d50ee190e998bac6996a8b8.jpeg

Scrum敏捷模型将在第二章中进行详解。

以下的惯用模型只是扩展了解一下：

1.7.3 增量模型（Incremental Model）

增量模型结合了瀑布模型和敏捷开发的优点，允许在项目早期交付软件的基本功能，然后通过一系列增量迭代逐步添加和完善功能。这种模型降低了整体风险，因为可以在早期就发现和解决主要问题，同时也便于适应需求的变化。

1.7.4 螺旋模型（Spiral Model）

螺旋模型是一种风险驱动的方法，特别适用于大型、复杂的项目。它将瀑布模型的线性阶段和原型开发的迭代特征相结合，通过四个主要阶段循环进行：制定计划、风险分析、工程实施和客户评估。螺旋模型在每个迭代周期中都包含风险评估和应对策略，有助于降低项目失败的可能性。

1.7.5 原型法（Prototype Method）

原型法强调通过构建软件的初步版本（即原型）来快速收集用户反馈，然后根据反馈迭代改进软件。这种方法可以加速需求的澄清过程，确保最终产品更贴合用户的真实需求。原型可以是低保真度的草图，也可以是高度交互的预览版本。

2. Scrum 敏捷方法

2.1 敏捷宣言

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。
由此，我们建立了如下的价值观：

  • 个体和互动 高于 流程和工具
  • 工作的软件 高于 详尽的文档
  • 客户合作 高于 合同谈判
  • 响应变化 高于 遵循计划

也就是说，尽管右项有其价值，我们更重视左项的价值。

2.2 核心理念

以最简单有效的方式快速地达成目标，并在这个过程中及时地响应外界的变化，做出迅速的调整。

2.3 敏捷12条原则

  1. 客户为先：通过持续不断地及早交付有价值的软件使客户满意。
  2. 拥抱变化：欣然面对需求变化(即使在开发后期也一样)，为了客户的竞争优势，敏捷开发过程中要掌控变化。
  3. 短迭代交付：经常地交付可工作的软件(相隔几星期或一两个月，倾向于采取较短的周期)。
  4. 业务参与：业务人员和开发人员必须相互合作，项目中的每一天都不例外。
  5. 以人为本: 激发个体的斗志，以其为核心搭建项目，提供所需的环境和支持，辅以信任，从而达成目标;
  6. 激励个体贡献：以受激励的个体为核心构建项目。为他们提供所需的环境和支持，相信他们可以把工作做好。
  7. 成果导向：可工作的软件是衡量进度的首要标准。
  8. 保持节奏：敏捷过程倡导可持续开发。
  9. 追求卓越：坚持不懈的追求技术卓越和良好的设计，以此增强敏捷的能力。
  10. 简单务实：简单是尽最大可能减少不必要工作的艺术，是敏捷的根本。
  11. 团队自组织：最好的架构、需求和设计来自自组织的团队。
  12. 持续改进：团队定期反思如何提升效率，并依此调整自己的行为。

2.4 Scrum(争球)——开发实践

Scrum是一种流行的敏捷开发框架，它通过短周期的迭代开发来逐步实现项目目标。Scrum定义了三种角色：产品负责人、Scrum Master和开发团队，以及一系列会议和工件，以确保项目的顺利进行。

2.4.1 标准框架

IMG_20240927_144701.jpg

  • 每日站会（Daily Stand-up）：在敏捷开发中，团队成员每天都会进行一次简短的会议，通常称为“站会”，以更新彼此的工作进度、计划和遇到的障碍。
  • 评审会议（Review Meeting）：在每个迭代（Sprint）结束时，团队会举行评审会议，展示在该迭代中完成的产品增量，收集反馈，并与利益相关者共享进展。
  • 冲刺（Sprint）：在敏捷开发中，Sprint是一个时间固定、通常为一到四周的时间周期，在这个周期内，团队致力于完成一个预定的产品增量。
  • 冲刺挤压项（Sprint Backlog）：Sprint Backlog是Sprint开始时由团队从Product Backlog中选择的任务列表，团队承诺在Sprint结束时完成这些任务。
  • 产品挤压项（Product Backlog）：Product Backlog是产品待办事项列表，包含了所有需要完成的功能、改进、修复等，通常按照优先级排序。
  • 回顾会议（Retrospective Meeting）：在每个Sprint结束时，团队会进行回顾会议，讨论在Sprint期间哪些做得好，哪些需要改进，以便在未来的Sprint中做得更好。
  • 计划会议（Planning Meeting）：在每个Sprint开始之前，团队会举行计划会议，确定Sprint的目标、选择Product Backlog中的任务，并制定完成它们的计划。
  • 潜在的可交付（Potentially Shippable Increment, PSI）：在敏捷开发中，每个Sprint结束时，团队应该有一个潜在的可交付产品增量，这意味着产品增量已经完成到可以发布给用户的程度，尽管团队可以选择不立即发布。
  • 产品增量（Product Increment）：产品增量是指在Sprint结束时，团队完成并集成到产品中的新功能或改进，它是产品的一部分，并且是可用的。

2.4.2 基本特点

  • 开发中每个冲刺（sprint，即交付周期）长度一般为 2～4周，成员为8人左右，建议为2±7人。
  • 一旦冲刺计划会议结束，任何需求都不允许添加进来，并由专人（通常是scrummaster）严格把关，不允许开发团队受到干扰。
  • 用户故事（userstory）可以不严格按照优先级别来实现，要考虑实现的业务价值。
  • 软件开发的实施过程没有固定的实践模式，要求开发者在"三支柱"的支撑下通过”自觉保证"来开展工作。
  • 常见文档：产品订单、冲刺订单、燃尽图、冲刺计划等

2.4.3 三大支柱

透明、检查、调整。

2.4.4 三个角色

产品负责人（Product Owner）

  • 角色特性：
    • Product Owner 由单人承担。
    • 是产品的最终负责人。
    • 精通业务，代表客户或者产品的最终用户。
    • 果断，有决定权。
    • 总有时间回答需求方面的问题，支持团队完成Sprint目标。
  • 角色职责：
    • 建立产品的愿景，并确保团队理解。
    • 负责项目的融资和产品的投资回报率(ROI)。
    • 负责管理 Product Backlog。
    • 和开发团队协作，支持团队完成Sprint目标。
    • 对开发团队的工作结果提供反馈，接受或者拒绝工作结果。决定产品发布日期及内容。

敏捷教练（Scrum Master）

  • 角色特性：

    • 不是团队的经理，不能命令团队如何工作。
    • 服务型领导，服务于产品负责人和开发团队。
    • 具有影响力，通过影响力来引导团队创造更大价值的产品。
    • Scrum团队的“敏捷教练”，促使团队按照Scrum敏捷开发方式运行，为Scrum过程负责。

  • 服务于产品负责人：

    • 保Scrum团队中的每个人都尽可能地理解目标、范围和产品域。
    • 指导产品负责人有效管理产品积压工作项。
    • 指导产品负责人懂得如何安排产品积压工作项来最大化价值。
    • 理解并实践敏捷，引导Scrum敏捷开发事件。
    • 帮助Scrum团队理解为何需要清晰且简明的产品积压工作项。

  • 服务于开发团队：

    • 作为教练在自组织和跨职能方面给予开发团队以指导。
    • 指导开发团队创造高价值的产品。
    • 移除开发团队工作进展中的障碍。
    • 引导Scrum敏捷开发事件。
    • 在Scrum还未完全采纳和理解的组织环境中，作为教练指导开发团队。

  • 服务于组织：

    • 带领并作为教练指导组织采纳Scrum敏捷开发。
    • 在组织范围内规划Scrum敏捷开发的实施。
    • 帮助员工和利益相关者理解并实施Scrum和经验导向的产品开发。
    • 引发能够提升Scrum团队生产率的改变。
    • 与其他Scrum Master一起工作，增强组织中Scrum应用的有效性。

所以敏捷教练的主要职责为：

  • 保证团队资源合理利用。
  • 保证各个角色及职责良好协作。
  • 解决团队开发中的障碍。
  • 作为团队和团队外部的接口，协调解决沟通中的问题。
  • 保证开发过程按计划进行，确保冲刺计划会议，每日站会，冲刺评审，冲刺回顾等活动顺利且正确的得到执行。

开发团队（Developers）

  • 开发团队的责任：负责在每个冲刺结束时交付潜在可发布的产品增量。
  • 开发团队的特性：
    • 小型团队：最佳团队规模: 6±3 或者7+2。Scrum的精髓在于小团队。个体团队具有高度灵活性与适应性。
    • 自组织：团队管理自身事务:没有“经理”的角色；没有人可以命令团队如何把PBI实现成可发布的功能。
    • 平等：Scrum敏捷开发不认可开发团队成员的头衔，无论承担哪种工作他们都叫做开发人员，此规则无一例外。
    • 跨职能：开发团队中的每个成员可以有特长和专注领域，但是责任属于整个开发团队。
    • 原子性：Scrum敏捷开发不认可“子团队”，强调团队功能整体性，不依赖于外部团队拥有完成项目所需全部技能。

IMG_20241011_150108-mmva.jpg

三大角色共享的不好影响：

  • 三个角色各有分工。
  • 角色共享会导致混乱。
  • 不利于“专注”。

规模化敏捷团队配置“扇出”模型：

IMG_20241011_150120.jpg

2.4.5 三个工件

  1. 产品积压工作项（Product Backlog）
  2. 冲刺积压工作项 （Sprint Backlog）
  3. 产品增量（Increment）

2.4.6 五个事件

  1. Sprint（Sprint本身是一个事件，包括了如下4个事件）
  2. Sprint计划会（Sprint Planning）**
  3. 每日站会（Daily Scrum）**
  4. Sprint评审会（Sprint Review）**
  5. Sprint回顾会（Sprint Retrospective）**

2.4.7 五个价值观

  1. 承诺 ：愿意对目标做出承诺
  2. 专注 ：把你的心思和能力都用到你承诺的工作上去
  3. 开放 ： Scrum 把项目中的一切开放给每个人看
  4. 尊重 ：每个人都有他独特的背景和经验
  5. 勇气 – 有勇气做出承诺，履行承诺，接受别人的尊重
  • 实例：

f29b64c42058f8a3ac9c669f773dc9da.jpeg

  • 一个敏捷开发方法 —— 极限编程（XP）

极限编程是一种轻量级的敏捷开发方法，它强调通过简化流程、提高团队协作和持续改进来提高软件质量。XP倡导一系列实践，如结对编程、测试驱动开发、重构等，以帮助团队更好地应对变化。

R-C-kxmf.jpg

2.5敏捷团队的特点

  • 灵活适应性：敏捷团队的首要特点就是灵活适应性。这种团队能够迅速响应变化，并能够灵活地适应新的要求和挑战。与传统团队相比，敏捷团队更注重根据需求变化来调整工作计划和优先级。
  • 自组织和自治性：敏捷团队以自组织和自治为基础。在敏捷团队中，团队成员具有自主决策的权力，能够根据项目的需求和目标，自行安排工作和分配任务。
  • 迭代和增量式开发：敏捷团队通常采用迭代和增量式开发的方法。这意味着在开发过程中，敏捷团队会将大型项目分解为小的可管理的任务，通过一次次的迭代，逐步交付产品的不同版本。
  • 客户参与和持续反馈：敏捷团队非常重视客户的参与和持续反馈。在敏捷开发中，客户通常被视为团队的一部分，其意见和反馈对项目的成功至关重要。敏捷团队通过与客户进行频繁的沟通和合作，不断获取客户的需求和期望，并及时进行调整和优化。

2.6 DevOps

  • DevOps 是一种文化理念、工具与实践的结合，目的是更快更可靠地向用户持续交付价值。
  • 目前这个理念和实践在行业内得到大量的应用和落地，陆续出现了持续集成、持续交付、持续部署以及持续发布。

3. 软件项目启动及项目计划管理

3.1 软件项目管理中的实践域概览

3.1.1 估算

  • 目的：估算开发、采购或交付解决方案所需的工作和资源的规模、工作量周期和成本；为做出承诺、策划和减少不确定性提供依据，有助于尽早采取纠正措施并提高实现目标的可能性。
  • 敏捷团队是在产品积压工作项列表细化梳理和冲刺计划期间进行估算的，通常是粗略的数量级估算。
  • 在实践应用中，通常使用相对大小来估算规模，使用故事点或某个度量单位作为规模大小的衡量单位。
  • 在规模估算的基础上，完成任务和工作量估算；对于估算中讨论和确认的假设，要在冲刺回顾时进行审查，以改进估算。

3.1.2 策划和计划

  • 目的：制定计划来描述在组织标准和约束条件内完成工作所需的内容，包括：预算、进度、资源需求、能力和可用性，质量，功能需求，风险和机会；要执行的工作，适用的组织级标准过程集、资产和裁剪指南，依赖关系，由谁执行工作，与其他计划的关系，利益相关者及其角色等，从而增加实现项目目标的可能性。
  • 在使用Scrum的敏捷开发中，通常由以下5点来支撑策划实践域：
    • 产品订单，整个已知故事集的已划分优化级的用户故事或长篇故事；
    • 冲刺订单，冲刺中选择的用户故事或长篇故事，由敏捷团队进行估算并进一步细分为任务；
    • 故事责任，团队成员自行认领用户故事，并承诺在冲刺期间完成，
    • 进度，每个冲刺都有一个固定的持续时间，冲刺的集合定义了预期的总发布进度;
    • 预算，坚持一个固定的团队、固定的时间盒模型，在进行总体检查时，有助于识别项目预算的关键因
      素。

3.1.3 监视与控制

  • 目的：提供对项目进度的掌握，以便在绩效显著偏离计划时采取适当的纠正措施；通过及时采取行动调整显著的绩效偏差，提高达到目标的可能性。
  • 在敏捷开发的软件项目管理中，需要关注如下内容：
    • 任务看板显示正在执行的工作状态，特别是分配给冲刺的任务和积压工作列表项的状态。
    • 发布燃尽图显示每个冲刺中剩余的故事点数，并且表明发布的所有工作通常由几个冲刺组成。
    • 每天更新冲刺燃尽图，指示完成冲刺工作所需的时间。
    • 墙上或数字屏幕上的视觉展示信息，指示团队绩效、文化和任务的当前状态。
    • 通过发布计划、产品积压工作项梳理、冲刺计划、冲刺执行（每日站会）、冲刺评审/演示、冲刺回顾等来完成项目的监督与控制。

3.2 项目立项

3.2.1 立项要点

  • 从管理的角度来看，项目立项属于决策的范畴，在公司运作过程中，不只有产品研发的立项，也有业务的立项；
  • 大多数企业都有自己的项目立项流程，以降低项目投入的风险，避免研发项目的随意性；
  • 通过项目立项，加强项目的目标、成本和进度考核，提高项目成功比例；杜绝不实际的研发项目展开，避免公司资源浪费。

3.2.2 目的

对于研发

  • 降低项目投入的风险，避免研发项目的随意性；
  • 加强项目的目标、成本和进度考核，提高项目成功比例；
  • 杜绝不实际的研发项目展开，避免公司资源浪费。

对于业务

  • 不放过可以赢利并且能做或可以做的项目，拒绝亏本并且不值得亏本或者暂时做不了或不值得做的项目；
  • 比较清楚地了解用户需求和客户信用状况，减少合同签订后的变更；
  • 确定一个比较合理的报价。

3.2.3 内容

  • 项目背景：非定制开发类项目或公司运营类项目，必须编写市场分析、竞品分析、投资收益分析（即经济可行性），这三类分析可以通过单独的文件完成 。
  • 项目范围及目标
  • 项目验收标准
  • 项目资源及费用预算
  • 项目进度控制
  • 项目风险控制
  • 市场推广及工程实施相关建议或措施

3.2.4 参照重点

在《立项报告》、《立项可行性分析报告》、BRD（商业需求文档）
等文档中对项目进行陈述。尽可能全面的考虑方方面面的因素，权衡得失。通常至少包括：

  • 产品在市场上的竞争情况如何，前景如何，是否值得研发？
  • 产品研发到底有多大把握？
  • 项目是否可行，技术积累如何，现有人力能否调配过来？
  • 项目要完成哪些需求？需求是否明确，是否合理？
  • 工作由谁负责，哪些人去做？如何做？

3.2.5 注意点

  1. 应估算整个生命周期每个阶段、各项活动、各类相关人员必须为该项目投入的工作量和成本，而不是只关注开发阶段的工作量及成本。
  2. 工作量和成本估计如果涉及多个部门，应由相关部门分别估计，然后再汇总。
  3. 既要计算直接成本和工作量，也要考虑间接成本和工作量，特别是要考虑边界成本、机会成本等以便为企业决策提供全部的支持。
  4. 为项目开发需要而购买软硬件设备，或者项目交付后项目成果可以进一步作为企业的新产品或新版本，或者已经有了初步成果而通过新项目可以节省产品开发所需的投入等。
  5. 工作量到成本的折算，可以用整个部门上一个年度的人均开支，也可以用上一个季度的人均开支或各类人员的人均开支。
  6. 业务费、项目奖金及其他必须的特殊开支，应计入成本。
  7. 应考虑风险储备，以及项目相关各方沟通协调所需的工作量和成本。
  8. 要为必然会有的需求变更而引起的工作量增加留出余地。

3.3 项目评审

3.3.1 评审活动

  • 在软件工程7项基本原理里提到“坚持阶段评审”，通过评审可以避免把缺陷带入到后续的环节。
  • CMMI的多个过程域中也强调了“评审”实践。
  • 在PMBOK中，“营造协作的项目团队环境“原则、交付绩效域、情境领导力模型等多处 强调了“评审”的作用及重要性。
  • 在敏捷开发实践中更是通过频繁的评审(Review)来检视已完成工作产品、开发的进度，发现偏差并采取纠正措施。

为什么开展

  • 技术层面：

    • 通过评审提高项目的生产率，改善软件的质量；
    • 评审可早期发现错误，减少了返工时间，还可能减少测试时间。

  • 从管理层面：

    • 通过评审可以发现项目组织管理过程中的问题，以便针对这些问题采取纠正措施;
    • 发现管理中的改进点，提高整个项目组的管理水平。

3.3.2 类型

3.3.2.1 从目的角度

管理评审
  • 为了使整个团队或组织能更好的进步和发展，通常需要对原来的状况进行回顾，分析并总结出存在的问题和改进的措施。
  • 目的：评价管理体系的适宜性、充分性和有效性;总结组织管理的整体效果，并从当前取得的业绩基础
    上找出与预期目标的差距，同时还应考虑任何可能改进的机会。
    • Scrum敏捷开发中，可以把冲刺回顾会议划到管理评审中，在项目管理中开展的
      立项评审、里程碑评审、结项评审等也都可以划分到管理评审类别。
技术评审（同行评审）
  • 需求评审：对梳理的积压工作项或编写的用户需求说明书、需求规格说明书等进行评审。
  • 设计评审：对系统的技术框架、数据库设计、功能设计及用户界面设计等的评审。
  • 代码评审：对代码进行走查、使用工具静态检查、核心代码进行评审等。
  • 质量验证评审：对测试方案、测试用例等进行评审。
过程评审
  • 通常是由组织的品质管理部门发起，开发过程评审的作用如下：
    • 评估管理流程的质量;
    • 考虑如何处理和解决评审过程中发现的不符合问题，
    • 总结和共享好的经验;
    • 找出需要进一步完善和改进的部分。

3.3.2.2 从严格程度角度

正式评审
  • 通常适用于重大的决策，特别是与项目团队外部需要达到共识或一致的事项;要召开正式的评审会议，形成正式的会议记录，并对会议记录中事项落实进行跟踪反馈，比如立项、项目验收、项目里程碑等的评审。
非正式评审
  • 通常适用于团队内就一些重要事项达到一致的评审。只需召开项目团队内部日常会议来评审即可，但也需要对会议上确定的事项记录并跟踪反馈完成结果。
审核
  • 通常适用于不太重要的事项，由项目团队内相关人员通过讨论来达成共识，并确定后续的工作内容或措施。

3.3.3 评审材料的选择

  • 在项目中，不大可能对所有的产品和文档都进行评审，需要选择必须评审的内容。
  • 遵循的原则：选择那些最复杂和最容易出问题的部分进行评审，比如
    • 基础性和早期的文档，如用户需求说明和用户原型等:
    • 与重大决策有关的文档，如技术体系架构、业务架构模型等;
    • 对如何做没有把握的部分，如一些挑战性模块，它们实现了不熟悉的或复杂的算法，或涉及复杂的商业规则和开发人员不了解的其他领域；
    • 将不断被重复使用的部件。

3.4 项目策划

3.4.1 内容

  1. 梳理并分解项目需求，标识项目工作产品和活动，编制工作分解结构(WBS)。
  2. 估算工作产品的规模、活动的工作量、花费的成本和所需的资源。
  3. 确定项目的组织结构，人员分工及沟通协调机制。
  4. 划分项目阶段并制订工作进度安排。
  5. 识别并制定项目资料管理计划。
  6. 识别和分析项目风险，编制风险管理计划。
  7. 与利益相关者协商相关约定，比如约定需求变更的处理流程、上线或产品发布的相互协作内容等。
  8. 编写项目开发计划，并与利益相关者就项目计划达成一致，以此作为项目跟踪监督的依据。

3.4.2 通用流程

  1. 定义需求，确定待开发事务要求，客户的需要。
  2. 针对已经理解的需求，给出一个概要设计或者初步解决方案、解决问题的思路。
  3. 如果有可参照的历史数据，在对照历史数据的情况下完成项目规模的估算；如果没有可对照的历史数据，则用工程估算法进行项目规模估算。
  4. 采用和 3类似的方法进行工作量估算。
  5. 根据可用资源(含人员)确定项目进度安排。
  6. 根据确定的项目进度安排完成项目开发，在此过程中收集规模和工作量数据，分析过程进展，形成项目跟踪报告；并且在结项(或阶段回顾)时总结相关过程数据，形成团队的历史数据。

3.4.3 Scrum敏捷开发管理模式下的项目策划

  1. 每个阶段性发布开始前需要根据项目的进展情况编制针对该阶段的发布计划(规模化敏捷框架里称之为PI计划)，然后再根据每个迭代(冲刺)形成冲刺计划。
  2. 在实际研发过程中，不可能一次性把项目的估算及详细计划、详细进度安排确定下来。特别是在每个发布或冲刺的积压项还没有梳理完成之前，在对需求还没有明确的情况下，更不可能把详细计划及任务安排确定下来。
  3. 工作开展时，又不能在没有计划或工作安排的情况下进行后续的细化工作，所以在使用Scrum开发管理模式时，为了保证具有一定规模的项目顺利开展，通常会制定多类计划，分别来达成不同的目标。

3.4.3 敏捷中常见的五种计划

IMG_20241011_143112.jpg

3.4.4 敏捷开发中常见计划

  • 总体计划，根据长篇故事及干系人一起确定的计划，明确包含哪些长篇故事及其描述；有些类似于立项报告。
  • 项目计划，确定项目的生命周期即开发模式，明确里程碑，明确项目每个阶段的大体进展安排；该计划需要干系人评审通过，并可以定期更新。
  • 发布计划(PI计划)，是特性级别的计划，它将特性分配给选代(因此，一个发布计划包含每个计划迭代的粗略范围)，并确保团队在承诺的发布日期交付。
  • 冲刺计划，关注当前冲刺的安排及要完成的内容。

4. 软件需求及开发积压工作管理

4.1敏捷开发的需求

4.1.1 常见需求来源

  • 客户提供的意见、要求，用户招标文件；
  • 利益相关者提供的意见、要求；
  • 以前的工作或岗位工作标准；
  • 现有的解决方案，当前系统发现的问题或对当前系统的增强报告；
  • 业务所在领域的参考文献；
  • 与业务领域相关的法律和法规、标准；
  • 客户的业务政策，比如:销售政策、商务政策、市场推广政策；
  • 以前的技术或业务架构设计及原则；
  • 业务环境需求(如实验、测试和其他设施、信息技术基础设施)；
  • 针对竞争性产品的分析；
  • 用户任务的内容分析，开发具体的情节或活动顺序，确定用户利用系统需要完成的任务，由此可以获得用户用干外理任冬的必必要功能需求。

4.1.2 需求包含的内容

  • 技术需求——需要提供技术解决方案类的需求

    • 在需求调研阶段收集及需求分析阶段确定的功能需求
    • 在设计期间开发的外部接口或连接需求、内部接口或连接需求
    • 在需求调研阶段及需求分析阶段确定的质量、操作、性能需求
    • 在需求分析阶段开发的验证、确认、验收准则
    • 在需求调研阶段及需求分析阶段确定安全性需求

  • 非技术性需求——需要从商务角度考虑的需求

    • 价格和成本
    • 交付的约束条件
    • 资源的约束条件
    • 培训、客户互动(例如状态报告、会议)
  • 为了避免需求范围蠕变，制定准则以指定适当的渠道来接收需求变更。

4.1.3 基于用例的需求获取及分析方法

对功能性需求进行分析时可按如下步骤获取需求的细节：

  1. 定义项目的视图和范围，可以采用“长篇故事-特性-需求/用户故事/产品积压工作项”三级分解的方式加以明确。
    • 第一级：长篇故事 1
    • 第二级：特性 1.1
    • 第三级：产品挤压工作项 1.1.1
    • 第四级：任务 1.1.1.1
  2. 确定使用功能的用户类/岗位。
  3. 在每个用户类/岗位中确定适当的代表。
  4. 确定需求决策者及其决策过程。
  5. 选择所用的需求获取技术。
  6. 运用需求获取技术对作为系统一部分的应用场景(即用例)进行开发并设置优先级。
  7. 从用户那里收集质量属性、操作要求和其他非功能性需求。
  8. 编写详细的用例描述使其融合到必要的功能需求中。
  9. 评审用例的描述和功能需求。
  10. 如果有必要，开发分析模型(被研究对象的一种抽象，形成对客观事物或现象的一种描述) 用以澄清需求获取的参与者对需求的理解。
  11. 开发并评估用户界面原型以帮助想象还未理解的需求。
  12. 站在用户的角度，开发概念测试用例/验收条件/测试要点。
  13. 用测试用例/验收条件/测试要点来论证用例、功能需求、分析模型和原型。
  14. 在继续进行设计和构造系统每一部分之前，重复以上步骤，完成对需求的获取及分析。

长篇故事

  • 长篇故事分两类，业务长篇故事直接提供业务价值，而使能(Enabler)长篇故事用于推进架构跑道，以支持即将到来的业务或技术需求。
  • 长篇故事是一些最重要的企业投资，利益相关者需要就其意图和定义达成一致。
  • 在致力于实施之前，长篇故事需要分析；对长篇故事的分析包括长篇故事的最低可行产品(MVP)的定义；MVP 是新产品或业务解决方案的早期和最小版本，用于证明或反驳长篇故事的假设。

特性

  • 特性通常是代表软件的一个可交付的组件(模块)，而长篇故事通常代表要完成的业务计划或方案。
  • 特性代表可以给客户带来价值的产品功能或特性，通常有如下特点：
    • 特性向上承接长篇故事，向下分解为产品积压工作项。
    • 相比长篇故事，特性更具体形象，客户可以直接感知，通常在产品发布时作为发布说明的一部分发布给客户。
    • 特性通常持续数个星期，需要多个冲刺完成交付。
  • 特性应该对客户都有实际的价值，特性的描述通常需要说明对用户的价值，比如:使用手机的患者希望通过网上预约挂号，以便在预约的时间去就诊。
  • 说明：有些大型解决方案，会在长篇故事与特性之间增加一个“能力”的划分，以更好的管理积压的需求。

4.2 用户故事Invest原则

  • Independent(独立的):每个产品积压工作项应该是独立的，可独立交付给客户，要尽量避免产品积压工作项之间的相互依赖。
  • Neqotiable(可讨论的):不必非常明确的阐述功能，指细节应带到开发阶段与程序员、客户来共同商议。
  • Valuable(有价值的):应该很清晰地体现对用户或客户的价值，最好的做法是让客户编写故事。
  • Estimable(可估计的):能估计出工作量/规模。
  • Small(小的):要小一点(可以在一个迭代中完成)，建议落在1~3人天的工作量区间里，最好能一天就可以完成。
  • Testable(可测试的)：成功通过测试可证明开发人员正确地实现了产品积压工作项。

4.3 需求的两份文档

  • 用户需求说明书（对外）
  • 需求规格说明书（对内）

4.4 积压项梳理示例——某公司

需求收集整理 -> 需求拆分分析 -> 需求估算确认 -> 需求优先级排序

需求精准度直接影响产品质量!

4.4.1 关键活动

  1. 需求策划、分析
  2. 需求讨论，确认达成一致
  3. 需求拆分、规模估算
  4. 需求优先级排序
  5. 需求验收准则、完成的定义确认(DoR)

4.4.2 思考

  1. 如何提高或保证需求梳理的质量与效率?

    • 采用结构化的需求收集方法，如用户故事、用例等。
    • 使用需求管理工具来跟踪和组织需求。
    • 定期进行需求评审会议，确保所有相关方对需求有共同的理解。
    • 实施需求变更控制流程，以管理需求的变更。
    • 进行需求优先级排序，确保最重要的需求首先得到满足。

  2. 需求的完成定义及验收准则的作用?

    • 完成定义（DoD）和验收准则（DoR）为团队提供了明确的标准，以确定何时需求被认为是完成的。
    • 它们帮助团队成员对需求的完成有共同的理解，减少误解和返工。
    • 验收准则确保产品符合客户和用户的期望。

  3. 敏捷开发遇到需求发生变更时如何处理?

    • 敏捷开发鼓励变更，因为它们通常带来更好的产品。
    • 变更应该通过变更控制流程进行管理，评估其对项目的影响。
    • 团队应该重新评估优先级，并将变更纳入未来的迭代计划中。

  4. 此阶段的参与人员有哪些？分别有哪些活动？

    • 产品负责人：负责收集和分析需求，定义产品愿景和优先级。
    • Scrum Master：协调活动，确保Scrum流程的正确实施，帮助团队解决阻碍进度的问题。
    • 开发团队：参与需求讨论，提供技术反馈，负责交付产品。
    • 客户或用户代表：提供需求输入和确认，参与验收产品。

  5. 积压项怎么拆分对价值流动性的影响?

    • 将积压项拆分成小的、可管理的部分可以提高价值流动性，因为这样可以更快地交付价值。
    • 小的、频繁的交付允许更快的反馈循环，有助于及时调整方向。
    • 拆分积压项还可以减少风险，因为每个小部分都更容易管理和测试。

4.5 看板流动性

  • 看板团队使用客观的度量，包括平均交付周期、在制品和吞吐量来了解其流程并改进流动性。
    通常使用累积流图(CFD)来表达，如下图所示：

    image.png

  • 这个图是强调产品积压工作项的数量随时间而变化的程度，它可以用来跟踪和预测项目的进展情况。

5. 项目冲刺及跟踪管理

5.1 敏捷开发的冲刺

5.1.1 特点

  1. 冲刺是Scrum的核心，持续时间不能超过一个月。
  2. 每个冲刺可以被视为一个小项目；目标是完成可发布的产品增量。
  3. 一旦冲刺开始， 它的时长是固定的，不能延长或缩短，不能做出有害于冲刺目标的改变，且不能降低质量目标。
  4. 冲刺是其它事件的容器，包括冲刺计划会议、开发工作每日站会、冲刺回顾和冲刺评审。
  5. 冲刺的需求范围是固定的；冲刺开始后，不能添加或更改冲刺订单。
  6. 产品负责人与开发团队之间对在冲刺范国内要做的事可以进行澄清和重新协商，只有产品负责人有权取消冲刺。

5.1.2 冲刺的PDCA循环理念

  • 最短可持续交付周期是精益敏捷开发的一个重要目标，敏捷团队会尽快执行完整的 PDCA 循环，PDCA 学习环中的步骤对应于以下冲刺事件：

    • 计划(Plan)--冲刺计划;

    • 执行(Do)--冲刺执行

      • 包含每日站会的小循环；

    • 检查(Check)--冲刺评审；

    • 调整(Adjust)--冲刺回顾；

5.1.3 敏捷实践建议--预冲刺

在项目的初始时期，正式冲刺之前要做的一些事情，主要有：

  • 确定技术解决方案或搭建开发的方案；
  • 准备开发用的机器设备，开发环境；
  • 建立构建和部署管道，即持续集成和持续交付的管道；
  • 准备好测试环境和部署环境，并与构建和部署管道配置在一起。

5.2 软件估算

  • 软件估算是指根据软件的开发内容、开发工具、开发人员等因素对需求调研、程序设计、编码、测试等整个开发过程所花费的时间及工作量做的预测 。
  • 保证估算准确的考虑点
    • 基于已完成 的类似的项目进行估算；
    • 使用简单的“分解技术 ”来进行项目成本及工作量的估算；
    • 使用一个或多个经验模型 进行软件成本及工作量的估算。

5.2.1 影响估算准确性的因素

  • 估算待建造产品规模 (即大小)的能力；
  • 把规模估算转换成人的工作量、时间及成本 的能力；
  • 项目计划反映软件项目组能力的程度 ；
  • 产品需求的稳定性 及支持软件工程的工作环境。

5.2.2 内容

  • 软件工作产品的规模大小估算——这是一切估算的基础；
  • 软件项目的工作量估算；
  • 软件项目的成本估算；
  • 软件项目的进度估算；
  • 项目所需要的人员、计算机、工具、设备等资源估算。

5.2.3 方法

  • 常用的估算方法：Delphi 、PERT(计划评审法)
  • 工作量估算模型：COCOMOII
  • 基于类比的估算：借鉴历史项目数据
  • 规模估算方法：LOC(代码行)、FPA(功能点)、UCP(用例点)、UP(故事点)

通常认为，如果一个模型的75%预计值与实际值只有25%的误差，那么这个模型就是可以接受的（Fenton，1997）。

5.3 Scrum估算

5.3.1 特点

  • 团队集体估算：在开发过程中团队共同承担责任，由团队集体承诺完成一个冲刺的工作；因此对待完成的产品积压工作项的估算也是由集体来决定(Delphi法原理)
  • Scrum估算是由一组类斐波纳契数列 的数字组成，0、0.5、1、2、3、5、8、13、20、40、100、?、∞（一共13张牌）；可以使用估算扑克或类似的工具支持完成估算。
  • 估算大小，而不是时间，使用相对估算 ，而不是绝对估算。
  • 记录每个冲刺的团队速度，为以后计划做参考（借鉴历史数据）。

5.3.2 初定标准规模

  • 开始做估算之前，从待实现的产品积压工作项列表中选择一个初步认为规模不是最大又不是最小的功能需求项 。
  • 由产品经理(需求分析人员、产品负责人)对这个项进行讲解，团队理解该需求的业务逻辑，若有疑问，产品经理进行解答；直到大家都没有问题为止。
  • 团队拆分之任务，并预估用时；任务拆分时要考虑到前端开发、后端开发、系统设计、单元测试、联调测试、系统测试等各块的工作。
  • 得到整体用时，并确保小组要对用时达成一致。
  • 把这个项的大小定义为标准规模，以3个故事点来计。

5.3.3 Scrum估算方法

敏捷估算扑克法

每个团队成员拿到一组卡片，包括0,0.5,1,2,3,5,8,13,20,40,100,?,∞,共计13张。

  • ①产品负责人从产品积压区中取出第一个产品积压工作项(需求)进行讲解，并询问大家是否有疑问直到没有疑问为止。
  • ②开发团队针对这个工作项进行讨论，产品负责人在此过程中澄清疑问。
  • ③当开发团队成员都充分了解这个工作项后，每个团队成员参照团队定义的标准规模，按照自己的预估给出估算结果，并选择相应的扑克出牌，估算结果不能告诉其他人，出牌时数字朝下扣在桌子上。
  • ④所有人都给出结果后，一起亮出估算数字。
  • ⑤如果大家给出的结果不一样，则出牌为最大值和最小值的人给出详细的估算考虑说明。通过此过程主要为了明确:团队成员是否想法一致、是否存在分歧、是否有未考虑到之外。讨论之后再重新出牌估算，最终团队达成一致。
  • ⑥产品负责人选择一个产品积压工作项，重复以上步骤，直到产品积压区中的所有工作项估算完成。估算结果填写到对应的产品积压工作项的“规模”处。

三角估算法

  • ①把确定标准规模的产品积压工作项标识为A，放在白板上，规模标识为3。
  • ②从产品积压区的最上面取出一个产品积压工作项B，团队通过讨论，就其规模和A进行对比；如果比A大，放在A的右边；如果比A小，放在A的左边；如果和A差不多大小，放在A的下面。
  • ③继续从产品积压区中取出下一个产品积压工作项C，重复步骤②，分别和工作项A、工作项B进行比较，直到为C找到合适的位置。
  • ④重复步骤②和③，直到所有的产品积压工作项都完成放置。
  • ⑤比较A左边的产品积压工作项，估算值为2还是1，把左边的所有工作项估算值设置为2或1；同样把A右边的工作项，按列标明估算值。

5.4 Sprint(冲刺)计划会议

  • 目的：计划当前冲刺要做的工作。
  • 与会人员：产品负责人、敏捷教练(SM)和开发团队。
  • 时间点：冲刺的第一天。
  • 时长：2小时 * 冲刺周数(1-4)。
  • 会议议程：
    • 确定当前冲刺要完成哪些功能(做什么)。
    • 确定如何完成这些功能(怎么做)。
  • 会议结果：冲刺目标确立，产生冲刺订单，团队承诺完成冲刺目标。

5.4.1 任务估计及工作容量

  • 在一个冲刺内，开发团队所有成员可供用来工作的时间总和称之为工作容量。
  • 工作容量 = 8 * 0.75 * 人数 * 迭代时间 * 0.9
  • 冲刺计划会议上就需要看待完成的产品积压工作项所有任务的工作量之和是否在开发团队的工作容量之内，如果超出了工作容量，则与产品负责人协商调整冲刺产品积压订单。
  • 对任务所花费的工作量有很多种估计方法，可以使用 Delphi法等来估计每个任务所要花费的工时。

5.4.2 预估冲刺速度

  • 团队在开始工作之前，没有办法知道自己的冲刺速度，为了得到这个速度，通常是使用初始冲刺计划会议的方式来确定。这个计划会议与安排任务的冲刺计划会议完全相同，只是在冲刺之前执行。
  • 在计算团队冲刺速度之前，需要计算开发人员的可用时间及并设置在冲刺期间的可用工作容量。可以按如下方法来计划可用时间：
    • 明确一个冲刺需用多长时间，建议按两周来确定。
    • 计算一个冲刺有多少工作日，企业通常按每周5个工作日来计算。
    • 每个团队成员在冲刺期间可工作多的时间，要去除假期或其他休息日、计划参加的会议占用的时间等。

建议

  • 会有浪费时间或未知活动导致的一些拖延，如果没有历史数据则建议分配25%的拖延时间。这样计算下来如果每天是8小时，则团队容量为每天6小时。
  • 此外，还要考虑开发团队要有不少于10%的时间用于参加积压项(需求项)梳理。

5.5 冲刺中的日常活动

5.5.1 进度监控

燃尽图

燃尽图：使用此信息显示Sprint中所有任务的总工作时间。其为团队提供了一个即时的视觉效果，可以预期何时完成所有任务。

  • 显示每个冲刺中剩余的故事点数，并且标明发布的所有工作通常由几个冲刺组成。
  • 通过显示随着冲刺的进行而减少的剩余工作量，用图形化的方式来显示团队如何进行工作的。

ab760004c8aac5cd05394b36695e158e.jpeg

速度图

  • 有助于说明团队实现产品积压工作项的能力。

累积流图

  • 此图从所有冲刺的角度显示了从定义的时间段到当前的进度。

5.6 每日站会

  • 目的：每天检视完成冲刺目标的进度，发现偏差，以便会后及时调整。
  • 时间点：每天工作刚开始的时候或团队约定固定时间段。
  • 地点：任务板前。
  • 时长：一般15分钟。
    • 形式：大家站立开会。
  • 会议议程：每人回答以下三个问题：
    • √ 昨天，我做了什么
    • √今天，我要做什么
    • √ 我遇到了什么问题
  • 与会人员：产品负责人，开发团队(必须)，SM(可选)，其他人可以听，不能说话。
  • 会议结果：每位团队成员都了解项目状态。

5.7 冲刺评审会议

  • 映射瀑布模型中的项目结项验收中验收过程
  • 目的：检视完成的产品增量是否符合用户的预期；收集反馈以便调整。
  • 时间点：冲刺的最后一天。
  • 时长：一般不超过4个小时。
  • 与会人员：产品负责人(必须)，开发团队(必须)，SM(可选)，用户(可选)。
  • 会议议程：
    • √产品负责人总结当前冲刺的完成情况
    • √开发团队演示已完成的功能并解答用户提出的问题
    • √用户提出反馈，并和产品负责人讨论对产品积压工作项的调整
    • √可以讨论发布日期
  • 会议结果：修订后的产品积压工作项列表，并闻明可能进入下个冲刺的功能。

5.8 冲刺回顾会议

  • 映射瀑布模型中的项目结项验收中结项总结过程
  • 目的：Scrum团队检视自身并创建下一个冲刺改进计划的机会。
  • 时间点：冲刺评审会之后。
  • 时长：一般不超过4个小时。
  • 与会人员：产品负责人(可选)，开发团队(必须)，SM(可选)。
  • 会议议程：
    • √团队回顾冲刺的过程，找出做的好的方面和需要改进的方面
    • √对需要改进的方面进行优先级排序
    • √选择优先级高的事项，制定改进计划
  • 会议结果：改进计划。

5.9 Scrum事件时间限制

  • 冲刺：1 - 4 weeks
  • 计划会议：1 - 8 hours
  • 每日站会：15 mins
  • 评审会议：1 - 4 hours
  • 回顾会议：1 - 4 hours

6. 软件配置管理

6.1 软件配置管理

6.1.1 配置管理的概念

  • 类似于宝来的发动机无法配置到宝马上去，无论是软件还是硬件，都需要有一个清晰、一致的产品配置清单，以保证产品可以按预期的设计进行组装、运行；在产品开发过程中要始终保证这个清单的一致性、完整性，并清晰可存取。
  • 配置管理及版本控制是指通过技术及管理手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施和过程，它通过控制、记录、追踪对软件的修改和每个修改生成的软件组成部件来实现对软件产品的管理。

6.1.2 配置管理的内容

  • 配置管理：包含 版本控制、工作空间管理、并行开发控制、过程管理、权限管理、变更管理等内容。
  • 软件配置管理：是在贯穿整个软件生命周期中建立和维护项目产品的完整性。
  • 主要是确保如下几块内容:
    • 软件配置管理的各项工作是有计划进行的；
    • 被选择的项目产品得到识别，控制并且可以被相关人员获取；
    • 已识别出的项目产品的更改得到控制；
    • 使相关组和个人及时了解软件基准的状态和内容。

6.1.3 配置管理的系统

  • 总控模式，SVN、TFVC、VSS等，在服务器端保留一份拷贝。适用于：
    • 大型项目代码库；
    • 权限管控比较严格，可以到文件级别；
    • 比较难于合并的文件类型，比如:二进制文件等。
  • 分布式模式，微软Git、GitHub、GitLab等，每个开发人员在本地克降一个完整的拷贝。适用于：
    • 小型或模块级的项目，对于大型的项目需要借助辅助工具来操作；
    • 基于开源代码的；
    • 分布式团队；
    • 跨平台工作的团队；
    • 新领域的代码库。

6.2 基本概念

6.2.1 配置库

  • 存放配置项的存储库，配置库结构的组织形式是配置管理活动的重要基础，其会影响开发活动的开展。

  • 按配置项的类型分类建库最为常见：

    • 适用于通用的应用软件开发项目。
    • 这类项目开发的产品继承性较强，开发工具比较统一，对并行开发有一定的需求。
    • 使用这样的库结构有利于对配置项的统一管理和控制。
    • 提高开发和发布的效率。
  • 缺点:这样的库结构并不是面向各个开发团队的开发任务的，所以可能会造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦。

  • 按任务建立相应的配置库

    • 适用于专业软件的研发项目，使用的开发工具种类繁多，开发模式以线性发展为主，没有必要把配置项严格的分类存储，人为增加目录的复杂性。
    • 对于研发性的软件机构来说，还是采用这种设置策略比较灵活。

  • 配置库的日常工作:主要保证配置库的安全性及可用性，包括配置库的定期备份、清除无用的文件和版本、检测并改进配置库的性能等。

6.2.2 基线

  • 基线由一个或若干个通过(正式)评审并得到确认的配置项组成，是项目进入下一个生命周期阶段或在敏捷开发中进入下一个冲刺的出发点(或基准点)
  • 基线是软件文档或源码(或其它产出物)的一个稳定版本，它是进一步开发的基础，只有经过授权后才能变更。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。

6.3 变更控制执行的活动

  • 启动并记录变更请求(需求变更、工作产品的故障和缺陷，描述对工作产品和解决方案的影响)；
  • 分析变更请求的影响(进度、技术、项目需求、发布计划等)；
  • 对变更请求分析和优先级排序；
  • 与受影响的干系人达成一致，并形成记录；
  • 跟踪变更请求直到关闭；
  • 以保持完整性的方式整合变更(修改是经过授权，更新配置项，工作产品的版本等)；
  • 执行审查或测试以确保变更没有造成意外的影响；记录对配置项的变更及其理由。

7. 软件测试管理与软件质量保证 (书中第8章)

7.1 持续测试

  • 其通过与持续集成结合，强调及时反馈质量、测试持续进行，通过各角色之间的协同工作，持续发现缺陷并快速修复。

7.2 软件测试的定义

  • 2018年《计算机科学与技术名词》给出的定义：对软件进行检测和评估，以确定其是否满足所需结果的过程和方法。是帮助识别开发完成(中间版本或最终的版本)的计算机软件整体或部分的正确度完整度和质量的软件过程，是软件质量保证的重要子域。

7.3 哪些可以认为是缺陷？

  • 软件没有实现产品规格说明所要求的功能模块。
  • 软件中出现了产品规格说明指明不应该出现的错误。
  • 软件实现了产品规格说明没有提到的功能模块。
  • 软件没有实现虽然产品规格说明没有明确提及但应该实现的目标。
  • 软件难以理解，不容易使用，运行缓慢，或最终用户会认为不好。

7.3.1 原因

  • 软件模型或者说业务建模不正确，即对要做什么理解不正确，占比高达60%以上，且难于纠正。
  • 代码编写错误，占比大概20%，比较容易纠正。
  • 软件变更会引入新的缺陷，而不只是变更部分产生缺陷，即个别功能的修改会影响到其他部分。
  • 软件庞大，功能十分复杂；或者与软件对接的第三方软件本身存在问题，也会导致缺陷的产生。
  • 失控的项目管理、紧迫的项目工期、人力资源配备不足、沟通不充分等，这些也会导致大量缺陷的产生，并且导致软件质量的失控。

7.4 软件测试的敏捷开发实践

  • 通过开发过程中各种检视来减少缺陷的产生，同时通过持续集成及持续测试，尽早发现代码中的缺陷并修复。
  • 其主要目标是怎么避免把BUG带到系统中，提倡“内建质量”，全员对质量负责，而不是质量保证人员；全员具备质量意识。

7.5 软件测试的基本准则

  1. 完全测试程序是不可能的。
  2. 软件测试是有风险的行为，如何针对风险制订做出明智抉择，去粗存精。
  3. 测试无法显示潜伏的软件缺陷，可以报告已发现的软件缺陷，却无法报告潜伏的软件缺陷，更不可能保证找到全部的缺陷。
  4. 与自然界的寄生虫类似，软件缺陷也会成群出现：
    • 程序员怠倦，第一天编写代码还不错，第二天就会烦躁不安了，受这些因素影响会成群的产生缺陷；
    • 程序员往往会犯同样的错误，每个程序员都有自己的偏好及编码习惯，发现一个缺陷，其编写的功能会有类似缺陷；
    • 某些软件缺陷是大灾难的征兆，一开始某些缺陷似乎毫无关联，但其有可能是由一个极其严重的原因造成的。
  5. 杀虫剂怪事，与农药杀虫是一样的，软件开发人员对测试方法及技术也有免疫力，只有发明新的杀虫剂(测试技术或方法)去找虫子。
  6. 并非所有软件缺陷都能修复，要权衡成本、进度及市场需要。
  7. 软件测试员在小组中不受欢迎，软件测试员的任务是检查和批评同事的工作，挑毛病，公布发现的问题。

7.6 软件测试分类

7.6.1 按测试特性

  • 白盒测试：测试人员直接在软件的源程序上进行测试、修改、复测。要求测试工程师对软件的内部结构及逻辑有深入的了解，并掌握写成该源程序的语言。分为：语句测试；分支测试；路径测试；条件测试；目测。
  • 灰盒测试：介于白、黑两者之间，是两者的结合。测试工程师对软件程序结构有一定了解，但了解的程度又不需要达到白盒测试的深度。
  • 黑盒测试：测试人员不必深入了解软件的内部设计，只是从一个终端用户的角度，根据产品说明书的指标，从外部测试软件的各项功能及性能。黑盒测试主要是功能测试。

7.6.2 按开发过程

  • 单元测试、集成测试、系统测试、用户验收测试及 回归测试。
  • 回归测试一般是在缺陷修改之后执行，保证原缺陷不在重现，并且缺陷的修改不影响其他功能。

7.6.3 按测试要求

  • 基本功能测试(Smoke testing)：也称为冒烟测试，只对软件的关键功能做测试，而不必卷入细致的测试，不必面面俱到。
  • 全面测试(Sanity testing)：不仅对软件关键功能测试，还要覆盖软件的全部功能，是回归测试的主要组成部分。
  • 基准测试(Benchmark testing)：对指定的一个或一组程序及数据在不同的计算机上执行测试，以测定其在标准情况下、特定配置下的工作性能，并将其执行速度、完成需时等加以比较。

7.6.4 按软件特性

  • 功能测试：主要包括等价区间测试，把输入空间划分几个“等价区间”，在每个区间中只需要测试一个典型值即可。又可以分为 边界值测试、随机测试、状态转换测试、流程测试等。
  • 非功能测试：主要包括：安装/卸载测试、使用性测试、恢复测试、兼容性测试、安全测试、性能测试、强度/压力测试、容量测试、任意测试等。

7.6.5 按测试角度

  • Alpha版——公司内部测试的版本，该版本的特征为：
    • 软件的所有功能已基本实现；
    • 所有的功能已通过测试，一般情况下推向市场前不再增减（一般为集成测试）；
    • 已发现的缺陷中，严重级别的已修正并通过复测；
    • 软件性能测试可提供基本数据。
  • Beta版———对外发布公测，该版本的特征为：
    • 次严重缺陷基本完成修正并通过复测；
    • 完成测试计划（一般为系统测试方案）中的每一项具体测试；
    • 一段时间内缺陷的发现率低于修正率；
    • 所有相关文件（用户指南、软件说明、版本说明等）得到最后修正。
  • 发布版——正式发布版本，一般在Beta3之后软件正式发布，该版本的特征为:
    • 缺陷发现率低于修正率，此距离逐渐拉开并一直保持稳定的一段时间；
    • 测试部门对所有已修正的缺陷重新测试并通过；
    • 技术支持部门对产品的提出认为可行；
    • 所有用户反馈都已妥善处理；
    • 所有文件准备就绪；
    • 得到测试部门认可。

7.7 良好自动化测试的特征

  • 用例之间相互独立，即前一个用例的执行结果对后一个用例的执行没有影响。
  • 其次，测试用例的运行结果必须稳定，多次执行的测试结果应该是稳定的、不变的。
  • 测试用例的运行速度必须快，当一个测试用例由多个执行步骤组成时，每个步骤都需要一定的执行时间；要通过执行策略来提高速度。
  • 测试环境应该统一，确保编写的测试用例能一致的行，从而最大化自动测试的收益。

7.8 DevOps时代的测试实践建议

  • 测试左移，是指测试人员更早地参与到软件项目前期的各项活动中，在功能开发之前定义好相关的测试用例，提前发现质量问题。早期引入测试过程有助于防止缺陷，并为开发人员提供了在整个开发阶段应用动态变更的灵活性。
  • 测试右移，就是直接在生产环境中监控，并且实时获取用户反馈。在这种方法中，从用户侧收集反馈，根据用户反馈持续改进产品的用户体验满意度，提高产品质量。测试右移有助于更好的响应意外情况。
  • 为了迎合不断加快的交付频率，越来越多团队的测试活动开始向左右两侧移动。
    • 一般问题修复成本较高和面向企业收费的软件，一日生产环境中出现了问题会造成比较大的损失，通常采取测试左移的方式；
    • 对于具有展示功能的软件产品，更容易在生产环境中发现问题，通常采取测试右移的方式。

7.9 敏捷开发的软件质量保证理念

  • 品质管理的名言：检查即不会提高质量，也不会保证质量。检查进行得太迟了。质量，无论高低，都已经存在于产品中了。质量在产品和服务中是无法被检查的，只能内建（质量内建）进去。—— 爱德华兹.戴明

7.9.1 敏捷测试怎么避免瀑布模型的浪费

  • 敏捷架构：通过协作、浮现式设计、意图架构，以及简单设计支持敏捷开发实践；避免采用大型预设架构。
  • 敏捷测试：每个人都要做测试，解决方案以小的增量进行开发和测试，并且团队应用测试前置和测试自动化实践。
  • 重构：更新并简化了现有代码或组件的设计，而不更改其外部行为。
  • 探针：用于获得必要的知识，以减少风险、更好地理解需求，或者增加故事估算的可靠性。

7.10 Azure Test Plan

  • 测试用例：这是测试的最小单位，就是要测试的具体内容和步骤，一般包含了3个值:“操作步骤，期望结果，实际结果”。其实任何人测试都是这样的一个步骤，第一步，做什么，看看执行结果有没有和期望的相同。
  • 测试套件：当测试用例越来越多的时候，我们就需要使用测试套件进行分组一般一个需求会有很多个测试用例，因为测试用例包含了正向测试、逆向测试、边界测试等等。
  • 测试计划：测试也是需要有计划，某个周期根据需求来定义要测试的套件，比如，第二个冲刺，需要测试22个套件，里面包含了127条测试用例。

8. 项目总结及持续改进(书上第十一章)

8.1 项目总结及复盘

8.1.1 总结分析的4个问题

  1. “我们打算做什么？”，即本次任务的目标是什么。
  2. “实际发生了什么情况？”，即我们是怎么来做的。
  3. “为什么会发生这些情况？”，对其中的问题做原因分析。
  4. “下次我们将怎么做？”。

8.1.2 代码复用总结

  • 前端代码复用
  • 后端代码复用
  • 技术框架复用