ACP-发现与解决问题

最近在着手准备ACP考试，仔细看了下相关的书籍，对每章知识点进行相应的整理，想着记录下来，后续如有更好的理解，再回头更新。
之后会按照以下目录进行梳理：

• 敏捷的理念
• 价值驱动交付
• 干系人管理
• 打造高绩效团队
• 适应性计划
• 发现与解决问题
• 持续改进
• 敏捷的实践

发现与解决问题

• 问题概述
  敏捷的核心是为了持续改进，针对过程中发现的问题，及时反馈和修正，通过高频次的反馈，发现问题，分析问题，解决问题。
  尽早发现问题和处理变更能有效地减少重复工作从而降低成本，因而缺陷循环时间的概念应运而生，即故障引入到修复的时间，长短代表来对应的修复成本。
  问题的处理流程一般如下，可以通过pdca来理解：

  • 定义问题；
  • 收集信息
  • 分析原因
  • 备选方案
  • 选择方案
  • 实施方案
  • 跟踪反馈
  • 问题是否被解决，如有：结束；没有：重新定义问题

• 发现问题
  以下是发现问题的多个途径和方法：
  每日站会：站会上的第三个问题：遇到了什么阻碍，就在要尽早发现团队成员在项目中遇到的问题，尽早曝光，及时解决，而不是等到客户抱怨不断或者等到回顾会再来总结；
  站会只需要明确问题三要素即可：问题是什么？谁来解决？什么时间解决？
  循环时间：从任务开始到任务结束的时间。任务结束的定义：获得了客户的验收，因为这样才能交付商业价值，才算真正的完成；
  循环时间和在制品数量有很大关系，而在制品会带来浪费、返工和效率的下降，敏捷就是为了最小化循环时间；
  公式：循环时间 = 在制品数量/团队吞吐量；
  吞吐量在于预测团队未来的绩效，循环时间可以对客户就交付日期做可靠的承诺。
  故障泄漏
  故障是无法避免的，但是可以针对“已发现的故障泄漏数量”来追溯这类故障产生的原因，通过这个环节帮助团队不断评估并提高质量保证和质量控制的效率。
  质量标准
  质量是产品的生命，发现问题&解决问题的目的就是为了确保交付高质量的产品。
  质量标准和时间会包含如下内容：

• 用客户验收来衡量产品质量，即客户的满意才可以作为验收标准；

• 尽可能自动化测试；

• 确保每个迭代都进行测试；

• 在下个迭代前，至少修复90%的已发现缺陷；

• 鼓励质量保证和质量控制人与开发、业务一起工作，对每个功能特性的验收标准达成一致理解；
  在评估质量时，可以借助一些工具，比如：控制图、趋势图、根本原因分析、鱼骨图、流程图等
  趋势图：基于现实的数据来预测将来的可能性，比如：在累计流量图中，可以通过趋势分析来预测完工的日期；
  控制图：控制图是用来确定一个过程是否稳定，或者是否具有可预测的绩效，是属于质量控制的常用工具。控制图的元素主要包括：

  • 均值；
  • 控制界限，常被设置在正负3西格玛处
  • 规格界限（客户能接受的最大偏差）
  • 失控（判定失控的范围：超出界限或是连续7个点在同一侧）
  • 七点原则
  • 非随机原因

• 解决问题
  解决问题的活动

  • 持续集成：持续集成是敏捷项目管理中尽早发现问题的一个典型应用，在现在项目中使用越来越多；
    有如下几点好处：

    • 及时获悉代码合并的错误
    • 尽快修复错误而不是拖延到发布
    • 及时获取反馈信息
    • 进行频繁的单元测试
    • 快速回退版本
      集成测试缩短了问题解决的周期，降低了变更应对的成本；

  • 风险探测：是研究探索性问题的一个快速方法，通过前期小规模实验和探测来降低项目的风险。
    “快速失败”的模式，相比于把剩余的资源和资金投入到最终必将失败的项目中去，“快速失败”是有益的，节省成本&消除浪费。

  • 频繁的确认与验证：通过此类操作，用以改进和提升产品交付的质量；其实在项目中很多实践都或多或少的运用到：

    • 结对编程：立即反馈；
    • 单元测试：极限编程上一步就是单元测试，持续集成同理，反馈都很快；
    • 客户合作：频繁地跟客户合作和增量交付，及时得到客户反应和确认，更好的交付高质量产品；
    • 每日站会：每天反馈进展和障碍；
    • 评审会：为来确保交付给客户是被需要的，也是一种确认和验证。

    频繁的验证也是为了尽早发现问题，将变更成本降到最低；

  • 测试驱动开发（TDD）：主要流程包括：测试、编码和重构；
    主要优点：

    • 聚焦：聚焦于测试，出发点还是功能需求，确保功能是满足客户需求的；
    • 全面：在编码前编写测试用例可以最大限度地对代码进行充分的测试，更高的测试覆盖率会提升系统的质量；
    • 早期：越早、越频繁的测试会及时发现开发过程中的问题，避免问题留到后面产生昂贵的代价和修复成本；
    • 灵活：小规模开展单元测试可以提升系统的可扩展和灵活性；

    存在的不足：

    • 同一个人编写测试代码和编码，会对需求的测试和编码存在同样的误解；
    • 对用户接口类的功能测试比较薄弱，需要投入大量时间；
    • 维护成本高，尤其在变更比较大的情况下，不仅要维护代码，还要维护测试代码。

  • 验收测试驱动开发（ATDD）：测试的关注点从代码转向需求，在编写代码前就确认功能的验收标准。

  • 探索性测试：作用在成品软件上，为了提高产品质量；

  解决问题的步骤

  • 收集数据：
    • 时间轴：相当于划定好时间范围，在范围内的问题进行回顾；
    • 三五成型：3个5，针对5个人，在5分钟内问5个问题，收集反馈；
    • 颜色标识：用带颜色的记事贴贴在时间轴上，描述情绪或士气高低；
    • 寻找优势：寻找优势，争取在下一个迭代中发挥；
    • 满意度直方图：迭代中满意度以直方图展示；
    • 团队雷达：多维度数据展示工具，从多个领域去衡量当前迭代表现。
  • 分析原因：
    • 头脑风暴：安静书写、循环发言、自由讨论出想法和灵感，通过其他技术（亲和图、思维导图等）方式进行归纳分类，使用100分法、名义小组等方式进行排序；
    • 名义小组：促进头脑风暴的一种技术，投票表决；
    • 五问法：起源于精益思想，目的是帮助找到问题的根本原因。
    • 鱼骨图（因果图、石川图）：常用的分析原因的方法，五类因素：人、机、料、法、环。
  • 采取行动：敏捷团队会采用一些群体决策技术对各种解决方案进行确认，确保达成一致的认识，并设置目标进行推进实施；
    常用的技术有：
    • 简单主题：帮助团队就采取的行动达成一致。比如在回顾会上使用的：海星图、快船等方式，就是确认几个简单的主题：好的keep，不好的stop；
    • SMART目标：
      • specific：目标是明确具体的；
      • measurable：目标是可以衡量的，即是有明确验收标准的；
      • attainable：目标是可以达到的；
      • relevant：目标是于组织的其他目标具有相关性；
      • time-based：是有明确截止日期的。