2013-06-09 11:07:10 cheny_com 阅读数 4055
  • 敏捷开发实践

    本课程集中介绍敏捷开发的实践,包括: 如何编写用户故事,如何进行故事估算? 如何根据特定条件判断需求的优先级? 敏捷方法中最常用的看板方法如何使用?看板原理如何理解? DOD与SOS案例

    78 人正在学习 去看看 黄啟河

本人受邀参加Scrum Gathering的北京站,并在Open Space分享本届大会最富争议话题,欢迎现场参与:


敏捷开发早期估算(开放分享)

7
讲师:陈 勇 | 06月30日 13:00~06月30日 14:00 北京紫光国际大厦-主会场                 所属专题:

agiel-estimating

 

序:

By 专题制作人:李忠利

“响应变化胜过遵循计划”,所以敏捷开发中的估算过程主要指在每个迭代计划会中,由开发人员自主估算本次迭代的工作内容。可是,随着一个个迭代结束,开发人员可能才逐渐感觉到整个项目需要一年,而实际上,高层领导早就签订合同或立项要求整个项目在半年内完成……而这个项目如果真的超期了一倍,那么到底是高层领导的决策失误,还是团队的生产率只有别人的一半?

这就让我们不禁想问:

有没有一种方法,在签署合同或立项前,仅仅凭借几页Word和有限交互,就能把十几人年的项目推算到±20%的精度内?

有没有一种方法,不仅能在早期做估算,还能把估算结果直接演进为敏捷开发中的史诗故事和用户故事?

有没有一种方法,不仅能让开发者意识到代码的不断增长,也能让客户和领导同步地理解并认可需求的蔓延?

有没有一种方法,能在项目结束时,简单数数史诗故事和用户故事,就能将项目的完成情况与此团队的历史做纵向比较,甚至还能与其他团队、乃至业界的数据做横向比较,并让客户和老板信服?

……

这注定是一个极富争议的话题,从开始到最后,专题制作人和评审组的意见一直大相径庭。我们见过有争议的话题,但从未发生过分歧如此之大的事情!

在Scrum Gatheing北京的Open Space中, “火星人”创始人兼首席架构师陈勇,将向大家展示如何使用这种方法的经验总结。

06/29-06/30,北京Scrum Gathering,不见不散!

话题介绍 :

众所周知,敏捷开发中的估算过程主要集中在迭代计划会中,由开发人员自主估算本次迭代的工作内容。可是,如果开发人员的估算推测整个周期需要一年,而整个项目已经立项要在半年内完成,该如何处理?

本讲座所涉及的早期估算方法引入了功能点分析FPA的概念,可以让产品经理在项目之初勾勒功能轮廓的时候,基于非常少的信息和文字即可大致推算出所需的工时。此功能轮廓的描述内容还能在进一步的开发过程中,直接演进为有相对固定颗粒度的史诗故事和用户故事。

此早期估算方法的主要来自IIOM(国际外包管理协会)“火星人敏捷开发平台”本身的研发过程的经验总结。

目标受众:产品经理/PO,项目经理

文中涉及的讨论在此链接中有详尽描述(应PMBar邀请所作的三次在线研讨汇总)http://blog.csdn.net/cheny_com/article/details/7692917

整体脉络如下,点击小图看大图:

1. 开发人员只需要在迭代前选择少数故事进行少量精细估算,而产品经理需要面对海量故事且可能在甚早期(立项,报价)进行粗略估算,怎么办?

2013-05-03_113605

2. 用户故事(从下面数第三个蓝条)跨度从1D到2M不等,无法简单地通过计数来进行早期估算;但功能点的业务操作(EI/EO/EQ即常说的增删改查)和业务数据(ILF/EIF即常说的信息点、实体)则存在非常一致的绝对尺寸。

2013-05-03_113625

3. 通过计数业务数据ILF可进行甚早期估算(这是NESMA的第二级简化方法)

2013-05-03_113651

 

4. 业务数据判断规则和修正系数(用于不同难度的应用),此规则比IFPUG和NESMA的规则略通俗化,但结果为1:1。

2013-05-03_113704

5. 业务数据(ILF/EIF)演进为史诗故事也叫数据故事,业务操作(EI/EO/EQ)演化为传统的用户故事(作为一个……可以……以便……)

2013-05-03_113731

6. 增强/重构/缺陷/债务是更小颗粒度上的故事,不属于客户理解的“产品的业务功能”

2013-05-03_113745

7. 通过将增强/重构/缺陷/债务等子故事关联到数据故事(史诗故事)或操作故事(即“作为一个……可以……以便……”)来进行管理

2013-05-03_113819

8. 这一方法能使用同一套数据同时打通下图中的7种管理方法或实践。

2013-05-03_113836

 

2013-07-14 13:49:25 cheny_com 阅读数 4146
  • 敏捷开发实践

    本课程集中介绍敏捷开发的实践,包括: 如何编写用户故事,如何进行故事估算? 如何根据特定条件判断需求的优先级? 敏捷方法中最常用的看板方法如何使用?看板原理如何理解? DOD与SOS案例

    78 人正在学习 去看看 黄啟河
 7月16日周二晚上7:30~9:00,陈勇,【敏捷网络课堂第六期】【免费】敏捷开发早期估算
课程简介:
“响应变化胜过遵循计划”,所以敏捷开发中的估算过程主要指在每个迭代计划会中,由开发人员自主估算本次迭代的工作内容。可是,随着一个个迭代结束,开发人员可能才逐渐感觉到整个项目需要一年,而实际上,高层领导早就签订合同或立项要求整个项目在半年内完成……而这个项目如果真的超期了一倍,那么到底是高层领导的决策失误,还是团队的生产率只有别人的一半?
这就让我们不禁想问:
有没有一种方法,在签署合同或立项前,仅仅凭借几页Word和有限交互,就能把十几人年的项目推算到±20%的精度内?
有没有一种方法,不仅能在早期做估算,还能把估算结果直接演进为敏捷开发中的史诗故事和用户故事?
有没有一种方法,不仅能让开发者意识到代码的不断增长,也能让客户和领导同步地理解并认可需求的蔓延?
有没有一种方法,能在项目结束时,简单数数史诗故事和用户故事,就能将项目的完成情况与此团队的历史做纵向比较,甚至还能与其他团队、乃至业界的数据做横向比较,并让客户和老板信服?

网址:http://www.duobei.com/room/5350757421  
课程资源:http://download.csdn.net/detail/cheny_com/5751351 (需要注册,无需积分)

CSDN什么时候也开设网上课堂就好了:)
2013-07-14 23:10:00 weixin_30847939 阅读数 2
  • 敏捷开发实践

    本课程集中介绍敏捷开发的实践,包括: 如何编写用户故事,如何进行故事估算? 如何根据特定条件判断需求的优先级? 敏捷方法中最常用的看板方法如何使用?看板原理如何理解? DOD与SOS案例

    78 人正在学习 去看看 黄啟河
 7月16日周二晚上,陈勇,【敏捷网络课堂第六期】【免费】敏捷开发早期估算
课程简介:
“响应变化胜过遵循计划”,所以敏捷开发中的估算过程主要指在每个迭代计划会中,由开发人员自主估算本次迭代的工作内容。可是,随着一个个迭代结束,开发人员可能才逐渐感觉到整个项目需要一年,而实际上,高层领导早就签订合同或立项要求整个项目在半年内完成……而这个项目如果真的超期了一倍,那么到底是高层领导的决策失误,还是团队的生产率只有别人的一半?
这就让我们不禁想问:
有没有一种方法,在签署合同或立项前,仅仅凭借几页Word和有限交互,就能把十几人年的项目推算到±20%的精度内?
有没有一种方法,不仅能在早期做估算,还能把估算结果直接演进为敏捷开发中的史诗故事和用户故事?
有没有一种方法,不仅能让开发者意识到代码的不断增长,也能让客户和领导同步地理解并认可需求的蔓延?
有没有一种方法,能在项目结束时,简单数数史诗故事和用户故事,就能将项目的完成情况与此团队的历史做纵向比较,甚至还能与其他团队、乃至业界的数据做横向比较,并让客户和老板信服?

网址: http://www.duobei.com/room/5350757421  
课程资源: http://download.csdn.net/detail/cheny_com/5751351 (需要注册,无需积分)

CSDN什么时候也开设网上课堂就好了:)

 

转载于:https://www.cnblogs.com/dyllove98/p/3190250.html

2019-08-22 17:08:56 weixin_44280696 阅读数 162
  • 敏捷开发实践

    本课程集中介绍敏捷开发的实践,包括: 如何编写用户故事,如何进行故事估算? 如何根据特定条件判断需求的优先级? 敏捷方法中最常用的看板方法如何使用?看板原理如何理解? DOD与SOS案例

    78 人正在学习 去看看 黄啟河
高质量的估算能够帮产品负责人优化效率和冲突。因此,精准估算的重要性毋庸置疑。

估算并非易事。对软件开发人员来说,估算堪称是最难的工作之一。估算必须考虑所有能帮助产品负责人做出影响整个团队和业务决策的因素。因此,从开发到高管都为它焦头烂额也不足为奇,但这种做法是错误的。敏捷估算并不是什么性命攸关的大事,就只是估算而已,事实就这么简单。
我们不用要求团队周末加班加点来弥补一项被低估的工作。换句话说,与其事后补救,不如事前看一看有什么方法可以让敏捷估算尽可能变得更精准。

与产品负责人(PO)合作

敏捷开发中,产品负责人 要负责确定backlog的优先级次序——即一个按优先级排好序的工作列表,其中包含关于产品所有所需完成的功能和修复的缺陷的简短描述。产品负责人能够从业务中提取需求,但他们不一定了解具体如何实现。因此,精准的估算能让产品负责人对每个工作项目的工作量有新的了解,这对他们评估每个项目的相对优先级能起到一定作用。
开发团队开始估算后,关于需求和用户故事的问题会经常出现。这是一件好事:这些问题可以帮整个团队更加充分的理解工作。对产品负责人来说尤为特别,将工作项拆解为粒度较小的任务,然后通过估算故事点帮助他们确定所有(和可能隐藏的)工作的优先级。而一旦他们得到开发团队的估算后,可能会再重新排列backlog中的工作项。

敏捷估算是一项团队工作

敏捷估算的关键在于全员(包括开发人员、设计人员、测试人员、部署人员……等等)参与。团队每个成员都能就产品和需要交付的工作贡献一个用户故事。例如,如果产品管理者想要实现支持新浏览器这一看似简单的功能,开发和QA就需要谨慎权衡,因为他们的经验告诉他们这个看似简单的需求背后可能隐藏巨大的困难。
同样的,设计的变更不仅要设计团队的投入,还需要开发和QA人员的参与。缺乏全员参与的估算会降低估算质量,也会导致团队士气低迷,因为关键的贡献者会认为自己被排除在外。所有这些因素都会影响最终交付的软件质量。
因此,不要让你的团队成为封闭估算的受害者。封闭状态下的估算只会加速失败。!

故事点和小时数

传统的软件开发团队以时间为单位来估算工作量,例如:天、周、月等等。而敏捷团队大多采用故事点为计量单位。故事点的相对规模(工作量)用斐波那契数列如0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100表示。这听起来似乎有点有违常理,但这种抽象的表述实际上能够促使团队针对工作的难点做出更果断的决策。下面是使用故事点的几点原因:

  • 以日期为单位,无法计量那些无法避免的非项目相关的工作,如需要团队成员参与的电子邮件、会议和访谈等。
  • 日期可会存在一定的感情因素,而相对估算则可以剔除感情因素。
  • 每个团队估算工作的范围略有不同,这意味着团队的速度(以故事点为计量单位)自然也会有所不同。反过来,这样就可以避免出现以速度为争端的团队间的勾心斗角。
  • 一旦团队就每个故事点价值的相对工作量达成一致,团队就可以在无争议的情况下实现点数的快速分配。
  • 故事点能够激励团队成员以工作难度而非耗费的时间为基础来解决问题。这确保团队成员能专注于价值交付,而不是强调花费了多少时间。

故事点和计划扑克

使用故事点进行估算的团队会用计划扑克的形式来统一团队的估算值。团队从backlog中抽取一个工作项,简单地讨论之后,请每个成员在脑海里构思一个估算。然后每个人拿一张卡片,写下自己的估算值,由scrum master收齐卡片后展示每位的估算值。如果估算一致,那么讨论结束,如果存在不同的估算值,就花点时间(无需太久——几分钟即可)了解为什么成员给出了不同的估算。记住,估算讨论应该抓大放小、提纲挈领,如果团队过于纠缠细节,则暂停讨论,提升讨论的水平和高度之后再继续。

精准估算讲究效率,无需浪费时间

任何单个任务都不应花费超过16小时。(如使用故事点,则可以设置20个故事点为上限)。如果单个工作项超过这一工作量,对其进行精准估算会更难。而精准估算对于位于backlog顶部的工作项来说尤为重要。如果单个工作项的估算超过了16小时(或20个故事点)的上限,意味着我们需要将其拆分为更小的工作项并重新进行估算。
对于那些位于backlog下方的工作项,可以只进行粗略估算。因为等到团队真正开始要做该工作项时,需求可能已经发生了变化,相应的应用程序肯定会有所变化。因此,先前的估算可能就会不那么准确。所以不要浪费太多时间去估算那些可能会发生变更的工作项。只需要提供粗略的估算,为产品负责人提供一个可以用来确定产品路线图优先级次序的大概数据即可。

借鉴以往估算的经验

回顾会议是团队从已完成的迭代中总结经验教训的机会,当然也包括估算准确性总结。很多敏捷工具可以跟踪故事点,这让团队可以更轻松地反思和调整估算。例如,我们可以尝试提取过去故事点估算值为8 的5个用户故事,讨论每个工作项的工作量是否大致相同。如果存在差异,讨论其背后的原因。然后将讨论得到的经验用于未来的估算。像敏捷的其他实践那样,估算也是一项熟能生巧的实践。因此团队肯定会越做越好。

翻译/校对:Worktile

文章来源:Worktile敏捷博客

欢迎访问交流更多关于技术及协作的问题。

文章转载请注明出处。

2019-12-10 10:57:17 weixin_44280696 阅读数 90
  • 敏捷开发实践

    本课程集中介绍敏捷开发的实践,包括: 如何编写用户故事,如何进行故事估算? 如何根据特定条件判断需求的优先级? 敏捷方法中最常用的看板方法如何使用?看板原理如何理解? DOD与SOS案例

    78 人正在学习 去看看 黄啟河

敏捷估算的价值

  敏捷估算,就是在敏捷开发中,对即将开始的工作进行工作量、复杂度和持续时间的相对估算。通常情况下,软件开发过程中有很多未知数:技术更新,需求变更,系统之间的依赖关系等,它们都会影响估算结果,所以说估算是一项费时费力的工作,并且得到的结果也是不精确的。既然如此,我们为什么还需要进行敏捷估算呢?

  1. 估算和计划是紧密相关的,估算结果是计划的重要依据。决策者需要这个估算结果,来调整需求优先级,进行资源安排,甚至砍掉这个功能。
  2. 对客户来说,估算结果可以给出一个功能上线的预期更甚至于承诺,尽管这不是绝对准确的。
  3. 估算对团队来说,给了团队一个机会来提前讨论需求,建立对需求一致的理解,消除疑问。
  4. 估算需要团队深入研究还未开始工作,提前考虑将会涉及到的团队合作甚至是跨团队的合作,大大提升实际工作中的团队效率。

  估算的初衷虽然是得到完成功能时间的预期,但是我认为这项活动最重要的价值在于估算过程中对需求建立的深入理解,以及事先为实现功能的方法和策略做的全盘考虑。这一定会在接下来的实际工作中起到相当重要的作用,甚至决定了整个迭代能否完成目标。

为什么使用故事点

  估算是一件很困难的事,它同所有预测未来的事情一样,结果往往都存在巨大的误差。想要得到精确的预测结果,则需要花更多的时间来了解细节。而团队进行估算所花时间的边际效益必然是递减的,因此花太多时间在估算上是相当不划算的。那我们该如何进行估算?

  别忘了,人类的本质是什么?不是说复读机!

  我的意思是,人类生来更擅长相对估算而不是绝对估算。因此,相对值的估算会更快和更容易理解。比如,我面前有两栋楼,一栋的高度是另一栋的两倍,我可以迅速判断出来。但是我可能无法得出一栋楼是100米,另一栋是200米的结论。所以,在敏捷估算中,我们引入了故事点。

  故事点是一个对工作量、复杂度或者持续时间进行估算的相对计量单位,最早在scrum和极限编程这一类的敏捷方法中开始使用。因为主要估算对象是用户故事,所以被称为故事点。

  杠精本精有必要出来杠一下了,故事点不一样是1个故事点,2个故事点的度量单位么,怎么就成相对估算了?

  这是因为故事点的大小没有标准。也就是说,每个团队的故事点都是不一样的。对一个团队来说3个故事点的工作,可能对应了另一个团队5个故事点的工作。用故事点进行估算,我们不会说这个功能需要100个小时来完成,而是说这个功能是8个故事点,工作量大概是4个故事点的某功能的两倍。

  故事点采用数字计数同时也带来了一个问题,它会让人自然的想追求精确,这和相对估算是冲突的。因此,我们建议采用斐波那契数列(0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144)来进行估算。因为当一个需求的估计值越大的时候,我们进行估算的结果误差也越大。我们要避免去纠结这个需求到底是20个故事点还是21个故事点,这是没有任何意义的。

** 估算的对象**

  由于估算需要我们同时做到尽量快速和准确,所以估算的对象选择也是相当重要的。敏捷开发中,需求经常被分为史诗、特性和用户故事三个等级,用户故事下又能拆分成任务。这么多类型,我们到底对谁进行估算?

  首先,过大的工作量会导致估算结果误差过大,导致史诗和特性不太适合故事点估算。其次,任务又太过细致,对任务进行估算的话耗费时间。所以,按排除法我们还剩下用户故事。(当然,根据实际情况,有时候我们也可以对特性或者对缺陷进行估算。)

如何进行估算

  估算的结果是属于团队的,不属于个人。首先,因为负责某个需求的人并不确定,所以整个需求是由团队负责。其次,团队决定的估算点数可能比个人估算更加合理。更重要的是,团队一起估算时,团队成员针对一个需求的讨论和见解分享是整个团队成长的契机。因此,比起个人估算,我们建议进行团队估算,团队中绝大部分成员参与估算是有必要的。

我们常用的团队估算方法是扑克估算,具体操作流程如下:

  1. 每个团队成员分发一套写着0、0.5、1、2、3、5、8、13、20、40、∞、?的卡片。
  2. 产品负责人负责讲解需求待办列表挑选出来的需求,团队成员提出自己的疑问,产品负责人一一解答。
  3. 团队成员进行估算,选出自己估算结果对应的卡片盖在桌上,不要告知其他团队成员。
  4. 所有人都确认自己的估算结果后,大家一起翻开卡片,展示自己的估算结果。
  5. 团队评估估算结果,让给出估算点数最大和最小的成员分别陈述自己给出当前结果的理由,团队讨论,消除分歧,得到一致的结果。(这一步尤为重要,讨论过程是团队分享知识和经验绝佳机会。)
  6. 选择下一个故事,重复第2步。

  不过,既然到了斗地主都必须是在线活动的9012年了,扑克估算这种小事当然不再需要人手一副纸质卡片。

** 一、在线创建房间,添加估算需求,支持多种打分方式(扑克估算、T恤估算)。**

image.png

二、成员快速打分,标记最高最低分,支持多种得分计算方式(算术平均数、切尾平均数、中位数、众数、自定义)。

image.png

三、记录最终结果,随时回顾。

image.png

  这么好用的宝贝哪里找?扫一扫下图二维码就可以啦!

image.png

“划重点”

  • 故事点对于不同团队有着不同的定义。所以故事点不能作为评估团队绩效的标准!同时也要避免估算时点数膨胀,给出真实的估算结果。
  • 估算的时候保证参与成员都对估算对象有足够的了解,有疑问的地方一定要提出并得到产品负责人的解释。
  • 不要过度关注故事点的绝对大小。保证3个故事点的需求比2个故事点大,比4个故事点小就够了。
  • 团队有必要始终坚持统一的故事点标准。
  • 请使用上面的小程序进行敏捷估算。

本文作者:Worktile 产品经理 彭东锴

文章来源:Worktile敏捷博客

欢迎访问交流更多关于技术及协作的问题。

文章转载请注明出处。

没有更多推荐了,返回首页