Scrum gathering 2012 shanghai...

download Scrum gathering 2012 shanghai ’­ç§•·ˆ†¼œ¼”讲è¯‌é¢ï¼•·¼°ç®—ç„–°è§†è§’(Alan Atlas)

of 34

  • date post

  • Category


  • view

  • download


Embed Size (px)


讲师: 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 of Scrum gathering 2012 shanghai...

  • 1. A Fresh Look at EstimationAlan Atlas

2. Alan Atlas CST, CSCAgile Conference 2012 3. 4. 5. 8 6. I think we will beable to release thisfeature five sprintsfrom now. 7. This feature willcost two complete sprints of our 5person team. 8. I think we candeliver this project in 8 sprints.(Actually we think 6 but were paddingto be careful.) 9. Estimation does not create value. () Estimation does not reduce work. () Therefore, estimation is waste in Leanterms. (, , ) And Estimates can be mistaken as commitments (, ) 10. To form an opinion about; evaluate. (; ) A tentative evaluation or rough calculation,as of worth, quantity, or size. (, , ) A judgment based on ones impressions; anopinion. () Usually implies a subjective and somewhatinexact judgment () 11. An oxymoron is a phrase in which contradictory terms appear side by side.(Oxymoron ) 12. Im almost positive we are done.It was a dark night and the moon shone with silvery lightDetailed SummaryAmerican CultureMilitary Intelligence Adult Male 13. Accurate Estimate() 14. 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? Hereis what I do when I cant answer a question: I make a guess! 15. 24 16. SL1 2 3 5 8 131 2 3 5 8131 2 3 5 8131 2 5 82 5225 17. Wouldntit be nice if every story was the same size? Every story is then a 1, or else a 247. Itdoesnt matter. Wecan do that by splitting stories until theyare all about the same size. This gets us all of the benefits of splitting atthe same time that it eliminates estimating. No need to estimate. This works exceptionally well in kanban. 18. StoryTask Pts IdealHoursConsolidated13Financial Report Design Integration2 Data Structure Import from first 6 data source 19. 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 atrick to help you get started. 20. Useideal hours for tasksTasks are small and so are hours. Ifyou estimate effort, then story points andideal hours are correlatedMore story points means more ideal hours because both estimate effort Now,since you estimate stories and tasksdifferently, the two estimates can be used asa sanity check 21. StoryPoints Sum of TaskIdeal HoursDisplay Time 24Enter Time 59ScaleChange Time35DisplaySet Y Axis Scale 112Change Y Axis37ScaleAdd Graph Title35 22. Variable part timers () Specialists () Learning curve () 23. Team Percent Project Days Total projectMemberAllocated Hours perAvailable hours daythis sprint available this sprintXianshen100610 60Brenda1006848Li 50310 30Mei 1006530Jiang 100610 60Daniel100610 60Total288Minus 10%ScrumOverhead26033 24. Always estimate Estimate when Relative estimationnecessaryusing Planning Poker Estimate by splitting Story Points and Ideal Affinity estimationHours No task estimation (or Capacity Planningno tasks!) Complexity, Effort, Capacity planningand Doubtwhen necessary 1 Story Point = 1 DayOld Days Nowadays