Agile estimating planning agile tour shanghai 2010

Copyright UPerform 您的敏捷与项目绩效伙伴 �

Agile Tour China – 申城��᠋᠌᠍敏捷估算与计划概要

UPerform Consulting�优普丰顾问机构 �

www.UPerform.cn


简介 Introduction!

•  Bill Li （李国彪）


敏捷宣言 Agile Manifesto!

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

我们正在揭示更好的软件（成果）交付方法，我们使用它并且帮助其他人使用。通过这些，我们意识到：�

Individuals and interactions over processes and tools 个体及交互胜于流程与工具 �

Working software over comprehensive documentation 可用的软件（成果）胜于冗长的文档�

Customer collaboration over contract negotiation 与客户的协作胜于合同谈判 �

Responding to change over following a plan 对变化的响应胜于遵循计划�

That is, while there is value in the items on the right, we value the items on the left more.*”

也就是说，我们认可右边事项的价值，但我们更加重视左边的事项�

* www.agilemanifesto.org: © 2001, the above authors this declaration may be freely copied in any form, but only in its entirety through this

notice


预定义（理论的）过程 vs. 实验性过程�Defined （Theoretical）vs. Empirical Process

 命令及控制 Command & Control �

 对你预计会发生的进行计划 Predict and plan upfront �

 强制按计划，不管条件的变化 Enforce the Plan �

 使用变更控制 “Control” Change �

 边前进边学习 Learn as we go �

 计划好会变更（需求，工作环境，市场等）Plan to change �

 欢迎变更 Embrace Change �

 使用检视及适应调整 Inspect and Adapt �

Thanks to Peter Borsella


敏捷的心 The Agile Heart!

The Courage of Geese

大雁的勇气 �“It is typical to adopt the defined (theoretical) modeling approach when the underlying mechanisms by which a process operates are reasonably well understood. When the process is too complicated for the defined approach, the empirical approach is the appropriate choice.”

在过程运行的根本机制相当简单易懂的情况下，典型做法是采用预定义的（理论的）建模方式。若过程复杂程度超出预定义方式的能力范围便应选用实验性方式。  Process Dynamics, Modeling and Control, Ogunnaike and Ray, Oxford University Press, 1992



敏捷的心 The Agile Heart!



h:p://bucf.files.wordpress.com/2008/09/general_of_the_army_dwight_d__eisenhower_1947.jpg

Plans are nothing; planning is everything 计划本身不重要；持续做计划才是硬道理

– Dwight D. Eisenhower 艾森豪威尔


我们应该怎样应对？ �

我们基于现有的信息做决策⋯⋯经常做 �

不做多而全的一次性决策⋯⋯分布到项目进程中 �

－－－使用“用户故事”⋯⋯一起做 �


沟通，计划与决策中的力量平衡 �

•  如果业务（产品）人员完全支配 �–  单方制定要交付的功能和交付日期，可能会不管交付人员是否清楚需求和有没有能力交付 �

–  可能会要求进行详细的大而全的前期需求定义，甚至签名锁定 �–  通常期限快来临时加人，加班，降低质量，或者所谓的违约 �–  ⋯⋯ �

•  如果开发人员完全支配 �–  会使用更多的技术语言来代替业务语言来描述需求 �–  开发人员可能不去真正聆听和理解用户和产品业务的需要 �–  也有可能为了交付更复杂和大而全的系统而牺牲质量，或单方面简化功能细节 �

–  可能单方面作出一些产品人员或用户应该参与的决策 �–  ⋯⋯ �


迭代

发布

优先级

高

低

未来的发布

价值

成本

风险

知识

典型的敏捷需求管理方式：��᠋᠌᠍拉动式－渐进式需求管理 (Pulled and Evolving) �

Thanks to Daniel Teng & Mike Cohn


计划洋葱 (Planning Onion) �

每日

迭代

发布

产品

组合

战略

团队关注点

Strategy, PorSolio, Product, Release, IteraVon (Sprint), Daily

Thanks to Mike Cohn


The “Iron Triangle” of Project Management 项目管理的“铁三角”!

Scope 范围�

Cost 成本� Time 时间�

传统方法：项目范围驱动项目预算及工期

(Traditional: Scope Drives

Cost and Duration) �

Quality 质量？�


The “Iron Triangle” of Project Management 项目管理的“铁三角”!

Scope 范围�

Quality 质量� Time 时间�

敏捷方法：围绕价值，质量及工期驱动项目范围。而且可能是不断适应调整的。�

Value/ROI 商业价值�

Agile: Business Value Driven, based on Quality and DuraVon, to determine scope


Scrum敏捷项目管理价值观!

•  商业价值的尽早交付及按优先级别交付可能比项目范围完成的完整性重要�•  尽早的，频繁的交付可用的软件（成果）可能比整个项目什么时候完成重要�•  可用的软件（成果）是主要的项目进度衡量指标�•  因为我们关注价值及结果，所以我们是以客户或用户及市场为导向�•  时刻关注质量，降低长期的成本�•  软件项目中最大的风险是在后期发现产品方向或设计上的错误以及质量的重大缺陷�

•  所以我们频繁的测试及检视�•  真正的需求是不可能在项目前期全部明确的�•  所以我们通过频繁的检视与适应调整来把握需求及降低风险�•  并且通过频繁的检视与适应调整来响应市场及需求的变化�


eLearning： RelaVve Size 相对大小－－国家面积!


Agile EsVmaVng 敏捷估算 �

我们着眼于相对的投入（Size of Effort)，或者大小，以区别于用时间进度。为什么？�

•  允许交付条件的不同（比如谁来完成工作等） •  允许自修正的开发速度（比如对工具用熟练时速度变快，但故事的规模应该是不变的）�•  通常比用估算绝对数值更快更容易


计划扑克 Planning Poker �

团队里的每一人会用计划扑克（或普通的扑克牌）来代表相对投入的大小： �Ace = 1 Deuce = 2 Three = 3 Five = 5 Eight = 8 Jack = 13 Queen = 20 King = 40

(For you math wizards, this is a distorted Fibonacci series)


敏捷估算 2.0 �

Thanks to Steve Bockman & Brad Swanson

US#7

US#6 US#5 US#4

US#3

US#2 US#1

US#8

1 5 2 3 8 13

最后才为大小赋值（故事点）

可能会有缺口！


•  把最高优先级的用户故事卡放在中间（桌上或者板上） �•  团队成员轮流作进行下面操作之一（直到这次要估算的故事都已经放进来）： �

–  把下一个故事放进来一个其认为合适的位置 �–  挪动一个已经放进来的故事到新的位置 �（左小，右大，卡片间的距离代表相对大小的差异，放在另一个故事的下方代表其大小差不多） �

（一个成员操作时，其他成员只能提问，不能发表自己的观点） �

•  当所有这次要估算的故事都放进来后，可以再轮流操作一轮 �•  集体为目前的估算赋值（Fibonacci, Power of 2⋯⋯) �•  最后讨论一下还有没有需要调整估算的故事（Color Coding⋯⋯) �

•  (另一种方法：动态团队估算） �

敏捷估算 2.0 －说明 �

Thanks to Steve Bockman & Brad Swanson

UPerform Your Agile and Project Performance Partner �UPerform Your Agile and Project Performance Partner �

33个层次的计划��᠋᠌᠍3 levels of Planning �

Thanks to Mountain Goat Software, LLC


Velocity 速率 �

针对不同的情形有不同的方法： �

  历史数据 �  尝试1－2个迭代 �  尝试1－2个故事 �  直接估算，以后调整 �


Velocity 速率 �

建议一直采用速率范围（Mike Cohn: always use a velocity range) �

有不同的方法得出范围区间值： �  估算一个速率（使用承诺驱动得出），直觉判断范围（“我们就用 +－ 15%”) �  或者利用其他团队历史数据的相对标准差（“SD/mean = 17％”） �  如果你们团队有历史数据，计算可信区间（Confidence Interval) �


使用 Confidence Interval �

Thanks to Mike Cohn


固定范围发布计划 Fixed-scope Release Planning!

  我们最多需要几个Sprint？（总的故事点/低速率） �  我们至少需要几个Sprint？（总的故事点/高速率） �  我们有可能需要几个Sprint？（总的故事点/中间速率median） �

  同样的，我们可以做固定日期(Fixed-date)的发布计划⋯⋯ �

  通常基于这样的原始发布预测，再来考虑人手问题，也就是成本问题（我们一直都先假设固定的迭代成本，记得“敏捷项目管理铁三角”） �

  也可以先不考虑人手问题⋯⋯ �


Release Planning 发布计划 �

迭代: 1

Capacity: 40 Allocation: 42

迭代: 2


迭代: 3


迭代: 4


迭代: 5


迭代: 6


产品发布�

Goal – Beat the competition 目标－赢得竞争�



Sprint Planning 的目的 �

  主要目的是：对Sprint的目标（准备交付的产品Backlog事项）达成共识并作出集体承诺 �

  任务分解和任务估算是确定Sprint目标的手段之一，充其量只是次要目标 �

  另外一个益处可能是知识和经验的分享 �  以及对需求的进一步讨论和解决方案的初步探讨 �


2种方式速率驱动 vs. 承诺驱动的计划方式��᠋᠌᠍

Velocity Driven vs. Commitment Driven �

  速率驱动：“我们上次Sprint完成15个故事点，这次就选择15个点的故事作为Sprint的目标。” �

（Yesterday’s Weather) �

  潜在问题：速率会波动，而且可能会很厉害 �

  速率主要用于中长期的规划（例如发布计划），因为⋯⋯ �


承诺驱动的Sprint计划方式!

  团队讨论产品Backlog中最高优先级的事项 �  将其分解成任务 �  团队估算每一个任务（理想小时） �  团队自问：我们可以承诺完成这批任务吗？ �

  如果可以，取下一个产品Backlog（PBI） �  如果不可以，把此PBI放回，看看可否取另一个小的PBI �

  团队容量：需要团队这个Sprint总的理想小时数（可以是一个范围，沙桶 vs. 水桶） �

  速率数据？ �


The Daily Scrum（Daily Standup Meeting) 每日例会 �

•  频密检视和适应点 �•  变量： �•  每天！ �•  不超过15分钟 �•  站立 �

•  并不是一个问题解决会议： �•  让团队成员之间通报信息 �•  可以邀请其他人参加 �•  只有团队成员、ScrumMaster及PO可以发言（记得“鸡”与“猪”） �•  可以在你们的项目任务板前面进行 �

•  若需要问题解决会议，相关人员在会后自组织进行 �

Thanks to Daniel Teng for the picture


每个人都主动回答三个问题 �

•  记住，这并不是对ScrumMaster的进展状况汇报 �•  这些回答是在团队面前的信息分享，属于自管理的一部分，也是个人对团队的承诺 �•  通常ScrumMaster负责记录问题与障碍（障碍Backlog） �•  通常会后就可以更新迭代 Backlog 与 Burndown �

我过去一天做了什么、完成了什么? 1

我下来一天准备做什么、完成什么? 2

我碰到什么问题与障碍? 3

Thanks to Mountain Goat Software, LLC


Q&A

敏捷是人们之间及其与这个世界之间互动的态度，及方式

开放思维、乐活乐工勇敢专注、敏捷共赢

[email protected]

Twi:er: @ScrumChina

Documents

Agile estimating planning agile tour shanghai 2010