在这里插入图片描述

概述

为了帮助大家理解,我尝试从软件开发实践和管理体系两个维度去解释。先列举一下核心实践,然后从软件开发的几条管理主线帮助大家串联一下这台看似松散,实则精密的机器。这里要再次提醒大家我们讨论的范围仅仅是开发段,所列实践也不会特别关注团队文化建设。

敏捷是什么?

Resolve complexity and uncertainty with continuous and fast feedback to create ability responding to changes with low cost, so that achieve better effect
利用持续、快速反馈来破解复杂性和不确定性,建立用较低成本来响应变化的能力,从而达到更好的效果
4条敏捷宣言和12敏捷原则给出了更为具体的解释。
 

什么是Scrum

Scrum是基于试验性过程(经验主义)的框架,用来解决不确定问题和维护复杂产品。试验性过程的三个支柱分别是Transparency 透明、Inspection 检验、Adaptation 适应。
Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time……It is iterative and incremental…… (from Mike Cohn)
Scrum 作为一种敏捷过程让我们关注于在最短时间内交付最高价值……它是迭代和增量式的……
Scrum的出现借鉴了《新的新产品开发方式》、精益思想、时间盒、SmallTalk面向对象编程中的模块化概念等。

Scrum起源

1986年,竹内弘高和野中郁次郎在哈佛商业评论上发表论文《The New New Product Development Game》,文章首次提到了将Scrum工作方式应用与产品开发,他们指出:
“传统的接力式的开发模式已经不能满足快速灵活的市场需求,而整体或“橄榄球式”(Rugby)的方法——团队作为一个整体前进,在团队的内部不断传球并保持前进,这也许可以更好的满足当前激烈的市场竞争。”
1993年,Jeff Sutherland在 Easel公司定义了用于了软件开发行业的Scrum流程
1993年,Ken Schwaber受哈佛商评论文影响,用Scrum方法拯救了一个濒临失败的项目。
1994年,Ken Schwaber建立了“控制混乱”网站。
1995年,Jeff Sutherland应邀将哈佛商评的文章转发给正在创立极限编程的Kent Beck
1995年,Jeff Sutherland和Ken Schwaber规范化了Scrum框架,并在OOPSLA 95上公开发布。
2001年,敏捷宣言及原则发布、敏捷联盟成立,Scrum是其中一种敏捷方法。
2001年,Ken Schwaber和Mike Beedle推出第一本Scrum书籍《Scrum敏捷软件开发》。
2002年,Ken Schwaber 和Mike Cohn共同创办了Scrum联盟。

更多Scrum历史考古,参见 http://www.jackyshen.com/2017/08/02/is-your-Scrum-lean-enough

预定义过程与经验性过程

预定义
经验性(Scrum)
Command and Control 命令控制
Plan in details 详细计划
Enforce the plan 强制按计划
“Control” change “控制”变化
Learn as we go 边前进边学习
Change happens 变化会发生
Embrace change 拥抱变化
Inspect and Adapt 检视和调整
 简单来说用中国的俗话说就是 『走一步看一步』、『船到桥头自然直』。
 

Scrum介绍

Scrum的3个角色

Development Team 交付团队的使命和特征

3 – 9 people  3 – 9 人
Cross-functional 跨职能
All skill set in different functional areas; 具备不同的职能
No sub teams; 没有子团队
T-shape talent (generalized specialization); “T” 型人才,通用的专才
Full-time(100% Dedicate) 全职投入
Membership changes only between sprints; sprints之间方可换人
Sit together; 坐在一起
Self-organized 自组织
No management title; 没有管理者头衔
Whole team accountability; 全员责任制
Team takes most of the project work; 团队承担大部分微观管理工作
Decide how much work to take on in a sprint 决定迭代的工作容量
Deliver Product Increments in every sprint 每个迭代交付产品增量
Responsible for HOW & quality 对“怎样做”和交付质量负责
Manage Sprint backlog and track the progress 管理Sprint Backlog并跟踪进度
Figure out the best way to work together as a team 找到团队内部合作的最佳方法
Collaborate with other teams and parties 与其他团队及相关方协作
Make continuous self improvements 持续自我改进

Product Owner  产品负责人的特征和职责

One person, not a committee; “一”个人, 而非一个委员会
Authorized to make decisions on WHAT; 被授与产品(“做什么”)决策权
Drives product success; 驱动产品走向成功
Provide leadership on product; 提供产品领导力
Represent project to the stakeholders; 面向干系人代表团队
Represent stakeholders to the team; 面向团队代表干系人
Collaborates with everyone; 和所有人合作
Ideally taken by real user; 理想情况下是真正的用户来担任
Creates the Product Vision; 建立产品愿景
Start with “Why”; 从“为什么”开始
Defines the feature of the product (the “What”); 定义产品功能(“做什么”)
Ensure the readiness of sprint input; 确保迭代输入准备好
Responsible for Return of Investment (ROI); 负责最大化投资回报
Orders/Prioritizes Product Backlog to best achieve goals according to the feedback; 根据反馈,为最好地实现业务目标将产品Backlog排定优先顺序
Decides on Release date and content; 决定版本发布日期和内容
Be committed to collaborate and be available to team; 愿意投入到合作中并且在需要时被团队找到
Accept/reject work results; 接受或退回工作成果

ScrumMaster  团队敏捷教练的特征和职责

Represents project to the management; 面向管理层代表团队
Represents management to the team; 面向团队代表管理层
No management title or power – CANNOT make decisions on behalf of the team;  没有管理头衔和权力 – 不代表团队做出决定
Coaching the team and PO rather than being a player; 更多是一个教练
Authorized to be a sheep-dog; 被授权的‘牧羊犬’
Change agent of team and organization; 团队和组织变革的代理人
Listens much more than tell; 听多于说
Is a servant leader with influence; 是一个具备影响力的仆人式领导者
Teach Scrum to everyone;向大家布道Scrum
Role model of enacting Scrum values, principles, practices and framework; 彰显Scrum价值观、原则、实践和框架的模范
Protects the team; 保护团队
Help to remove impediments and wastes; 移除障碍和浪费
Coaches and grows team on practices to continuous improvements; 教练和培养团队的实践,帮助持续改进
Facilitates collaborations; 引导大家的协作
Improves effectiveness of change in the organization ; 提升组织变革的效果

SM Candidate 候选者特征

开放心态,积极探索,愿意分享和帮助他人。经历过转型或至少了解组织政治生态,善用权力但不渴望权力。中等偏上的技术和产品知识水平。具备沟通能力和意愿包括影响力。从性格像限看,友善或表现型偏多
Open mind, active exploring, willing to share and help others. Experienced in transformation or at least understand political ego-system of organization, be good at using power w/o eager to that. Above average level of technology and product knowledge. Have communication and influencing skill. More of extroversion.

ScrumMaster Common Focused Area    ScrumMaster常见的关注领域

Team

Ceremonies & Meetings Facilitation 引导仪式和会议
Learning & Team Development 学习和团队发展

PO

PB Refinement 需求待办清单的梳理

Tech

Continuous Integration 持续集成
Decoupling 解耦

Organizational

Cross-team collaboration 跨团队协作
Coaching upper management 对管理层进行教练
Increase Transparency 提高透明性
 

Scrum的3个工件

Product Backlog  产品Backlog

An ordered and emerging list of features fulfilling the Product Vision
一份动态的有序列表,包含了符合产品愿景的各种功能
And other things providing value to the user
以及其他为用户带来价值的工作
A healthy product backlog must be “UPERFORM”:
一个健康的product backlog应当满足UPERFORM原则:
Unified, 唯一的
Pull-based, 拉动式
Emergent, 动态的
Revealed, 公开的
Feature-sliced, 纵切的
Ordered, 已排序
Ready, 准备好
Measurable, 可度量
Open to all but ultimately groomed by the PO; 对所有人开放但最终由PO维护
Focus on ‘WHAT’ brings users the biggest value; 关注于“什么“带给用户最大的价值
The best Product Owner starts with “WHY”; 最优秀的PO从“为什么”开始

Sprint Backlog  迭代待办项列表

The Product Backlog items selected for this Sprint plus the plan for delivering them 为本Sprint所选择的PBI以及交付所选PBI的工作计划之和
Extension and subset of the product backlog
产品Backlog 的延伸和子集
The set of work to achieve the Sprint Goal    为实现Sprint目标所要完成的工作集合
JIT (Just In Time) design in considered
涵盖‘恰到好处’的设计
Breaks large work down into smaller pieces (PBI -> SBI)
将大块的工作分解为更小的单元 (PBI -> SBI)
Focuses on ‘HOW’ team is going to get the work done and deliver the value in one sprint
关注于“怎么做”的问题:如何在一个sprint内完成工作以交付价值
Owned by the Development Team
被开发团队拥有
Team selects items from the product backlog they can commit to completing and creates the sprint backlog
团队从product backlog中选取他们可以承诺完成的项目并创建sprint backlog
Collaboratively, not done alone by the ScrumMaster
协作完成,不是由ScrumMaster负责
A visible tool for the team to manage itself during the sprint
一个可视化的工具让团队在sprint内部自我管理

Sprint Goal 迭代目标

The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog.  迭代目标是本迭代中通过实现PB来达成的目标
It provides guidance to the Development Team on why it is building the Increment.  向团队提供构建该增量的理由(why)
It is created during the Sprint Planning meeting. 在Sprint Planning会议上产生
The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint.  给予团队一些在功能实现上的灵活性

Visible Task Board Kanban 可视化任务墙看板

Task board is a common visible tool to manage sprint backlog   任务板是一个常见的用于管理sprint backlog的可视化工具
Self-organized: Individuals or small groups sign up for work 自组织:团队成员或小分队自己领取工作
Team decomposes PBI to SBI  团队一起将PBI分解为SBI
Team decides SBI granularity     团队决定合适的SBI颗粒度
Work is not assigned  没有一个人主导任务的分配
Sign up for new work after one work is done  完成一项任务才认领另外一项任务
Based on priority and try to reach fully DONE on a PBI   按照优先级,努力使一个PBI尽早完全完成
Team tracks remaining work of the Sprint, daily
团队每天跟踪Sprint中剩余的工作
Any team member can add, delete or change the sprint backlog item (SBI)
任何团队成员可以添加,删除或变更sprint backlog事项 (SBI)
Work for the sprint may emerge
sprint内的工作有可能动态涌现
Visible to the world,对全世界可见
Update in real time,随时更新
Represents the current progress toward the Sprint Goal,
直观展示Sprint目标完成的进展
Work visibility management tool, 工作可视化管理的工具

Sprint Burn Down Charts       迭代燃尽图

Sprint Burn Down Charts Sprint 燃尽图是一个可选的可视化工件,用来管理Sprint Backlog,并帮助团队自己跟踪进度和暴露风险
Updated in real time 随时更新
Represent the amount of work remaining,度量Sprint剩余工作的总量
Different approaches to creating burndown charts,燃尽图有不同思路
Estimated remaining efforts,剩余工作量估算
Tracking DONE only,跟踪已完成项

Potentially Shippable Product Increment (PSP)  潜在可交付产品增量

The sum of all the Product Backlog items completed during a Sprint and the value of increments of all previous Sprints
当前Sprint所完成的PBI,以及之前所有Sprint的增量价值之和
Potentially releasable and meet the Definition of Done
潜在可交付,并符合完成的定义
Must be in useable condition regardless whether the Product Owner decides to release it
必须是可用的产品,不管PO是否决定对外发布
 

Scrum的5个活动

Sprint 迭代

Scrum projects make progress in a series of “sprints”
Scrum项目由一系列“sprint”组成
Analogous to Extreme Programming iterations
借鉴了极限编程中的“迭代”
Typical duration is  less than a calendar month at most, or even shorter
不超过一个月的日历时间, 建议1~2周
A constant duration leads to a better rhythm
通常是定长的,有利于产生更好的交付节奏
Sprint ends only when the time-box expires
只有当时间盒到期时,Sprint结束
Product is developed according to DoD within a Sprint
根据DoD定义,全部相关工作在sprint内完成
Not to change Sprint Goal; 不去改变Sprint的目标
Not to change Sprint length during a Sprint; 不改变当前运行中的Sprint的长度
Can a Sprint be terminated?
Sprint可以被中止吗?
Yes 可以
Product Owner can cancel the Sprint if business circumstances require
出于业务需要,Product Owner可以取消Sprint
Team can discuss with Product Owner to see how to handle, if they are unable to accomplish anything
如果无法完成任何东西,团队可以和PO协商应对
Go back to Sprint planning — any “not done” work performed should be put back to Product Backlog
重新做Sprint计划-所有还”未完成的工作”放回产品Backlog
Very rarely done!
罕有发生!(跟上面那句是关联在一起的,就是说极少数情况下会发生重新做整个迭代过程)

Sprint Planning   Sprint计划会议

Timebox: max 8 hours for 1 month Sprint
时间盒:1个月的Sprint最长8小时
Part I SELECTION 第一部分 选择
Define the Sprint Goal 定义迭代目标
Select the Product Backlog Items the team can commit to complete 选择团队可以承诺完成的迭代待办项
参与者:  Product Owner/Development Team/[ScrumMaster]
输入: Healthy Product Backlog 健康的产品Backlog
输入: Latest Increment  最新版本的增量
输入: Velocity of the Development Team of this Sprint 团队这个Sprint的速率
输出: Crafts a Sprint Goal with Selected Product Backlog Items 根据所选择的产品Backlog事项制定Sprint目标
Part II PLANNING 第二部分 计划
Decide how to achieve the Sprint Goal 决定如何实现迭代目标
Create the Sprint Backlog 创建 Sprint Backlog
Estimate the Sprint Backlog Items 估算迭代待办项
参与者:  Development Team/[Product Owner]/[ScrumMaster]
输入:Capacity of everybody of this Sprint 团队这个Sprint所有人的工作容量
输出:  Plan on how to meet the Sprint Goal (Sprint Backlog) 如何实现Sprint目标的工作计划(Sprint Backlog)
输出: Mutual agreement on the Sprint Goal 大家对Sprint目标形成共识

Daily Scrum 每日站会

Parameters,参数
Daily,每日
Same time same place, 同一时间同一地点
15-minutes,15分钟
Stand-up,站立
参与者: Development Team, [ScrumMaster], [Product Owner]
Inspect & adapt on Sprint progress for Sprint Goal,  为达致Sprint目标检视进展和调整计划
Not for specific problem discussion and solving,不讨论和解决具体问题
Other people can be invited to observe,其他人可以受邀来旁听
Only team members, ScrumMaster, Product Owner, can talk
只有团队成员,ScrumMaster和Product Owner可以说话
Helps avoid other unnecessary meetings
帮助避免其他不必要的会议
每个人回答三个问题
What did I get DONE yesterday to help DT meet Sprint Goal? 昨天我完成了什么,以便帮助交付团队达成迭代目标?
What will I get DONE today to help DT meet Sprint Goal? 今天我要完成什么,以便帮助交付团队达成迭代目标?
Are there any impediments slowing/blocking my progress to meet Sprint Goal?  有什么障碍影响我的进度和迭代目标吗?
This is NOT status for the ScrumMaster, it is broadcast in front of peers for self-management   不是向ScrumMaster汇报状态,而是向所有组员的广播,属于自管理的一部分

Sprint Review  Sprint 评审

Inspect & adapt on the Product and Product Backlog     检视和调整产品和产品Backlog
Team presents what it accomplished in the sprint that PO should accept timely 团队展示Sprint的成果,PO应当尽早验收
Product Owner explains what have been accepted as “Done” work and what have been rejected as “ not done” work                                                                                                                                                                                          产品负责人表明哪些“完成”的工作被接受了,哪些“未完成”的工作被退回了
Typically takes the form of a demo of new features or underlying architecture, obtain feedback and discuss on future adjustment to optimize value
经常以Demo新功能(及其依赖的架构)的形式,获取反馈和讨论接下来要做的工作,从而持续优化价值
Informal,非正式
4 hours max time-box for 1 month Sprint        1个月的Sprint时间盒最长4小时
No slides  不要用幻灯片
Least Preparation 尽量不要准备
Whole Scrum team participates
全Scrum团队参与
Invite all stakeholders and interested parties
邀请所有干系人及感兴趣的人士

Sprint Retrospective 迭代回顾

Inspect & adapt on how we work (people, relationships, process, tools…)
对我们如何工作(人、关系、过程、工具等)进行检视和调整
Continuous improvement on process, 对过程的持续改进
Timebox:  45min for 1 week Sprint 时间盒:每1周的Sprint花费45min
Whole Scrum team participates,全Scrum团队参与
Other interested parties are welcome by invitation,欢迎其他感兴趣的受邀人士
In a safe environment,在安全的环境中进行
One popular format: 3 Question format,一个流行的形式:三个问题
Start doing,开始做什么?
Stop doing,停止做什么?
Keep doing,继续做什么?
输出:  Improvement Action Plan for next Sprint  下一个Sprint的改进行动计划