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

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

新人其实不多偷懒，由于一方面正处于入门学习的高峰期，另外一方面工做时间不长须要获得企业和团队的承认。可为什么他们工做老是不得力呢？

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

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

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

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

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

技术：轻量级设计

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

有两种解决方法。

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

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

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

一种是师傅把本身的想法告诉徒弟（通常用一个白板，或一张白纸），徒弟提问师傅回答，到差很少为止。

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

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

2. 前检查点

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

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

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

1. 共同估算

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

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

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

2. 验收标准

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

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

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

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

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