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

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

　　英文原文： 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 一书。