敏捷

敏捷宣言及思维模式

敏捷宣言（4条）：

个体以及互动 而不是 过程和工具

可用的软件 而不是 完整的文档

客户合作 而不是 合同谈判

应对变更 而不是 遵循计划

‍

重点：重探索、重实践；轻文档、轻计划

‍

敏捷的12大价值观（重点）：

  1. 尽早持续交付有价值的软件
  2. 欢迎提出变更
  3. 要交付可用的软件，周期越短越好
  4. 信息传达最有效的方法是面对面交谈
  5. ** 可用的软件是衡量进度的首要衡量标准 **
  6. 提倡可持续开发
  7. 简洁，减少浪费，精益
  8. 定期反省

‍

重点关键字：** 关注价值、小批量、消除浪费 **

‍

精益与看板方法

‍

如何看待精益、敏捷、看板方法三者之间的关系：

敏捷和看板方法是精益思想的衍生物。精益思想是一个超集，与敏捷和看板方法拥有共性。

共性在于：** 交付价值、尊重人、减少浪费、透明化、适应变更、持续改善。 **

‍

不确定性、风险和生命周期选择

‍

迭代和增量方法，应用了：

  • 非常短的反馈循环
  • 频繁调整过程
  • 重新进行优先级排序
  • 定期更新计划
  • 频繁交付

‍

敏捷生命周期

‍

  1. 预测型

  2. 迭代型（变更频繁、复杂度高）

  3. 增量型（频繁少量交付）

  4. 敏捷型

    基于迭代的敏捷（考试默认）：timebox固定

    基于流程的敏捷

‍

混合敏捷方法

‍

  • Scrum框架

  • 看板方法（流程可视化）：工作流可视化，障碍易被察觉，通过在制品限制WIP来实现流程管理

  • 极限编程XP（注重效率和质量）

    故事卡：什么角色，需要什么功能，实现什么目的

    持续集成

    重构：之前的临时解决方案，存在隐患，需要被重新解决（技术债务）

    自动化测试：开发好的功能快速发布

    测试驱动开发：明确验收标准后再进行开发工作

‍

Scrum框架

‍

Scrum团队的三个角色

敏捷教练 Scrum Master（帮助产品开发团队学习、应用Scrum来达成商业价值，服务大家，解决工作中的障碍，对团队效能负责）

产品负责人 Product Owner （对产品相关的内容what，拥有决策权，例如：做什么，按照业务价值大小排优先级）

开发团队 Developers（决定开发方法how，负责DoD，对交付结果负责）

‍

Scrum团队是自组织的，没有子团队或层次结构

Scrum团队是跨职能的，干活不求人，破梳子型通才

Scrum团队通常是10人以下，如果团队过大，可以考虑Scrum of Scrum

‍

Scrum的三个工件

产品待办事项 Product Backlog（大需求池）

迭代待办事项 Sprint Backlog（小需求池）

增量 Increment

满足DoD的才可以被视为增量，增量必须是可用的

尽早完成增量，尽早展示，尽早获得反馈

如果有多个Scrum团队在同一产品上一起工作，必须一起遵守统一的DoD

‍

Scrum的5个关键事件

  1. 迭代 Sprint（容器型事件，包含了以下4个事件）

image​

  1. 迭代规划会 Sprint Planning （核心议题时下一次冲刺要实现的目标和范围）

    • 为什么这次迭代有价值（why）
    • 这次迭代能完成什么（what）
    • 如何完成所选的工作（how）

‍

  1. 每日站会 Daily Scrum

    促进信息在团队内共享和透明（领导可参与，只倾听不干预）

    ①完成了什么工作；

    ②计划做什么；

    ③遇到什么问题；（记录问题到停车场区，会上不解决，额外安排解决）

‍

  1. 迭代评审会 Sprint Review

    向利益相关方展示工作结果，但是要避免会议仅限于展示

    展示不要单向展示，** 要互动沟通，要获得反馈 **

    产品负责人PO负责接受或拒绝用户故事

‍

  1. 迭代回顾会 Sprint Retro

    • 产品待办事项以外的变化要记录 （但是不确定优先级）

    • 团队共同讨论和识别出最有用的改变

  2. 隐藏款： 产品细化会/产品精化会/产品研讨会/产品梳理会（通常在精化会后可以列出符合DoR的产品待办事项条目）

‍

如果迭代目标Sprint Goal 已经过时，迭代可以取消，只有PO有取消迭代的权力。

用户故事从大到小：史诗＞特征＞用户故事＞任务

在团队需要学习一些关键技术或者功能要素时，可以考虑刺探Spike，来用于方法探索（可以多种方案齐头并进测试）

‍

敏捷发布计划

定愿景 → 形成产品路线图（分几步走） → 发布计划（路线图+多长时间完成）

image​

‍

Scrum价值观

承诺、专注、开放、尊重、勇气

‍

仆人式领导

‍

  • 仆人式领导是一种为团队赋权的方法。

  • 鼓励团队创造一个人人都能成功的环境

  • 仆人式领导通过管理关系，在团队内和组织中建立沟通与协作，有助于消除障碍，促进团队理顺过程。

  • 仆人式领导的工作重点，从“管理协调”转向“促进合作”，帮助每个人各尽所能地思考和工作。

  • 仆人式领导通过成为公正的搭桥者和教练来促进大家协作，不是替代他人做出决策。

  • 仆人式领导还应该关注冗长的过程

  • 仆人式领导的职责示例：

    1. 教育相关方了解敏捷、如何敏捷
    2. 通过知道、鼓励和帮助为团队提供支持（培养和发展团队成员，帮助他们超越自身角色，即使失去他们也在所不惜）
    3. 通过技术项目管理活动来帮助团队（量化风险分析、提供培训、开展活动……）
    4. 庆祝团队的成功，创造相互欣赏的积极氛围，建立加强合作的良好意愿。

‍

敏捷团队

‍

  • 最有效的敏捷团队，往往在3~9个人。 团队成员100%是专职成员 。（任务切换会损失效率）

  • 敏捷角色：

  1. 跨职能 团队成员
  2. 产品负责人
  3. 团队促进者（敏捷教练、项目经理、Scrum主管……）

  • 团队工作场所：开放式办公区（渗透沟通）、洞穴

  • 分散式团队的管理沟通的技术：鱼缸窗口、远程结对

  • 敏捷团队需要 团队章程， ​ 包含了团队价值观、工作协议、基本规则、团队规范

  • 敏捷项目的衡量指标

    团队预测完成或使用【 交通灯状态 （红黄绿）】来描述项目的能力

    预测型衡量指标的问题在于：他们往往不反映真实的情况。（注意内红外绿的 西瓜项目 ）

    敏捷团队倾向于使用基于经验和价值的衡量指标，而不是预测型指标

    敏捷是基于对客户有可见价值的工作产品（可用性）

‍

敏捷工具和技术

‍

  • 燃尽图/燃起图

    速度：本次迭代中实际完成功能的故事点大小总和

    不同团队速度不具有可比性

    ** 团队衡量速度时，一定要确认故事已完成可用，要衡量已完成的工作 **

    燃起图可以看得出变更，燃尽图看不出变更

‍

  • 看板（流程可视化）

    基于流程的敏捷团队使用的衡量指标：交付周期、周期时间、响应时间

    交付周期 ：交付一个工作项目花费的总时间

    周期时间 ：处理一个工作项目所需的时间（通过衡量周期时间，发现瓶颈和延迟问题）

    响应时间 ：一个工作项目等待工作开始的时间

    在制品限制WIP：达到在制品限制WIP后，团队不能将工作从左边提取到下一列

    蜂拥模式：工作存在瓶颈时，团队成员一起解决问题

    image​

‍

  • 功能图

  • 挣值分析

  • 累积流图（把看板变成图）

    image​

‍