• 00
  • 00小时
  • 00
  • 00
2023敏捷武林大会-上海站,正火热免费报名中...
Search
Close this search box.

巧妙使用“故事点”进行敏捷估算

克强在“敏捷中国”讨论组中引发对敏捷的估算的讨论(“Scrum sprint plan中规模估算的做法调查”,“关于story point的单位”)。我想分享一下我自己对敏捷估算方法的理解以及对于“故事点”的认识。

在敏捷开发中,团队通过两种方法对迭代做计划。
  • 基于承诺”Commitment”。做法很简单:
    • Product Owner从Product Backlog中取下一个用户故事(按照优先级),对这个用户故事进行解释,
    • 团队对用户故事进行讨论,明确需要解决的问题,
    • 整个团队确定是否能够在下一个迭代周期中完成这个故事,
      • 如果团队没有信心完成该故事,计划会议结束,或者把这个用户故事进一步划分成更小的用户故事重复第一步。
      • 如果团队有信心完成该任务,重复第一步。
  • 基于速率”Velocity”
    • 确定Product Backlog中用户故事的规模(用“故事点”)
    • 确定团队迭代的开发速度(“昨天的天气”)
    • 从Product Backlog中取出相应量的用户故事。
基于速率的估算中,需要确定一个“故事点”,也就是确定一个速度的单位。而在敏捷计划与估算计中,这个“故事点”是没有单位的。为什么?首先来看一下传统的规模估算的方法(标准日、代码行数)的问题。
  • 绝对估算 vs. 相对估算
    传统的方式是通过计算出一个绝对值(有单位,比如多少人天,多少代码行)。然后,做出计划。很大的问题是,人天生不擅长做绝对估算,人们更擅长做相对估算,更容易在相对估算值上达成共识。举一个简单例子,估算从上海市人民广场到徐家汇的距离,如果使用公里或者米等绝对单位,多个估算者很难达成共识,往往陷入没有必要的讨论和争吵。而如果用相对距离,比如从人民广场到徐家汇的距离相当于两倍的从人民广场到火车站的距离,人们就很容易、很快达成共识。因此对一个需求点来说,关注于相对大小也更容易使整个团队在估算值上达成共识。
  • 关注规模(而不是将不同维度的概念混淆)
    比较合理的估算方法是,首先估算整个规模,然后有一定的历史数据,知道速度,从而可以做出计划,推算出时间。比如我们看书,一共三百页,一天看十页,很容易就算出是三十天。如果使用理想日(时间维度),其实就是把这个过程搞反了,从时间维度反过来推算规模。同时使用“故事点”可以综合考虑一些其他因素包括复杂度、不确定性等,基于故事点的规模估算是在综合考虑各种因素之后的综合估算。而用代码行数很难对复杂度、不确定性等作出估算
  • 忽略个人能力的不同
    不同人的理想日和代码行数估算是不同的,是根据每个人的能力和认识的不同而不同的。但是使用关注“相对大小”的“故事点”就可以解决这个问题。同样举距离的例子,每个人的能力是不同的(有人步行、有人跑步、有人公车、有人地铁、有人开法拉利),但是所有人得出的相对规模值还是一样的。因此使用相对规模估算就可以不需要考虑这种个人能力因素。
  • 不可相加
    传统估算方式的一个很大的问题是,估算不能相加。每个人的理想日是不一样的,这样成员甲的估算(理想日)就不能和成员乙的估算(理想日)相加。基于这种相加结果的计划肯定是不准确的。在敏捷开发中,需要整个团队一起对任务进行估算,因此需要一个能够达成团队共识的标准 – 也就是“故事点”。
因此,为什么“故事点”没有单位?
  • 首先,故事点是一个相对量,相对值是没有单位的;小学乘法:被乘数 × 倍数 = 积。故事点估算值就是这个倍数。
  • 其次每个团队的单位“故事点”是不同的,很难也不需要统一。
最后,其实敏捷的计划估算与传统的计划估算很大的不同是对计划的态度。在敏捷开发中,计划估算只是一个对未来的预测,因为是一个预测,所以总是有不确定性。敏捷开发计划承认这种不确定性,因此对计划估算的态度应该是不断根据新的发现,对计划进行不断的调整,但是不需要过于关注预测的准确性(我们的工作是为客户开发有用的软件,而不是提供可靠的计划。如果公司以预测的准确性来衡量员工的绩效,那其实大家也该考虑换一个地方了,这又是一种局部优化)。

关于作者:

爱迪德高级软件经理,InfoQ中文站特约编辑。他是亚洲第一位也是目前唯一一位认证Scrum教练(Certified Scrum Coach)Daniel具有多年的敏捷项目(Scrum & XP)实践经验以及丰富的带队经验。

Daniel20061月创建了Irdeto上海研发团队,并将ScrumXP成功引入了团队。目前该团队主要负责数百万美金级别的大型付费媒体计费及客户关系管理系统的开发及维护,四年中成功发布产品的两个新版本。系统现在在美洲、欧洲以及亚洲的许多国家运行。

Daniel一直致力于将海外的敏捷思想、理论及方法以及实践介绍到国内,帮助国内的软件团队高效并有趣地工作,真正为客户创造价值。作为敏捷社区的活跃分子,Daniel通过博客、InfoQ以及讨论组等宣传敏捷。Daniel经常受邀到各个会议中针对敏捷话题进行演讲,他是敏捷中国2009的讲师,并受邀QCon北京2010以及在CSDN举办的软件开发2.0大会2009等中作关于敏捷的演讲。

Dianelblog: http://www.cnblogs.com/tengzy/

Search
最新敏捷认证课 ~ 火热报名中
3月30-31日
Scrum Master (CSM) 认证课
张宁宁 Lance Zhang 授课
4月20-21日
Leading SAFe领导大规模敏捷认证课
Eric & Scott 授课
4月20-21日
专业Scrum Master (PSM I) 认证公开课
丁志润 Derek Ding 授课
6月22-23日
专业Scrum产品负责人(PSPO)认证公开课
丁志润 Derek Ding 授课
分类文章
9月15-17日
SAFe ScrumMaster & Leading SAFe官方认证双证班
Eric Liao & Scott Wang 授课
9月18-22日
SAFe认证-SPC SAFe认证培训师导师班
Kurt Jäger & Eric Liao 授课

预约回电

课程顾问将尽快给您回电
电话咨询 400 696 6280