scrum gathering 2012 shanghai 播种敏捷分会场演讲话题:敏捷估算的新视角(alan...
DESCRIPTION
讲师: Alan Atlas 目前是Scanbuy, Inc. 的技术总裁。从事专业技术超过30年。从布朗大学的心理学学士,到麻省大学电机工程学士,他随后加入了贝尔实验室作为一名硬件工程师,然后迅速去乔治亚理工学院并拿到了电机工程硕士学位。在贝尔实验室的那段时间,他接触了软件,并自学了C语言编程。进入软件开发领域以后,Alan花了一些时间在数据获取工作站的实时UNIX内核中开发内核功能。被升级为OS开发组经理后,Alan开始了25年的技术经理生涯。在这期间他荣升至高级副总裁级别,之后他自动降回开发部经理,因为那个职位好玩很多。那些年的主要事件包括OSF Motif 1.0的发布和AvidNews 1.0的发布。AvidNews 1.0是行业中获奖的广播新闻管理系统,由Avid技术支持。 在亚马逊担任网络服务部高级开发经理时,Alan发现了Scrum。他成为了认证ScrumMaster,并带领他的团队在使用Scrum一年之后,成功发布Amazon S3。这成为Codie奖获奖的网络服务,提供了无限网络连接存储。Amazon S3项目的成功,以及Alan对Scrum方法的热爱,使Scrum在亚马逊网广泛散布开来。Allan成为了认证Scrum培训师和亚马逊第一个全职敏捷培训师和教练。他的经验使他立志成为认证Scrum教练,然后转换职业为全职敏捷教练和培训师。Alan在2009年敏捷大会和慕尼黑Scrum聚会中做过演讲。 话题介绍: 多年来估算的技巧一直是Scrum里面困扰着大多数人的领域. 让我们大家一起在Alan大师的引导下来重新细细的审视这门技巧. 使之变得更简洁, 更加符合敏捷的理念. 为什么需要估算? 多久(重)估算一次? 我们可以不使用传统基于复杂度,时间,心力,以及怀疑的估算方法吗? 在本次的演讲当中, Alan大师将为听众比较不同的估算法, 包括了Wideband Delphi, Planning Poker, The Team Estimation Game, 以及The Backdoor 等方法之间的差异. 何时应该估算工作量和团队的能力? 为何我们应该同时考虑理想时数和故事点数? 它们之间又有何不同呢? 以上所有的疑问都将由Alan 大师以其十多年的敏捷以及Scrum的经验和独到的见解为您解答。TRANSCRIPT
A Fresh Look at Estimation
敏捷估算的新视角
Alan Atlas
Alan Atlas CST, CSC
Agile Conference 2012
http://www.flickr.com/photos/teuobk/2104039823/
http://www.flickr.com/photos/elenchos-seattle/3839827249/
8
“I think we will be
able to release this
feature five sprints
from now.”
“This feature will
cost two complete
sprints of our 5
person team.”
“I think we can
deliver this project
in 8 sprints.” (Actually we think 6 but we’re padding
to be careful.)
Estimation does not create value. (估算无法产生价值)
Estimation does not reduce work. (估算无法减低工作量)
Therefore, estimation is ‘waste’ in Lean terms. (因此, 从精益的角度来看, 估算是一种’浪费’)
And…
Estimates can be mistaken as commitments
(同时, 估算时常被误认为就是承诺)
To form an opinion about; evaluate. (形成一个意见; 评估)
A tentative evaluation or rough calculation, as of worth, quantity, or size. (一种暂时性的评估或者大概的有关於价值, 数量, 或者大小的计算)
A judgment based on one‘s impressions; an opinion. (根据一个人的印象所作的判断)
Usually implies a subjective and somewhat inexact judgment (通常隐含了一种主观且不怎麽準确的判断)
An oxymoron is a phrase in which
contradictory terms appear side by side.
(Oxymoron 指的是在一句话当中出现两个观念相衝突的字或词)
“It was a dark night and the moon
shone with silvery light”
Detailed Summary
Military Intelligence
American Culture
Adult Male
“I’m almost positive we are done.”
Accurate Estimate (準确的估算)
Here is a question I can answer:
How much effort can your team apply to the
project during this sprint?
Here is a question I cannot answer:
How much complexity can your team complete
during this sprint?
Here is what I do when I can’t answer a
question:
I make a guess!
24
S L
1 3 5 8 13 2
2
2
2
2
2
3
3
5
5
5
5
8
8
8
13
13
1
1
1
25
Wouldn’t it be nice if every story was the
same size?
Every story is then a ‘1’, or else a ‘247’. It
doesn’t matter.
We can do that by splitting stories until they
are all about the same size.
This gets us all of the benefits of splitting at
the same time that it eliminates estimating.
No need to estimate.
This works exceptionally well in kanban.
Story Task Pts Ideal
Hours
Consolidated
Financial Report 13
Design Integration
Data Structure
2
Import from first
data source
6
… … … …
Mike Cohn once said:
“If you are not comfortable with story
points, then just pretend one story point
equals one ideal day.”
Mike Cohn forgot to say:
“Only do that until you figure out story
points because it is not really true. It is a
trick to help you get started.”
Use ideal hours for tasks
Tasks are small and so are hours.
If you estimate effort, then story points and
ideal hours are correlated
More story points means more ideal hours
because both estimate effort
Now, since you estimate stories and tasks
differently, the two estimates can be used as
a sanity check
Story Points Sum of Task
Ideal Hours
Display Time 2 4
Enter Time
Scale
5 9
Change Time
Display
3 5
Set Y Axis Scale 1 12
Change Y Axis
Scale
3 7
Add Graph Title 3 5
Variable part timers (隨時在改變的臨時工人員數)
Specialists (專家)
Learning curve (學習曲線)
Team
Member
Percent
Allocated
Project
Hours per
day
Days
Available
this sprint
Total project
hours
available
this sprint
Xianshen 100 6 10 60
Brenda 100 6 8 48
Li 50 3 10 30
Mei 100 6 5 30
Jiang 100 6 10 60
Daniel 100 6 10 60
Total 288
Minus 10%
Scrum
Overhead 260 33
Old Days Nowadays
Always estimate
Relative estimation
using Planning Poker
Story Points and Ideal
Hours
Capacity Planning
Complexity, Effort,
and Doubt
1 Story Point = 1 Day
Estimate when
necessary
Estimate by splitting
Affinity estimation
No task estimation (or
no tasks!)
Capacity planning
when necessary