敏捷计划

敏捷与OKR实践(如何让OKR与敏捷计划共存)

Bob Jiang
僵化的详细长期计划(根据消耗的预算跟踪进度)正在敏捷组织中迅速成为对过去的褪色怀旧记忆,这由预测和非静态路线图代替。定期在这些可视化文件前聚会,您将能够学习、共享并触发重要的对话,解决依赖性并邀请服务型领导的行为。使您的OKR和预测计划共存! 在这个博客中,我想给出带有可视化示例以及伴随的重复仪式。可视化和伴随的仪式可以共享进度,并确保持续解决和减轻障碍和依赖性。它还将预测变成对话(与被视为承诺的项目计划中捕获的固定估计相反)。 参与团队回答的核心问题是: 敲黑板 - 划重点(译者注) “您是否有信心在本季度末之前完成关键结果?” 你可能还喜欢 Google OKR小册子 如果您不熟悉OKR,目标和关键结果的概念,则可以将目标视为”让我们对这一领域/问题/需求加倍研究”,而关键结果则视为”让我们完成这一特定影响/结果/目标/交付成果”这将推动我们朝着目标迈进。” 对于每个季度,目标数量通常限制为3-5。每个目标依次具有3-5个关键结果。常见的指导原则是,平均而言,您应该以关键结果的70%成功,即以30%失败,这是正常的并且可以接受。该准则可确保我们设定大胆的目标,并避免安全起见。为什么?好吧,如果我们惩罚成功率不到100%的事情,我们最终将优化军阀制度。 OKR白板站立会议 当2017年重新引入OKR时,我曾在Spotify担任敏捷教练。我所工作的部落(认为半自治部门)不希望OKR成为PowerPoint中的静态幻灯片,而该幻灯片很快就被人们遗忘了,但是在生活我们可以随时”计划”,以找出如何互相帮助。 与其以数字演示形式总结部落的集体协作的OKR,我们将它们(OKR)写在一块大白板上,该白板在所有团队旁边的走廊上非常醒目。每两周一次,我们进行OKR白板的站立会议。希望加入的每个人都受到欢迎,但我们要求每个团队(八个团队)至少有两名代表参加。 会议的例行很简单。我们走上了白板,一次实现了一个目标。对于每个目标,我们都会大声读出关键结果的措辞。提供该关键成果的工作团队简短地分享了进展并宣布了他们的信心水平。会议持续了15至25分钟。 置信度 对于每个关键结果,相关团队都回答了以下问题: “您是否有信心在本季度末之前完成关键结果?” 绿色自信的笑脸 –完全自信这会发生。我们可以准备市场营销活动。 橙色担忧的笑脸 –我们可能做不到,应该提醒利益相关者。 红色悲伤的笑脸 –没办法。这不会在本季度内发生。不过,我们仍在努力。 检查 –完成。已交付。做完了。 停止 –我们已停止进行此工作(…由于优先级的改变或关键结果本身已变得无关紧要)。 每个关键结果下方都有6-7个框(取决于该季度中发生了多少个两周的周期),每个OKR白板站立会议都用掉一个框。当我们进行第三次站立时,我们填写了第三个方框,依此类推。这种方法使我们对我们的信心水平有了历史的认识。 如果有几个团队提供相同的关键结果,那么他们每个人都分享他们的进度和信心水平。但是,最悲观的置信度是框中显示的置信度。 提供关键结果的团队名称以方框下方的小文字表示。 实际上,我们有第六个符号-?问号表示”我们还不知道”。有时事实证明这是现实,他们真的不知道。但是对我来说那很奇怪。如果团队不确定自己是否有决心在OKR周期内实现目标,那么如何使团队”致力于”关键结果?但是事实证明它很有用,因此我们使用了它。 关键对话触发器 但是,重要的不是信心笑脸本身的更新-重要的事件是当笑脸的颜色从上次OKR白板站立起改变了颜色。 这些变化是重要对话的关键触发因素。绿色的笑脸变成橙色或红色的笑脸时,我们暂停下来,直到我们共同弄清楚如何采取行动后才继续进行讨论。房间里谁能帮忙?会议室中的谁可以将需要帮助的团队与可以帮助的人联系起来?我们需要提醒利益相关者吗?谁提醒利益相关者?要改变置信水平吗,需要做什么?等等。 仅在决定了至少一项有力措施(有可能推动我们前进)之后,我们才进行下一个关键结果。 即使每个团队每天都尽自己最大的努力来减轻障碍和解决依赖性,但OKR白板站立会议提供了一个反复出现的机会,可以将问题升级为需要扩大支持的朋友和领导者组织。 庆祝完成 当有人宣布他们完成”关键结果”并在框中打勾时,我们显然以雷鸣般的掌声庆祝。 服务型领导的机会 最初,一名敏捷教练协助OKR白板站起来。在前几次的站会中,三个部落首领都没有找到时间来参加。但是在第四次站会,其中一个部落首领加入了。 在几分钟之内,我相信他意识到这是一次千载难逢的良机,可以阅读所有团队的脉搏,对进度进行汇总并提供有益的服务型领导行为。他可以提供建议(在被问到时),为团队面临艰难的选择时提出前进的道路,并由于他或她的广泛网络而提供帮助,将需要的团队与利益相关者和组织的其他部门联系起来。 下一次OKR白板站立会议,所有部落首领都作为观察员参加了会议,准备在被要求时提供帮助和支持。很快他们甚至轮流为仪式本身提供帮助。 OKR白板审查会议 当季度结束后,我们聚集在一起参加OKR白板审查会议。我们回顾了已完成的关键结果,并讨论了未完成的结果。我们能学到什么?在下一个OKR周期中,我们可以带些什么?我们如何改善可视化和OKR板站立状态? 完成百分比 在第二季度,我们运行OKR白板站立会议,我们添加了一个方面来尝试使进度更新更加完整。对于每个关键结果,相关团队不仅回答他们的信心如何,而且还估计到目前为止他们已经完成了多少工作。(译者注:这个百分比慎重加) 我们为什么要这样做?好吧,我们觉得我们缺少故事的一部分。我们了解到,有时即使有些团队只是猜测自己已经完成了10%的工作,他们还是感到超级自信。有时,即使90%的工作都完成了,团队也感到非常悲观。在某些情况下,这是非常有用的信息。 组织内传播 当下一个OKR周期的时候,我们进行OKR白板后续行动的方式已在内部传播。令我们感到惊喜的是,几个部落抄袭了我们的方法。 当某种东西传播并在内部进行时,这是工具/技术/方法有用且有价值的最好”证明”。 可能的变化 如果这种方法对您有所启发,但您在团队或部门中未使用OKR,则此方法有许多变体,仍将静态预测转换为持续对话,从而触发重要对话。 预测扑克计划 如果假设我们正在处理解决一系列特定问题或完成功能之前无法交付产品,那么我们可以要求团队成员逐个猜测 “多少周/每次冲刺可以完成我们需要达到X?”通过在便利贴上写下他们的猜测。 删除最悲观和最乐观的投票,并在白板上写下剩余的范围。如果估计范围不会每周减少一周,那么您就有机会讨论可能采取的措施或缓解措施。 截止日期置信度 有时我们需要应付一个固定的期限。也许我们的机会窗口有限,或者也许我们必须在特定日期之前满足法律要求(例如GDRP)。然后我们可以问团队“我们在日期Z之前完成X的信心如何?” 可以用五个手指进行投票。一根手指代表超级悲观,五根手指超级乐观。三根手指可能意味着紧张。如果信心没有每周增加一次,我们将讨论需要做的事情或摆在我们面前的选择。 版本的猜测 一些团队会持续交付,但仍需要与利益相关者和客户沟通进度和期望。他们从产品待办列表中拉取工作加入到Sprint中。 可视化预测的方法是在Backlog中添加两行(例如,使用胶带)。 每个Sprint Review团队的成员都会问自己两个问题: “我们对在接下来的四个冲刺中交付多少产品列表条目充满信心?” “在接下来的四个冲刺中,我们还能提供多少呢?” 绘制一条绿线以可视化我们有信心我们将完成产品列表的工作。绘制红线以可视化乐观范围。

敏捷软件开发中的版本规划

Bob Jiang
如上图,开始之前我们假设产品backlog做过第一次梳理,并且总的故事点为127.  0. 在迭代开始之前,需要有一个产品backlog,并且其中顶部的一些故事是相对更详细的。  1. 产品backlog需要符合INVEST标准(参见我的一篇博客)。为了达到这个标准,需要产品负责人(PO)和团队一起(早期有可能是团队代表或核心人)对产品backlog进行优先级排序,估算(有故事点估算、团队估算、三角估算等方法)等梳理工作。  2. 假设我们有一个产品backlog如附件所示,每个sprint为3周,第一个sprint团队计划完成21个故事点,基于以上假设,这个项目需要6个sprint完成,即6x3=18周时间  3. 当第一个sprint结束的时候,很不幸,团队只完成了14个故事点。那么需要基于这个事实,对于发布计划进行调整。需要10个sprint完成,即10x3=30周时间  4. 如果第二个sprint完成了18个故事点,则基于第一个和第二个sprint的数据,发布计划调整为8个sprint,即8x3=24周。此时,由于有了2个sprint的数据,我们可以对发布计划的承诺是在24周(最好的情况下)~30周(最差的情况下)之间。  5. 如果第三个sprint完成了20个故事点,则基于前三个sprint数据,发布计划调整为7个sprint,即7x3=21周。此时,由于有了3个sprint的数据,我们可以对发布计划的承诺是在21周(最好的情况下)~30周(最差的情况下)之间。  以此类推,一般来说,我们都是在3个迭代之后,对项目的发布计划做出承诺的。  \================================================================ 欢迎大家提出其他不同的版本规划方法,或者建议。谢谢! -———————————————————————- 微信公众号: 敏捷那些事儿(agileplus) Agile1001公开课,每月一次,旨在推广和传播敏捷开发思想和Scrum,希望更多的开发者受益。欢迎关注。课程信息会定期发布,敬请关注。公开课汇总链接。