ACP-敏捷的实践

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

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

敏捷的实践

• 看板
  看板开发方法通过限制在制品（WIP）来帮助解决问题，并减少开发变更带来的浪费和成本的增加。
  在拉式系统中被使用，通过限制WIP，一步步完成开发任务。
  本身是一种精益技术，形式上采用来任务板/故事墙/状态强的增强版；
  核心原则：

  • 流程可视化：可视化流程的方法对项目跟踪非常重要。
  • 限制WIP：明确限制流程中各状态上同时进行对任务数上限。保持进行中工作量可以减少问题、瓶颈对发生，聚焦并持续改进；
  • 关注流程：可以清楚的解释如何工作，体现共同的目标-改进。

• 精益
  精益软件开发不是敏捷方法，但是价值观很接近。精益是将精益生产方法应用于软件开发。七大核心概念如下：

  • 消除浪费：要想获得最大化的价值，必须消除浪费（延期、没用的功能、等待）；
  • 授权团队：尊重团队成员并由团队进行决策，保证项目效率，有利于项目成功；
  • 快速交付：快速交付有价值的软件来最大化项目的投资回报率（ROI）
  • 全面优化：检视系统的整体而不是一部分，关注整个组织的优化改进。
  • 品质为先：不是测试为先，通过重构、持续集成、单元测试等技术手段加强质量保质；
  • 晚做决策：延迟决策，尽早进化和最晚决策；可以理解为消除不必要的变更浪费；
  • 强化学习：通过尽早沟通和频繁的反馈来建立学习的内容。软件项目是业务和技术两项经验的积累，需要尽快开始并保持学习的状态。

• 极限编程
  轻量级的软件开发方法，价值观是沟通、简单、反馈、勇气和尊重。
  “探针”是迭代中使用的技术手段，用于探测未知的工作与风险。
  极限编程价值观

  • 沟通：保证团队成员都知道对他们的期望和团队其他成员的工作，每日站会非常重要；
  • 简单：“最简洁的东西是最可行的”为指导，减少复杂程度、多余的功能，消除浪费；
  • 反馈：尽早暴露反馈问题。早期出现的错误可能是有益的，可以减少后期改进的成本；
  • 勇气：有勇气将我们的工作对别人公开可视，体现在结对编程，开发人员需要自动备份和进行单元测试，并且需要有足够的勇气和细心来做重要的改动。
  • 尊重：每一个人低讴在一起工作，素有人都对项目的成功或者失败负责。

  极限编程的12个技术实践

  • 计划游戏：发布计划和迭代计划；
  • 小版本：频繁对小版本，更快的交付价值，客户更多对反馈。基础是：严格的测试和持续集成；
  • 用户测试：定义需要完成的功能的一部分。团队可以根据验收标准进行自动化测试；
  • 集体代码所有权：代码归属集体所有，任何人都可以修改任何代码；
  • 编码标准：由于代码归属集体，所以需要统一的编码标准与规则；
  • 可持续的开发速度：长期的加班是不允许的，最高的生产率水准是一个团队可以达到持续的开发速度；
  • 比喻：解释设计的理念和创建共同的技术愿景，让项目干系人理解和解释项目开发的系统是如何工作的。意思就是说能够更人更清楚明白系统在做什么；
  • 持续集成：在项目中是非常关键的，是尽早增量交付和持续改进的基础。
  • 测试驱动开发：通过测试来推动整个开发的进行；在测试的不断保护下，不断重构代码，以消除重复设计，优化设计结构，提高代码的重用性，从而提高软件产品的质量；测试驱动开发过程中争取可以尽可能短地进行测试-反馈循环。
  • 重构：在测试和持续集成基础上，调整代码改善软件质量和性能，使设计模式和架构更合理，提高软件的扩展性和维护性。
  • 简洁设计：“可工作的最简化的东西”，相比于很多项目失败与庞大和复杂的编码，简洁的设计是降低风险的策略；
  • 结对编程：可以尽早发现错五，还能共享知识。

• Scrum
  Scrum概述
  是一种基于跨职能团队以迭代、增量的方式进行复杂系统或者产品开发的框架；特点如下：

  • 组织分拆为小规模、跨职能的自组织团队；
  • 工作拆分成一些小而具体的交付物，按优先级排序，估算没想任务的相对工作量；
  • 将时间拆分为短迭代，迭代结束时对基本可以交付的代码进行演示（评审会）；
  • 每个迭代结束后跟客户一起确认发布目标，并据此优化发布计划，更新任务优先级；
  • 每个迭代结束后进行回顾以及过程优化。

  敏捷的各类方法都有一个共同功能点：短迭代方式交付客户价值。

  下面简单的介绍下Scrum中的一些概念：

  1. Sprint 0：第一个迭代前的特殊士气，用来完成一些必要的准备工作。
     • 团队组建、导入培训
     • 确定PB，以及可供第一个迭代开发的用户故事；
     • 架构设计；
     • 原型开发；
     • 测试和验收策略；
     • CI、开发、测试环境等技术基础设施的准备
     • 办公环境和办公用品的准备；
     • 制订初始的发布计划；
     • 定义各种DoD；
  2. Sprint H：同紧急版本，当正常Sprint所完成的软件赠来给你还达不到产品发布标准时，在产品发布之前要专门留出用于“还债”的一段时间。
  3. SOS：当Scrum扩展到更大规模的技术。可以有两种含义：多团队代表组成的虚拟会议&多团队的每日站会；

  Scrum是一个框架，包含很多技术和工具。主要有：

  • 3个角色
  • 4个仪式
  • 3个工件

  Scrum中的3个角色

  • 产品负责人PO：负责最大化产品和开发团队工作的价值；主要职责有：
    • 定义所有的产品功能；
    • 决定产品发布的内容以及日期；
    • 负责产品的投入产出；
    • 排序功能的优先级；
    • 调整产品功能和迭代顺序；
    • 认同或者拒绝迭代的交付；
      PO对产品代办列表（PB）的内容和排序的决定必须是可见的，开发团队必须尊重PO的意见并按照PO的意见进行开发和实践。
  • 开发团队：负责用户故事的实现，主要负责每个迭代结束时交付潜在的产品增量，必须是‘完成’状态的。
    开发团队由组织组建并得到授权，团队自组织和管理他们的工作。主要特点有：
    • 自组织：如何交付潜在的可发布产品增量，是由开发团队自主决定，SM不要干预，除非团队需要；
    • 跨职能：拥有交付产品增量所需的全部技能；
    • 共担责任：责任属于整个开发团队；
    • 规模：考虑职能、敏捷和灵活性，通常开发团队在5～9人；
    • 集中办公：一般情况都在同一地点办公。
  • Scrum Master：负责加强对Scrum的理解，指导团队成员正确理解并实施Scrum。主要的职责有：
    • 对项目的直接管理；
    • 带领并指导团队的Scrum实践；
    • 移除开发团队工作中的阻碍；
    • 确保团队能够胜任其工作，并保持高效的生产率；
    • 使得团队紧密合作，团队个人具有多方面的工作能力；
    • 保护团队不受外来因素无端的干扰；
    • 在自组织和跨职能方面指导开发团队；
    • 协助PO管理代办实现，以及和开发团队沟通项目愿景、目标以及产品代办事项。

  Scrum中的4个仪式
  Scrum通常在每个迭代中使用固定的会议，以此来减少其他无效的会议。每个仪式都有时间盒的限制。

  • Sprint计划会议（迭代计划会）
    特性：

    • 标志着Sprint的开始
    • 确定哪些用户故事会纳入到本版本当中
    • PO必须为迭代计划会准备一个最新的、经过排序的PB；
    • 通常有时间限制。

    计划会议通常会分成两个部分，

    • 上半场：PO确认本次迭代需要完成的功能，说明迭代的目标以及达成该目标需要完成的代办事项列表；
    • 下半场：开发团队自己决定选择产品代办事项中用户故事的数量，并且进行故事的估算和任务的细分等。
      上半场主要是PO澄清需求，告知目标以及用户故事的优先级，确保用户的需求与开发团队的理解是一致的；
      下半场根据理解的目标，结合实际资源、代办事项优先级与开发速度，进行用户故事的估算、选择和任务的划分；

    计划会议的输入输出：

    • 输入：产品代办事项、最新的产品增量、开发团队的开发速度等；
    • 输出：开发团队能够解释如何自组织完成迭代目标和预期的产品增量；

  • 每日站会：
    特点：

    • 每天进行；
    • 固定时间（15分钟）；
    • 同一时间、同一地点；
    • 所有人都可以参加，但是只有Scrum的角色才能发言；
    • 不是汇报会议，而是团队之间的承诺；
    • 不是每次都要SM主持，团队成员可以负责召开；

  • Sprint评审会
    主要包含如下内容：

    • PO邀请Scrum团队和主要干系人参会；
    • PO说明哪些代办事项已经即完成，哪些还未完成；
    • 开发团队演示完成的工作并解答关于所交付增量的问题；
    • PO讨论当前产品代办事项情况，根据当前进度预测可能的完工日期；
    • 评审市场或潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变。

    输出：一份修订后的产品代办事项列表，阐明很可能进入下一个迭代的代办事项。

  • Sprint回顾会
    持续改进是敏捷的核心，回顾会的核心就是为了持续改进。目的主要在于：

    • 总结上一个迭代中的经验和问题；
    • 找出后续潜在改进的主要方面，同时加以排序；
    • 制订改进工作计划。

    在回顾会议结束后，团队应该明确在接下来的迭代中需要实施的改进，并且跟踪；

  Scrum中的3个工件

  • 产品代办事项：要在某个迭代中实现的需求或者工作列表，特点如下：

    • 需求涞源：是产品需求变动的唯一来源
    • 动态的：PB是不完整的，需要持续更新的
    • 有序的：排序越高越清晰、具体；排序越低，细节越少
    • 唯一的：每个产品都有一个产品代办事项，与团队数量无关
    • PO负责：产品负责人负责管理内容、可用性和排序（最终决定权）。

  • 迭代代办事项： 是当前迭代选出的用户故事列表；特点如下：

    • PB的子集；
    • （有且只有）开发团队任何人都可以添加、删减或者更改迭代中的工作项；
    • 关注HOW，团队怎么做才能在一个迭代中完成任务的交付；
    • 开发团队通过每日站会跟踪剩余工作量，更新剩余工作量的估计，预测迭代目标完成的可能性；

  • 产品增量：当产品代办事项或者增量被描述为“完成”时，即可以作为发布的产品，“完成”的定义是需要在工作开始前被定义的。在客户多次参与的基础上，每次迭代被定义完成的产品增加到产品增量上。
    同一个项目团队对“完成”的定义必须一致，也体现了Scrum的透明性。