2上的SCRUM培训学习笔记。敏捷Scrum实践集核心精髓免费入门学习课程培训教材。

by admin on 2018年9月19日

2012年10月27日交28日到庭了优普丰组织的当京定期2龙之Certified(不是Certificated)
Scrum
Master培训,收获多。参加培训前邮件中介绍Vernon老师是独会中文的美国人数,一开始以为这会培训注定是一个鬼子讲上一样堆放英文,然后起只中国丁于边上翻译的讲座了,没悟出这个vernon中文水平真是好,正常的语速的中国话他任得一些题材为没有,汉语说之也罢是一对一清楚,只有少数的配小口音。vernon先生浑身散发着英雄的热量(他自命的Passion),当热到一定程度后,vernon就管鞋子拖掉,一双白袜子开始在会议室里走来走去。

为回馈敏捷社区对上海优普丰敏捷学院成立10年来的支持,我们决定免费放出敏捷开发Scrum实践集核心精髓免费入门学习课程培训教材,包含美国Scrum联盟的Certified
Scrum
Master培训(即CSM认证)公开课培训的核心内容,方便大家预习和习Scrum实践,更好地问询敏捷开发是什么。本讲义遵循Scrum
Guide
2016以及美国Scrum
Alliance官方CSM认证学习目标(learning objective) 2017版本。感谢Vernon
Stinebaker(史文林)、Bill Li(李国彪)、Jacky Shen
(申健)对按照教材讲义的孝敬。内容和CSM认证考试题库中测试题目之攻目标大致相同。

图片 1

迅速是呀?

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高速原则于闹了更实际的解释。

image.png

敏捷宣言和Scrum

此前对迅速开发有部分打听,最早接触的凡终极编程XP,知道出17个好滑雪之软件人士琢磨出了资深的迅猛宣言,对片民俗的庞大之软件开发提出了挑战。

图片 2

敏捷Agile就如相同将大伞,Scrum、XP、FDD等等都是里的一模一样各类,Scrum是如出一辙栽框架,更讲求于片经过,XP更重视于行。

图片 3

以掌握敏捷的几乎独要点,Vernon先生专门规划了一个传递纸球的小游戏,准备等同堆放用报纸揉成的小球,参加培训之8总人口也同组,围成一绕站立,规则不行粗略,只能用手传球,球打一个人手到其它一个人员之间要来空中时,球要传递给无相邻的人口,一个圆球经过所有成员后才终于1划分,1分钟里传递小球的个数为总成绩。游戏展开了5-7车轮,每轮中间有1分钟之座谈时间。

图片 4

游玩就略,但也会深刻地回味以下要点:

1)每轮的讨论还能增长下同样不行的成绩,第一车轮好像就招了6独,最后一轱辘传了100多只,最后的精益求精幅度的大吃咱们友好尚且爱莫能助想像

2)设计更精心之方案免设这着手,只有实行起来才会提出来针对的改进建议

3)短日内的核定也是一对一有意图的,1分钟就少,但欠日呢同会激励起的大脑无穷的创造力。

4)减少每个人没事等待的时,并行作业让球不停歇地当多个人之间很快流动,大大减少了等候的时刻

5)当成绩提高至早晚水准后,如果不在方或者工具及冒出革命性的革命,成绩就未会见再次起多万分的增高

6)把30分钟的到底时分解为数迭代,每个迭代中进行实践以及小结,远远比进行29分钟的精雕细刻筹划讨论和1分钟的施行而立竿见影得几近。

图片 5

 

Scrum总结起来就是3355,实际上应该叫3455:3栽角色,3栽工件,4种植仪式(活动)和5个传统。2天的教程实际上即便是围绕着334来介绍的,当然讲解的经过不断地干到5种价值观的讨论。

 

图片 6

 

 

什么是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 Team由三栽角色构成。

有关三栽角色跟龙舟比赛的切近比较:PO相当给舵手,把握团队发展的势头;TEAM相当给划桨运动员;SM相当给鼓手,负责协调组织。

1)Product Owner

客户代表,决定产品的进化方向vision,对ROI负责(投资回报率return on
investment),本身最好就是是个customer,PO是一个人,负责被PBI(Product
Backlog Increments)排序,负责掩护Backlog,确认Sprint的结果(Accept
Sprint
Results),PO有权利决定是否产品得以发布,PO不自然写尽底用户故事,PO要时时刻刻和集体沟通,PO有决定权Authority。

2)SCRUM Master

斯称号相当有重,参加2天的养,还从未Scrum的实践经验,通过了求证考试,就得叫Scrum
Master了。

咱们普遍认为这个SM最没有事情可做,但老师一再强调这个角色蛮忙碌,特别对未成熟的团组织和在列的首,我们管原先项目经理负责之政工各个写下去,贴于这白板及,发现此SM好像就是是工作未多,他在全体过程中就是一个教练、一个咨询师的角色,他实在就是是辅导你怎样开始正确的Scrum各个过程、会议等等。

SM在普团队中自及同样栽老师、教练、促进的意图,要确保组织不被惊动、保证集体高效地展开工作,移除一些绊脚石。他差点儿没有呀权利,但如来影响力。

图片 7

图片 8

Vernon关于在一部分议会及ScrumMaster为什么可摘参加的注释:

While the ScrumMaster is optional at many meetings they are
responsible for assuring the Scrum framework is being effectively
applied, so as you note in the area discussing the ScrumMaster role
they are likely to be quite involved in all meetings, especially
initially as the team needs to be trained and coached to understand
how to effectively conduct the meetings: to understand their structure
and purpose.

3)DEV Team

软件或要出于同样广大程序员一行一行写出来,这就是是Team的任务了,这里Team中每个人之技艺要控得全面(有特长,但无克仅仅擅长的从),要会自组织管制、跨职能、人数控制以5-9总人口之间、最好全职(可能产生微量两样)、No
Title(没有严格的分工,没有要求、编码和测试的分工)。

 

Scrum中没项目经理的角色,没有上下级的涉,vernon打了一个比喻,说Scrum有点共产主义,但共产主义中最好广泛的凡上下级领导涉嫌。感觉根据我们当下之现状,三个角色太难找的凡Product
Owner,这个角色表示正用户利益,但倘若常常跟开支组织混在一齐。

 

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

其三个工件

图片 9

1)Product Backlog

Product Backlog = a dynamic list of features that might appear in our
product.

Vernon先生的诠释:

PBI=feature, A bunch of PBIs = product Backlog

It might also be worth noting that PBIs don’t have to be software. The
Scrum framework can be applied to areas outside of software, so PBIs
could be other product features as well; for example the introduction
in a book, or a chapter in a book.

值得注意的凡:PBIs并不一定专指软件。Scrum框架可以运用叫软件之外的旁领域,因此PBIs也足以是外产品特点,例如在出版业,可以是书写之一个回。

斯Product Backlog就是软件出品之法力列表,由多PBI(Product Backlog
Item)组织,一个PBI又由于众多SBI(Sprint Backlog
Item)组成,这个Backlog要粘贴在一派好墙上,上课时早已问了vernon老师,这个事物全用工具在开发团队的网站首页上行不行?vernon说得,但偏偏所以电子的backlog会潜移默化开发效率,所以他们店或用大墙和不畏利贴,一些情会录入到电子backlog中。

25独稍点儿积木的打叫丁知情了事先级的第一作用,要在最好短缺的时日内获取的极致要命的纯收入,就是只要先期成功那些黑星星。

图片 10

2)Sprint Backlog

是Backlog感觉好叫任务了,通常PBI颗粒太非常,无法执行,只有讲为SBI(小于2天的工作量)才会开始动手做。感觉顿时东西好像GTD里用Project分解为Action的长河,不了其它类型为还是这么来分解的。

 

3)Tracking/Increment

这个事物在原先就是是赖燃尽图,现在类似说为不是必的了,实际上Backlog也全然可体现出档次之拓展情况。

图片 11

预定义过程和经验性过程

Command and Control 命令控制
Plan in details 详细计划
Enforce the plan 强制按计划
“Control” change “控制”变化

vs.

Learn as we go 边前进边学习
Change happens 变化会发生
Embrace change 拥抱变化
Inspect and Adapt 检视和调整

季单移动

Scrum就是出于同样积的Sprint组成的,这个Sprint实际上就是迭代,每个Sprint最少吗1天,最丰富也4到,由4单移动做。

Vernon的注解:

In theory there is no minimum sprint duration, one day is just the
shortest I’ve seen in a production environment. Sometimes in training
we use 1/2 day sprints. A key concept, however, is that for a sprint
to be a sprint, it must include the 4 meetings.

反驳及尚未最小之sprint长度限制,一龙之sprint长度是自在产品开发中来看了的不过小的长短,在培育时有时可以用1/2天同日而语sprint的长。然后,一个sprint可以叫sprint的最主要是它们要带有4单会议。

Sprint是永恒长短的,有或率先差迭代以后,周期有点调整,但后来运一个安乐的命,这就是Scrum的rythym节奏。

以Sprint期间,功能范围不再变化,即PBI从左边拿到Sprint Backlog区后,不再接受新的SBI。

Vernon的注解:

SBIs are emergent, and defined by the team, so it is quite possible
that new SBIs will be added during the sprint. This is just to say
that the team has developed a deeper understanding of how they will
complete the PBI. So, during a sprint the SBIs can change, but the
PBIs that the team has committed to cannot change. “No change” during
the sprint refers to PBIs.

SBIs具有涌现性,是由集体来定义之,因此在sprint之间会油然而生新的SBI。也就是说,团队对于什么好PBI已经生矣浓厚的掌握,因此当sprint期间SBI是可以扭转的,但组织已承诺的PBI不可知转。在sprint中之”No
Change”是凭借PBI而言的。

 

图片 12

1)Sprint Planning

其一过程有点需求分析的意,实际上为是一样栽承诺Commitment。这个会而由于2独号做,第一级叫作Selection,第二号叫作Planning。

第一路由PO、TEAM参加,SM可选。对于1周之sprint,这个路不超1时。

在马上同样步是依据PBI的先级将到Sprint
backlog中,对于比较充分的粒度,还要讲。

次品由TEAM参加,PO和SM可选,但PO要遵循吃随到。对于1周之sprint,这个阶段不超越1时。

 

2)Daily Scrum

即就是是大名鼎鼎的站立会议,要于每天相同之岁月、相同的地址做,少于15分钟。

Scrum(由于它们不是一个缩写单词,所以一般不要大写所有字母)的术语也是缘于橄榄球中之见面开球仪式,在rugby这种移动中,每个运动员都是从组织的、跨职能的,需要根据场上的动态地调整计划。

会上要是应对3独问题:

What did I get done in the last work period?

What will I get done in the next period?

Any impediment(障碍)?

透过就三只问题,团队拓展广播式的关联,跟踪项目之速,分享部分文化,更要的是为组织做出一种承诺Commitment。

3)Sprint Review

这种回顾对于长度也1周到之sprint,不超1时,不待PPT,非正式的交流。整个过程也是TEAM和PO参加,SM可选。最好还要请有stakeholder参加。

Vernon的注解:

PO and team are required, ScrumMaster is optional. Stakeholders are
encouraged to attend this meeting. Since this meeting is a key means
of the PO soliciting feedback from stakeholders, their participation
in this meeting is essential. The PO might even be the host/driver in
this meeting.

4)Sprint Retrospective

其一会对长度也1圆满的sprint,不越45分钟。整个经过TEAM参加,SM和PO可选。

此历程是以明天的穿梭改进,不发话好消息,提出1-3只改进建议,然后就是是celebrate。

Vernon的注解:

The Sprint Review is the meeting where the working results of the team
are shared with the stakeholders and the PO. The Sprint Retrospective
is the meeting where the team considers how they can continuously
improve.

The Sprint Retrospective is the meeting where the team considers how
they can continuously improve. The team is required and the PO and
ScrumMaster are optional (at the discretion of the team). Typically
the team would encourage their participation unless the PO or
ScrumMaster themselves are in some way an impediment to the team
improving.

Scrum框架3355概览和Scrum术语

用户故事

User Story并无是SCRUM中之情节,但可用于SCRUM中。

PBI相当给User Story,而SBI相当给任务Task,SBI的颗粒度要自愧不如0.5天。

Vernon的注解:

1/2 SBIs are a practice my company uses, but not a formal definition
included anywhere related to either User Stories or Scrum. As you
correctly note earlier in your blog, SBIs are typically 1 – 16 hours
(less than 2 days) in duration. 1/2 day is just our practice.

PBI要描绘到什么水平?DEEP原则:

Detailed Appropritly 比较清晰的

Emergent 涌现性

Estimated 被估算的(以团队的道来估计)

Prioritized / Order 被排序的

图片 13

Scrum的3个角色

估算

vernon先生由散发着巨大的热能,所以要不停歇地补水份,每天带在同样挺瓶(搞不清楚2升或3升)基本上都喝得多。一个游乐就是是量他喝剩下的次的体积,8只人之估计从400ml到1600ml不等于,相差这么宏大,说明了丁不擅长用绝对化的多少来评估事物,而下百分于来打量时,范围就合在55-65%中。

优普丰的计划扑克可以用来集体对职责工作量进行评估。

图片 14

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 emerginglist 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
选择团队可以答应完成的迭代待处件

Part II PLANNING 第二有的 计划
Decide how to achieve the Sprint Goal 决定如何兑现迭代目标
Create the Sprint Backlog 创建 Sprint Backlog
Estimate the Sprint Backlog Items 估算迭代待处件

  • Part I
    • 参与者: 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
    • 参与者: 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的精益求精行动计划

Scrum的5单传统

  • 勇气****Courage:因为咱们无是单打独斗,我们能感受及⽀持,⽽且掌握更多之资源。这通与我们勇⽓去迎接更怪之挑战。
  • 开放****Openess:在团协作面临,大家还见面发表我们召开得咋样,以及遇到的拦路虎。我们发现用担忧说出是⼀件好事,因为只有这样才能够吃这些担忧这取缓解。
  • 专注****Focus:由于我们当⼀段时间外就注意于少数几乎桩业务,所以我们可充分好地合作并赢得优质的面世。我们会再快地交给有价之事项。
  • 承诺****Committment:由于针对⾃己的数发生再⼤的掌控,我们会出更坚定的信心去获得成功。
  • 尊重****Respect:因为咱们当同步工作,分享同成功失败,这有助于培育并加深相互之间的看重,并协助彼此成为值得尊重的食指。
  • People personally commit to achieving the goals of the Scrum
    Team.
  • The Scrum Team members have courage to do the right thing and
    work on tough problems.
  • Everyone focuses on the work of the Sprint and the goals of the
    Scrum Team.
  • The Scrum Team and its stakeholders agree to be open about all
    the work and the challenges with performing the work.
  • Scrum Team members respect each other to be capable, independent
    people.

Scrum团队

Scrum三不胜角色,合起来称Scrum团队。

当人情的办事措施下,开发集团会生出成千上万不等的角色,比如项目经理、产品经营、架构师、设计师、用户体验设计师,程序员,测试人员,DBA等等。但是,在Scrum的办事法下,总共不过生三只角色,
这三独角色分别是成品负责人(PO), Scrum Master(SM)和提交团队(DT)。

咱们便可以因划龙舟的团组织角色来类比Scrum的角色,划龙舟通常发生舵手、鼓手、划桨团队三单角色。Scrum中之PO就是舵手的角色,他对成品之样子荷,对产品的Why和What负责,对产品的愿景,产品包括哪些重大的特性负责。Scrum中之Scrum
Master鼓手的角色,他拉组织维持高昂的气,并进行好的协作,他是一个Scrum的师,团队的训练,团队的服务式领导。Scrum中的交给团队,对承诺交龙舟赛的划桨团队,团队必须协调一致,作为一个总体提高,在如此的条件下只由独斗,各自为政没有任何胜算。

造从组织团的老三只约定

就的概念 Definition of Done (DoD)

当产品代办事项列表条目或者增量为描述为“完成”的时节,每个人且不能不懂得“完成”意味着什么。虽然就当不同的
Scrum
团队之间会有远大的异样,但是团队成员要对完成工作表示什么产生同样之知情,这样才能够保证透明性。这就是
Scrum 团队之“完成”
定义,用来评估产品增量在啊时就,并且没有屈服质量。

DoD这个定义是组织对活负责人的应允,是集体时力量的反映。可以用来指导开发组织询问在
Sprint 计划会议的时光他俩力所能及选多少产品代办事项列表条目。每个 Sprint
的靶子还是交遵循 Scrum 团队时的“完成的定义”的隐秘可授产品增量。

付出集团在每个 Sprint
交付产品功能增量。这个增量是可用之,所以活负责人可以选就宣布其。每个增量都增大给事先有增量并经过充分测试,以此保证拥有的增量都能做事。

趁着 Scrum
团队之熟,我们预料“完成”的概念会扩张,包含重复严标准来担保高质量。

消注意的凡,如果以每个迭代,我们本着“完成”的正经要求了低,那么就会造成在每个迭代,我们都见面残留有完他之工作,完成他的做事持续累计会多项目的风险,有或造成产品负责人决定颁布的上,产品也为累了过多之得他之做事要望洋兴叹发布,以致被我们尚待一个额外的Sprint来使它们稳定。

预备好之概念 Definition of Ready (DoR)

当PO拿出Product
Backlog请团队带工作时,团队是否能否及时开始,抑或充满疑惑,似懂非懂?有些戏精工程师就以迭代根据自己之了解胡乱开,待至验收的上产品负责人及客户大叫“这不是本身只要的!”

乃DoR这个概念(也称“就绪的概念”)正式产品负责人针对集体的许诺,是团组织会开工的保证。团队有权利要求PO提供这检查清单中之必备内容,不然的话就优先不上马是工作。

DoR一般包括:每个PBI和用户故事应具有背景及目标、足够亮的信、已估、已排序、已记录下验收标准测试用例,界面原型草图,乃至浏览器兼容性列表等等。

团伙工作约定 Team Working Agreement

为如团队纪律。自组织团队中每个人焉合作配合?就如乔布斯以《The Lost
Video》中干的,打过去团队就是是一旦简明对象,然后起一个容器,让大家彼此拌嘴、碰撞、打磨,于是丑陋的石呢会见成为美好的石头。

世家之间磨合的预约和规则是抱实际的,外人不克吧无能为力被有一个习俗的流程强迫大家以,一定是豪门提出、大家认可,大家才会履行下。

这些干活儿约定可显式化张贴出,也同意更改。比如每个迭代回顾会的当儿,SM可以带大家对Working
Agreement进行翻新。一般内容被连:开站会时、用什么工具IDE、持续集成轮流当、讨论时禁止玩手机、一浅只生一个话题、先不鉴定别人的想法等等。

快快估算

Absolute Estimation 绝对值估算
number with a ‘unit’, like MD/Hours, Line of Code etc
带有”单位“的数字,例如人天/小时,代码行数等

vs.

Relative Estimation 相对值估算
number WITHOUT a unit: number of times we compare one against another
不带来单位的数字:一个数字和另外一个数字的自查自纠

Why Relative Estimation 选择相对估算的理

Estimation == Best Guess
Accuracy over Precision
Accuracy vs. Effort of estimation
Work Effort ≠ Time

用户故事

哎呀是用户故事?

用户故事是从用户的角度来叙述用户渴望获得的效果。一个吓之用户故事包括三单因素:

  1. 角色-Who:谁要采用此职能。

  2. 倒-What:需要好什么样的机能。

  3. 商业价值-Why:为什么要这个效应,这个意义带来怎么样的值。

用户故事平凡以如下的格式来表述:

英文:

As a [who], I want [what] , so that [why].

中文:

作为一个<角色>, 我思念要<活动>, 以便于<商业价值>

举例:

作为同样个招聘者,我思使发布一个职信息,以便为应聘者能够看出跟投递该职位。

亟待小心的是用户故事不能够利用技术语言来讲述,要利用用户可以知道的事务语言来叙述。

Jeff Paton升级Ron Jeffries的5C

卡(Card) –
用户故事一般写于聊之报事贴卡片上。卡片上或会见刻画及故事的简描述,工作量估算等。
交谈(Conversation)-
用户故事背后的细节来与客户要产品负责人的交流沟通。
肯定(Confirmation)- 通过验收测试用例确认用户故事让科学就。
构建(Construction) – 团队经过技术手段实现者用户故事的渴求和效力。
结果(Consequence) – 交付于用户真正用,并收获反馈。

良好用户故事之六单特点- INVEST原则

INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable

一个好之用户故事应按照INVEST原则。

独立性(Independent)—
要硬着头皮的为一个用户故事独立为其他的用户故事。用户故事里面的乘让制定计划,确定优先级,工作量估算都变得够呛困难。通常我们可以通过结合用户故事以及分解用户故事来减因。
然而协商性(Negotiable)—
一个用户故事之内容如果是足以商量的,用户故事不是合同。一个用户故事卡片上只是针对用户故事的一个简单易行的描述,不包括无与伦比多之底细。具体的细节在联系等起。一个用户故事卡带有了无以复加多的细节,实际上限制了同用户的维系。
起价(Valuable)—
每个故事要对客户有价值(无论是用户还是购买方)。一个受用户故事发生价的好点子是被客户来写下它们。一旦一个客户意识及即是一个用户故事并无是一个契约而且得开展商议的时段,他们拿特别愿意写下故事。
足估算性(Estimable)—开发组织要去估计一个用户故事以便确定优先级,工作量,安排计划。但是于开发者难以估计故事之题目源于:对于世界知识的缺乏(这种场面下要再次多的维系),或者故事太死了(这时需要将故事切分成小些的)。
紧张(Small)—
一个吓的故事在工作量及万一尽可能少小,最好不用过10只理想人/天之工作量,至少要确保的是以一个迭代或Sprint中能够一气呵成。用户故事更老,在布置计划,工作量估算等地方的高风险就是会见越来越怪。
可测试性(Testable)—一个用户故事要是足以测试的,以便为认同它们是得就的。如果一个用户故事不克测试,那么你就无法清楚它们什么时候可以做到。一个不得测试的用户故事例子:软件应该是善使的。

Scrum检查清单

你的组织及组织中,Scrum与快速举行的如何啊?可以用这Scrum
Checklist来做只免费的自评估吧。

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图