敏捷开发“松结对编程”实践之二:计划与设计篇(大型研发团队,学习型团队,139团队,师徒制度,设计评审,预想陈述,共同估算,扑克牌估算)
Posted on 2011-07-04 20:27 阳光VIP 阅读(108) 评论(0) 编辑 收藏 举报本文是“松结对编程”系列的第二篇。(之一,之二,之三,之四,之五,之六,之七,之八)
新人其实很少偷懒,因为一方面正处于入门学习的高峰期,另一方面工作时间不长需要得到企业和团队的认可。可为何他们工作总是不得力呢?
新人的真正问题在于无心办错事和好心办错事。
无心办错事包括没学过某种好的方法、不知道企业已经有某些可用代码或库、不懂业务等种种问题。
好心办错事包括想做一个比领导想想的更好的功能、过度思考了可复用性可维护性等。
这两个问题笔者都经历过(作为新人和老人),“避免”是最好的方法,而不是事后改正,这就需要在设计阶段和计划阶段从技术、管理两个方面来提前预防。
--------------------------
技术:轻量级设计
如果要把一个任务分配给一个“不放心的人”,有两种办法保证成功:师傅把设计做出来交给徒弟做,但是“设计文档”的详细程度很难把握,写少了做不出来,写多了等做出来了很多内容又多余了;师傅徒弟结对编程,但是很占用师傅的时间,尤其是倘若徒弟“实际上”(可惜只有上帝知道)完全可以胜任这个任务。
有两种解决方法。
1. 事前轻量级设计:预想陈述(有点隐喻的意思)
预想陈述是微软很久以前就使用的一种方法,任何人(不只是徒弟)有什么设计,不用写下来因为太费时间了而且还可能被抛弃,而是给大家讲一下。大家会给出评价和意见,以保证其正确性。然后此人就按这种方法去实现了,倘若成功了也被认可了,就简单写下来以供日后参考使用。由于系统已经存在,这个简单写下来的设计可以真的很简单。
在“松结对编程”里边,有两种类似的做法。
一种是师傅把自己的想法告诉徒弟(一般用一个白板,或一张白纸),徒弟提问师傅回答,到差不多为止。
二种相反,徒弟讲给师傅听,师傅师傅质疑和指导,到差不多为止。
两者都不要事先形成永久文档,但都在被证明可行(就是编码完成后)写一个简单文档记录。任何代码之外的能帮助理解当时做法的文字/图片都可以称为文档,没有字数限制。如果能和用户故事放在一起则更好,一个描述做了什么,一个描述怎么做的。
2. 前检查点
就是在某事开始的时候进行临时结对编程。一般发生在某个功能刚开始做的时候,详情会在之后的“日常活动篇”做详细描述。
管理:共同计划(共同估算,扑克牌估算)
预想陈述、前检查点虽然已经很轻量级了,但是如果师傅和徒弟都刚刚对需求(用户故事)有所了解,还给不出很清晰的思路的时候,比如在Scrum计划会上,怎样快速知道徒弟有没有理解需求,有没有大致的实现思路呢?那就是共同估算(扑克牌估算是共同估算的一种最好的实现形式)。
1. 共同估算
共同估算的原理和做法还是很复杂的,这里只简单说说,以后会有文章详细讲述。
共同估算就是师傅和徒弟基于相同的信息(一般是在计划会上听PO讲完故事的时候),一起说出自己认为做完这件事情需要多久。基本原理是:若两个人对某件事情的工期认识是相同的,那么他们的实现方法不分高下,用哪种方法都差不多。
为了防止人云亦云,一般需要采用匿名方法,而扑克牌估算就实现了高效有效的共同匿名估算(另有文章详述)。
2. 验收标准
为了基于相同的目标建立共同估算,也为了防止需求镀金或最终软件不能满足需求,师傅和徒弟要建立对需求的共同理解。
简单方法就是两者(其实是师傅和多个徒弟)一起参加估算会,一起听PO讲解故事。但最好是在此之后,建立一个“文档化”的验收标准。比如在一张故事卡/Excel表里……上写上“需集成;无性能要求……”等最简单的描述(请参考本博客的敏捷开发分类下一片关于验收标准的文章)。
共同估算+验收标准,使得师傅和徒弟(推广为高手和新手)使用大致相同的方法,做大致相同的东西。共同估算既是一个工作的过程,也是一个学习的过程,因为在理解做什么和怎么做的同时,徒弟也向师傅学到了东西。
--------------------------------------------
这里描述的基本上都是前期工作方式,基于莫非定理(只要事情能出错,就一定会出错)只在事前预防还是不够的,在日常工作中仍需要师傅与徒弟进行配合工作,具体细节将另有文章描述。
点击下载免费的敏捷开发教材:《火星人敏捷开发手册》