[原]Scrum Gathering开放分享:敏捷开发早期估算by火星人陈勇,北京,6.30!

标签: | 发表时间:2013-06-09 11:07 | 作者:cheny_com
出处:http://blog.csdn.net/cheny_com

本人受邀参加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

 

陈 勇

分享嘉宾: 陈 勇

具有丰富的工程技术与项目管理实践经验,从其程序员、项目经理、CMMI/FPA功能点估算/敏捷咨询师、事业部总监、副总经理等各种技术与管理岗位获得的一手经验,令其可以站在企业管理者的角度,以更广的视角来理解敏捷开发,并能配合和推动非研发部门协作推广敏捷。
作者:cheny_com 发表于2013-6-9 11:07:10 原文链接
阅读:194 评论:1 查看评论

相关 [scrum gathering 开放] 推荐:

[原]Scrum Gathering开放分享:敏捷开发早期估算by火星人陈勇,北京,6.30!

- - 陈勇的博客 - Scrum 敏捷开发培训咨询,绩效管理,团队管理,《火星人敏捷开发手册》
本人受邀参加Scrum Gathering的北京站,并在Open Space分享本届大会最富争议话题,欢迎现场参与:. 敏捷开发早期估算(开放分享). 7 讲师: 陈 勇 | 06月30日 13:00~06月30日 14:00 北京紫光国际大厦-主会场                 所属专题: 开放空间会议.

Scrum的故事

- Philip - 《程序员》杂志官网
2001年2月,17位敏捷先驱齐聚犹他雪鸟度假村,起草《敏捷宣言》的时候,Scrum只是众多方法中不太起眼的一个. 十年之后,Scrum却成为最流行的敏捷方法,几乎成为敏捷的代名词. 本文来介绍下Scrum的两位创始人——Jeff Sutherland与Ken Schwaber. 大家可能不会想到,Jeff Sutherland的第一份工作居然是美国空军战斗机飞行员,还曾于1967年获得了“壮志凌云”称号,完成过100次飞越北部越南的作战任务.

scrum经验

- - CSDN博客研发管理推荐文章
Scrum是基于过程控制理论的经验方法,倡导自组织团队;其运行框架核心是迭代增量型并行开发,也是“适应性”的软件开发方法. Scrum提供了高度可视化的用于管理软件开发复杂性管理的敏捷项目管理的实践框架或敏捷过程,可以用于对现存软件工程实践的包装,提高软件生产率,改善沟通和合作的方法,使人们协作并注重业务目标.

Trello中的Scrum

- - IT瘾-infoq
Trello的用户数量近期超越了1000万的大关,它正迅速成为各色敏捷团队中流行的工具. 它的简洁及在Web、移动端优秀的体验,使它从众多更复杂的解决方案中脱颖而出,赢得了更多的团队. 因为Trello完全不在意用户如何使用,所以导致用户在用它进行Scrum过程最佳实践时产生一些困惑. 去年,我就如何使用Trello及对Scrum和Kanban过程进行管理与很多人进行了交流,同时,我还翻遍了网上所有关于使用Trello管理敏捷过程的文章.

用Scrum的方式实施Scrum

- - CSDN博客研发管理推荐文章
       用Scrum的方式实施Scrum就是说组织利用Scrum的流程来实现组织的转型. 要成功实施Scrum,必须在组织内进行两项主要改变:首先,软件开发人员必须被派到小团队中,还需要教会他们如何使用Scrum进行软件开发;其次,移除所有有碍于优化创新和软件交付的障碍,这些障碍会随着Scrum的使用逐渐显现.

Scrum 实施经验

- bluesnail - 新浪UED
Scrum是一种迭代式增量软件开发过程,通常用于敏捷软件开发. Scrum在英语的意思是橄榄球里的争球. 虽然Scrum是为管理软件开发项目而开发的,它同样可以用于运行软件维护团队,或者作为计划管理方法:Scrum of Scrums. Scrum定义了许多角色,根据猪和鸡的笑话分为两组,猪和鸡:.

Scrum中的QA(一)

- - ITeye博客
来自“Priyanka Hasija”的经验,她认为QA在Scrum中要做到:. ① 不仅仅是完成test case,还可以作为Product Owner的代理,完成Acceptance test,在PO没有时间的时候代替PO和团队沟通,甚至通过质疑各种假设等方式帮助PO明确需求. QA在复杂的用户场景和异常流程方面更有感觉,这些可以帮助开发人员做估算时不仅仅考量“happy path”.

Scrum中管理bug

- - CSDN博客研发管理推荐文章
如果bug来自于正在开发的sprint. 会在task阶段就被QA/Scrum Master/Product Owner标记为有bug,并且Story不能被置为done状态,这个很容易解决. 如果bug来自于已经结束的sprint,那么怎么办呢. 理想状态下是将bug放到backlogs中,然后由product owner调整其优先级,并决定放在后面的哪一个sprint中修复.