如何打造合作型团队——阿里内贸团队敏捷实践

本文中，来自阿里内贸团队的工程师分享了所在团队打造合作型“精英”小团队的敏捷实践方法，同时讲述了实践的效果，旨在给大家一些启发，以供参考和借鉴。

能打造出Facebook里所提倡的“精英团队”固然非常好，但这样会对团队中的每位成员都有较高的要求。我所在的团队希望通过将团队合 作精神运用在项目的各个阶段来打造出一支强有力的合作型小团队，并且取得了很不错的战绩：每两周发布一个版本，完成了几次零Bug的项目，实现了一年线上 零故障。

我们团队由2名产品经理、6名开发人员和2名QA组成，并根据团队特点量身定制了一套敏捷的开发方式。本文主要分享在需求、设计、开发和总结等阶段中如何提高团队成员的合作意识，从而形成团队合力的最佳实践。

 

需求串讲评审

提倡需求串讲。上游的质量决定了下游的质量。在软件开发中需求文档属于最上游的输出，所以我们格外重视需求评审。为了让团队成员能充分理解需求，并提高团队 成员的参与度，项目需求不能总由产品经理来讲解，而应采用轮流讲解的方式，每次迭代由不同的人员讲解。需求文档会提前发给所有团队成员，请大家消化和准 备。在进行需求评审时选某一名成员上台讲解需求。虽然需求评审最核心的任务是在“评”上，但如果团队成员都不能很好地理解需求或者不能很好地参与到需求评 审上，是很难做好需求评审的。

全员参与设计

为了提高设计和评审的效率，并且能够让全员充分参与到设计和评审中，我们团队提倡结对设计、简单设计、交叉设计和全员参与设计评审。

• 提倡结对设计。需求评审完之后，会让团队成员一起来认领任务，但每个任务必须由两名成员认领，这两名成员分别是这个任务的主Owner和辅Owner，并结对设计这个任务。
• 提倡简单设计。第一是设计快并易懂，第二是只做必要的设计。在设计评审前做的设计只能算设计草稿，用Visio等软件做设计比较费时间，在设计评审后还要 修改，如此反复很浪费时间。而事实上一支笔和一张纸足以完成一次设计，先在纸上画出自己的设计思路，然后同结对的成员进行讨论，最后评审完之后将设计图拍 照提交到文档库。对于互联网产品的开发，提倡只做必要的设计，需要时再重构。因为根据以往的经验，扩展性良好的业务设计通常会有三个问题：第一，设计和开 发时间比较长；第二，代码不易读；第三，大部分扩展以后都不会用到。
• 提倡交叉设计。为了让团队中每个人都能充分了解各个模块，所以在不同的项目中每个人负责的模块会不一样。项目1中设计A模块的人，可能会在项目2中设计B模块。
• 全员参与设计评审。为了全体成员都能充分参与到设计评审中，我们制定了几个固定的策略。

评审时间要短。因为大部分人在会议中只能专注20分钟，所以设计评审要在40分钟内结束，设计者可使用PPT或直接在黑板上画出设计思路。让参与者充分了解设计的模块。如果是对已有功能的修改，设计者必须先讲这块功能原来什么样，现在需要修改成什么样，涉及哪些修改点，是如何设计的。这能让其他模块的设计者更了解这个模块，参与到这个模块的设计评审中。

如果设计方案审批没通过，则需要设计者返工。为了提高效率，不需要再开一次会议评审重新设计的方案，将相关人叫到座位旁边确认就可以。

结对Code Review

• 提倡结对Code Review。如果模块是由一个人设计的，那么Code Review时审查者只能帮助队友Review出代码中是否有坏味道，却很难Review业务逻辑是否完全正确。因此，提倡结对Code Review，每个模块由两个人设计，然后分开开发，最后交叉Code Review，这样能Review对方代码中的业务逻辑是否正确。
• 提倡主动Code Review。结对的成员相互Review代码会存在一定局限性，所以项目经理要对核心功能进行Review。如果团队中有人提前完成功能，也提倡他们主动帮其他人Review代码。
• 代码审查的时间。在时间充裕时，提倡每天进行一次Code Review，好处是修改成本低。通常情况下，在提交测试前2天开始做Code Review，但如果时间比较紧，也会在项目结束后做Code Review。

寻求帮助的晨会

晨会通常用于汇报工作进度，而我们希望将打造成寻求团队合作的会议。很多时候，项目质量低下主要是因为团队成员开发时间不够。如果某位成员实现某个功能发生 了延迟，那么他肯定没时间写单元测试，更没有时间帮别人做Code Review。此时，就应该在晨会上将这个问题告知团队其他成员。我们不会因某名成员实现功能延迟而责怪他，更不会让他加班追赶进度，而是在晨会时请其他 团队成员帮他完成单元测试和Code Review。我们是一个团队，有问题绝对不会让团队的某名成员独立承担。

不断精进的项目总结

这些方法不是团队创建之初就有的，是通过每次项目总结和下个项目实践不断精进出来的。在做项目总结时，所有成员都要针对本次项目的不足提出下个项目需要改善的地方，定出下个项目中可尝试的实践，并确定一位负责人和完成时间。

根据经验，如果不确定负责人和完成时间，任何实践基本都很难完成。另外，我们通常只定一个实践在下个项目中执行，定多了也很难完成。而且为了让大家能够在项目总结会议中畅所欲言，通常会将项目总结会议办成一个茶话会的形式。

为团队质量而赌

在项目开始前，开发人员和QA会轮流坐庄，赌本项目的Bug数会是多少个，输的一方要给赢的一方买饮料喝。这么做主要是为了在提高项目质量的同时培养团队合 作意识。如果开发要想获胜，那么团队中的每名开发人员都尽量不要产生Bug，避免拖累整个团队，而团队的其他成员为了实现目标会更加主动地帮助同学做 Code Review。但这个目标必须定得非常合理，如果项目中涉及到大量的前端开发，则Bug数会更多，目标要定低一点。在本次项目目标达成之后，下一个项目会 定更高的目标。