scrum敏捷项目管理 读书笔记

简介

相关概念

预定义过程控制：造车等按定义好的过程实施，可重复执行的过程，适用于机制简单易懂的情况

经验性过程控制：复杂度超出预定义过程的能力范围

• 可见性，过程中对结果有影响的方面必须清晰可见
• 检查，过程中的各方面必须被频繁检查
• 适应，对检查中发现的过程做出修改和优化

软件开发项目：运用先进且不断发展变化的技术解决商业问题，获得竞争优势

scrum简介

scrum使用经验方法（或有时称为经验主义）以适应客户不断变化的需求。经验主义是根据实际经历的内容做出决策的行为。经验方法意味着以事实为基础，以经验为基础，以证据为基础的方式开展工作，特别是，进展是基于对现实的观察，而不是基于大量前期要求的虚构计划。

产品backlog是敏捷开发中用来管理需求列表，排定优先级，形成迭代计划，组织开发/测试和交付过程的工具。可以说，产品backlog是一个敏捷团队管理开发过程的核心，所有的活动和交付物都围绕backlog来进行。

scrum方法的骨架：迭代（产品backlog–>可交付的功能增量)。

经验主义和三大支柱不仅对scrum过程很重要，它们也是scrum的基础。这是您的团队在您创建的产品和您为团队使用的流程中实现持续改进的方式。角色，事件和工件只有在遵守基于价值的渐进式改进的情况下才能发挥作用，这些改进是通过接受频繁的反馈和接受变革而产生通常学习和改进过去的错误和经验，不断完善流程，提高持续交付能力。

scrum支持经验过程控制的每一个实施的三大支柱是：透明度，检查和适应性，如下图所示：

• 透明度

  • scrum中的透明度可以通过scrum工具实现，例如产品backlog，任务板和Burndown图表，每日站立，回顾，完成定义，sprint评论等。这些工具用于通过跨职能团队转移工作流程。这是scrum的关键优势之一
  • 允许关于工作和团队进度的可见性。这意味着当团队实现其目标时，负责该目标的人员可以得到认可和赞赏

• 检查

  必须经常检查scrum工件并朝着目标前进，以检测不希望的差异。scrum中的检查可以通过scrum活动来实现，例如：

• 使用通用的scrum板和其他信息来清除每个人的项目当前状态
• 在开发史诗期间收集客户和其他利益相关者的反馈
• 创建优先产品backlog，并执行发布计划流程
• 产品负责人检查和批准交付物

• 演示和验证sprint流程中的客户

• 适应

  在敏捷世界中，我们始终拥抱和适应变化，以便我们不断改进。适应意味着我们改变不起作用的东西或者更好的作用。这意味着我们不断进行小型实验，保持正常工作，并在失败时进行改变。我们使用检查结果来决定接下来要运行的实验，例如：

• 开发团队，每日站立仪式期间每天检查和调整
• sprint Review是另一个仪式，scrum团队将要求所有股东提供反馈并相应调整

• 在sprint Retrospective期间，scrum团队在内部讨论问题和改进机会。将作为一个团队准备和调整新计划，以产生更多价值

  在scrum中，决策是基于观察和实验而不是基于详细的前期规划。经验过程控制依赖于透明度，检查和适应性这三个主要思想。这意味着项目成果应该：

• 向负责结果的人员了解流程的重要方面
• 及时检查sprint目标的进度，以检测不良差异
• 尽快调整流程，以尽量减少任何进一步的偏差或问题

scrum角色

product owner、scrum master、开发团队

1 产品经理product owner

• 负责制定backlog，并设定优先级
• 对外担任开发商的角色，对内担任客户的角色
• 不能与团队中的开发人员有直接的上下级关系

2 scrum master

• 管理scrum进度和流程，上下沟通
• 对PO担任team的角色，对team担任PO的角色，排除PO和team之间的障碍，确保PO直接推进开发工作
• 不能与team中的开发人员有直接的上下级关系
• 是一个没有权力的领导者
• 适时引入变革，有策略，千方百计提升开发团队的生产力
• 改善工程实践和工具、确保每个功能增量具备潜在可交付性
• 向各方确保团队工作进展实时更新并高度可视

3 开发团队

• 所有的开发、测试人员，负责规划每个sprint的工作量

scrum流程

一个scrum的标准流程为：收集backlog -> 挑选backlog到sprint中 -> 执行sprint -> 交付、验收sprint成果 -> 总结sprint

![png](https://xueyp.github.io/assets/images/my/20191226_02.png)

1 收集backlog

• 执行者：产品经理

• 任务：收集backlog、制定优先级

  这个阶段是只有产品经理参与的，产品经理根据市场需求、产品定位等汇总出本次项目的所有待办事项，并将每个待办事项制定相应的优先级。

2 选取backlog中的事项加入到sprint中

• 执行者：开发团队
• 参与者：scrum master

• 任务：按照优先级挑选待办事项到下一次的迭代中

  需要注意的是开发团队在挑选的时候根据开发的人力资源来选择挑选的数量，但是必须按照优先级从高到底的顺序来挑选。

3 开始执行sprint

• 执行者：开发团队
• 参与者：scrum master

• 任务：完成本次迭代的所有待办事项

  一个sprint即是一次迭代，往往设置为一周到两周，一个标准的sprint包含以下几个环节，站立会议要求每日都要举行，之后要及时更新任务版、燃尽图。

  

4 交付、验收sprint

• 执行者：开发团队
• 参与者：产品经理、scrum master
• 任务：交付最终产品给产品经理验收

5 总结sprint

• 执行者：scrum master

• 参与者：开发团队、产品经理 - 任务：总结本次sprint什么做得好、什么做的不好、后续应该怎么做

  需要注意的是只有sprint的总结大会是归属于scrum master负责的，其他环节他只作为一个指导而存在。

6 资料

scrum整个过程中产出的资料主要有：

• backlog：待办项列表
• 燃尽图：横坐标为时间轴，纵坐标为工作，理想情况下该图应为向下的曲线直到零
• 任务版：纵坐标为任务，横坐标为任务所处的状态（待办、在做、待验证、完成）

scrum角色准则

product owner

• sprint评审会议上展示的产品增量必须是可立即实施的

scrum master

• 从传统项目管理的控制者转为为引导者和教练，scrum master是领路人，而不是管理者
• 保护团队的sprint过程免受干预

  开发团队

• 交付的产品增量必须是完成了开发、测试等工作，具备即时实施能力的功能-生鱼片规则

  scrum简会

• 自上次scrum简会后的一天里我做了什么？
• 从现在到下次scrum简会的一天里我准备做什么？
• 工作中遇到了哪些障碍？

sprint计划会议

• 项目投资人希望项目结束时达成哪些成果？
• 每个sprint应做出哪些进展？
• 如何使项目投资人相信该项目是有价值的投资，以及项目申报者有能力交付预期收益？

sprint评审会议

• 每次评审会议都将呈现预估与现实、团队期望完成与实际完成任务间的差异

Scrum任务量估算

任务计划和评估对于按照优先产品Backlog中指定的要求迭代开发产品至关重要。Scrum团队在任务评估会议中估算完成任务列表中每项任务所需的工作量。此过程的结果是Effort Estimated Task List。

Scrum团队使用Task列表，这是一个包含团队为当前Sprint提交的所有任务的综合列表，用于开发Effort Estimated Task List。

任务列表必须包括任何测试和集成工作，以便Sprint的产品增量可以成功地集成到之前Sprint的可交付成果中。尽管任务通常基于活动，但任务被分解的粒度级别由Scrum团队决定。

Scrum团队在Sprint计划会议期间使用此Effort Estimated Task List创建Sprint Backlog和Sprint Burndown Chart。

进行计划扑克的步骤

• 1.每个团队成员获得一组卡片，包括0,0.5,1,2,3,5,8,13,20,40，？，∞，共12张牌。
• 2.该产品所有者描述要素的团队。
• 3.团队成员讨论该功能，并在需要时询问产品所有者问题。
• 4.当成员完成讨论后，他们每个成员选择一张扑克牌来代表估计。然后同时显示卡片。
• 5.如果团队评估不同的估计。我们同意吗？我们有差异吗？有什么我没考虑过的吗？那些选择最高或最低价值的人应该在每个成员选择另一张扑克牌之前与小组分享他们的推理。
• 6.讨论结束后，您可以估算另一轮，团队需要达成协议。
• 7.返回第二步并开始估计下一个条目。

注意事项：

• 估计大小，而不是估计时间段，使用相对估计而不是绝对估计
• 估计速度 - 记录和平均每个Sprint的团队速度

工作量估计

好的工作量评估，必须建立在对当前参与项目的实际情况有全面了解、有足够清晰的看法的基础之上。评估的结果必须成为整个项目可控的基础，可以给项目负责人（在我们公司通常是项目经理或者产品经理——偶们的产品经理们通常一定程度上兼职了一些项目经理的职责）制定合理的计划提供可靠的依据。

工作量高估的代价却是线性的可控的,低估的代价是非线性的不可控的。由于低估带来的计划延期等问题在管理规范的团队里面需要进行延期原因分析、影响评估、计划变更评审等等相关工作，这些工作所需要代价叠加起来往往是非线性增长的。所以不要有目的的去低估，更不要盲目的乐观！低估的代价比高估的代价更高。

工作量评估不准确的原因：

• 低估
• 拍脑袋
• 遗漏工作

正确的评估工作量方法：先做好充分的工作量分解，在不遗漏工作的前提下，对每个分解出来的子任务合理评估工作量。所谓的合理评估量就是不拍脑袋，不刻意低估也不刻意高估。

1 工作分解

WBS工作分解结构

分解出来的工作包应该是名词，不是动词。还需要识别和定义为实现工作包而进行的活动，活动不是WBS的组成部分，活动输出的是活动本身，而不是工作包中定义的交付成果。

2 活动清单

• 包含项目所有活动
• 包含每个活动的标识和工作范伟描述

• 使团队和自己清楚具体需要完成什么工作

  活动有三种主要类型，除了独立型活动，往往还有许多相关的依赖型活动、支持型活动

3 工作量估算方法

• 类比估算：参照过去类似项目的工作量估算。成本低，速度快，准确度低
• 参数估算：基于历史数据和项目参数，如单价、单位时间的工作量等。 评估的准确性取决于参数模型的成熟度和基础数据的可靠性。 通常适用于重复性工作
• 三点估算：最悲观、最乐观、最可能三种情况给出的评估值。结果符合统计学规律，推荐使用
• 储备分析：应急储备和管理储备，主要是项目管理者应该主要关心的，直接一点说就是预留一些缓冲时间（不单要考虑工作量，还要考虑成本等更综合的因素。不单是有时间的储备，还可能有人力的储备、资金的储备等）
  • 已知-已知风险：可以预测的异常情况，同时也能预测这种情况发生的概率，且一旦它发生会对工作计划产生多大的影响
  • 已知-未知风险：可以预测到的异常情况，但是不知道他发生的概率到底有多大，也不能预测它如果真的发生了，会对工作进度产生多大的影响。
  • 未知-未知风险：完全未知的风险，基本上是想都没想到，以前的项目经验当中也没有发生过的异常事件，更无法预测它一旦发生会对工作进度产生什么样的影响

  

  • 功能点估算法

    WBS分解将项目先按大的模块拆分、再逐层细分。理论上，拆分的粒度越小越好，但考虑到工期问题，通常我们能拆分到某支具备独立功能的交易就可以了。基于WBS，我们评估通过定义每个功能的输入有多少字段、输出有多少字段、用到多少张数据表、用到什么文件等，定义项目的复杂系数，然后可以自动计算出项目的最少工作量、推荐工作量和最多工作量。最后项目经理采用的工作量只要在区间范围内即可。   该方法操作起来较为简单，也方便高层领导验证，防止虚报；方法基于组织的历史经验数据建模，可持续改进优化。要用好功能点估算法，需要做到以下几点：

  • 项目类型划分。通常可分为新建类、升级改造类，不同类型也对应不同的复杂系数。
  • 功能拆分尽可能细。可下探到交易、函数、数据表、文件。从这个角度讲，有点像自下而上估算法。
  • 功能分类，初始化复杂系数。将功能分为查询交易、维护类交易、新增类交易、删除类交易、新增数据表、修改数据表、文件上传、文件下载等等，并为每类功能定义初始的复杂系数（这个靠专家判断了）。
  • 建立与需求跟踪矩阵的关联。防止为了凑工作量瞎编功能。

5 德尔菲法

  项目经理在拿到需求后，经过需求分析，列出需求涉及到的功能(WBS分解)。评估每一个需求条目的工作量，首先每位评估人背靠背根据自己的经验判断完成每个需求条目所需的工作量，并提交到系统；然后系统针对每个需求条目对应的工作量加总取平均，然后将每位评估人评估的工作量与平均值比较，任一需求条目的偏差超过阈值（比如10%），则视为不通过，需要重新评估；如此反复，直到偏差在10%以内。

德尔菲法具有以下特点：
- 反馈性：表现在多次作业，即在偏差超过阈值时反复修订与评定。
- 独立性：参与评估的专家之间独立评估，不商量、不讨论，只通过他们头脑中的数据资料和经验，经过分析，判断和计算，确定出理想的结果。
- 统计性：对各位专家提出的意见进行统计，再取平均数或是中位数统计出量化结果。

充分的工作分解、科学理性的任务评估再加上合理的储备分析，最后的出来的一个总的工作量评估会是一个相对合理、可靠的结果。在此基础上制定的工作计划更加合理可控。每经历一个项目，做项目总结时候都有必要有针对性的做一些相关的经验教训总结，提炼一些关键数据沉淀下来供团队后续的项目来做参考。越成熟的团队，工作量评估工作做的越好，并且因此对项目的把控能力也会越来越强。

参考

版权声明：本文为博主原创文章，转载请注明出处。 旭日酒馆

• 读书笔记 (61)

• 读书笔记 (61)