敏捷开发--scrum应用指南
hanqunfeng
这个作者很懒,什么都没留下…
展开
-
sprint目标
出于某些原因,制定sprint目标确实很困难。 但我发现即使是像挤牙膏一样把它挤出来,那也是值得的。半死不活的目标也比啥都没有强。 这个目标可以是“挣更多的钱”,或者“完成优先级排到最前面的三个故事”,或“打动CEO”,或“把系统做的足够好,可以作为beta版发布给真正的用户使用”,或“添加基本的后台系统支持”等等。 它必须用业务术语表达,而不是技术词汇,让团队以外的人也原创 2009-11-14 17:31:00 · 1491 阅读 · 0 评论 -
sprint计划会议的优先级
优先级1:sprint目标和演示日期。这是启动sprint最起码应该有的东西。团队有一个目标,一个结束日期,然后就可以马上根据产品backlog开始工作。没错,这是不像话,你应该认真考虑一下明天再开个新的sprint 计划会议。不过如果确实需要马上启动sprint,不妨先这么着吧。认真说来,只有这么点儿信息就开始sprint,我还从来没有试过。 优先级2:经过团队认可、要添加到这个sp原创 2009-11-15 15:39:00 · 832 阅读 · 0 评论 -
任务板与燃尽图
任务板分为四列:第一列:尚未开始的backlog及其任务,每个任务要有预估并制定负责人;第二列:已经开始的backlog及其任务;第三列:已经完成的backlog及其任务;第四列:燃尽图和未计划任务及可编入任务。 未计划任务:在计划中没有包含的任务,有可能是在分解backlog时没有分解完全,也有可能是一些突发任务,亦或是技术任务。这部分在做回顾时要重点讨论发生原创 2009-11-15 21:36:00 · 6360 阅读 · 0 评论 -
story point 的单位?
通用方程为1个有效的人-天=6个有效的人-小时。为什么不用人-小时,原因在于:原创 2009-11-15 21:57:00 · 3928 阅读 · 0 评论 -
讨论scrum的几个问题?
1.怎样布置团队房间?最好独立,封闭,不受外界干扰,总之要使团队感到舒服。任务板:每日进行更新设计板:用于团队讨论设计流程 2.团队为何要坐在一起?便于交流,交流很重要。“一起”意味着:• 互相听到:所有人都可以彼此交谈,不必大声喊,不必离开座位。• 互相看到:所有人都可以看到彼此,都能看到任务板——不用非得近到可以看清楚内容,但至少可以看到个大概。• 隔离:原创 2009-11-16 18:16:00 · 2081 阅读 · 0 评论 -
怎样进行每日例会
例会应该控制在10分钟以内,做到这一点,只需在例会中问三个问题:1.昨天做了什么?2.今天计划做什么?3.有什么困难或是否需要他人协助? 例会中除了以上三个问题外,scrum master还要做如下的事情:1.更新任务板(根据以上三个问题)2.处理迟到的家伙3.处理“我不知道今天干什么”的情况 2和3没有固定的答案,可以根据团队的实际情况进行制定,比如2可以罚款,3原创 2009-11-16 18:29:00 · 2756 阅读 · 0 评论 -
sprint计划会议
先来看一个时间表:Sprint 计划会议:• 13:00 – 17:00 (每小时休息10分钟)• 13:00 – 13:30。产品负责人对sprint目标进行总体介绍,概括产品backlog。定下演示的时间地点。• 13:30 – 15:00。团队估算时间,在必要的情况下拆分backlog条目。产品负责人在必要时修改重要性评分。理清每个条目的含义。所有重要性高的backlog条目都要填写原创 2009-11-14 15:37:00 · 1311 阅读 · 0 评论 -
backlog三要素
1.范围(scope)2.重要性(importance)3.估算(estimate) 范围(scope)和重要性(importance)由产品负责人设置。估算(estimate)由团队设置。在sprint计划会议上,经过团队和产品负责人面对面的对话,这三个变量会逐步得到调整优化。 质量:质量分为外部质量和内部质量• 外部质量是系统用户可以感知的。运行缓慢、让原创 2009-11-14 17:06:00 · 703 阅读 · 0 评论 -
sprint的长度--三个星期
sprint应该多长才好?嗯,时间短就好。公司会因此而变得“敏捷”,有利于随机应变。短的sprint=短反馈周期=更频繁的交付=更频繁的客户反馈=在错误方向上花的时间更少=学习和改进的速度更快,众多好处接踵而来。但是,时间长的sprint也不错。团队可以有更多时间充分准备、解决发生的问题、继续达成sprint目标,你也不会被接二连三的sprint 计划会议、演示等等压得不堪重负。产品负原创 2009-11-14 17:27:00 · 2046 阅读 · 0 评论 -
如何制定sprint之间的休整时刻?
sprint之间的休整时刻是指上一个sprint结束到下一个sprint开始之间的时间。 保证不在同一天举行sprint回顾和下一个sprint计划会议。在启动新的sprint之前,每个人都应该至少度过一个不需要考虑sprint的夜晚。原创 2009-11-18 10:00:00 · 2223 阅读 · 0 评论 -
怎样进行sprint回顾
坚持要做回顾,在有关回顾的种种一切中,最重要的就是确保回顾能够进行。 回顾是Scrum中第二重要的事件(最重要的是sprint计划会议),因为这是你做改进的最佳时机!如果没有回顾,你就会发现团队在不断重犯同样的错误。 我们如何组织回顾? • 根据要讨论的内容范围,设定时间为1至3个小时。• 参与者:产品负责人,整个团队还有我自己。• 我们换到一个封闭的房间中,或者舒适的原创 2009-11-16 21:54:00 · 2419 阅读 · 0 评论 -
怎样进行sprint演示
应该让团队中的每个成员都进行演示,即便他这次说的不好,那么下一次,他一定会提前准备好的,这对他主动地理解业务是很有帮助的。 一次做得不错的演示,即使看上去很一般,也会带来深远影响。原创 2009-11-16 18:31:00 · 2099 阅读 · 0 评论 -
我们怎样让别人了解我们的sprint呢?
我们怎样让别人了解我们的sprint呢?我们要让整个公司了解我们在做些什么,这件事情至关重要。否则其他人就会发出抱怨,甚或对我们的工作做出臆断。 可以使用wiki记录下当前的sprint信息,然后使用邮件告知相关人员。 sprint信息应该至少包含如下信息:原创 2009-11-15 20:43:00 · 2260 阅读 · 0 评论 -
怎样制定sprint计划
1.一般来说使用故事点(story points)来作为估算的依据,一个故事点就是一个理想的人/天;2.由开发团队对每个backlog条目进行预估,比如backlogA需要3个story points,backlogB需要4个story points,等等;3.由项目负责人制定每个backlog的优先级,并排序;4.由开发团队从中选择能够完成的backlog加入到sprint back原创 2009-11-14 17:52:00 · 2551 阅读 · 0 评论 -
如何在sprint会议上讨论backlog的细节?
在大多数sprint 计划会议上,大家都会讨论产品 backlog中的故事细节。对故事进行估算、重定优先级、进一步确认细节、拆分,等等都会在会议上完成。 那么该如何实际操作呢? 推荐使用索引卡,把它们贴在墙上或摆放在桌子上。示例如下: 这种用户体验比计算机和投影仪好得多。原因是:原创 2009-11-15 14:06:00 · 1127 阅读 · 0 评论 -
如何做时间估算--计划纸牌
估算是一项团队活动——通常每个成员都会参与所有故事的估算。 为啥要每个人都参加?原创 2009-11-15 15:01:00 · 1261 阅读 · 0 评论 -
实践scrum随笔
1.产品BackLog2.对于BackLog的估算3.燃尽图--burndown4.了解团队的生产率5.掌握scrum众多的基础实践 Scrum和极限编程(XP)都要求团队在每一次迭代的结尾完成一些可以交付的工作片段。迭代要短,有时间限制。将注意力集中于在短时间内交付可工作的代码,这就意味着Scrum和XP团队没有时间进行理论研究。他们不会花时原创 2009-11-13 10:30:00 · 925 阅读 · 0 评论 -
如何明确故事内容
在明确故事内容时一定要向产品负责人如何进行演示,因为这很可能会决定你开发的方式,也间接的影响到了你对故事的时间估算。 例1:团队和产品负责人都对sprint计划很满意,打算结束会议。这时Scrum master问了一个问题,“等一下,还有个‘添加用户’的故事没有估算时间呢,把它解决了吧!”几轮计划纸牌以后,团队意见达成一致,认为这个故事需要20个故事点;产品负责人却站了起来,说话因为生气原创 2009-11-15 15:18:00 · 689 阅读 · 0 评论 -
故事与任务
“任务”和“故事”的区别是什么呢?嗯,这个问题问得不错。区别很简单。故事是可以交付的东西,是产品负责人所关心的。任务是不可交付的东西,产品负责人对它也不关心。 故事如果太大就应该进行拆分,力求保证故事的大小在2至8个人-天之间。否则不好控制。 例子: 故事拆分为多个故事 故事拆分为任务 我们会看到一些很有趣的现象:• 新组建的Sc原创 2009-11-15 15:27:00 · 1262 阅读 · 0 评论 -
技术故事
技术故事:或者叫做非功能性条目,或者你想叫它什么都行。是需要完成但又不属于可交付物的东西,跟任何故事都没有直接关联,不会给产品负责人带来直接的价值。 比如系统的公共组件,代码重构等等,这些并不能给项目负责人带来之际的可交付物,但会对项目的稳定性和提高效率有很大的作用, 这些技术故事往往容易被项目负责人所忽视,因为他们更注重实际上看得到摸得着的东西。 作为一个技术经理,原创 2009-11-15 19:06:00 · 1492 阅读 · 0 评论 -
定义“完成”
单独用一篇文章介绍足以说明它的重要性。 一定要在完成sprint计划会议前定义好每个故事的完成含义,并在项目团队中达成共识。 比如说测试通过,或者部署上线,总之要有一个完成的定义。原创 2009-11-15 14:52:00 · 625 阅读 · 0 评论 -
backlog与bug
我们采用jira来做bug跟踪系统,同时会将backlog与拆分的任务维护在jira上。 我们每一次sprint都会经历需求确认,开发,测试,部署上线的完整流程。如果在到达发布日期时仍有没有修复的bug该如何处理呢? 一般来说应该对每一个bug进行分析,如果不属于严重bug,则可以结束当前的sprint,否则当前的sprint宣告失败,需要重新进行评估。 如果在下一原创 2009-11-15 20:02:00 · 3029 阅读 · 0 评论 -
sprint回顾中发现的问题如何处理?
回顾中发现的问题示例: 1.“我们应花更多时间,把故事拆分成更小的条目和任务”这个问题很普遍。每天的例会上,都会有人说“我真的不知道今天该干什么”。所以在每一个例会之后,你都要花些时间来找出具体任务。通常这些事情提前做会更有效率。典型动作:无。团队很可能会在下一个sprint计划会议上自己解决掉这个问题。如果它重复出现的话,就延长sprint计划会议的时间。2.“太多的外界干扰”原创 2009-11-18 09:56:00 · 1932 阅读 · 0 评论