项目初始会议 – 如何在一次会议中达成共识

　　英文原文：http://www.infoq.com/articles/project-inception-meeting

　　在启动一个项目之前预先达成团队共识，这一点在效能和效率上是非常必要的。项目对发起人的重要性体现在哪里？项目如何适用于整个组织的蓝图？项目的最高优先级条目有哪些？以及项目发起人愿意在哪些方面进行妥协？如果团队成员在这些方面没有和发起人达成一致，就有可能导致项目进展脱离进度，或者项目成果无法满足项目发起人的预期。同样地，如果项目发起人与团队无法达成一致，项目发起人就可能会对团队的能力，项目发布的质量与时间抱有不现实的预期。那么，你该如何让这个广义上的团队达成一致呢？

　　通常情况下，团队成员个人很少会在日常工作中与项目发起人产生大量的互动。通过与整个团队高忠诚度的交流来达到团队共识，远比大量的邮件、文档和电话会议更为有效。通常情况下，由于地理位置，干系人的时间安排和项目安排的原因，保持整个广义上的团队每天都能够保持高忠诚度的交流是不可能的，但整个广义上的团队肯定可以保证在某一个指定的日子里聚在一起。

　　在Pivotal公司，特别是在我们Cloud Foundry团队，我们保证团队达成共识的一个有效方法就是开一整天的独立的会议，我们称之为初始会议。通过本文，你将会学到与这个方法有关的“为什么”，“什么”和“如何”的有关答案，并且回顾一些从这个方法受益的具体例子，这些案例都来自于真实的Cloud Foundry项目和团队。

　　什么是初始会议（Inception）？

　　典型的初始会议就是，团队用一个工作日的大部分时间，专注于为启动一个新的项目做准备。在需要对进行中的项目进行重新讨论的时候，初始会议一样也可以用于进行了几个月的项目上。理想情况下，在初始会议之后的第二天，研发团队就可以开始那些高优先级的、具体的和可操作的用户故事了。

　　有的时候，启动会议可以使我们团队在开工之前，更早的发现干系人或者是项目的目标不清晰，需要做一些额外工作，从而对共同的目标进行提炼和达成一致。在团队开始工作之前对问题进行澄清和达成一致，远远好于团队已经工作了数周，甚至更长时间之后再重新研究，这些做过的工作迟早也会被丢弃。

　　初始会议与其他流程和方法有关吗？

　　极限编程（Extreme Programming）有一个概念叫规划策略（Planning Game）。初始会议的很多元素都是受这个方法启发。不过在Pivotal公司，我们启动项目通常都是用非常统一的会议议程，它非常有效。这与和松散定义的规划策略的议程不同，后者往往贯穿于项目的整个阶段，而不仅仅是一天。

　　一些人也许会将“初始”这个单词与统一软件开发过程（Rational Unified Process（RUP））中的初始阶段（Inception Phase）联系起来。初始会议和 RUP中的初始阶段在语言或目的上都比较相近，但是初始会议是更为轻量级的方法，它能够在一天内达到类似的目标。

　　为什么要像这样开一整天的会？

　　会议的主要目的是达到团队共识和更好的启动项目。Graham Siener说：初始会议就是让团队关注于“知道项目要创建什么并且从哪里开始”。我的经验是，初始会议可以让团队达成一致，从而更好的开始一个项目，快速交付价值，并且不会在错误的事情上浪费时间。

　　谁应该参加这个初始会议?

　　初始会议的参会者应该包括做这个工作的核心团队、发起项目的干系人或者他们的代表。特别地，还要包括业务、产品、开发，也许还有像运维与支持等其它团队。也有可能包括上下游团队的代表，他们是这个团队开发产品的制造商或者是客户。实践表示，当会议人数超过10人，会议的效率就会开始下降，那是因为这会产生许多小组讨论，而且让20个人有效地参与是很困难的。如果被邀请者列表变得太长，初始会议的引导者或者项目发起人就可以要求团队参与度不高的受邀者，让可以代表他观点的其他参与者参加这个会议。有时候，大规模的初始会议是不可避免的，其代价就是降低每个参会者的参与度并有可能降低共识度。

　　项目发起人或干系人应该参加，或者应该派代表参加，代表是可以代表他们的观点并且是给予授权的。如果发起人没有时间参加这个重要的会议，但又想对项目的决定施加重要的影响或控制，那么这就发出一个信号，这个团队并没有获得对现在和将来所需要的和应有的支持与关注。

　　获得一位有经验的团体引导师是重要的，他可以公平地主持会议。对引导师而言，拥有高效的主持能力是至关重要的。他们负责高效地按照议程主持会议，保证团队进行有效的沟通，理解团队应该在哪些地方深入讨论片刻，并且知道哪些讨论占用了太长的时间，应该暂停，并在之后用小组讨论的方式得出结论。

　　初始会议应该安排在什么时间？

　　理想情况下，在新的项目开始即将之前，或者对于已存在的长期项目，即将开始一个新的主要工作之前，应该启动初始会议。如果一个团队有相当数量的人加入或者离开、或者在方向上有很大的变化，那么重新主持一个初始会议可以帮助团队达成共识。

　　初始会议应该怎样主持？

　　会议引导师应该要求参与者全身心的投入，除了休息时间，不允许打开电脑或者接电话从而分心。引入以下规则：“如果你待在这里，你就全心全意的待着。”可以极大地提高会议的有效性。

　　理想情况下，初始会议应该在一个大的会议室进行，有白板和大的白板纸。推荐使用多种颜色的马克笔、各种颜色的索引卡，胶带和一些像零食或糖果形状的可以用来投票的东西。会议中间应该经常休息，每小时休息五到十分钟。

　　现场与远程参与者

　　相比远程参与者，现场参与者的好处如何强调都不为过。远程参与者更容易受到干扰，从而影响沟通的忠诚度。我以前曾看到过初始会议有几个远程参与者的情况，相对于现场初始会议来说，我觉得远程的初始会议参与度不够，团队从我的参与中所获得的好处则更少。有时候，由于受到现实情况的限制，远程参与的方式确实无法避免。在这种情况下，请尝试用最好的远程在线技术，例如高品质的麦克风和独立的摄像机。用笔记本自带的低音质的麦克风和摄像头容易让参与者受到邮件和浏览网页的干扰。

　　典型的初始会议议程

　　介绍-保持介绍简短，因为你要花几乎一天的时间和团队在一起，并且你们会通过一天的会议彼此很好地认识。让引导师提醒每位参与者简单的介绍几个关键信息会非常有帮助，例如他是谁、为什么在这里等等。

　　愿景和目标 – 项目发起人和Product Owner应该阐明简洁的项目长期愿景和接下来几个月的近期目标。对于愿景和目标的讨论需要给团队安排一定的时间。

　　非目标 – 和目标一样重要，明确的说明什么不是我们的短期目标非常重要。清晰的说明非目标，是我们限定当前工作范围的一种方式，这样给了团队快速发布价值的许可，暂时不考虑那些今后想要、但不是现在必须要有的东西。要确保为小组讨论非目标预留时间。

　　风险 –房间里的每一个人都要用索引卡片识别项目的主要风险。让每个人针对每一个风险写一张索引卡片，需要多少张风险卡片都没问题。引导师应该对风险分类，把相关的风险卡片放到一个类别里叠成一堆。随后把风险读出来，并且给参与者机会，让他们解释在卡片中写下的风险。这还不是对每一个风险进行小组讨论的时机，只是试图理解可能有哪些风险存在。然后，引导师指示每一个人用糖果或其他投票道具对风险投票，每个人三票，找出你认为对于达成项目目标风险最高的类别。你可以对某一个风险类别投出所有的三票，也可以给三个风险类别分别投票。投票结束之后，我们应该从投票数最多的风险分类开始讨论。将每个分类的风险的投票得分记在白板上，或者是一张图片上。团队在当天结束之前应该对其重新投票，看看有没有什么变化。通常情况下是有变化的。

　　角色/情景人物 – 引导师应该进行一个小组练习，用来识别与项目有关的角色 或情景人物。我曾见到过多种不同的识别方式，既可以通过Product Owner简单的陈述来选出角色与人物，也可以让大家一起进行头脑风暴讨论以得出各种不同的角色和情景人物。关键的目标就是让团队的每一个人理解用户都是谁。

　　活动/工作流程–针对项目短期目标范围内的每一个用户角色或情景人物，引导师应该与讨论组一起定义每个角色或情景人物的活动与工作流程。引导师应该针对讨论组的不同情况选择一种合适的方法。可以使用简单的方式，例如让Product Owner定义关键的活动，然后允许组内讨论，也可以是像游戏一样更有创意的方法。用户与系统如何交互的高层次的描述形成了项目功能的基础，通常在之后可以直接分解为用户故事。例如“学生Bobby在书店的目录里面查找一本书，把找到的条目放到他的购物车中，并且完成支付。”就是一个高层次的工作流程的例子。

　　用户故事 – 如果有时间，可以把活动和工作流程分解到更小的、具体可操作的用户故事。不要担心写的太过具体化，Product Owner可以在事后提炼这些语言和细节。有时候在初始会议中并没有时间做这个活动，所以估算和排序必须在高层次的活动与工作流程的粒度上进行。这样也是可以的，因为这是Product Owner的工作，和开发团队一起工作，引导他们遵循初始会议的流程，确保尽快地写出用户故事。

　　估算 – 对于非常重要的用户故事，需要与会的开发人员快速地给出粗略的估算。如果你的估算是在用户故事的层面，可以试图使用团队在开发阶段使用的故事点系统。如果你的估算是处于史诗、活动或工作流程级别的，可以尝试使用几个开发人员周的粗略估算方式。Martin Fowler的 Thrown Estimate 技巧非常有效，可以快速地得到粗略估算。如果你有大量的条目需要估算，我的同事Evan Willey建议使用Affinity Estimating方法。重要的是，客户端发起人和Product Owner可以从负责实现的团队那里直接得到估算。

　　优先级 – 让Product Owner把用户故事按照优先顺序排列，并且允许小组讨论和验证。Product Owner应该能够根据业务价值来判断团队工作的优先级。这些功能在当前阶段是“必须的”，还只是“可有可无”？可以根据团队的大小，看看这个基于故事点的估算是否可以转换成项目周数。在我参加的几乎所有的初始会议中，估算和优先级几乎都预示着团队必须减少在几个月内发布的内容。现在就是一个很好的时机，与项目发起人和Product Owner讨论一些取舍，因为他们很可能是首次从负责交付项目的团队那里得到半精确的估算。

　　风险 – 重复之前的风险讨论环节，看看风险是否发生了变化。

　　下一步 –对接下来几天或几周应该做些什么进行小组讨论。这是为了让团队的每个成员达成一致或者告诉每一个人，接下来团队要使用的开发与签入的流程。通常情况下，引导师和Product Owner会把白板的内容拍下来、收集活动中使用的索引卡片、捕获行动项，并对谁应该发出一篇总结达成统一意见。我偶尔看到团队把初始会议产生的那些白板纸、索引卡片和白板的图片放到团队的工作区域。随着时间的流逝，这些内容就变得过时，价值也开始降低。

　　回顾 – 用敏捷回顾会议对初始会议进行讨论，哪些做得好，哪些东西人们有问题或者有困惑，哪些做得不好，以及对下次会议有什么好的主意等等。

　　放松 –大家在房间里已经待了一整天，每个人都已经非常疲惫。当天的工作结束时间或许已经快到了，最好让团队在办公室以外，例如选择有利于社交的某个集合地，做一些放松娱乐的活动。通常情况下，那些不能参加初始会议的那些人想知道会议的结论并希望与团队沟通，所以邀请那不能参加初始会议的人也是个不错的主意。让这个活动保持随意是比较重要的，因为某些团队成员需要时间放松减压。

　　持续的达成一致

　　初始会议在某一点上及时地达成一致是非常好的，但为了确保持续的达成一致，在项目中也应该使用其他类型的循环反馈回路。有效的反馈回路方式包括每日站立会议，每周的迭代计划会议，每周与项目发起人的会议，每周或每两周的回顾会议，以及项目功能的持续发布。在几个月或者重要的里程碑之后，我建议启动另一个初始会议。因为达成一致的团队才是一个有效的团队。

　　Cloud Foundry项目的初始会议

　　我曾在 Pivotal公司的Cloud Foundry 团队中工作过2年，我相信我们工作的方式给我们带来了高效的生产力，拥有优秀的功能团队，成员们也在工作中获得了乐趣。每一个Cloud Foundry的子项目在启动时都会进行初始会议，包括一些最有创意的功能项目，例如 Loggregator。Loggregator是从所有的应用中直接添加一些聚合的日志给用户，并且从远程终结点的系统日志中排出。在初始会议中，我们明确地从团队中得到半精确的估算，我们确保功能范围只限于流日志，并不扩展到日志的持久化和搜索功能。用Golang重写Cloud Foundry 命令行接口是我们得益于初始会议的另一个项目。在Inception会议中，团队达成一致，我们将从Ruby版本的命令行接口（CLI）开始再考虑改进用户体验，从而帮助我们减少了重写的范围，并有了更好的用户体验。

　　在我以前很多的软件开发经验中，都是使用更传统的瀑布式流程，有大规模的提前设计和文档编写，大规模的团队，以及持续一年或更久的长期项目。我再也不想回到那样的工作方式上了。自从Pivotal 实验室创建以来，我们就用务实的现实项目和持续的改进， Pivotal公司现在使用的方法是基于有25年历史的 极限编程 和敏捷原则。这个流程保证我们达成共识，让核心团队与外部发起人及干系人对项目有共同的理解。在你下一次开始新的项目和方案的时候，不妨试着启动一个初始会议或类似的¹会议吧。

　　¹ 对于这个方法更多更全面的讨论，我的同事Andrew Clay Shafter推荐阅读Diana Larsen和Ainsley Nies写的Liftoff: Launching Agile Teams & Projects 一书。