敏捷开发“松结对编程”实践之二：计划与设计篇

本文是“松结对编程”系列的第二篇。

新人其实很少偷懒，因为一方面正处于入门学习的高峰期，另一方面工作时间不长需要得到企业和团队的认可。可为何他们工作总是不得力呢？

新人的真正问题在于无心办错事和好心办错事。

无心办错事包括没学过某种好的方法、不知道企业已经有某些可用代码或库、不懂业务等种种问题。

好心办错事包括想做一个比领导想想的更好的功能、过度思考了可复用性可维护性等。

这两个问题笔者都经历过（作为新人和老人），“避免”是最好的方法，而不是事后改正，这就需要在设计阶段和计划阶段从技术、管理两个方面来提前预防。

--------------------------

技术：轻量级设计

如果要把一个任务分配给一个“不放心的人”，有两种办法保证成功：师傅把设计做出来交给徒弟做，但是“设计文档”的详细程度很难把握，写少了做不出来，写多了等做出来了很多内容又多余了；师傅徒弟结对编程，但是很占用师傅的时间，尤其是倘若徒弟“实际上”（可惜只有上帝知道）完全可以胜任这个任务。

有两种解决方法。

1. 事前轻量级设计：预想陈述（有点隐喻的意思）

预想陈述是微软很久以前就使用的一种方法，任何人（不只是徒弟）有什么设计，不用写下来因为太费时间了而且还可能被抛弃，而是给大家讲一下。大家会给出评价和意见，以保证其正确性。然后此人就按这种方法去实现了，倘若成功了也被认可了，就简单写下来以供日后参考使用。由于系统已经存在，这个简单写下来的设计可以真的很简单。

在“松结对编程”里边，有两种类似的做法。

一种是师傅把自己的想法告诉徒弟（一般用一个白板，或一张白纸），徒弟提问师傅回答，到差不多为止。

二种相反，徒弟讲给师傅听，师傅师傅质疑和指导，到差不多为止。

两者都不要事先形成永久文档，但都在被证明可行（就是编码完成后）写一个简单文档记录。任何代码之外的能帮助理解当时做法的文字/图片都可以称为文档，没有字数限制。如果能和用户故事放在一起则更好，一个描述做了什么，一个描述怎么做的。

2. 前检查点

就是在某事开始的时候进行临时结对编程。一般发生在某个功能刚开始做的时候，详情会在之后的“日常活动篇”做详细描述。

管理：共同计划（共同估算，扑克牌估算）

预想陈述、前检查点虽然已经很轻量级了，但是如果师傅和徒弟都刚刚对需求（用户故事）有所了解，还给不出很清晰的思路的时候，比如在Scrum计划会上，怎样快速知道徒弟有没有理解需求，有没有大致的实现思路呢？那就是共同估算（扑克牌估算是共同估算的一种最好的实现形式）。

1. 共同估算

共同估算的原理和做法还是很复杂的，这里只简单说说，以后会有文章详细讲述。

共同估算就是师傅和徒弟基于相同的信息（一般是在计划会上听PO讲完故事的时候），一起说出自己认为做完这件事情需要多久。基本原理是：若两个人对某件事情的工期认识是相同的，那么他们的实现方法不分高下，用哪种方法都差不多。

为了防止人云亦云，一般需要采用匿名方法，而扑克牌估算就实现了高效有效的共同匿名估算（另有文章详述）。

2. 验收标准

为了基于相同的目标建立共同估算，也为了防止需求镀金或最终软件不能满足需求，师傅和徒弟要建立对需求的共同理解。

简单方法就是两者（其实是师傅和多个徒弟）一起参加估算会，一起听PO讲解故事。但最好是在此之后，建立一个“文档化”的验收标准。比如在一张故事卡/Excel表里……上写上“需集成；无性能要求……”等最简单的描述（请参考本博客的敏捷开发分类下一片关于验收标准的文章）。

共同估算+验收标准，使得师傅和徒弟（推广为高手和新手）使用大致相同的方法，做大致相同的东西。共同估算既是一个工作的过程，也是一个学习的过程，因为在理解做什么和怎么做的同时，徒弟也向师傅学到了东西。

--------------------------------------------

这里描述的基本上都是前期工作方式，基于莫非定理（只要事情能出错，就一定会出错）只在事前预防还是不够的，在日常工作中仍需要师傅与徒弟进行配合工作，具体细节将另有文章描述。