《敏捷软件开发 : Scrum实战指南》—3.4 建立团队

建立团队

不管选择首先建立一个公司范围内的团队顾问池，还是在小规模的范围内尝试这种模式，组建团队时首先都要考虑项目需要哪些技能。如果技术能力有欠缺，可以向熟悉该项目的同事求助。在鉴别出需要的技能组合之后，还需要考虑一些软实力，比如沟通能力、开放的心态以及团队合作的能力。这些能力常常更难鉴别，但对成功至关重要。这些技能如表3-2第一列所示。

一旦列出技能、能力，就开始挑选合适的人员，把他们映射到你的挑选表中，包含他们的可用性。对每一个人从0星到5星进行打分。记住，这不是一个绝对的量化评估，而只是一个主观的评价。做这个事情你可能需要帮助，在这个过程中加入第二种观点。结果如表3-2所示。相比故事中Rebecca匆忙中的涂鸦，这是一个更加正式的版本，可以根据具体人员与需求进行修改。

核心团队

让我们假设表3-2 是 Rebecca 在会议后画的。从表3-2中，一眼就可以看出 John与 Michelle 完全可用，他们共有三项关键技能：架构、SQL 与数据建模。另外，他们两个也被认为具有良好的团队合作精神。Rebecca 的项目碰巧有大量的 SQL 工作，因此尽管Michelle具有SQL的技能，Rebecca确定她在这个方面需要更多的帮助。看着其他SQL人员，Rebecca在Larry和Scott的名字上画上了圈，他们在一定程度上可用，很可能可以成为全职的成员。她期望的专职团队成员包括John、Michelle、Larry与Scott。从图3-1可以看出，Rebecca的核心团队并不能覆盖项目所需的全部技能。

表3-2  关于能力、技能和可用性的样本列表，对团队成员候选人的主观评价

图3-1  核心团队不能覆盖整个项目

团队顾问

一旦组成核心团队，大家就一起开会讨论自己的优势、劣势以及项目的技能空白。如果发现有技能上的空白，就需要考虑能够利用哪些团队顾问。

让团队开始接触团队顾问池里满足要求并且能够和团队配合的人，如果还没有一个专门的团队顾问池，就在公司范围内寻找。假设 Rebecca 的团队从 Michael 那里得到了承诺，他可以做 C#的代码审核，并且结对来帮助团队完成可能搞不定的 API。团队还要求David与Stefan分别担任用户界面与 Ajax 的团队顾问。最终的团队结构图如图3-2所示。注意团队顾问是如何填补团队技能空白的。

图3-2  团队顾问填补了项目的空白

团队大小

我们都有这样的成见：小团队往往工作做得更快。增加人手需要额外的上手时间。布鲁克斯(Fred Brooks)在《人月神话》[BROOKS] 中提出了布鲁克斯定律：“在已经延迟的项目中增加人手会使项目进一步延迟。”但这是常态吗？

《快速软件开发》作者麦康奈尔(Steve McConnell)在1999年的论文[MCCONNELL] 中提出：“管理得当的项目不像混乱项目那样对布鲁克斯(Brooks)定律很敏感”，因为如果有更好的管理、文档以及设计，人们可以顺利加入项目。然而，甚至他也承认，每个项目都有一个增加人手后反而降低生产力的临界点。这个会降低生产力的可能性带来一个问题：核心团队应该多大规模？团队应该有多少个顾问？

帕特南和迈耶斯(Lawrence H. Putnam & Ware Myers)在1998年进行了一个关于团队大小的研究[PUTNAM]。他们的成果发表在1998年的卡特联盟(Cutter Consortium)上。他们俩研究了491个(新增或修改的)代码行为35 000～95 000的中等规模的项目，全都是1995年至1998年间完成的管理信息系统项目。

他们确认，由5到7人组成的小团队交付时间更短(参见图3-3)，当团队超过9人以后成本会显著增加(参见图3-4)。

图3-3  平均项目时间，小团队花的时间更少

图3-4  团队成员一旦超过8人，开发成本就呈指数级上升

如果有团队顾问，合适的团队大小应该是4到6个核心成员，这样一来，即便加入1到3个团队顾问，仍然可以保持恰当的团队大小。记住，团队顾问可以来来往往，但核心团队要一直保留。

核心团队与团队顾问一起工作

一旦建成由核心团队成员与团队顾问组成的团队，就需要建立鼓励团队合作的指导方针。不同组织有不同的指导方针，但都应该包括下面几条。

在整个Sprint期间，核心团队与团队顾问共同、平等地对他们的交付承诺负责。团队顾问要按时上班，尽量参加每日站会，而且在整个 Sprint 里把自己归为团队成员。除了在某一领域是专家以外，团队顾问与团队核心成员没有任何差别。在核心团队成员与团队顾问之间没有任何等级关系。如果有任何人或事阻碍了任务，必须在每日站会中提出，并立即解决。

也要记住，不能拥有一个完全由团队顾问组成的团队。团队的绝大多数人应该自始至终都只做这个项目。

团队顾问与会议

只要经济和交通上可行，团队顾问就应该参加相关 Sprint 的所有Sprint 会议。记住，团队顾问加入团队是有特定原因的，他们并不是紧急情况下的“备胎”。团队顾问在 Sprint 中有特定的任务，不管是直接工作，还是帮助其他成员完成工作，或者两者兼有。因此他们应该在每日站会上报告进度，并在 Sprint 计划会议与评审会议中提出意见。

l     计划会议：团队顾问在计划会议中可以提高团队的专业水平。如果团队正在估算并碰到一个他们不如团队顾问熟悉的用户故事，团队顾问的意见就是有参考意义。

l  每日站会：团队顾问参加每日站会，可以提高他们对项目的认识，了解项目的进展。

l  Sprint 评审会议与回顾会议：团队顾问参加评审会议可以让客户看见做这个项目的每个人，无论是全职的还是作为顾问。让他们参加回顾会议也是有益的，因为他们对团队情况有更好的了解，但记住，他们花在回顾会议的时间也来自于他们总的可用时间。

如果由于预算或者时间的限制而使团队顾问无法参加 Sprint 会议，团队就要和产品负责人一起决定如何充分利用团队顾问的时间。如果团队顾问在一个 Sprint 中只能有 8 个小时用于项目，而要求他承担的工作却需要整整 8 个小时，那么对于团队与产品负责人来说，团队顾问完成更多的工作就比参加 Sprint 会议更有价值。另外一方面，团队与产品负责人也可以选择减少团队顾问的任务，使他有时间参加每天日常的 Sprint 活动。对于这些会议，不管决定怎么做，核心团队、ScrumMaster、团队顾问以及产品负责人都需要知道核心团队与团队顾问之间的安排与承诺。