这是 Wonz 记录的 第 7 篇 笔记

课程：《敏捷实践》

来源：公司内部培训

一、为什么敏捷，敏捷是什么？探秘业务可持续交付的密码

1. 软件开发的发展过程

更规范 -> 更灵活

软件开发是探索的过程、知识发现的过程。

2. 核心价值观

1) 价值驱动

关注高优先级目标，尽早开始，要事第一。

用最小的资源创造最大的价值。

一分钟总结：高优先级、尽早开始、价值优先、成果导向。

2) 适应变化

频繁的交付可见成果，目的是验证我们对市场和需求的认知，确保交付正确的成果，同时获取反馈进行快速调整。

敏捷方法关注持续交付可见的正确成果。

增量
Scrum方法：迭代开发、增量交付、持续的检查和调整
1-2周一个迭代，每个迭代长度为固定的时间盒

频繁的交付可见的成果进行验证，及时进行调整。

3) 自组织

目标驱动、共享责任。

管理层微观管理成为瓶颈，团队等待指令，反馈慢；自组织的团队反馈更快、效率更高。

授权、支持、引导、反馈。

管理层关注打造团队、引导团队实现目标。

4) 技术卓越

XP（极限编程）

追求技术卓越，简化不必要的工作提升敏捷力。

3. 敏捷宣言

1) 个体互动胜于流程和工具

以人为本，人是获得成功的最为重要的因素
沟通及互动是催化剂、黏合剂，推动项目走向成功
适当的使用流程和工具有助项目成功，反之有助项目失败

2) 工作的软件胜于详尽的文档

“工作的软件”是指能够帮助客户解决问题，为客户带来价值
文档要适用，力求少而精，过渡的文档输出并不会为客户带来价值

3) 客户合作胜于合同谈判

客户价值为先，体现共赢
客户深度参与，频繁交互，应对不确定的变化

4) 响应变化胜于遵循计划

在敏捷中，项目应该从始至终地拥抱变化
敏捷需要有计划，但不是完全拘泥于计划，进行控制管理
随时响应变化的能力常常决定着一个软件项目的成败

4. 敏捷十二原则

价值优先：我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

拥抱变化：即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

经常交付：经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。

业务参与：在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

以人为本：围绕被激励起来的人个来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。

直面沟通：在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。

成果导向：工作的软件是首要进度度量标准。

持续交付：敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

追求卓越：不断地关注优秀的技能和好的设计会增强敏捷能力。

精益求精：以简洁为本，它是极力减少不必要工作量的艺术。

团队自组织：最好的构架、需求和设计出自与自组织的团队。

持续改进：每隔一定时间，团队会回顾如何才能更有效地工作，然后相应地对自己的行为进行调整。

5. 敏捷金字塔

价值：敏捷宣言、核心价值观

原则：敏捷十二原则

方法：Scrum、DSDM、Crystal、FDD、Kanban、XP

实践：站会、计划、回顾、价值流动、重构、WIP、结对、测试、持续集成

二、需求拆分及估算，降低开发风险，制定合理计划

1. 什么是需求

用户—需求—解决方案—达成共识

2. 需求拆分的原因及方法

收益

降低复杂度，拆分后易于分析需求，识别问题
频繁交付，及时反馈质量
价值驱动、优先级排序
建立共识，促进协作

原则

独立，避免需求耦合
对用户有价值的，避免接口需求，界面需求
小的，避免开发测试完成超过3天
可测试

方法

业务流程拆分法
业务操作拆分法（CRUD）
业务规则拆分法
数据多样性拆分法
展示展示拆分法
大头工作拆分法
简单/复杂拆分法
延迟性能拆分法
探索性研究拆分法

3. 需求估算的原因及方法

收益

计算成本、周期
了解投资回报
做计划
团队对齐需求，发现并排除坑

4. 团队速率

团队速率是一个团队在一个周期（Sprint、周）中实际完成的点数。

通过团队速率可以知道团队做的有多快。

计算速率

记录每个Sprint/周的速率，得到平均值。

三、敏捷团队及环境，构建实施敏捷的组织结构和文化

1. 高效团队的特征

高度信任
统一目标
清晰角色
牢固的关系
共享领导力
卓越的沟通
有效的过程
持续进化
伟大的成果

2. 敏捷团队及环境

三个角色

Product Owner 产品负责人

拥有一个可行的、充满吸引力的产品远景，能激发团队、公司及客户的激情；
构建一个路线图来实现这个愿景，让每个人都看见并遵守；
构建一个价值驱动、持续完善的需求清单；
花一半时间与客户，销售员，市场部门在一起；
花一半时间与开发团队在一起告诉他们正确的需求。

Scrum Master

保护团队正确的运用敏捷实践；
保证团队良好协作、自组织、工作高效；
协调和组织会议；
与所有角色协同工作、移除障碍；
管理团队内外的依赖；
支持团队、作为团队和外部的接口，屏蔽外界对团队的干扰。

Developer Team 研发团队

帮助产品负责人完善需求（解决方案）；
需求研发及商业发布（开发的是功能而不是BUG）；
持续改进团队，流程、协作、工程实践等能力。

特性团队

团队内可以做到端到端，所以减少了等待，周期加快
比较容易快速交付可用的产品增量
减少了团队之间依赖，计划会更容易
责任范围的扩大，各种不同领域的专家在一个团队，增加了个人学习和团队学习的机会

3. 构建高效团队文化

自组织团队

团队决定谁做什么，即任务的分配
团队决定如何做，如何实现目标，即团队做技术决策
团队需要在确保目标的前提下制定团队内的行为准则
团队有义务保持过程的透明性
管理层和团队教练通过引导的管理方式给出指导思路，帮助团队向正确的方向前进
管理层不直接决定团队内的工作分配

四、固态项目交付深度解密，迭代+增量式交付的核心框架，打造有节奏有目标感的团队

1. 什么是Scrum

Scrum 是一个用于开发和维护复杂产品的框架，是一个增量的、迭代的开发过程，专注于最短的时间内交付最高的商业价值。

2. 三个角色和三个物件

三个角色

Product Owner
Scrum Master
Developer Team

三个物件

Product Backlog
Sprint Backlog
Increment

3. 五个价值观和五个活动

五个价值观

Courage（勇气）
Openness（透明）
Focus（专注）
Commitment（承诺）
Respect（尊重）

五个活动

Product Backlog Refinement（需求梳理）
Sprint Planning
Daily Scrum
Sprint Review/Show Case
Sprint Retrospective

4. 应用及扩展

Sprint 日历
规模化Scrum

五、敏态项目交付深度解密，破解软件研发7种浪费，利用精益思想追逐高效率交付

1. 精益思想

精益的诞生

科学管理原理
大规模生产
丰田生产方式
戴明14点

精益思想5大原则

价值：价值只能由最终客户来确定，任何不为客户增值的活动都是浪费。
价值流：使承载客户价值的产品或服务从概念到发布，或从下单到交付给客户的所有步骤构成的过程。
流动：让承诺客户价值的需求顺畅流动起来。
拉动：客户拉动生产、下游拉动上游。
尽善尽美：持续改善要求每一位管理人员及作业人员，要以相对较少的费用来连接不断地改进工作。

映射价值流

团队的价值流应由团队成员共同识别并达成共识。

价值流映射5步法

第1步：分析工作项的类型
第2步：列出工作项从诞生到交付给客户或用户的整个过程中都经过的哪些环节
第3步：分析哪些环节是增值环节，哪些是不增值环节
第4步：估算每个环节的耗时
第5步：团队共同讨论，如何去除不增值的环节，或者缩短不增值的时间

2. 精益看板

什么是看板

可视化管理
增进共识
任务清晰
高效协同
职责共享

总结：看板 = 可视化 + 拉动

可视化管理与拉动系统

可视化管理

将工作管理所需要的任何信息可视化在团队的工作区域，让每个人可见，使团队的工作流程更加直观，有效表达团队内部的信息，从而实现管理上的透明化。

拉动系统

在制品少：未完成的需求在研发管理数量很少，完成一个需求再从队列中拉入一个需求；
风险低：并行处理的需求少，当交付截止日期临近，可以集中精力交付正在研发管道中的需求，从而延期风险可控；
浪费低：一旦市场或客户的需求有变化导致大量需求作废，由于只有少量需求正在研发管道，浪费成本较低；
交付时间短：团队同时处理的需求量与团队的产能匹配，不会因为人力不够而停滞流动，因而交付周期短。

看板6大实践

可视化
限制在制品数量
管理价值流（也叫工作流）
显示化定义工作流转规则
构建反馈环
协作式改进, 试验中演进（使用模型和科学方法）

六、敏捷团队如何开展测试？存在哪些挑战？

1. 传统测试在敏捷环境面临的挑战

时间短
变更频繁
文档较少
资源不足

2. 什么是敏捷测试？

敏捷测试是一套遵循敏捷软件开发原则的软件测试实践，敏捷开发将测试集成到开发过程中，而不是将其作为单独的阶段。因此，测试是核心软件开发的一个组织部分，并积极参与软件开发过程。

3. 敏捷测试与传统测试的异同

传统测试	敏捷测试
测试发生在最后阶段	测试发生在开发过程中
团队之间正式沟通更多	团队之间沟通面对面非正式活动更多
自动化测试是可选的	自动化测试被高度推荐
从需求角度测试	从用户角度测试
详细的测试计划	精益的测试计划
计划是一次性活动	不同级别的计划
项目经理为团队做计划	团队被授权并参与计划
繁重的需求说明文档	较轻的需求说明文档

4. 敏捷交付下的测试策略

“质量左移”测试策略作为敏捷开发交付的核心理念之一贯穿到整个软件生命周期交付中。