大规模敏捷：一个真实的故事

本文要点

• 准备为期两天的大房间计划分。优先考虑它！
• 开始，先为首次大房间计划分定个日期，好让大家去做准备。
• 通过切分和细化，使团队大体上理解史诗故事。
• 一起设定总体规划，与关键干系人在方向上达成一致。
• 在运行大房间计划会时，按照团队的成熟度调整推动者的数量，了解你们的第一次会议将产生大量用于下次会议的经验。

多支团队以敏捷的方式一起协作能更快地为客户交付新产品的服务，我们发现对于许多公司来说， 这就是如何在市场竞争中快速转变的答案。然而大规模敏捷，是比“仅仅”实现团队级敏捷更大更困难的挑战。它是一个组织级的漫长旅程……

这是《以切分、总体规划和大房间计划会实现大规模敏捷》系列文章的第一篇。这是一个真实的故事，来自一家财务服务公司的特定项目，该项目针对的是欧盟金融工具市场法规的投资顾问延伸责任。

人的称谓已经发生了改变。

在我们深入探究这个故事之前，先来适当了解几个词汇。该金融市场法规项目决定遵循以下步骤，我称之为大规模计划会。

大规模计划会

大规模计划会，包括切分和总体规划，是一种可以帮你迎接大规模的计划挑战的实用方法。大规模计划以整体战略目标为出发点，包括以下四个层次的计划会：

1. 切分计划会
2. 总体规划会
3. 大房间计划会
4. 迭代计划会

虽然各种大规模框架为大房间计划会（所有团队和干系人会一起在此聚两天时间）提供了可用的框架，而且大多数组织清楚如何召开迭代会议，但是准备此类大房间计划会仍要做很多的工作。这也正是需要具有切分会和总体规划会的大规模计划会的原因了。

金融工具市场法规项目和六月份的首次大房间计划会

我在五月加入这一项目之后，做的第一件事就是为首次大房间计划会设定日期为六月十六至十七日，我们邀请了团队中的每个人以及其他商业方面的关键干系人，还有两三个负责组织实施的人。我们对时间安排进行了大量的讨论。最大的问题是，“我们会准备好吗？”…项目第一联络人 Pia、首席 scrum master Sally 和我坚持这个日期，我们认为这样能促使大家做好准备。事实证明，我们是对的。我们想把它做好，就能把它做好。稍后我们进行详细地讨论。

在这个大日子来临之前，Pia 设法让业务各部门从他们的观点描述并交付了他们所需的史诗故事。

然后，最终六月十六日到来了，每个人聚到一个大房间里。Pia 向我们提醒了金融工具市场法规（遵从欧盟法规，为银行客户提供更好的投资建议和服务）的商业效益，作为主要的推进者，我随后提出了这两天的计划。请参见图表：每个团队的计划会日程。

每个团队选择他们觉得属于他们自己的史诗故事（参见图表：史诗故事与团队），然后开始分解为用户故事。

后来，问题出现了……

网上银行团队没看到任何与自己相关的史诗故事。所以为什么还要待在大房间里开会？

另外有支 12 人的团队围坐在圆桌旁。其中两个人在那里讲，其他人低着头一言不发，看起来没精打采的。

其他团队动力倒是比较强，可是根本就不理解史诗故事，所以也很难把它们分解成业务特性。

真是一团糟！

我请网上银行与我一起移步户外，这样就可以畅谈一下了。目前急待解决的问题是，他们是如何组织的。在我看来，他们的团队很像筒仓，因为他们各自对接其他每个产品，包括投资服务。但是我没跟他们讨论这些，因为这么安排也不是团队的想法。相反，我赞成他们分散开，与其他的团队一起参加大房间计划。在某种程度上来说，他们现在就是这样的情况。这会让他们与其他团队更加紧密。

Pia、Sally 和我形成一致意见，我们几个也应分散到团队中，每个人负责推进两个团队。

小贴士
本文中，你会发现一些高亮显示的地方和小贴士，就像这个框，现在第一个小贴士来了…

大房间计划应有足够多的推动者
基于敏捷和团队成熟度，确保有足够的推动者推动大房间计划。通常情况下，一名推动者可以应付一到三支团队。

那支 12 个人的团队有另一个要克服的难题。它简直太大了，很难在一起做有实际意义的计划。我走过去告诉了他们。他们所有人一起看着我，就在我刚要告诉他们拆分之前，Pia 赶紧走过来低声对我说，“嘘，Ole。交给他们自己处理，看看会是什么结果。”然后，不一会儿他们就站起了身，分成了两组，开始了单独的交流。很快，他们就弄了两块团队看板讨论起来。他们自己组织成了两个团队。太神奇了！

给予控制权，形成自主性
面对大问题时（以及所有其他类似的局面），你需要让个人发挥主观能动性。否则，你永远都无法取得成功。和那么多人在一起，你作为管理者是无法计划和控制所有问题达成目标的。你只能让他们拿出主动性，如果你给他们控制权，会比你大包大揽要好。

现在，我们只剩下“我们不理解史诗故事”这个难题了。但在大房间计划期间这一点没那么重要，所以我们并没去解决它。

我们很清楚，让商业各个部门陈述和交付史诗故事就会带来这样的问题。我们坚持六月这一天是不是难度太高了？如果我们给他们更多的时间，团队会不会更多地参与到描述中，从而理解史诗故事？实际上，我们不这么认为。我们把它视为一个学习机会，我们向自己保证，在三个月后的大房间计划会之前要支持团队更好地理解史诗故事。

设定一个日期——促使大家去做准备
为第一次大房间计划会设定一个多少偏乐观的日期，能促使大家去做准备。如果你想等所有人都准备好了，那么可能你会永远等下去。

切分——细化——理解

在团队以某种方式开始开发一些业务特性之后（最终，与业务部门有很多的交互），他们想为下次大房间计划会做准备了。这是出于业务方面的考虑，我觉得这非常好。我们已经有了主人翁精神。这不再是管理者的计划，而是他们自己的计划。

其中一支团队请我帮忙解答一个问题：完美的史诗故事看起来是什么样的？

我看了看我在以往项目中经历过的史诗故事。又看了看别的项目中其他的史诗故事。我思忖良久，又看了很多，最终觉得很泄气，因为我没找到一个可以称之为完美的史诗故事。

然后我开始思考成功的项目和不成功项目之间的差异，发现史诗故事的格式无关紧要，甚至其他任何模版或需求规格说明书都是如此。

我遇到该团队后跟他们分享了切分和细化需求的关键：

1. 共同理解
2. 切分史诗故事的方式
3. 描述的格式

这些顺序分先后，所以史诗故事的格式在这三点之中相对最不重要。

为开始共同理解它，我们做了两件事。第一件事，我们把他们带来的需求进行了分组。史诗故事、特性和故事融为一体是种不错的组合。有些人问道：“这是故事地图吗？”我说，“是的”，然后解释了为什么我把故事地图看得这么简单：把你的需求放在一张表外，然后移动它们使结构合理，最好将潜在的发布作为结构的一部分。

这引发了一场关于如何组织需求的激烈讨论。大多数需求都与三个新投资银行产品有关，从简单的投资建议到完整的投资证券组合支持。大多数人辩称应按产品切分（潜在的发布），所以我们应该将一个产品 100% 开发完成，把它投入到市场，然后再转向另一产品。其他两个人主张我们应该首先为所有这三款产品想出所有的法律问题，因为不管怎么说我们已经有律师参与了，然后是所有这三款产品的上市计划，再然后是推出这三款产品的其他东西。

我推荐，为了更早得到实际上更小的潜在发布，增加早期反馈和学习，逐个产品（product-by-product ）（参阅故事地图插图，哪种方式？）是一种较好的切分方式。对此团队取得了一致的意见。

现在是时候深入每个需求了，我们一次只拿一个需求，按以下方式细化：1、头脑风暴出所有可能会遇到的问题，写在红色便笺纸上，粘在有该需求的纸上；2、然后尝试一个人一个人地去回答这些问题，把答案写在绿色便笺纸上。有些问题我们可能回答不了，那么就把它交给项目联络人，由他们负责找能够回答这些问题的人。

通过首先来问问题加以理解
为让所有人有共同深入的理解，在你回答任何问题之前，可以先让他们头脑风暴所有可能想到的问题，这一项不错的技巧。这比提问 -> 回答 -> 提问 -> 回答的模式能覆盖更多的方面。这项技巧在待办事项细化（包括进一步细化）方面有非常大的帮助。

切分和理解——从零开始

期间，项目中不同的团队从大房间计划中找出一些他们仍旧不理解的史诗故事。 scrum master 已经把它们打印出来并组织了一个研讨会，项目联络人准备去解释它们。

开始几个小时，他们围坐在圆桌旁围绕这些史诗故事展开了讨论。但他们未取得任何进展。什么结论都没形成。它就是让人觉得很困惑不解。我们商量移到房间的另一头，把八个史诗故事列出来，然后开始在索引卡上写任务，并把它们放到史诗故事上。 不论 scrum master 如何努力地组织这些卡片，不论项目联络人如何努力地解释他对每个史诗故事的理解，大家仍觉得很迷茫。

然后有人说，“为什么我们不把这些旧史诗故事推到一旁，写我们自己的新史诗故事。这样，我们就不需要猜测谁谁谁在写这些旧史诗故事时是怎么想的了。”

然后，情况发生了变化！

又是几个小时过后，这个团队准备好了他们的新史诗故事，打算将它们展示给干系人，以确保他们的思路是正确的。

从零开始来理解
与其试图猜透别人的想法，不妨从零开始，相信大家的群众智慧，这经常能更有效地达成共识。

通过总体规划为下次大房间计划会做准备

我们在准备下一次十月份的大房间计划会时，讨论了第一次会议存在的所有问题，发现还有两件事不太理想：

• 我们针对金融工具市场法规没有足够清晰的长期计划。
• 不同业务部门间未对重要程度和紧急程度达成共识。

上次之后，我们做了个总体规划，但其实也就下三个月的内容比较靠谱，再往后就很难说了。因此，大家不太清楚本次大房间计划会要考虑什么，以及应该把什么再往后推一推。

而且，某些业务领域非常热衷于金融市场工具法规的每个细节，而其他领域更关注用户体验。

换句话说，没有清晰的方向。不论在大房间计划会期间还是之后，要谅解大家花时间从不同的角度来讨论方向，或以不同的角度切入。

我们决定在十月份召开下次大房间计划会之前，拉其他的干系人参与到九月下旬的总体规划会中。我们邀请了每支团队的项目联络人、筹划指导委员会、三个业务领导和 Pia、Sally，当然还有我，一共有 12 个人。

我们先从认为后三个月能到什么程度开始的。在总共 15 个史诗故事中，有两个已经全部完成了，有七个完成了 50%。这不是我们想达到的结果。

然后，我们使用带有 T 恤尺寸的计划纸牌评估了史诗故事。这样大家就能更投入地参与其中了。

我们排了下优先级，我坚持把所有史诗故事放到一起，由业务领导共同商定什么对整个公司最重要。其中一位对我说，“我清楚对于我们这个领域最重要的是什么，但我怎么知道对于其他业务领域来说什么最重要呢？”他说这句话的时候就站在另一个业务领导的旁边，而我只是笑了笑，环视了一下整个房间，这位业务领导笑了笑接过去说“哈哈，我可以告诉他们”。哦耶！

他们真正地参与了讨论，讨论了他们认为我们应在接下来的三个月里完成多少，之后达成了结论：下一批 26 个史诗故事。

同时，我完成了计算（参见插图：项目点）。我算出前三个月我们安排的史诗故事评估有 228 个点（用 T 恤尺寸交流评估的），也就是我们所谓的项目点。但我们只完成了 125 个（97 个计划内的，外加 28 个计划外的）。

使用同一算法，我算出他们在接下来几个月的目标大约是 606 个项目点！

我们收起雄心壮志泼了点冷水，做了调整，准备下次大房间计划会。

通过项目点测量项目进度
只通过汇总所有明细进度报告来测量项目进度往往很消费时间，这个方式与之不同，通过对史诗故事级的粗略估计你可以快速、轻松地了解全貌，并进行计算。

第二次大房间计划会（十月份）

金秋十月，大家再次欢聚一堂。我们看到比上一次多了一些人。网上银行团队带了一些同事过来。几个业务领导也都露了面。显然，大家都对它有所耳闻了，也想参与进来。

我们先从看看前三个月完成了什么开始着手，使用的就是总体规划的概览。然后，我们展示总体规划的结论，它仍有些乐观，但没 606 个项目点那么夸张了。

然后团队聚集到史诗故事概览板周围，这次我们请他们思考各自在这些史诗故事中扮演的角色，即使是小角色。接下来我们把每个人放在一张小的彩色便利贴上，表示他们的团队在这些史诗故事中（参见插图：史诗故事与团队 II）。

在大约一小时之后，我们大体了解哪些团队主要推动哪些史诗故事了，以及其他哪些团队还与每个史诗故事相关。

这个效果令我们非常诧异。有那么多人站在白板前，在这两天里来来往往，一般大家来自不同的团队，讨论对彼此有怎样的需要，对彼此能提供怎样的帮助。

通过可视化团队与史诗故事之间的关系来增加跨团队间的协作
各种史诗故事牵扯到的不只是一只团队，在大房间计划会期间和之后将其呈现出来，以增加跨团队间的协作。

接下来发生了一件事，几乎在没有任何指导的情况下，团队自发开始拆分和评估了。我发现 Sally 和 Pia 几乎什么也没做，当然，也包括我。

我非常地开心，不告诉大家做什么，而是让他们按自己的理解做出自己的决定，以及互相动员和邀请参与首次大房间计划会，这就是现在明显收到的回报。新的工作方式已经内化到了团队和大家心中。我们即将实现持久的改变！

在这些团队致力于他们的计划和之间的协作时，Sally 有时间去改进项目板了，从而为团队交付特性做好准备。她买了一些漂亮的胶带，规划了一下这块板，包括为每支团队每个迭代特定数量和尺寸的便利贴分配空间。同时，她考虑了第一块项目板上有很多的信息，很难了解大概的信息。所以，她决定请团队为他们的特性取个简称，只把名称写在粘在项目板上的便利贴上。

最终，一块结构更好的项目板诞生了，它只有少量的细节，能更好地说明大概情况，是个更好的每周 Scrum-of-Scrums 的工具，所有 scrum masters、项目联络人和其他干系人聚在它旁边，了解实际进度并去比较与计划的偏差。

我很好奇他们怎么看花上大房间计划上的时间，所以我问了几个人起初抱怀疑态度的人。看看他们是怎么说的：

大家是怎样参与大房间计划会的？

太令人兴奋了。许多干系人都参与进来了，与我们一起交流，这真是太好了。我们面向整个项目讨论任务和评估。它太大了，太复杂了，就像意大利面。我觉得每个人都学到了很多。

真是太好了。它打开了我的视野，现在能理解其他人都在做什么了。那块项目板超级概括了整个项目。

两天是个很长的时间。这笔投入值得么？

“是的，没错。结果使我感到吃惊。一开始，我觉得两天时间太长了。但每个人都学到了很多。我们现在清楚需要彼此交流了。为了协作。这笔投入很值。”

“每一秒都很值。有事发生时，我们可以直接走过去找其他人聊聊。往常我们是不那么做的。看看房间里的气氛，非常地嗨。”

有哪些地方我们可以做得更好吗？

当然，没有一件事是完美的。我们在持续学习。其中最应该改进的一个地方是：

我们经历了其中一个需要额外关注的史诗故事。这个特别的史诗故事的截止日期比其他都要难达成，它更加复杂，有更多的团队和干系人参与。我们试着任命了一个史诗故事负责人，由他负责将它确定下来，这很有帮助，但是还不够。我们未达成截止日期，因此必须赔偿一年的软件授权。回过头来看，我们应坚持把两个最主要的参与团队聚到一起。

总结

这是我的故事，在本文章开头，我提到过一些要点，我希望能就此给你一些现实观点：

• 准备为期两天的大房间计划分。优先考虑它！
• 开始，先为首次大房间计划分定个日期，好让大家去做准备。
• 然后，通过切分和细化，使团队大体上理解史诗故事。
• 现在，一起设定总体规划，与关键干系人在方向上达成一致。
• 最后，在运行大房间计划会时，按照团队的成熟度调整推动者的数量，了解你们的第一次会议将产生大量用于下次会议的经验。

下一篇文章

在本系列下一篇文章中，我将深入探讨切分、总体规划和大房间计划，分享更多的经验，提供更多的具体要决和技巧。敬请期待。

关于作者

Ole Jepsen 是一名敏捷转换顾问，与考虑领导变革的组织一起共事。Jepsen 运用其敏捷方法论方面的知识、基于目的的领导力和推动力，与组织和领导共同打造让大家茁壮成长交付价值的开发组织和工作场所。

查看英文原文： Scaling Agile – a Real Story