Cloud & Sun
首页 分类 标签 归档
Cloud & Sun

目录

Scrum 学习笔记

Gethin 收录于 软件工程
   约 484 字   预计阅读 3 分钟 
/images/content.jpg

Scrum Learning Notes

Scrum 学习笔记

理论与价值观

在有限的时间（TimeBox）里 团队一起合作（Work Together），我们彼此信任（Trust）并发挥自我最大的能力和优势（Do The Best），持续不断的交付（CI，CD）可用、有价值（Usable，Valuable）的软件，赢得客户的满意。

敏捷宣言

个体和互动 高于 流程和工具 （合作，信赖）
工作的软件 高于 详尽的文档 （产品增量）
客户合作 高于 合同谈判（同一组织）
响应变化 高于 遵循计划（公开，透明）

5 个价值观

专注 - 由于我们在一段时间内只能专注于少数几件事情，所以我们可以很好的合作并获得优质的产出，我们能够更快的交付有价值的事项。
公开 - 在团队合作中大家都会表达我们做的如何，以及遇到的障碍。我们发现将担忧说出来是一件好事，因为只有这样才能让这些担忧及时得到解决。
尊重 - 因为我们在一起工作，分享和成功失败，这有助培养并加深互相之间的尊重，并帮助彼此成为值得尊重的人。
承诺 - 由于对自己的命运有更大的掌控，我们会有更坚定的信念去获得成功。
勇气 - 因为我们不是单打独斗，我们能够感受到支持，而且掌握更多资源。这一切赋予我们勇气去迎接更大的挑战。

8 大价值观

诚实，开放，勇气，尊重，专注，信任，授权，合作

12 个原则

  1. 我们最重要的目标，是通过及早和持续不断地交付有价值的软件使客户满意。
  2. 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
  3. 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
  4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
  5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
  6. 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
  7. 可工作的软件是进度的首要度量标准。
  8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。(稳定的速度)
  9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
  10. 以简洁为本，它是极力减少不必要工作量的艺术。
  11. 最好的架构、需求和设计出自自组织团队。
  12. 团队定期地反思如何能提高成效，并依此调整自身的行为表现。

3 个角色

PO
Scurm Master
Team

3 个工件

Product Backlog
Sprint Backlog
Burndown chart

5 个活动

产品待办事项列表梳理
Sprint 计划
每⽇ Scrum 站会
Sprint 评审
Sprint 回顾

估算与计划

计划失败的原因

  1. 基于活动而不是基于特性
    1. 活动不会提前完成
    2. 延误沿着计划表向下传递
    3. 活动不是互相独立的
      基于活动的计划分散了我们对特性的专注，而特性才是衡量客户价值的单元。解决策略：使用 FDD 策略。
  2. 多任务处理导致更多的延迟 - 每个人都达到 100%负荷，这和让高速公路保持 100%负荷结果相同，谁都无法取得任何进展。解决策略：专注 feature，合理估算
  3. 不按优先级开发特性 - 传统计划假设所有任务都会完成，但这样会造成如果无法完成会舍弃一些特性，而这些特性可能会比交付的更有价值。解决策略：明确优先级。
  4. 忽视不确定性 - 最明显的效果就是造成 delay。 解决策略：迭代。
  5. 把估算当作承诺 - 估算只是一个可能性，而对一个可能性做出承诺是不可能的。解决策略：对特性承诺而非时间。

估算大小的策略

故事点的优势

  1. 故事点有助于驱动跨功能行为
  2. 故事点估算不会过期
  3. 故事点是纯粹对大小进行度量
  4. 故事点估算通常更快
  5. 我的理想人天不等于你的理想人天

理想人天

  1. 理想人天在团队以外更容易解释
  2. 理想人天估算更容易开始
  3. 理想人天便于预测速度

使用模糊的故事点产生的不舒服感觉是非常短暂的。
公司让实际人天接近于理想人天的压力会带来负面影响。
使用故事点估算更有说服力。

为价值制定计划

确定优先级因素

  1. 价值
    1. 估算经济回报是一件很困难的工作，常常需要一种替代方案对价值估算 ** 确定渴望度的优先级
  2. 成本
    1. 确定经济优先级
  3. 新知识
    1. 关于产品的知识
    2. 关于技术的知识
  4. 风险
    1. 进度风险
    2. 成本风险
    3. 功能风险

确定渴望度优先级

  1. 客户满意度的 Kano 模型
    1. 作为阈值的特性
    2. 线性特性
    3. 兴奋点和惊喜点
    4. Kano 模型
      5 个度量点:
      我希望这样; 我预期就是这样; 我没有意见; 我可以忍受这样; 我不希望这样;

https://cdn.jsdelivr.net/gh/Gethin1990/PicBed/BlogImg/20210529200313-2021-05-29-20-03-13.png

https://cdn.jsdelivr.net/gh/Gethin1990/PicBed/BlogImg/20210529200338-2021-05-29-20-03-38.png

https://cdn.jsdelivr.net/gh/Gethin1990/PicBed/BlogImg/20210529200359-2021-05-29-20-04-00.png

分解用户故事

用户故事的六个特性 - INVEST

独立性 Independent、可协商性 Negotiable、有价值 Valuable、可以估算 Estimable、短小 Small、可测试性 Testable

  1. 何时分解用户故事
    用户故事太大，不能放进单次迭代的时候
    大型故事分解有助于作出更准确的估算
  2. 按照数据边界分解
    按照用户故事所支持数据的边界来分解大型用户故事
  3. 按照操作边界分解
    CURD
  4. 去除横切考虑
    例如：日志
  5. 忽略满足性能限制
    考虑把功能性和非功能性需求隔离到不同的用户故事，从而分解大型用户故事
  6. 分解具有混合优先级的用户故事
    如果大型用户故事中的小故事具有不同的优先级，则可以对它们进行分解
  7. 不要把故事分解成任务
    不要把大型用户分解成任务，而是寻找一种方法来让一颗曳光弹穿过整个故事
  8. 避免相关变化的诱惑
    避免在具有适当大小的特性中增加相关变化而把事情弄糟，除非这些变化具有相同的优先级
  9. 组合用户故事
    对于2周一次的迭代周期工作的团队来说，合适的做法是把特性分解成 2-5 天的用户故事
    组合小故事

确定经济优先级

  1. 收入来源
    1. 新收入
    2. 增量收入
      促进现有客户购买更多许可
      包含了可以独立出售的可选，附加模块
      包含允许提高收费的功能
      促进对咨询服务的使用
    3. 留存收入
      如果不开发项目或主题，公司会损失的收入
    4. 操作效率
      需要或者在公司成长后需要很长时间的事
      部门之间更好的集成和交流
      减少人员更替
      对新人缩短培训时间
      任何对时间敏感的过程
      综合多个过程
      任何可以提高准确性和减少返工的工作
  2. 经济指标 1 金钱的时间价值 2 净现值 NPV 3 内部收益率 4 投资回收期 5 折现回收期

会议与实战

Product Bocklog Refinement

框架 Skeleton

  1. 展示现阶段以及中期目标
  2. 展示并澄清 Product Backlog
  3. 团队估算 PBI
  4. PO 按照期望团队交付的顺序为 PBI 排序
  5. 分成小组协作对需求建模，切分以及确定验收条件

备忘录 Cheat Sheet

  1. 梳理之前是否与利益相关者一起评估确认远景、目标和 backlog 条目
  2. 团队和主要的利益相关者在场
  3. 会议由 ScurmMaster 或者 PO 引导
  4. 预留 sprint 总时间的 5%-10%梳理 backlog
  5. PO 把远景、目标和整个 backlog 分享给大家
  6. 技术风险是否被确认并创建响应的 spike
  7. Product Backlog 是一个有序列表
  8. 把所有的反馈、变更、缺陷记录到 Product Backlog
  9. 产品 Backlog 包括现景、近景和远景
  10. 团队一起对所有的条目估算
  11. 排列靠前的条目都有验收条件而且有具体实例
  12. 所有不确定的问题被记录下来等待会后继续调研

Sprint Planning

PART I

  • 展示重要的 PBI
  • 澄清 PBI 相关的问题
  • 团队协作梳理新的 PBI
  • 团队按照顺序尝试选择 PBI

PART II

  • 重新调整“完成的定义”
  • 计算团队下个 Sprint 可用时间
  • 团队一起讨论可能的实现方案
  • 团队协作创建任务并估算
  • 根据时间或速率向 PO 做出最终承诺

Spint Review 框架

  • 评估已经完成的 PBI 与承诺的 PBI 和 Sprint 目标
  • 用讲故事的方式演示完成的功能
  • 收集反馈
  • 展示接下来要做的重要 PBI

Sprint Retrospective

  • 安全感 How much will each person participate
  • 发现 Big Picture
  • 分析 Continue; Fix; Stop;
  • 计划 Where dowe want to be? How do we get there from here?
  • 收尾 How to ducument; How to execute;

发布计划策略

  • 确定满意条件，（日期驱动，特性驱动）
  • 估算用户故事，
  • 选择迭代周期长度，（官方建议：2 周迭代，压力分摊，6x2+1）
  • 估算速度，（速度策略）
  • 确定用户故事的优先级，
  • 选择用户故事和发布时间
    • 确定最初 1-3 个迭代的具体工作
    • 卡片记录

迭代计划策略

  • 速度驱动的迭代计划（客观）
    • 调整优先级
    • 确定目标速度
    • 确定迭代目标
    • 选择用户故事
    • 把用户故事分解成任务
      只包含此项目增加价值的工作 - 如“回复邮件 1 小时”。
      尽量明确，直到养成习惯 - 如自动化测试培养。
      会议会占据（很多）时间（整体时间：如开会）。
      缺陷- 发现 bug 的迭代中就修复它们。
      处理依赖性 - 如 mock 数据
      难以分解的工作 - 探针策略
    • 对任务进行估算
      一部分设计就够了
      任务的适合大小
  • 承诺驱动的迭代计划（主观）
    • 要求团队做出承诺(团队主导，承诺特性非任务)“你们可以承诺交付我们已经讨论过的特性么？”
    • 对估算值求和 -实际上大多数团队在计划每天 4-6 个小时的工作量时候能够取得成功
    • 维护与承诺

估算速度策略

如果你在给出对速度的估算前可以进行一次或多测迭代，

有效原因与指导原则

敏捷计划有效原因

  • 经常重新计划
    • 承认不可能建立完美的计划，可以大量减少焦虑，而且可以逐步的消除这种不精确性。
  • 对大小和持续时间的估算时独立的
    • 大小和时间时有关系统的，但很多因素也会影响持续时间。 故事点来估算大小，接下来估算速度，然后规模和速度估算结合起来就可以得到持续时间
  • 在不同层次制定计划
    • 发布计划，迭代计划，每日计划。1.不同的计划是用于不同的目的事实。2.帮助开发团队从不同的角度来看待项目。
  • 基于特性而不是基于任务制定计划
    • 团队可以少做一些关于特定任务的预先考量。让团队思考正在开发的特性。
  • 小故事保持工作流畅
  • 每个迭代都要消除未完成的工作
  • 在团队层次跟踪
    • 不要准备个人燃尽图**而只绘制团队层次的燃尽图
  • 承认不确定性并为之计划

敏捷估算和计划的 12 条指导原则

  1. 让整个团队参与
  2. 在不同层次上进行计划
  3. 使用不同度量单位，让对大小和持续时间的估算保持独立
  4. 用功能或者日期来体现不确定性
  5. 经常重新计划
  6. 跟踪进度并沟通
  7. 承认学习的重要性
  8. 计划具有适当大小的特性
  9. 确定特性优先级
  10. 最好的估算和计划来源于事实
  11. 保留一些松弛度
  12. 通过前瞻性计划协调多个团队
- 完 -
「 感谢支持 」
更新于 2022-05-01
 scrum, 软件工程
返回 | 主页