在我来到开源中国之后，尝试将每日站会、代码审查、结对编程这三种编程实践带入团队。而这个过程，我个人觉得是一项非常宝贵的体验。我觉得可以拿出来和大家分享。

先介绍下目前我们团队的结构：3名Java开发，1名前端，2名实习。

以下我不会详细介绍它们分别是什么，也无意讨论它们有什么好处坏处，本文侧重分享在实践它们的过程可能遇到的问题，以及我们是如何处理的。

每日站会

每日站会 （Stand-up ）：是每天进行的会议旨在在组队成员之间进行状态更新。‘半实时’的状态允许参与者了解到潜在的挑战以及用于处理一个困难或者耗时的问题的协调精力。它在一些敏捷软件开发过程中有着特定的价值，譬如Scrum，但是同样可以在任何开发方法论中被使用。术语 “站” 衍生于通过保持与会人员站立的状态（长时间站立会导致不适）从而帮助控制会议的时间的实践。

我们每天会早上花十几分钟（具体时长看团队大小），大家一起站（是站）在卡墙前过卡。卡墙其实就是Team中的任务看板。就这样，我们从“已验收”列到“待办中”列，从上往下，一张卡一张卡的过。这里的卡是指定义了一个小功能需求的卡片。 

站会不过是向领导汇报

我在实践每日站会的时候，发现不少人把每日站会当成一种“向领导汇报”的过程。比如他们会习惯地汇报：我昨天做了1，2，3 blabla。一大串，仿佛说得少就是做的少。所以这个过程，我不断地指正，你们不是在向领导汇报，我们只需要对这件事情负责，说到你的卡时，你就说你的卡的当前状态就好了。慢慢地团队里就养成了对事不对人的文化。为什么呢？每日站会就是提醒我们每日的工作就是对这些“事”负责。

随着时间迁移，我们的团队就慢慢习惯了这种站会。也会在站会上开一些开玩笑了。不要认为这是浪费时间，这是团队文化中很重要的一部分。

站会时间把控问题

站会还可能会遇到的问题是站会时间的把控。所以，我们每日站会会有一个主持人。如果大家说偏题了，主持人就必须指正，让相关人在站会后自己讨论。如果大家讨论的这个问题是个大问题，那么，也是在站完会后再讨论。另外，主持人还要是轮换的，这样就可以将团队所有成员带入项目。

站会上的新人问题

每日站会常常遇到的问题是过卡时，这个人说得太细了，把功能的具体实现细节都说出来了。这时，我们不应该立即打断他。出现这样的情况，说明他一定是新人。我们应该选择在站会后单独找他重申一次每日站会的目的和内容。当然，一开始实践每日站会时，团队里除了你每个人都不懂时，你就有必要马上指正了。

代码审查

代码审查（Code review）是指对计算机源代码系统化地审查，常用软件同行评审的方式进行，其目的是在找出及修正在软件开发初期未发现的错误，提升软件质量及开发者的技术。代码审查常以不同的形式进行，例如结对编程、非正式的看过整个代码，或是正式的软件检查。 

我今天没有什么好说的

一开始，我实践时，遇到的最大问题是：团队成员喜欢说，我今天没有什么好说的。这句话听起来冷漠，其实背后的原因是大家不完全理解代码审查是什么，而不是因为他们真的没什么好说的。

这时，我会说：只要你今天做了的事情，你都可以说。然后，他们常常不知从何说起，接着，一上来就给我们讲代码细节。

遇到这种情况，我们需要再强调一遍代码审查需要说什么：上下文、你是如何解决问题的、解决过程遇到什么问题……有时被审查的人可能说的不够明白，我就会帮助补充。

这个过程，你可能会发现有些人在表达能力上的不足，导致听的人一头雾水。我的做法是理解他说的，然后尝试帮助他更好表达出来。这样，提升他的表达能力的同时，让他在团队里也更有归属感。

说得太多了

有时，有些成员可能会说的非常非常细。多人这样了，就会导致代码审查的时间过长。发生这种情况，将表达能力的问题排除外，大概就是这个人没考虑哪些应该是自己应该重点说出来的。这时leader就要站出来指正了。

没写代码怎么审查？

其实，我们实践的代码审查并不是十分严格。因为有时，我们一天下来没有写代码，而是做调研工作。遇到这种情况，被审查人也需要主动分享他今天的习得。有时，他说出来某个问题，也许其他成员也遇到过同样的问题，并解决了。这样就为团队节约时间。

结对编程

结对编程（Pair programming）是一种敏捷软件开发的方法，两个程序员在一个计算机上共同工作。一个人输入代码，而另一个人审查他输入的每一行代码。输入代码的人称作驾驶员，审查代码的人称作观察员（或导航员）。两个程序员经常互换角色。 

如何将结对编程带入团队？

我们的做法由一个懂得结对的人分别和团队里每一个人进行结对。结对前，详细说明结对可能遇到的情况，比如双方有争执，一直都是一个人写的情况，双方都遇到不懂的情况……然后，结对时穿插结对编程的知识。

团队成员中的两个都没有结对编程的经验，怎么办？

实际情况是我们遇到更麻烦的事情。

因为我在前端不擅长，所以我决定让两名前端结对。问题来了，这两个人都不会结对，在沟通方面也不是非常擅长。让他们结对后，我发现他们一起结对的时间非常少，一天下来基本就是各做各的。这时，我发现不对劲。我就分别找他们谈。为什么要分别呢？是希望他们大胆说自己的感受。

在和他们谈了之后，发现根本原因是他们没有完全理解结对编程的目的。这时，找到他们俩再重申一遍结对编程是为了什么，以及如何结对。

新人对结对编程常常有的疑惑？

他在写代码，我看着有什么用？

软件开发是一项集体脑力活，知识的流动在这项活动中非常关键。结对编程是促进知识流动的行为。

看别人写代码的人，我们称为“观察者”。写代码的人，我们称为“驾驶员”。观察者的职责是对写代码的人的代码进行审查。其实除了这点，我更看重的是这个分享思维方式的过程，会加速双方的成长。这个过程还能营造一种相互学习的文化。

我觉得我一个人一下子就写完了

说这句话的人的能力不会差。其实有这样的想法很正常。这时，我们就鼓励他多分享。当我深究下去时，他说写那些东西根本不需要动脑。还很得意的样子。不知道你们有没有发现其中的问题：他在做体力活。更大的问题是：他还不知道自己在做体力活。这时，我会说：当你在做体力活时，和机器没有区别，说明你在退步，这时，你应该跳出来，挑战自己，比如coach别人，或找到一种避免这种体力活的方法。

如果你有什么疑惑，可在本文评论留言。

小结

每日站会，代码审查，结对编程实践的先后顺序的？

本质上是没有先后顺序的。但是如果你是一位新来的leader，你就需要考虑你加入的团队的情况了。我们是先施行每日站会，代码审查。最近一个月才开始实施结对编程。为什么呢？因为对这些编程实践，如果强硬推行，可能会受到排斥。你需要时间让团队成员消化。

给人留下“什么都管”的印象

由于我带来了这些新的实践，看到团队成员实践过程的一些问题就会指出，所以经常给人“什么都管”的印象。

当leader什么都管时，leader要问自己为什么什么要管，而团队成员也要反问自己为什么什么都要被管。排除leader的性格问题外，大多数时，是因为团队还处于比较初级的阶段。你问问自己，团队里有多少人可以自己做leader的就知道了。leader应该跟大家说清楚这点。这样大家就理解你了。但是这个“初级”的阶段要多长时间？就要看你什么时候培养出另一个leader了。

你会发现我在本文没有谈什么M捷或者精Y，是因为我想就事论事，不想谈理论，只想解决实际问题。

问题来了，你发现团队中没有人会结对，你作为leader不懂得如何结对编程时，怎么将结对编程带入团队中呢？

这时就需要请外援了。好听一些，请咨询顾问。如果你觉得看了我的文章，觉得我还行，也可以找我。我在开源中国众包发布了一个专家服务： 将每日站会、代码审查、结对编程带入团队

Last modified on 2016-04-01