11个自组织团队同时教导自己敏捷

在上一篇文章中,我谈到了我如何学会 向很多人教授敏捷 与此同时。在写这篇文章时,我意识到这是自我组织的很好例证。在我主持会议时,这种认识就摆在了我的脑海中。“灵动沉浸” on March 10th at 敏捷与超越2012 .

虽然我’ve trained large groups of people on Agile many times over the last few years, it never occurred to me to create a video of the experience. This time, I decided to do it to illustrate large-scale self-organization in action. 那里 were eleven separate teams with no appointed leader.

我所做的只是建立学习环境,提供资料,并为每项活动提供一些说明。参与者自己组织成一个自我组织的团队来进行所有的学习/教学。

在仅仅一个半小时的时间内,所有11个团队都向自己学习了9种敏捷实践的基础知识,如下所示:

  • 形成 跨功能的 并置团队
  • 选择一个软件产品“build”
  • 写12 用户故事 该产品
  • 把故事放进一个 积压 借助业务价值进行排序 产品拥有者
  • 估算故事 故事点 使用 规划扑克
  • 使用2计划发布 迭代 值得的故事
  • 独立完成上述所有操作 自组织的团队

团队的自组织效果非常好,我能够捕获会议的许多视频片段,并且在整个会议的90分钟内仅需回答4到5个有关机械的问题。

一如往常,人们学到的最喜欢的东西之一是“Planning Poker,”一种涉及特殊纸牌的敏捷估计技术。我告诉别人我没有’不需要他们,我也放弃了我所有的额外费用。我带了48副牌,在会议结束时都没了。连一张卡都没有!

会议的短片(4:10)是 在YouTube上可用 .

Macomb社区学院的一些人制作了自己的视频(3:58)。的“灵动沉浸”部分从1:25到结束。

减少工作时间是敏捷的,因为工作软件是进度的主要衡量标准

燃尽图可以使用任何单位单位,例如小时或点数,但最初是Scrum’的燃尽图跟踪了迭代中剩余的工作时间。许多人仍将基于小时的燃尽图用作迭代过程中进度的主要指标。这是一个有用的工具,但类似于在(美式)橄榄球比赛中跟踪码数。它衡量活动,但不衡量成就。毕竟,30码的达阵百分比是多少?
工作软件是进度的主要衡量标准
敏捷宣言中的一项原则是“工作软件是进度的主要衡量标准“。但是,减少工作时间可以衡量和增强计划的进度,而无需任何软件,直到迭代结束。那’与在Waterfall版本发布之前不必拥有可用的软件几乎一样!这是许多人不再消耗时间或使用其他工具(例如消耗故事点)来补充时间的原因之一。
抢救点

按点数消耗图表是敏捷中最好的工具之一。它将敏捷的许多最佳方面融合在一起,并且让您立即了解自己的实际工作方式。基于积分的燃尽图的工作方式很简单。

对于您即将开始的迭代,请针对该迭代所针对的所有故事中的故事点总数。假设它由两个5点故事,两个3点故事,一个2点故事和两个1点故事组成。总共有20个故事点。制作一个带有X轴的图表,该图表代表从左至右从第一天到最后一天的迭代中的所有天。假设是10天。 Y轴表示已完成的故事点数,在这种情况下,将为0到20个故事点。

在每天结束时,您会汇总与满足“完成”定义的所有故事相关的故事点,并将总计记录在图表上。例如,如果您在第一天完成了1分的故事,在第二天没有完成,而第二天完成了2分的故事,则图表的第一天将具有1点的条形,而第一天则具有1点的条形第二天,第三天则是3分。

基于积分的燃尽图可让您每天以图形方式查看您在实现目标方面所取得的进展。它仅记录成就,而不记录活动,并允许您查看自己是否步入正轨或落后。对我来说,这正是“工作软件是进度的主要衡量标准。

韩元’t图表在迭代结束之前是空的吗?
刚开始时,您可能会认为图表会在大多数迭代中落后于您,并且仅在QA能够开始测试并标记故事完成时才进行追赶,但只要图表显示出稳定的前进之外,到迭代结束,这里是您应该问的一些问题:

  • 我们的用户故事太大了吗?这是否会阻止质量检查人员更早参与?
  • 人们一次写太多故事吗?
  • 我们是否无法生成稳定的版本以进行质量检查?
  • 开发人员是否会产生很多问题,然后继续讲下一个故事,而不是帮助质量检查解决问题?
  • 开发人员是否应该放弃他们正在做的事情并提供手写自动测试的机会?
使用基于积分的燃尽图,从团队到经理再到整个组织,每个人都可以立即了解项目和团队的健康状况。这简化了经理的工作,因为如果表明有任何问题,任何人都可以站起来并说“嘿,团队,我们正在搞砸,我们将如何处理团队?”
燃尽图强化了以下想法:
  • 使用故事点进行估算,可以实现整个团队的思考,例如该整个团队的指标。
  • 使故事尽可能小以使故事尽可能快地完成,从而将重点放在成就而不是活动上
  • 尽可能在同一地点和跨职能的团队工作,以使故事发生最快的周转时间
  • 使团队能够团队合作并自行管理更多事务
与燃烧时间不同,  逐点燃烧是全自动的!
您可能还没有准备好放弃燃烧时间,但是在那里’s no reason you can’不要同时使用。以及大多数敏捷项目管理工具,例如 团结版本一,将自动为您生成基于积分的燃尽图。
那里’还有一个原因,您可能要考虑从消耗大量的时间转移到消耗大量的点,假设您的用户故事总体上足够小,并且您大部分都是在迭代过程中一直完成故事。根据我的经验,团队成员不会’真的很喜欢每天都要输入剩余时间来完成任务,而常常忘记这样做,这使他们将精力集中在活动而不是成就上。同样,唯一需要手动操作的步骤是标记完成的故事,这有助于使整个过程更加流畅。

鸣叫

我如何发现敏捷可以同时教给200个人

我最近在一次活动中与一些敏捷专家交流,该活动涉及一次敏捷培训课程,该课程一次最多可容纳200人,他们对此表示怀疑。后来,我意识到我创建课程的道路…

敏捷书推荐

下列书籍是我推荐的主要书籍,作为学习敏捷各个方面的起点。尽管它们有很多重叠之处,但每个涉及一个特定主题。领导自我指导团队的人不是一辈子…

将看板引入现有的Scrum实施中

到目前为止,最需要我做的演讲是“Scrum和看板像巧克力和花生酱”. I’在美国和欧洲进行了演讲,最近在基辅举行了Agile EE演讲。人们总是在谈话后上台询问如何获得稳定…

Scrum:无需承诺!

几年前,我第一次谈到 将去耦原理应用于Scrum。从那以后我’我把一堆材料变成了一个演讲 “Scrum和看板就像巧克力和花生酱。” I’对演示文稿进行了许多更新,并将其介绍给了各种各样的观众。演示的主要要点之一是,Scrum中所有与迭代相关联的事物都可以以不再与迭代相关联的方式进行定义。我认为,一旦您对所有内容都做到了,那么在锚定点上就没有任何价值了。也就是说,在Scrum中根本不需要迭代。

我不时地’ve意识到我忘了解耦某些东西,将其弄清楚,然后将其添加到演示文稿中。例如,燃尽图,燃尽图和每个故事的时间框。每个故事的时间盒都很难注意到,因为在Scrum中,我们通常认为时间盒处于迭代级别,但实际上,这也将时间盒强加于各个故事上。如果您在不考虑迭代的情况下删除迭代,那么您还将删除每个故事的时间框。

但是最近,在2011年敏捷大会上发表的众多反馈表中,我发现了三个小词:“承诺呢?”哎哟。我错过了一个大的! Scrum团队做出与迭代相关的承诺。我怎么会错过呢?

当我考虑得更多时,我意识到当谈论从迭代中分离故事分配时,我确实以一种副手的方式解决了这一点。但是,我对此表示感谢。它使我意识到,我已经有效地撤消了承诺,好像耸耸肩违背了诺言一样。

Scrum’s Commitment
原来是Scrum’的承诺有点太严格了。甚至由Ken Schwaber和Jeff Sutherland修订的《官方Scrum指南》的版本,Scrum的共同创作者也承认这一点。在新版的《 Scrum指南》中,承诺已由预测取代。这个想法是,预测代表了产品所有者想要的东西以及团队认为它可以作为下一个可交付增量交付的东西的组合。 这是一个合理的响应,但我认为更改中会丢失一些内容。让’换一种方式来看。
互信
Scrum背后的原始想法’我们的承诺是团队致力于完成他们为冲刺而签约的内容,而其他所有人则致力于离开团队。这实际上是基于相互信任的两个承诺。没有这种相互信任,这两个承诺都将无法实现。但是,这两个承诺实际上都是完全不合理的,并且不要’反映现实。目标是好的,但是实现却很差。
问题在于团队没有先知。他们能 ’在他们实际尝试之前,可能无法知道工作的结果。通常,他们的估计是错误的。有时一点,有时很多。事情发生。产品负责人也不是先知。他们能’您可能不知道在冲刺的时间范围内会出现什么业务需求或客户需求会如何变化。坚定的承诺使双方都感到困难。
实际上,最重要的因素是团队与产品所有者之间的相互信任。通过这种融洽关系,团队可以在发现他们做出不切实际的承诺并要求改写故事时与产品负责人联系。它还使产品所有者可以向团队提出新要求,该要求比另一个未开始的故事更重要,并要求交换它们。
解耦预测
如果Scrum现在谈论预测,并且我们对相互信任的承诺过渡感到满意,那么真正的问题是我们如何将预测与迭代脱钩?首先,问问自己是否需要它。如果你不这样做’t, then there’没什么可做的。
另一方面,如果您觉得需要预测,则可以使用与将Scrum的其他方面解耦相同的方法,您只需重新定义时间范围即可。默认情况下,预测与迭代的时间范围相关。如果您的迭代当前为2周,请继续进行并提供2周的预测。这是一个微妙的要点,但是通过单独定义一个预测周期,它不再与迭代长度相关。例如,您可能要进行四周的迭代,然后再进行两周的迭代。但是,如果您将预测与迭代分离,则可以保留四个星期的预测。再一次,在将Scrum中的所有内容与迭代解耦之后,’没有锚定点的锚点的值?

您可能还会对此帖子的后续内容感兴趣, “坚持估计

Scrum和看板像巧克力和花生酱 Slides

对于那些参加了我最近的演讲之一的人“Scrum和看板像巧克力和花生酱,”这是演示文稿的幻灯片。如果你没有’如果您已经参加了会议,请注意没有演讲者的发言和发言…

规划扑克可以减少风险和浪费

那里 are three particularly valuable things that can happen during a 规划扑克 session. They may also happen during any flavor of estimation meeting, but seem to be more likely when 使用 规划扑克.

他们越大,他们越难跌倒

我建议您不要使用大于13的故事。大多数估计为8分或以上的故事都可以拆分为较小的故事。您应该一直在寻找机会将较大的故事分解为较小的故事。如果您有8分或更大的用户故事,则实际上可能是两个或更多变相的故事。故事越大,您的估计就越可能是错误的,并且您更有可能将许多较小的故事伪装成一个大故事。

例如,您可能会发现一个最初看起来像20点故事的故事实际上是两个8点故事,一个5点故事和2个三点故事,总共27个故事点。最好将这个庞大的故事分解成五个组成部分的故事,并分别进行估计。

但是请记住,故事只是为用户提供价值的故事。将故事分为“作为用户我想要X的后端”和“作为用户我想要X的所有UI”不是正确的方法。如果您无法创建仍然可以提供用户价值的较小故事,那么该故事已经与您目前知道的故事一样小。

知道什么时候走开

在讨论一个故事时,您可能会意识到该故事包含一个未知数,这听起来好像在实施该故事期间无法解决。在这种情况下,最好将故事分为研究故事和故事本身。例如,“作为开发人员,我想知道如何进行XYZ。”这样,如果您从不弄清楚如何处理未知部分,则无需为整个故事投入任何精力。该技术仅应作为最后的手段使用,但是这样做比知道存在一个大未知数并且必须在迭代结束时将整个故事拉长要好得多。

知道何时折叠

Lastly, you may decide that you just don’t have enough information to estimate a story. In that case, you should have a mechanism for informing the product owner such as marking the story “need more info.” 那里’s no point spending time on estimation if there is insufficient information to do so. You’ll just be glossing over the problem 和 producing a false sense of security.

散布研究故事并将故事讲给产品所有者看似拖延,但往往会养成良好的习惯。它使团队不会致力于包括研究项目在内的工作,将一些故事明确地定义为研究故事,并使产品所有者保持警惕。

数筹码

总而言之,如果您主要从事的是具有最终用户价值的小用户故事,那么您将减少将某些东西投入永不使用的产品的机会,并且还减少了针对那些从未获得价值的东西进行工作的机会。已完成或必须在整个过程中停产。您的故事越小,遇到问题时的风险就越小,您浪费的精力也就越少。

也可以看看:敏捷评估的五个基本要素

敏捷评估的五个基本要素

规划扑克是一种有用的敏捷估算技术(请参阅上一篇文章“规划扑克介绍“),但与整个团队,用户故事,速度和故事点结合使用时,它甚至更有用。我将这五种实践一起使用,作为进行敏捷估算的五个基本要素。

整个团队

敏捷开发的关键实践是使用整个团队。整个团队是由5至9人组成的跨职能团队。 “跨职能”是指整个团队包含完成团队目标所需的所有技能,而不是每个团队成员都有能力执行任何任务。如果您有9人以上,则将人员分为多个团队。

规划扑克提醒每个人,估算包括要使故事被考虑完成所需完成的所有工作。它包括开发,测试,文档以及将故事视为完成所需的其他任何内容。提醒您,直到整个故事都越过终点,团队中的任何人都不会因出色的工作而获得赞誉。与其说“好,我完成了开发,不知道测试员花了这么长时间”,不如说“您遇到什么问题,我能提供什么帮助”?

用户故事

因为用户故事是对工作的简单且易于理解的描述,所以用户故事使您可以专注于估计而不是花费大量时间讨论特定的增强请求或要求的真正含义。为了最大限度地发挥Planning Poker的优势,您需要善于创建和使用用户案例。

故事点

根据我的经验,用于估算的最佳单位是故事点。一个区域中具有两种不同技能或能力水平的两个不同人员可能需要花费不同的时间来执行特定任务。以小时为单位的估算将需要完成的工作范围与特定人员的工作速度混合在一起。

另一方面,故事点是用户故事范围的相对度量。故事要点将“什么”与“谁”分开。例如,如果您有一个使用.Net胜过Java的人,那么他们将估计Java故事要比使用Java胜任的人花费更多的时间。但是他们可能都同意,容易实现的事情要花两倍的时间才能完成。

要使用故事点,您需要创建一个相对范围的范围。一种简单的方法是找到用于表示单个故事点的简单直接的故事。然后考虑范围扩大了2、3、5和8倍的故事。对于每个故事点值,您应该有几个示例,以考虑到某些故事比编码具有更多的测试,比测试具有更多的文档等。

故事点主要用于计划,而不是用于实施。故事点用于通过计算速度来帮助确定迭代的内容。

速度

在敏捷中,团队的速度仅仅是与迭代中完成的故事相关的故事点数。例如,如果团队完成了8个故事,每个故事中的5个点,那么他们的迭代速度为40个故事点。在一个稳定的团队中,一个由全职工作的个人组成的团队是该团队的一部分,速度是衡量团队整体吞吐量的良好指标。

了解速度有助于进行计划。例如,如果您知道团队的速度是40分,那么您知道每次迭代可以得到40个故事点。团队根据产品所有者维护的待办事项决定要处理的故事。

超过零件总和

无论您当前正在使用哪种实践(整个团队,用户故事,故事要点,速度),规划扑克都是一种出色的工具。您使用的这些练习越多,它们彼此之间的作用就越强,您将从Planning Poker中获得更多的价值。相反,您越使用Planning Poker,在实施所有这些实践中将看到更多的价值。

下一个: 规划扑克可以减少风险和浪费

规划扑克介绍

敏捷开发的许多技术结合在一起提供的不仅仅是部分内容的总和。绝对适合此描述的一种技术是进行估计的Planning Poker方法。在本文的第1部分中,我将快速介绍Planning Poker的机制。然后,我将继续描述用户故事,整个团队,故事点估计和速度如何共同发挥作用,从而使Planning Poker的价值成倍增长,Planning Poker如何增强其他实践的使用和价值。如果您已经熟悉Planning Poker,则可以跳过“敏捷评估的五个基本要素“.

规划扑克是一种估算技术,由James Grenning于2002年在 同名纸 [pdf]。当我第一次听说Planning Poker时,我禁不住笑了。将软件开发和扑克混为一谈似乎有些愚蠢。在阅读了迈克·科恩(Mike Cohn)的出色著作《敏捷估算和规划》之后,我对规划扑克的原理有了很好的了解,但是感觉就像是德尔菲方法的一种变体,因此没有什么新意。

大约一年前 肯尼·鲁宾(Kenny Rubin) 来为我们做一些Scrum培训。这只是我们需要在AccuRev中提高敏捷采用率的关键。如果您正在寻找敏捷培训师,我强烈推荐Kenny Rubin。基于肯尼(Kenny)的解释和建议,我们决定在一个真实的项目中尝试“规划扑克”。结果是了不起的,并且在一个会议之后我们被迷住了。现在,规划扑克已成为我们敏捷流程的标准组成部分。

基础
为了玩规划扑克,每个参与者都需要一副规划扑克卡。这些很容易获得,只需使用Google的“ 规划扑克卡”或自己制作即可。您将需要以下卡:½,1、2、3、5、8、13、20和一张表示“我受够了”的卡。卡上的数字代表估算值。您可以使用故事点,理想的日子或其他一些方法,但是在这一点上,我假设(并主张)故事点。典型的牌组所包含的纸牌数量远远大于20,但是我想您会发现,使用Planning Poker一年或两年后,很少会使用20及以上的牌。

整个团队聚在一起进行一定时间的故事评估。一个小时通常是很长的时间,但这完全取决于您。当我说“整个团队”时,我假设您使用的是由5到9人组成的跨职能小型团队(请参阅后面的部分,讨论整个团队的使用)。

估计是按每个故事进行的,其顺序与待办事项相同,从需要估计的第一个故事开始。有人阅读并描述了这个故事。这通常是产品所有者,但可以是任何人。有些团队在没有产品所有者的情况下进行故事点估计,而只是跳过没有产品所有者参与而无法完成的故事。读完故事后,参加者讨论了一下故事,然后拿起他们的一张卡片并将其面朝下摆在自己面前,从而做出估算。一旦每个人都准备好了,就会显示所有估算值。如果估算值都相同,就可以完成。

通常,某些估计值特别低或特别高。估算值偏低可能表明估算者遗漏了一些东西,或者可能表明他们知道重用现有工作的方式,或者掌握了其他人不知道的一些其他有用信息。较高的估计值可能表明很多事情,但最常见的是,意味着估计者正在思考其他人可能不知道的事情。例如,可能有人指出,没有针对特定技术的测试框架或工具,并且要充分测试故事,团队将需要进行大量的设置工作。

无论如何,经过一轮讨论,每个人都会选择一个新的估算值。重复此过程,直到团队对估算达成共识。估算值将提供给该故事,然后继续进行下一个故事。当您在会议时间结束时结束时,故事用完了无法估计,或者有人打出“我受够了”的卡片。

好处

规划扑克最大的好处之一就是可以创造团队意识。整个团队都参与了估算。对于每个故事,这会增强团队主人翁意识和团队责任感。 规划扑克的另一个主要好处是您可以利用整个团队的集体智慧。但是,这仅在以敏捷的意义使用整个团队时才有效。

下一个: 敏捷评估的五个基本要素