Created by potrace 1.16, written by Peter Selinger 2001-2019 J 『NOTE』

07. Project Support Activities

 
  • J 『宋』
  • Dec 14, 2020
配置管理的意义是什么？
  • 配置管理是为了确保工作产品的完整性和一致性 （在比较大的软件系统场景下特别有用的）
一些概念
  • 配置项
    • 在配置管理当中作为单独实体进行管理和控制的工作产品集合
    • 典型的配置项 ： 需求描述文档，设计文档，代码，测试用例， 用户手册 等
  • 基线
    • 配置项持续演进的稳定基础
    • 发布一个基线包括该基线所有的配置项以及这些配置项的最新变更，因此，可以将基线作为接下来工作的基础。
配置管理的活动

Screen Shot 2021-01-04 at 6.03.12 PM

  • 配置管理的一块的工作
    • “识别配置项”的目的 ：为了减少管理的对象
    • 代码这个配置项你的粒度是什么？ 有两种不同的极端 👈 实际的项目都不会用
      1. 所有的代码作为一个配置项来管理，但是如果这样做，因为对于配置项它的修改必须是串行的来做，不允许并行的去修改同一个配置项。（串行的修改–效率太低）
      2. 每一个代码文件是一个配置项，这个导致的结果是配置项数量太多了
    • 实际的项目当中，折衷的主要手段就是按照模块。一个模块对应的是一个配置项
    • “建立配置管理系统” ：最核心的是变更请求数据库。它由变更请求进行管控
  • 一致性的建立
    • “跟踪变更请求”，“控制配置项变更”
    • 通常单元测试结束了，代码已经到配置库了，然后做集成
    • 为什么CI需要配置管理呢？– 因为实际集成成功率很低
三库管理
  • 工作库
    • 几乎没有任何的限制，只要是项目组的成员，你就有完全的读写权限
    • 本地工作的远程备份
  • 配置库
    • 里面放了多个配置项
    • 需求文档，设计文档，代码等等当他们成为一个稳定的版本之后， 应该把这一些制品从工作库拷贝到配置库里面去
    • 通常能完成这个操作的只有“配置管理人员”
    • 配置管理人员才有权限把一个工作制品放（写）到配置库里面去，其他人只能读
  • 产品库
    • 形成的基线通过评审之后，才会把这一次基线发布的所有的配置项从配置库拷贝到产品库
    • 只有“配置管理人员”的操作
  • 普通开发人员能够写的是工作库（生产库）
  • 通常回滚的时候，只会回滚到产品库里的某一个版本
为什么要实施度量和分析活动？

  • 度量和分析活动就定义了客观数据的获取与使用方式

  • 度量和分析活动

    Screen Shot 2021-01-04 at 9.42.49 PM

    • 最上面的这一块本质上他就是GQM

      • GQM最核心的体现就是它是一个系统化的自顶向下的度量体系的构建
      • 基于数据来做客观决策的一个顶层的设计

    • 建立度量目标 ：简单来说，一定是从你的管理的信息需求出发去建立起度量的目标

      • 你试图要通过度量去了解什么状况？这是你的度量目标

    • 你为了了解质量状态，打算去度量什么？

      • 可以去度量人员，人员智能，生产效率，缺陷数量，用户满意度等等

    • 你确定了去度量什么之后，这些数据打算谁来收集的？通过什么样方式来收集的？收集好了之后放在哪里？

      • 通产情况下，衡量大家的生产效率，前端和后段代码量上有比率。比如说前端的两行代码是后端的一行代码。你觉得比率弄出来比较合适呢？– 建议用GQM方法重新去修理一下他究竟希望鼓励的是什么？他希望看到团队的是什么？如果你希望鼓励的是这个团队有创新的精神，那么创新的角度去设计相应的度量的方式。

    • GQM实例

      Screen Shot 2021-01-04 at 10.37.58 PM

      • 具体的指标比如说计划外的活动公式和占用的时间跟计划内的活动公式的比率是多小

      • 从开发的角度来说 ：

        G: 最大化所有团队贡献者的生产力

        Q: 开发人员能够完成分配给他们的任务吗，或者他们遇到障碍了吗？

        M: 由个体或者工作组产生的项目工件的数量

      • 所以一定是顶层设计的

团队分析决策是如何开展的？

  • 为了降低错误决策的风险，尽可能基于客观事实和正确的流程来开展决策与分析活动

  • 决策分析活动

    image

    • 建立一个决策分析的指南 ： 最重要的事情 = 去定义一下什么样场景下需要去做真实的决策分析
      • 你的决策对项目的工期造成了一个月以上的影响，会拿这个标准作为你要去做决策分析的判断语句。
      • 项目组达成一个公式，大家来共同决定我们需要去开展真实的决策分析活动的标准是多小，条件是啥
    • 建立一个评价的标准
      • 同样的评价标准上面（技术的熟悉程度，开发的成本，质量的状态） 设置不同的权重，为什么有的是10分，有的是5分等等？– 通过设置不同的分支，最大可能去体现决策者的利益诉求，决策者希望什么。比如说，决策者觉得方案的稳定性比方案的成本意义更大。他可能会把成本分支降低，稳定性的分支抬高。
    • 选择评价方法
      • 评价方法 – 这个评价标准最后打分。打分的范围是1分到10分。什么样的情况下1分，什么样的情况下10分？
鱼骨图和根因分析

  • 目的是为了避免类似的错误反复的发生，所以找到问题的根本原因

  • 根因分析活动

    Screen Shot 2021-01-04 at 11.40.31 PM

    • 选择用来分析的问题或者缺陷
      • 为什么做这件事情？希望用最小的代价去解决最多的问题（80/20法则 ： 80%错误是由20%模块导致的）

  • 鱼骨图 (根本原因分析)

    • 这种方法独特之处在于在分析问题的时候，我们找原因不是只找第一层的原因
    • 除了找到某一个问题的根本原因，我希望你再往下挖掘到三层
    • 对于一个问题进行分析的时候非常典型的方式
      • 技术角度 、人员角度、 培训角度、过程角度

《Reference》

  1. 2020年(秋) 软件质量与管理 : 荣国平
Search