Scrum敏捷转型指南学习

Scrum概述介绍 – 新产品从无有

Scrum(不仅仅适用于软件开发)是一种用于开发创新产品和服务的敏捷方式(思路)：

1. 首先建立产品列表：一个按优先级排列的、成功开发产品所需的特性及其他功能的列表，不仅仅是需求方面的，任何影响到产品交付的风险项是不是都应该考虑进去？？
2. 制定里程碑：将整体的产品拆分成小的模块，分而治之
3. 制定迭代计划：在每个迭代中，明确必需要完成(设计、构建、测试)、迭代结束可用于验收的工作。每个迭代能够自组织
4. 迭代评审(迭代总结)：团队与利益干系人一起评审已经完成的特性。团队总结迭代中遇见的问题，协调团队的工作方式，利益干系人识别完成的产品特性是否满足要求，可以对产品列表进行调整：需求是可发生变更的。
5. 迭代实现目标：在每个迭代结束时，团队应当得到一个潜在的可发布的产品，如果业务上合适，就可以发布，如果不合适，可以把多个迭代的一组特性合并在一起发布。

分析影响项目进度：业务逻辑难、评审不及时、业务变更频繁等等

高质量交付的因素：表数据存储情况(表主键没定义)、需求理解有偏差、单元测试不够，

 

Cynefin框架 – 工作类型

将工作的类型分为5个域，每个域中有对应的解决方法。

复杂域

存在不可预测性的一些问题。这些问题如果有正确答案，我们可能也只是事后知道。在复杂域工作时，需要采用创造性的，创新的方法，需要为试验活动建立一个容忍失败的环境。在这个环境中，探索、感知、响应的能力非常重要

繁杂域 – 实践域

一些问题做起来困难，但是能够找到一些解决方案，可能需要专家根据实际经验找出这些答案，比如：性能优化，参数调优

简单域

简单问题的正确答案是显而易见的。

混乱域

快速做出响应，立即采取行动

无序域

不知道当前所处的是哪个域

看板 – 流程的把控

看板与scrum一样，都是敏捷开发的方法。看板适用于流程反复无常，常常被打断等工作场景。看板提倡以下要素：

1. 做记录，让工作流程可视化
2. 限制每一步的WIP(进行中的工作)数量，确保所做的工作不超出自己(团队)的容量
3. 度量并优化工作流程，实现持续改进

Scrum框架52

Scrum是一个用于组织和管理工作的框架。在这个框架的基础上，各个组织可以添加相关工程实践特有的实现方式以及在实现Scrum实践时所采取的特定方法。

随着冲刺过程中了解的信息越多，估算可能会发生变化。让团队做出承诺会导致团队为实现承诺而牺牲质量。

 

 

产品列表(PBI)-》冲刺规划-》冲刺列表(拆分的任务)，冲刺执行(每日站会)

 

产品列表 –》 冲刺规划  -》 冲刺列表   -》 任务列表

每日站会

牢记三个问题：

1. 昨天完成了什么
2. 今天计划做什么
3. 有什么障碍让工作无法取得进展或进展慢，或进展困难

每日站立会是必不可少的，通过检视与调整，能够帮助团队建立一个快速、灵活的工作流。

冲刺回顾

在冲刺回顾活动结束时，找出数量适中的过程改进项并承诺在下一个冲刺中采用：团队有个磨合期，前期会遇见一些问题，通过检视与调整，重新梳理工作流，抽出一些行动项

敏捷核心原则70

 

 

与传统计划驱动的对比

传统的计划驱动开发常常称为“瀑布开发”，也称为顺序式开发，按照需求、设计、编码、测试、运行，固定过程执行。计划驱动要求需求前后不会发生大的变更，前期设计也要做的尽可能可扩展。计划驱动要求定义良好的过程和检查点。

Scrum能很好地处理高不确定性而导致的很难做出宏观预测。

计划驱动倾向于将相同的工作类型放到同一个阶段执行(整体推进)，像需求调研阶段、设计阶段、开发阶段。Scrum是在一个迭代中包含了设计、开发、测试等。Scrum的一个迭代周期时间范围是1到4周。

Scrum包含的原则：

1. 产品开发固有的可变性和不确定性的相关原则
2. 平衡预测和适时调整之间的关系
3. 认知原则和半成品的管理原则
4. 进度和性能的相关原则

可变性和不确定性72

采用迭代和增量开发

迭代是分周期性，增量是逐步构建。迭代+增量=冲刺。每个冲刺都包含分析、设计、构建、集成和测试。这种模式又被称为蜂拥式开发。每个冲刺能够与前期已开发的特性进行集成与测试，否则就不能认为完成。

 

通过检视调整和透明充分利用可变性

Scrum认为只要是构建新东西，就必然存在一定的可变性，产品创建过程很复杂，无法事先给出详尽、严密的完整定义。

同时减少各种各样的不确定因素 – 迭代总结

1. 结果不确定性 – 需求不确定性
2. 方法不确定性 – 开发过程和技术的不确定性

通过迭代开发和增量开发，经常性的检视、调整规则的指导下，可以同时解决多种类型的不确定性。

预测和适应

 

不到最后时刻，不轻易做决定

当不做决定的成本大于做决定的成本(设计、开发时间成本)时，就要做决定了。当了解到更多的信息，做出的决策菜会更明智，而且决策成本也会很低

偏好适应性、探索式的方法

试错。探索指的是通过某些活动来获得知识，例如构建原型。

进度

通过验证工作结果来度量进度。

在scrum中，重要的不是开始了多少工作而是完成了多少对客户有价值的工作

在scrum中，质量并不是测试团队在最后阶段测出来的，而是保证在每个迭代中，哪怕是在最后把系统提交到测试中心，自己又自测了一遍。

最小够用满足工作可以开展

 

计划驱动重文档，可追溯

计划驱动原则与敏捷原则比较103

 

 

 

 

计划驱动原则：以过程为中心，定义出良好的过程和检查点(多维度定义：变更项记录创建任务、延期风险项记录、问题记录形成检查单)，在一开始就消除了结果的不确定性，再消除方法的不确定性，承认第一次就做对，如果第一次做不对，按照规定的先后顺序，偏差会越来越大

敏捷原则：以价值为中心，承认第一次就做不好，承认不确定性因素的存在，例如变更。通过探索式、试错式方式，发起迭代，快速反馈，对假设快速验证。

冲刺106

 

完成的定义

时长限定

时间盒

 

已经满足要求的时候还要镀金

持续期短

 

完成的定义

 

需求与用户故事93

用户故事描述了scrum在需求处理方式上与计划驱动的不同。Scrum以用户故事的方式创建占位符，明显侧重于对话沟通明确需求细节。

需求

在scrum中，需求细节是在开发期间持续不断的对话中商讨出来的。

通过业务人员或看需求文档，要求开发人员梳理出业务逻辑处理，或xmind功能图，把业务需求说明白

用户故事

用户故事包含：卡片(card) – 提醒、会话(conversation) – 探讨、确认(confirmation) – 验收，简称3C。一个功能模块(特性)可以理解成是一个用户故事。要求用户故事间松散耦合，相互独立，依赖程度不高，这样便于优先级排序。

卡片

 

卡片不是为说明需求的所有组成信息而设的。它存在的意义是提醒利益干系人、产品负责人及开发团队进行更深入的讨论。卡片可以看成是一个引子

会话

在卡片的基础上，探讨需求、设计、构建、测试等的细节。

确认

验收的标准，达到的满意程度

详细程度

 

用户故事的详细程度要有大小。用户故事类型有：史诗级故事、特性故事、冲刺迭代故事、非功能性需求故事(技术故事)、知识获取型故事。

史诗级 – 篇章

跨越一整个或多个版本，能够为概要产品规划和发布规划提供支持。史诗下包含更详细的用户故事。史诗是一个很好的占位符，等将来到合适的时间再创建大量更加详细的故事。

好故事的INVEST原则

评定故事写得好的6大标准INVEST：独立、可协商、有价值、可估算、小、可测试.

独立

用户故事间松散耦合，相互依赖程度不高，便于优先级排序

可协商

故事细节应该是可协商的，不应      该是以需求文档的形式写死的。

写死的坏处：出现问题会相互指责，彼此推卸 – 协商不够，双方都有责任。

       开发人员：如果你想要，就该把它写到文档里

       业务人员：你明显没有理解需求文档

      

有价值

开展这一块的用户故事，要明确它的意义有哪些，有哪些价值

可估算

估算指明故事的大小，因此也指明故事的工作量和成本

小

用户故事是放到冲刺中执行的，要求要做的故事应该大小合适的。

可测试

可测试意味着故事要有相应的优质接收标准。

非功能性需求

作为系统级约束，像指定的浏览器型号

收集故事

收集故事有两种方式：用户故事研讨会、绘制故事地图

用户故事研讨会

组织大家集体进行头脑风暴，讨论预期的业务价值，可以自上而下讨论(从史诗级往下讨论)，也可以自下而上讨论(想要的系统功能有哪些)

绘制故事地图

其基本思想是将概要性用户活动分解为工作流，工作流还可以继续分解成一套明确的任务。

 

产品列表-核心117

产品列表是一个按优先级顺序排列的、预期产品功能列表，可以看成是功能模块列表，也可以看成是用户故事列表。大多数PBI都是以故事点或理想天数来估算的。

 

 

产品列表的4大特征-DEEP

好的产品列表都表现出相似的特征：详略得当、涌现的、做过估算的、排列好先后顺序的。

详略得当

 

涌现的 – 新的需求，产品列表重排序

只要系统还在用，产品列表就永远不会完成或冻结。

做过估算的

每个PBI大有大小估算，相当于开发这个条目需要完成多少工作。

排列好先后顺序的

梳理

梳理指三大重要的活动：确立并细化PBI；对PBI进行估算；为PBI排列优先排序

增删改查：

改：细化、估算、排序

 

工作流管理

版本工作流规划了版本要做的特性有哪些，冲刺工作流细化了特性

版本工作流管理

产品列表的梳理活动必须支持版本规划活动。

 

冲刺工作流管理

细化要做的的产品列表，并将产品列表放到冲刺中实现。

 

当一个冲刺正在执行时，有两三个准备好的冲刺故事已放到管道中。项目迭代不能停止下来

大型产品，层级化列表

将产品列表按照领域拆分成领域列表，交由领域团队在进行拆分，例如电商系统，拆分成用户、支付等领域。

 

三层企业列表模型

组合列表(包含史诗)、程序列表(包含特性)和团队列表(包含可以放入冲刺的用户故事)

多个团队，一个产品列表

每个团队需要自己特有的列表

一个团队，多个产品

估算与速率139

估算的条目、何时估算、如何估算、估算单位、规划扑克

速率概念、速率范围、预测速率

技术债163

产品负责人226

开发团队262

变更的影响

变更会影响之前的工作努力白费，而且还可能损害团队的士气和信任关系。针对变更，产品负责人与团队进行一次坦诚的、关注影响性分析的讨论，并做记录变更，识别出哪些变更项可以必须做，哪些变更项可以延期做。

检查单形成

计划驱动消除了不确定性，一切都是按照事先规划好的过程进行，所以注重文档输出，可以追溯，注重检查单。

梳理出检查单，就要能够识别出问题有哪些，注重问题记录

检查单多维度记录：需求变更(内部、外部)、代码规范检查单、安装部署检查单、重点测试项检查单

自动化测试

当开发团队积累巨量手工测试用例时，可以考虑采用自动化测试。

 

 

 

团队建设

团队管理问题是个繁杂类型的问题，各个团队组织应该根据自己的实际情况，制定符合自己团队管理的实现方式及特有方法。

团队价值观

团队工作氛围

1. 团队整体工作氛围要求积极主动、乐观向上
2. 但是团队间个人间冲突造成的负面情绪很容易传染给团队的每一个人：团队间工作是相互协助的，当成员A与成员B工作需要相互配合时，成员A对工作产生消极态度，成员B就会受到影响，与成员B相互配合工作的成员C就会受到成员B的影响，以此类推，严重时团队所有成员都会产生负面情绪。
   1. 案例一：需求人员与开发人员：需求人员在写某一块需求时，只阐述了正常业务处理过程，对异常处理过程没写或写的有歧义。开发人员找需求人员要求把这一块的需求表达清楚，需求人员认为自己写的没问题，并拿语言挤兑(冲突升级)开发人员说：没见过你这样的开发人员，让其他开发人员一看就明白是什么意思。后来开发人员拿着写的需求找QA评审，QA认定这块需求对异常业务处理过程没写清楚。
   2. 案例二：需求人员与开发人员：开发人员按照前期梳理的需求完成的开发，不存在功能性问题，能正常运行，但是运行结果与预期结果不符，业务处理过程不对。需求人员说这块业务处理过程给开发人员说过，开发人员说这块是需求变更，相互指责。在顺序开发过程中，这类问题经常碰到。
   3. 案例三：开发人员与开发人员。团队成员A和团队成员B都有着自己的软件开发工作且开发时间紧，同时两个人共同负责成员C系统测试环境运维工作。成员A或B其中有一个人对运维工作有推脱，另外一个人肯定也会去推脱，如果系统测试进行不下去或者很难进行，最后成员A、B、C肯定会相互指责
3. 团队最终的工作氛围目标：人人都把自己当成项目经理，都有着很强的团队荣誉感

团队工作流程

团队计划由团队成员个人活动组成。当出现问题时，项目负责人第一时间不应该是去追究责任，因为大家是一个团队，出了问题，在其他人看来是这个团队出了问题，不会是具体的某个人的问题。所以项目负责人第一时间应该组织大家去排查问题原因，找到问题原因，并落实到以后的工作流程中，如果团队中因为该问题出现相互指责等负面情绪，应积极的引导大家到心平气和解决问题的轨道上来。工作要做到细