专栏首页yeedomliu《硝烟中的Scrum和XP》第4章 我们怎样制定sprint计划

《硝烟中的Scrum和XP》第4章 我们怎样制定sprint计划

2860元腾讯云代金券免费领取,付款直接抵现金,立即领取>>>

腾讯云服务器1折限时抢购,2核4G云主机899元/3年,立即抢购>>>

第4章 我们怎样制定sprint计划

  • sprint计划会议非常关键,应该算是Scrum中最重要的活动。只是它执行得不好,整个sprint甚至都会被毁掉
  • 举办sprint计划会议,是为了让团队获得足够的信息,能够在几个星期内不受干扰地工作,也是为了让产品负责人能对此有充分的信心
  • sprint计划会议会产生一些实实在在的成果
  1. sprint目标
  2. 团队成员名单(以及他们的投入程度,如果不是100%的话)
  3. sprint backlog(即sprint中包括的故事列表)
  4. 确定好sprint演示日期
  5. 确定每日scrum会议的时间和地点

为什么产品负责人必须参加

  • 有时候产品负责人会不太情愿跟团队一起花上几个小时制定sprint计划。“嘿,小伙子们,我想要的东西已经列举出来了,我没时间参加你们的计划会议。”这可是个非常严重的问题
  • 为什么整个团队和产品负责人都必须要参加sprint计划会议?原因在于,每个故事都含有三个变量,它们两两之间都对彼此有着强烈依赖
  • 范围(scope)和重要性(importantce)由产品负责人设置。估算(estimate)由团队设置。在sprint计划会议上,经过团队和产品负责人面对面的对话,这三个变量会逐步得到调整优化
  • 会议启动以后,产品负责人一般会先概括一下希望在这个sprint中达成的目标,还有他认为最重要的故事。接下来,团队从最重要的故事开始逐一讨论每个故事,一一估算时间。在这个过程中,他们会针对范围提出些重要问题:“删除用户这个故事,需不需要遍历这个用户所有尚未执行的事务,把它们统统取消?”有时答复会让他们感到惊讶,促使他们调整估算
  • 在某些情况下,团队对故事做出的时间估算,跟产品负责人的想法不太一样。这可能会让调整故事的重要性;或者修改故事的范围,导致团队重新估算,然后一连串诸如此类的连锁反应。
  • 这种直接的协作形式是Scrum的基础,也是所有敏捷软件开发的基础。
  • 如果产品负责人还是坚持没时间参加怎么办?一般我会按顺序尝试下面的策略
  1. 试着让产品负责人理解,为什么他的直接参与事关项目成败,希望他可以改变想法
  2. 试着在团队中找到某个人,让他在会议中充当产品负责人的代表。告诉产品负责人,“既然你没法来开会,我们这次会让Jeff代表你参加。他会替你在会议中行使权利,改变故事的优先级的范围。我建议,你最好在会议开始前尽可能跟他沟通到位。如果你不喜欢Jeff当代表 ,也可以推荐其他人,只要他能全程参加我们的会议就行”
  3. 试着说服管理团队为我们安排新的产品负责人
  4. 推迟sprint的启动日期,直到产品负责人找到时间参会为止。同时拒绝承诺任何交付。让团队每天都可以自由做他们最想做的事情

为什么不能在质量上让步

  • 我尽力把内部质量和外部质量分开
  1. 外部质量:系统用户可以感知的。运行缓慢、让人迷糊的用户界面就属于外部质量低劣
  2. 内部质量:用户看不到的要素,它们对系统的可维护性有深远影响。可维护性包括系统设计的一致性、测试覆盖率、代码可读性和重构等等
  • 一般来说,系统内部质量优秀,外部质量仍有可能很差。而内部质量差的系统,外部质量肯定也不怎么样
  • 我把外部质量也看作范围的一部分。有时出于业务考虑,可能会先发布一个系统版本,其用户界面给人的感觉可能比较简陋,而且反应也很慢;不过随后会发布一个干净的版本。我都是让产品负责人做权衡,因为他是负责定义项目范围的人
  • 假设产品负责人这样说,“好吧,你们把它估算成6个故事点也行。但我相信:一定能够找到些临时方案,节省一半时间。你们只要稍稍动下脑子就行”
  • 啊哈!他想把内部质量当作变量来处理。我是怎么知道的?因为他想让我们缩减故事的估算时间,但不想为缩减范围“买单”。“临时方案”这个词应当在你脑中敲响警钟……
  • 经验告诉我:牺牲内部质量是一个糟糕透顶的想法。现在节省下来一点时间,接下来的日子里你就要一直为它付出代价。一旦我们放松要求,允许代码库中暗藏问题,后面就很难恢复质量了
  • 碰到这种情况,我就会试着把话题转回到范围上来。“既然你想尽早得到这个特性,那我们能不能简化错误处理的功能,把“高级错误处理”当作一个单独的故事,放到以后再实现。或者也可以降低其他故事的优先级,好让我们集中处理这一个”
  • 一旦产品负责人弄清楚内部质量是不可能让步的,他一般都会处理好其他变量

无何止的sprint计划会议

  • 在sprint计划会议中最困难的事情是
  1. 人们认为他们花不了多长时间
  2. ……但他们会的!
  • 假如sprint计划会议接近尾声,但仍然没有得出sprint目标或者sprint backlog,这时该怎么办?我们要打断它么?还是再延长一个小时?或者到时间就结束会议,然后明天继续?
  • 这种事情会一再发生,尤其是在新团队身上。你会怎么做?我不知道。但我们的做法是什么?嗯……我通常会直接打断会议,中止它,让这个sprint给大家点儿罪受吧。具体一点,我会告诉团队和产品负责人:“这个会议要在10分钟以后结束。我们到目前为止还没有一个真正的sprint计划。是按照已经得出的结论去执行,还是明早8点再开4小时的会?”
  • 我会打断会议。是的,这个sprint让大家不太好过。但我们应该看到它的正面影响,整个团队都从中获益匪浅,下个sprint计划会议更有效率。另外,如果他们从前还觉得你定下的会议时间过长的话,下次他们的抵制情绪就会少一些了
  • 学会按照时间盒安排工作,学会制定合乎情理的时间盒,这对会议长度和sprint长度同样有帮助

sprint计划会议日程

  • 在sprint计划会议之前先为它初步制定一个时间表,可以减少打破时间盒的风险
  • sprint计划会议:13:00-17:00(每小时休息10分钟)
  • 13:00-13:30:产品负责人对sprint目标进行总体介绍,概括产品backlog。确定演示的时间和地点
  • 13:30-15:00:团队估算时间,在必要的情况下拆分backlog条目。产品负责人在必要时修改重要性评分。理清每个条目的含义。所有 重要性高的backlog条目都要填写“如何演示”
  • 15:00-16:00:团队选择要放入sprint中的故事。计算生产率,用作核查工作安排的基础
  • 16:00-17:00:为每日scrum会议(以下简称每日例会)安排固定的时间和地点(如果和上次不同的话)。把故事进一步拆分成任务
  • ScrumMaster根据会议进程的需要,可以对各个阶段的子进程时间安排进行调整

确定sprint长度

  • sprint演示日期是sprint计划会议的产出物,它被确定下来以后,也就确定了sprint的长度
  1. 时间短就好:公司会因此而变得“敏捷”,有利于随机应变。短的sprint=短反馈周期=更频繁的交付=更频繁的客户反馈=在错误方向上花的时间更少=学习和改进的速度更快,众多好处接踵而来
  2. 时间长的sprint也不错。团队可以有更多时间充分准备、解决发生的问题、继续达到sprint目标,你也不会被接二连三的计划会议、演示等等压得不堪重负

产品负责人一般会喜欢短一点的sprint,而开发人员喜欢时间长的sprint。所以sprint的长度是妥协后的产物。做过多次实验后,我们最终总结出了最喜欢的长度:三个星期。绝大部分团队的sprint长度都是三周

  • 刚开始要试验sprint的长度的长度。不要浪费太多时间做分析。选一个可以接受的长度先开始再说,等做完一两个sprint再进行调整。
  • 不过,确定了自己最喜欢的长度之后,就要在长时间内坚持不变。保持住这个长度以后,它似乎变成了大家共同的心跳节奏,每个人都感觉很舒服。这段时间内无需讨论发布日期之类的事情,因为大家都知道:每过三周都会有一个发布

确定sprint目标

  • 几乎每次sprint计划会议都要确定sprint目标。在sprint计划会议进行中,我会选某个时刻问一个问题,“这个sprint的目标是什么?”每个人都目光空洞地看着我,产品负责人也皱起眉头,开始挠下巴
  • 它必须用业务术语表达,而不是技术词汇,让团队以外的人也能够理解
  • sprint目标应该是尚未达成的
  • 可以在一个wiki页面列出所有团队的sprint目标,然后把它们放在一个显著位置上,保证公司所有人(不只是顶级管理层)知道公司在干什么,目的又是什么!

决定sprint要包含的故事

  • 就是哪些故事需要从产品backlog拷贝到sprint backlog
  • 每个矩形都表示一个故事,按重要性排序。最重要的故事在列表顶部。矩形尺寸表示故事大小(也就是以故事点估算的时间长短)。括号的高度表示团队估算的生产率(estimated velocity),也即团队认为他们在下一个sprint中所能完成的故事点数
  • 右侧的sprint backlog是产品backlog中的一个故事快照。它表示团队在这个sprint中承诺要完成的故事
  • 在sprint中包含多少故事由团队决定,而不是产品负责人或其他人
  • 这引发了两个问题
  1. 团队怎么决定把哪些故事放在sprint里面?
  2. 产品负责人怎么影响他们的决定?

产品负责人如何对sprint放哪些故事产生影响

  • 假设在sprint计划会议中我们遇到下图所示的情况
  • 产品负责人很失望,因为故事D不会被放在sprint里面。首先,他可以重新设置优先级。如果他给故事D赋予最高的重要级别,团队就不得不把它先放到sprint里面来(在这里需要把C扔出去)
  • 其次,他可以更改范围——缩小故事A的范围,直到团队相信故事D能在这个sprint里完成为止
  • 最后,他还可以拆分故事。产品负责人判断出故事A中某些方面实际并不重要,所以他把A分成两个故事A1和A2,赋给它们不同的重要级别

团队怎样决定把哪些故事放到sprint里面

  • 这里使用两个技术
  1. 本能反应
  2. 生产率计算

用本能反应来估算

ScrumMaster:“伙计们,我们在这个sprint里面能完成故事A吗?” Lisa:“呃。当然可以。我们有三个星期,这只是个微不足道的特性” ScrumMaster:“OK,那加上B怎么样?” Tom和Lisa一起回答:“自然没问题” ScrumMaster:“OK,那ABC一起呢?” Sam:“故事C要包括高级错误处理么?” 产品负责人:“不,你现在可以跳过它,只需要完成基本的错误处理” Sam:“那C应该没问题” ScrumMaster:“OK,那再加上D呢?” Lisa:“嗯……” Tom:“我觉得能完成” ScrumMaster:“有多少把握?90%还是50%” Lisa和Tom:“差不多90%” ScrumMaster:“OK,D也加进来。那再加上E呢?” Sam:“也许吧” ScrumMaster:“90%?50%?” Sam:“差不多50%” Lisa:“我没把握” ScrumMaster:“OK,那先把它放一边去。我们要做完ABCD。如果有时间的话,当然还可以做完E,不过既然没人指望它能完成,所以我们也不会把它算到计划里面来。现在怎么样?” 所有人:“OK”

  • 如果sprint时间不长,小团队根据直觉进行估算可以收到很好的效果

用生产率计算来估计

  1. 得抽估算生产率
  2. 计算在不超出估算生产率的情况下可以加入多少故事
  • 生产率是“已完成工作总量”的一个衡量方式,其中每一个条目都是用它的原始估算进行衡量的
  • 下图中,左边是sprint启动的估算的生产率,右边是sprint结束时的实际生产率。每个矩形都是一个故事,里面的数字表示这个故事的原始估算
  • 注意,这里的实际生产率建立在每个故事的原始估算基础之上。在sprint过程中对故事时间进行的修改都被忽略了
  • 这个数字并不精确。但它依然很有用,尤其是与啥都没有相比,感觉就更明显了。它可以给你一些硬生生的事实:“抛开具体原因,我们曾经以为能完成这么多,而实际完成的工作与当初预计的还是有区别”
  • 那个sprint里面差不多可以完成的故事怎么处理?为什么我们在实际生产率里面没把它的部分故事点数算进来?这就突出表现了Scrum的要求(实际上也是敏捷软件开发和精益制造的要求):把事情完全做完!达到可以交付的状态!事情只做了一半,它的价值就是0(也许还会是负数)
  • 我们在估算生产率的时候,动用了何等神奇的魔力?
  • 有一个很简单的办法:看看团队的历史。看看他们在过去几个sprint里面的生产率是多少,然后假定在一一个sprint里面生产率差不多不变
  • 这项技术也叫“昨天天气”。要想使用该技术,必须满足两个条件:团队已经完成了几个sprint(这样就可以得到统计数据),会以几乎完全相同的方式(团队长度不变,工作状态等条件不变)来进行下一个sprint
  • 例如,这个sprint一共有50个可用的人天
  • 这是我们的估算生产率么?不!我们估算的单位是故事点(story point),差不多可以对应于“理想化的人-天”。一个理想化的人-天是完美、高效、不受打扰的一天,但这种情况太少见了。我们还必须考虑到各种因素,例如要把未计划到的工作添加到sprint中、人们患病不能工作等等
  • 我们的估算生产率肯定要比50少了。少多少呢?我们引入“投入程度”(focus factor)这个词来看一下
  • 投入程度用来估算团队会在sprint中投入多少精力。投入程度低,就表示团队估计会受到很大干扰,或者他们觉得自己的时间估算太过理想化
  • 要想得出一个合理的投入程度,最好的办法就是看看上一个sprint的值 (对前几个sprint取平均值 自然更好)
  • 把上一个sprint中完成的所有故事的原始估算加起来,得到的和就是实际生产率
  • 从上面的公式中可以看出,下个sprint的估算生产率是20个故事点。这表明团队这个sprint中所能做的故事点数之和不能超过20
  • 在这种情况下,团队可以选择前4个故事,加起来一共19个故事点;或者选前5个故事,一共24个故事点。我们假设他们选了4个故事,因为它离20最近。如果不太确定,那就再少选些好了
  • 因为这4个故事加起来一共19个故事点,所以他们在这个sprint中最后的估算生产率是19
  • “昨天天气”用起来很方便,但需要考虑一些常识。如果上一个sprint干得很糟,是因为大部分成员都病了一星期。那你差不多可以放心假设这次运气不会那么坏,给这个sprint设个高点的投入程度;如果团队最近刚装了一个执行速度快如闪电的持续集成系统,那你也可以因此提高一下投入程度;如果有新人加入这个sprint,那就把他的培训占用的精力也算进来,降低投入程度;等等
  • 只要条件允许 ,你就应该看看从前的sprint,计算出平均数,这样可以得到更合理的估算
  • 如果这是个全新的团队,没有任何数据怎么办?可以参考一下类似条件下工作的团队,他们的投入程度数值是多少
  • 如果没有其他团队可以参考怎么办?随便猜一个数作为投入程度吧。毕竟这个猜测只会在第一个sprint里面使用。过了这次以后你就有了历史数据可以分析,然后对投入程度和估算生产率做出不断的改进
  • 我在新团队中使用的“默认”投入程度通常是70%,因为这是其他大多数团队都能达到的数值

我们用的是哪种估算技术

  • 我们审视上个sprint的投入程度和实际生产率。我们审视这个sprint总共可用的资源,估算一个投入程度。我们讨论这两个投入程度之间的区别,必要时进行调整
  • 大致有了一个要放入sprint的故事列表以后,我再进行“直觉反应”的检查。我要求他们暂时忘掉数字,感觉一下:在一个sprint里一口咬这么多东西会不会难以下咽。如果觉得太多了,那就移走一两个故事。反之亦基
  • 当天结束以前,只要得出哪些故事要放到sprint里面,我们就算完成了目标。投入程度、资源可用性和估算生产率只是用来达成这个目标的手段

我们为何使用索引卡

  • 在大多数sprint计划会议上,大家都会讨论产品backlog中的故事细节。对故事进行估算、重定优先级、进一步确认细节、拆分,等等都会在会议上完成
  • 要想收到好的效果,不妨创建一些索引卡,把它们放到墙上(或一张大桌子上)
  • 这种用户体验比计算机和投影仪好得多,理由如下
  1. 大家站起来四处走动=》他们可以更长时间地保持清醒,并留心会议进展
  2. 他们有更多的个人参与感(而不是只有那个拿着键盘的家伙才有)
  3. 多个故事可以同时编辑
  4. 重新划分优先级变得易如反掌——挪动索引卡就行
  5. 会议结束后,索引卡可以拿出会议室,贴在墙上的任务板上
  • 可以手写索引卡,也可以用简单的脚本从产品backlog中直接生成可以打印的索引卡(我博客上有这种脚本,地址是blog.crisp.se/henrikkniberg)
  • 重要事项:sprint计划会议结束后,我们的ScrumMaster会手工更新Excel中的产品backlog,以反映故事索引卡中发生的变化。这确实给管理者带来了一点麻烦,但是考虑到用了物理索引卡以后,sprint计划会议的效率得到了大幅度提高,这种做法还是完全可以接受的
  • 我们根据重要性给卡片排序(我们一般把最重要的放到左边,依次向右排列)。不过,一旦卡片被放到墙上,那就可以暂时忽略它的重要性评分,根据它们摆放的相对位置,来对比彼此的重要性。如果产品负责人交换了两张卡片,先不要浪费时间在纸上更新数字,只要确保会议结束后在产品backlog做更新就可以
  • 把故事拆分成任务后,时间估算就变得更容易(也更精确)了
  • 我们用即时贴贴在每个故事的下方,每张即时贴表示这个故事中的一个任务
  • 我们不会让任务拆分出现在产品backlog中,原因如下
  1. 任务拆分的随机性比较强,在sprint进行中,它们常常会发生变化,不断调整,所以保持产品backlog的同步很让人头大
  2. 产品负责人不需要关心这种程度的细节

定义“完成”

  • 有一点很重要:产品负责人和团队需要对“完成”有一致的定义。所有代码被check in以后,故事就算完成了吗?还是被部署到测试环境中,经过集成测试组的验证以后才算完成?我们尽可能 使用这样的定义:“随时可以上线”,不过有时候我们也这样说:“已经部署到测试服务器上,准备进行验收测试”
  • 最开始我们用的是比较详细的检查列表。现在我们常说:“如果Scrum团队中的测试人员说可以,那这个故事就算完成了”。然后责任就到了测试人员身上,他需要保证团队理解了产品负责人的意图,要保证故事的“完成”情况可以符合大家认可的定义
  • 我们慢慢意识到,不能把所有的故事都一概而论。“查询用户表单”跟“操作指南”这两个故事的处理方式就有很大差别。对后者,“完成”的定义可能就是简单的一句话——“被运营团队认可”。所以说,日常的一些认识往往要好过正式的检查列表
  • 如果你常常对怎样定义完成感到困惑(就像我们刚开始一样),你或许应该在每个故事上都添加一个字段,起名为“何谓完成”

使用计划扑克做时间估算

  • 估算是一项团队 活动——通常每个成员都会参与所有故事的估算。为啥要每个人都参加?
  1. 在计划的时候,我们一般都还不知道到底谁会来实现哪个故事的哪个部分?
  2. 每个故事一般有好几个人参与,也包括不同类型的专长(用户界面设计 、编程、测试等)
  3. 团队成员必须要对故事内容有一定的理解才能进行估算。要求每个人都做估算,我们就可以确保他们都理解了每个条目的内容。这样就为大家在sprint中相互帮助夯实了基础,也有助于故事中的重要问题被尽早发现
  4. 如果要求每个人都对故事做估算,我们就会常常发现两个人对同一个故事的估算结果差异很大。我们应该尽早发现这种问题并就此进行讨论
  • 有一项很优秀的技术可以避免这一点——它的名字是计划扑克。每个人都会得到如下图所示的13张纸牌。在估算故事的时候,每个人都选出一张纸牌来表示他的时间估算(以故事点的方式),并把它正面朝下扣在桌上。所有人都完成以后,桌上的纸牌会被同时揭开。这样每个人都会被迫进行自我思考,而不是依赖于其他人估算的结果。
  • 如果在两个估算之间有着巨大差异,团队就会就此进行讨论,并试图让大家对故事内容达成共识。他们也许会进行任务分解,之后再重新估算。这样的循环会往复进行,直到时间估算趋于一致为止,也就是每个人对这个故事的估算都差不多相同
  • 重要的是,我们必须提醒团队成员,他们要对这个故事中所包含的全部工作进行估算,而不是“他们自己负责”的部分工作。测试人员不能只估算测试工作
  • 注意,这里的数字顺序不是线性的。例如在40和100之间就没有数字
  • 因为一旦时间的估算值比较大,其精确度就很难把握;这样做就可以避免人们对估算精确度产生错误的印象。如果一个故事的估算值 是差不多20个故事点,它到底应该是20还是18还是21,其实无关紧要。我们知道的就是它是一个很大的故事,很难估算。所以20只是一个粗略估计
  • 需要进行更精确的估算?那就把故事分拆,去估算那些更小的故事!
  • 另外,你也不能搞那种把5和2加起来得到7的把戏。要么选5,要么选8,没有7
  • 下面这些卡片比较特殊
  1. 0:这个故事已经完成了或这个故事根本没啥东西,几分钟就能搞定
  2. ?:我一点概念都没有。没想法
  3. 咖啡杯:我太累了,先歇会吧

明确故事内容

  • 在sprint演示会议上,团队自豪地演示了一个新特性,但产品负责人却皱起眉头,“呃,看上去不错 ,但这不是我要的!”发生这种事情可真是糟透了!
  • 有些简单技术,可以识别出最明显的误解。最简单的办法就是确保每个故事的所有字段都被填满(更精确地说,这里提到的是具有高优先级,应该在这个sprint里面完成的故事)

例1 团队和产品负责人都对sprint计划很满意,打算结束会议。这时ScrumMaster问了一个问题,“等一下,还有个“添加用户””的故事没有估算时间呢,把它解决了吧!“几轮计划扑克以后,团队意见达成一致,认为这个故事需要20个故事点;产品负责人却站了起来,说话因为生气也走了调:”什、什、什么?!“经过几分钟的激烈争吵,最后发现是团队错误理解了”增加用户“这个故事的范围,他们以为这表示”要有个漂亮的Web界面来添加、删除、移除和查询用户“,但是产品负责人只是想”通过手写SQL操作数据库来添加用户“。他们重新进行评估,给它5个故事点,达成共识 例2 团队和产品负责人都对sprint计划很满意,打算结束会议。这时ScrumMaster问了一个问题,”等一下,还有一个'添加用户'的故事,它怎么演示呢?“一阵窃窃私语之后,某人站起来说,”呃,首先我们登录Web站点,然后……“产品负责人打断了他的话,”登录Web站点?!不不不,这个功能跟Web站点一点关系都没有,你给技术管理员提供个傻瓜都能用的SQL脚本就行“

  • ”如何演示“这段描述可以(而且应该)非常精简!不然你就没法按时结束sprint计划会议。基本上,它就是最平白浅显的语言,来描述如何手工执行最典型的测试场景。”先这样,然后那样,最后验证这一点“
  • 我发现,使用这种简单的描述,常常能够发现对于故事范围的最严重的误解。这种事发现得越早越好

把故事拆分成更小的故事

  • 如果你有一大堆0.5个故事点的故事,那你恐怕就会成为微观管理的受害者了。与之相反,40个点的故事,到最后很可能只能部分完成,这样不会为公司带来任何价值,只会增加管理成本。如果你们估算的生产率是70,而最高优先级的两个故事都是40个故事点,那做计划可就有麻烦了
  • 我发现很大的故事基本上都能进行拆分。只要确定每个小故事依然可以交付业务价值就行
  • 我们常常都力求保证故事的大小在2-8个人一天之间。一个普通团队的生产率大约是40---60,所以大概每个sprint可以完成10个故事。有时会减少到5个,有时也会多到15个。处在这个数量范围之间的索引卡是比较容易管理的

把故事拆分成任务

  • 故事是可以交付的东西,是产品负责人所关心的。任务是不可交付的东西,产品负责人对它也不关心
  • 在下图的例子中,故事被拆分成更小的故事
  • 下图是把故事拆分成任务的例子
  • 我们会看到一些很有趣的现象
  1. 新组建的Scrum团队不愿意花时间来预先把故事拆分成任务。有些人觉得这像是瀑布式的做法
  2. 有些故事,大家都理解得很清楚,预先拆分还是随后拆分都一样简单
  3. 这种类型的拆分常常可以发现一些会导致时间估算增加的荼,最后得出的sprint计划会更贴近现实
  4. 这种预先拆分可以给每日例会的效率带来显著提高
  5. 即使拆分不够精确,而且一旦开始具体工作,事先的拆分结果也许会发生变化,但我们依然可以得到以上种种好处
  • 注意——我们在实践TDD(测试驱动开发),所以几乎每个故事的第一个任务都是”编写一个失败的测试“,而最后一个任务是”重构“(提高代码的可读性,消除重复)

定下每日例会的时间地点

  • 一般是9:00、9:30或者10:00.最关键的是,这必须是每个人都能完全接受的时间

最后界限在哪里

  • 如果时间不够,我们应该把哪些做的事情砍掉呢?
  1. sprint目标和演示日期。这是启动sprint最起码应该有的东西。团队有一个目标,一个结束日期,然后就可以马上根据产品backlog开始工作
  2. 经团队认可、要添加到当前sprint中的故事列表
  3. sprint中每个故事的估算值
  4. sprint中每个故事的”如何演示“
  5. 生产率和资源计算,用作sprint计划的现实核查。包括团队成员的名单及每个人的承诺(不然就没法计算生产率)
  6. 明确每日例会固定举行的时间地点。这只需要花几分钟,但如果时间不够用,ScrumMaster可以在会后直接定下来,邮件通知所有人
  7. 把故事拆分成任务。这个拆分也可以在每日例会上做,不过这会稍稍打乱sprint的流程

技术故事

  • 我指的是需要完成但又不属于可交付物的东西,跟任何故事都没有直接关联,不会给产品负责人带来直接的价值

示例

  1. 安装持续构建服务器:为什么要完成它?因为它会节省开发人员大量时间,到迭代结束的时候,集成也不太容易出现重大问题
  2. 编写系统设计概览:为什么要完成它?因为开发人员常常会忘记系统的整体设计,写出与之不一致的代码。团队需要有个描述整体概况的文档,保证每个人对设计都有同样的理解
  3. 重构DAO层:为什么要完成它?因为DAO层代码已经乱成一团了。混乱带来了本可以避免的bug,每个人的时间都在被无谓地消耗。清理代码可以节省大家的时间,提高系统的健壮性
  4. 升级Jira(bug跟踪工具):为什么要完成它?当前的版本bug狂多,又很慢,升级以后可以节省大家时间
  • 实际上,出于显而易见的原因,技术故事常常会因为某种原因给设置一个低优先级,例如:”嘿,兄弟们,我知道持续构建服务器很重要,不过让我们先来完成一些可以带来收入的特性吧,然后再来弄那些技术上的东西,行不?“。产品负责人往往不能对此做出正确的权衡。我们可以采取下面这些做法
  1. 试着避免技术故事。努力找到一种方式,把技术故事变成可以衡量业务价值的普通故事。这样有助于产品负责人做出正确的权衡
  2. 如果无法把技术故事转变成普通故事,那就看看这项工作能不能当作另一个故事中的某个任务。例如,”重构DAO层“可以作为”编辑用户“中的一个任务,因为这个故事会涉及到DAO层
  3. 如果以上二者都不管用,那就把它定义为一个技术故事,用另外一个单独的列表来存放。产品负责人能看到它,但是不能编辑它。用”投入程度“和”预估生产率“这两个参数来跟产品负责人协商,从sprint里拨出一些时间来完成这些技术故事
  • 下面是一个示例

团队:”我们要完成一些内部的技术工作,也许要从我们的时间里抽出来10%,也就是把投入程度从75%降低到65%,你看行吗?“ 产品负责人:”不行!我们没那个时间了!“ 团队:”嘿……那看看上一个sprint吧。(大家的头全转向了白板上的生产率草图。)我们估算的生产率是80,但实际才有40,没错吧?“ 产品负责人:”没错!所以我们没时间干那些内部的技术活了!我们需要新功能 !“ 团队:”呃,我们的生产率变得这么糟糕的原因就是,构造可以测试的稳定版本占用了太多时间“ 产品负责人:”嗯,那然后呢?“ 团队:”唔,如果我们不做点什么的话,生产率还会继续这么烂下去“ 产品负责人:”嗯,接着说?“ 团队:”所以我们建议在这个sprinnt里抽出大概10%的时间来搭一个持续构建服务器,完成相关的一些事情,这样就 不会再受集成的折磨,接下来,每个sprint里面,我们的生产率都会提高至少20%!“ 产品负责人:”啊?真的吗?那为什么上个sprint我们没这么干?!“ 团队:”嗯……因为你不同意……“ 产品负责人:”哦,嗯……那好吧,这主意听上去不错,开始干吧!“

  • 当然,还可以把产品负责人排除在外,或者是告诉他一个不可协商的投入程度。但你不妨先尝试一下,让你们的想法达成一致
  • 建议你最好还是尽量让他知道所有的事情,让他制定一切工作优先级。透明也是Scrum的核心价值

bug跟踪系统vs.产品backlog

  1. 产品负责人打印出Jira中优先级最高的一些条目,带到sprint计划会议中,跟其他故事一起贴到墙上(因此就暗暗地指明了这些难题相对其他故事的优先级)
  2. 产品负责人创建一些指向Jira条目的故事。例如”修复那几个后台报表最严重的bug,序号是Jira-124、Jira-126……“
  3. 修复bug当作sprint以外的工作,也就是说,团队会保持一个足够低的投入程度(例如50%),从而保证他们有时候来修复bug。然后我们就可以简单假设,在每一个sprint中,团队都会用一些时间来修复Jira上报告的bug
  4. 把产品backlog放到Jira上(也就是放弃Excel)。把bug与其他故事同等看待
  • 我还是倾向于使用第一种方案。既简单,效果又好

sprint计划会议终于结束了

  • sprint计划会议是Scrum中最重要的活动。在这里投入大量努力,保证它顺利完成,后面的工作就会轻松很多
  • 如果每个人(所有的团队成员和产品负责人)离开会场时都面带微笑,第二天醒来时面带微笑,在第一次的每日例会上面带微笑,那sprint计划会议就是成功的

本文分享自微信公众号 - yeedomliu(yeedom_liu),作者:yeedomliu

原文出处及转载信息见文内详细说明,如有侵权,请联系 [email protected] 删除。

原始发表时间:2020-03-31

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 《硝烟中的Scrum和XP》第17章 ScrumMaster检查列表

    yeedomliu
  • 《硝烟中的Scrum和XP》第11章 sprint之间的休整时刻

    yeedomliu
  • 《硝烟中的Scrum和XP》第10章 我们怎样做sprint回顾

    yeedomliu
  • 《硝烟中的Scrum和XP》第10章 我们怎样做sprint回顾

    yeedomliu
  • 《硝烟中的Scrum和XP》第11章 sprint之间的休整时刻

    yeedomliu
  • 《硝烟中的Scrum和XP》第17章 ScrumMaster检查列表

    yeedomliu
  • Python视频编辑库:MoviePy

    MoviePy是一个关于视频编辑的python库,主要包括:剪辑,嵌入拼接,标题插入,视频合成(又名非线性编辑),视频处理,和自定制效果。可以看gallery中...

    py3study
  • H5(drag,百度地图使用,requestFullscreen,H5应用缓存)

    天天_哥
  • Linux 命令(100)—— expr 命令

    expr(expression) 命令用于计算表达式的值。支持关系运算、算数运算、字符串匹配、截取、获取长度等相关运算。只支持整数和字符串,不支持浮点数。若涉及...

    Dabelv
  • 脚本链接 ssh 自动输入密码

    首先安装 expectexpectexpect,因为默认是没有安装这个的,UbuntuUbuntuUbuntu 系统可以直接通过 sudo apt?get in...

    f_zyj

扫码关注云+社区

领取腾讯云代金券

http://www.vxiaotou.com