敏捷自上个世纪末诞生至今，相关的书籍和文章可以用汗牛充栋来形容了，而且不乏一些经典必读的著作。但我仍然有很多同事或者朋友，在刚接触敏捷的时候会陷入一种“丰田困境“：明明已经复制了丰田模式，却达不到丰田的精益效果。他们常常问我是否有什么书能从“术”这个层面，以时间轴的形式介绍在每个阶段应该做什么，达到什么小目标，那么就可以一步步让敏捷逐渐落地，给“高大上”的理念和方法论增添些烟火气。但可惜的是，目前市面上似乎还没有出现类似的书籍或文章。而这也促使我萌发了创作一系列文章来补充这个空白的想法，希望能抛砖引玉，帮助初次接触敏捷的人能走出上面的困境，真正享受到敏捷所带来的高效和快乐。

文中所分享的这些实践已经在将近10个团队里进行过验证，复用率至少可以达到80%。虽然如此，但还是请牢记：在不确定的环境中是不存在“最佳实践”的。所以，采纳的时候请结合自身团队的情况进行合理的裁剪，不要生搬硬套。另外，这些实践都以Scrum框架为基础，阅读前请了解一些Scrum知识，至少通读过《Scrum指南》，否则很多术语将会成为你的阅读障碍。

最后，郑重声明：这些实践并非都是我的个人原创。哈耶克曾经说过，人类的知识是分散在每个人身上的，而不是集中于某个人。这句话不仅仅符合敏捷对团队的认知，也正是我当下的创作理念和源泉。

一、什么是“斯巴达方阵”

电影《斯巴达300勇士》里，斯巴达国王列奥尼达带领300死士对抗波斯50万军队的壮观之举，不禁让人大呼过瘾。尤其是另敌人胆颤的斯巴达方阵，没有复杂的变化，也没有玄妙的机关，但其威力惊人，远超“以一当十”的效果。那软件团队中的“斯巴达方阵”应该是什么样呢？

图1 斯巴达方阵（来源于《斯巴达300勇士》电影海报）

参照布鲁斯·塔克曼的团队发展五阶段模型（图2），我们认为成熟期（Performing）就是团队的“斯巴达方阵”。此时的团队已经完全脱离了最开始的不稳定氛围，成为一个真正的团队并作为一个整体高效运作。成员间已经建立起足够的默契，工作时往往不仅限于交付自己的任务，也主动关注其他成员的困难，协同一致实现更高的目标价值。这时的团队氛围和工作绩效将达到顶峰。这也正如列奥尼达所说：我们形成一个无法突破的整体，那就是斯巴达方阵力量的来源。

通常，只需要6个Sprint 就可以打造出斯巴达方阵。换句话说，如果你的Sprint长度是2周，那也就是在三个月（90天）之后，你将得到一个战无不胜的真正团队（这应该还只是个保守的结果：如果你把Sprint的长度设为1周，那么在30个工作日之后就能做到了）。在此期间，你（做为Scrum Master）应重点关注团队和PO；之后，关注点可能会转移到工程实践和组织层面。

很简单是吗？但简单并不意味着容易。当时整个希腊城邦都在用这种方阵作战，但只有斯巴达能发挥出威力，被称作“上帝带领的军队”。

图2 塔克曼团队发展五阶段模型

二、启动Sprint之前

有些人会把启动Sprint之前的准备阶段称为“Sprint 0”。但由于这种称呼会混淆真正Sprint的一些宗旨（比如说每个Sprint都应该有“潜在的可交付的产品增量”等等），所以我们这里也不用这个简洁而又时髦的称呼。

这个阶段的目标是为Sprint的启动做好准备。其重要性不言而喻，应当如孕期那样谨小慎微。因为前期哪怕很小的失误，之后也将会被成千上万倍的放大，弥补起来困难重重。但也不必过于紧张，只要以下五点准备好的话，其他一般都不是问题：

1.     成立团队

2.     敏捷培训

3.     商定Sprint节奏

4.     生成Product backlog

5.     定义DoD

2.1成立团队

成立团队的目的不仅仅是把人召齐就立马干活，更重要的是在成立的过程当中，通过每个细节向成员们传达出一种参与和授权的理念，建立起开放、轻松、信任的氛围。这种理念和氛围是工作协同的基石。正因为如此，“务虚”才显得那么重要，何况也没那么容易做好。所以，我认为真正的Scrum Master不是在于对敏捷知识的掌握熟练程度，而是能够理解为什么要这么做，并且能够有意识的为未来做好准备和铺垫，甚至成为一种本能。可能这也是孟子所说的“假之”、“身之”和“性之”的三种递增的境界，也是我们常提到的“Being Agile over doing Agile”。

使命

Why——这是回答“为什么”要成立这个团队的问题，至关重要，值得花精力去仔细斟酌，并且后续的所有活动都应将围绕使命去做平衡取舍。使命只需要富有鼓舞性的一句话即可，但这句话将是团队存在的理由，也是激励团队可以为之永远奋斗的终极目标。比如说阿里巴巴的使命是“让天下没有难做的生意”，谷歌的使命是“整合全球信息,使人人都能访问并从中受益”。如果斯巴达三百勇士没有保家卫国的荣耀感，很难想象能有这么强大的战斗意志，取得歼敌两万余人的惊人战果。

成员

Who——团队是由人组成的，招兵买马是理所当然的事情。在Scrum的团队里，三个角色是必须的：Scrum Master, Developers, 还有PO。另外，按照《Scrum指南》里的规则，为了保持灵活性，一个Scrum团队的成员人数通常不超过10个，这也符合邓巴数字（10个人是能保持亲密关系的最大上限）。

团队人员的组成必须满足“跨职能”的要求。也就是说团队要拥有能够完成任务所需的所有技能，至少要包含开发和测试这两种技能。否则，后续的Sprint里会充满对外的依赖，跨团队无休无止的沟通、协调、交接和等待，将会耗尽团队所有的耐心和精力。关于这点，康威定律早已有精辟的描述：“设计系统的架构受制于产生这些设计的组织的沟通结构。”

队名

接下来，给团队起个有趣，且响亮的名字吧。这个过程本身也应该是个有趣的共创过程，让名字真正属于团队自己，而不是属于你，或者某位“领导”的。但你可以为队名指定粗略的范围或确定大致的原则，比如说需要符合其上级团队的风格，或者公司的一贯文化。我现在的公司，团队大都以动物为名，不同类别的团队之间略有微小差别以示区分，比如有的仅限于鸟类，而有的仅限于哺乳动物。

队标

根据队名设计一个队标，增强身份感和形象感。可以在团队内部举办设计大赛，或者干脆你自己在网上搜索几张图片（注意版权问题），最后请大家投票来决定采用哪一张。

队诗

如果团队的上级高管非常擅长诗歌创造，并且也愿意分享，那么请高管来赐诗一首，也是做好沟通管理的重要一步，另外还会给团队带来象征性的积极意义：团队是受到重视的。幸运的是，我们的CEO是牛津毕业的高材生，非常擅于英文诗歌的创作：）

队旗

队名、队标，还有队诗都准备好了，就可以制作队旗了（别忘了加上公司的logo）。如果队旗可以悬挂在所在团队的上方，并且覆盖了团队所在座位的四角，那种归属感和神圣感便会油然而生。

图3 队旗的示例

图4 将队旗置于团队座位上方四角（可以看出，Hawk团队属于一个更大的鸟类部门）

合照

可以在网上找到各种搞怪的合影姿势，让团队们投票选一个自己最心仪的；然后选个黄辰吉日，约好专业的摄影师，带上专业的照相机，大家一起来咔嚓。

图5 各种合照姿势（来源于新浪网）

邮件组/聊天群

为团队建立工作专用的邮件组、聊天群，以及一个不允许聊工作的生活聊天群（这个很重要！）。

主页

为团队建立一个工作专属的主页（共创的Wiki类页面），并将以上信息都放置到团队的主页上，最后别忘了在聊天群里通知大家主页有更新。

聚餐

万事俱备，找个时间搓一顿是难免的。这个环节就强调一点，准备些破冰小游戏，在聚餐中让大家真正熟悉起来。如果说团队里有会玩的小伙伴，也可以交给他来组织。