- 浏览: 317424 次
- 性别:
- 来自: 北京
文章分类
- 全部博客 (262)
- Java (20)
- 设计模式 (16)
- Oracle (13)
- Struts (1)
- 问题解决 (9)
- ibatis (2)
- Maven (5)
- Git (2)
- 实现原理 (6)
- 敏捷开发 (22)
- Spring (4)
- 算法 (8)
- MySQL (2)
- Java工具箱 (17)
- jQuery (1)
- 英语学习 (8)
- 杂谈 (15)
- 多线程 (15)
- Java解惑 (7)
- Linux (1)
- 重构36计 (6)
- 网络 (4)
- PHP (1)
- Socket (6)
- 面试 (1)
- JVM (14)
- 历史与故事 (5)
- 报表 (4)
- CMS (3)
- Windows (1)
- nginx (5)
- 架构设计 (7)
- RubyOnRails (2)
- Hadoop (8)
- Go (7)
- JS (1)
- Web (1)
- 项目实例 (5)
- ubuntu (4)
最新评论
-
jacking124:
按照你这个配置以后提示这个异常?Exception occur ...
Go语言学习:开发环境搭建及Hello World -
焦志广:
有请看http://jiaozhiguang-126-com. ...
Hadoop白皮书(1):分布式文件系统HDFS简介 -
w156445045:
Hadoop 有没windows环境下的配置呢,
谢谢。非常感 ...
Hadoop白皮书(1):分布式文件系统HDFS简介 -
xiangxm:
学习了。
Java 解惑知多少六 -
焦志广:
<div class="quote_title ...
易学设计模式四 命令模式(Commond)
团队中常见的一种情况计划、估算、设计的时候大家还在一起,但编程的时候就会分开。分开看似是安全的,但是却充满隐患。
2001年,一位招聘考试前三名(一共120员工)的程序员的两个月的成果被彻底放弃重写,原因是里边包含3000多个常数,而且很难修改(码流参数),重写的人座位距离他只有4米,重写也只花费了2周;2002年,一位月薪7000(那时候北京房价才3000多)的程序员编写了一个月的4000多行代码,在一个下午被重写为50多行,座位距离他只有5米的项目经理疑惑加惊讶地问:“你真的没学过c++ template?”。
这就是团队的距离,即使是高薪聘请来的程序员也难免犯错。难道我们只能避免下一次问题发生,而不能避免这次问题发生?
-----------------------------------------
前检查点
前检查点就是在做某功能的最初一段时间,师傅与徒弟结对编程,完成最初最重要的设计。
“开始做X功能的时候叫我一声,咱们敲定一下具体怎么做。”这个是师傅的前检查点标准语法。尽管在共同估算的时候大家还是略有共识,但是限于计划会的有限时间,徒弟未必真的知道怎么做。在刚开始的一两个小时里边,师傅带领徒弟一起把基本的结构理清楚,最好写上一些基本代码,让徒弟有一个直观的概念。
在上面提到的2周的重写工作中,重写者和被重写者一起工作了1.5天,重新设计了打包类、递归函数等最难缠的部分;被重写者在剩下的两周里边完成了工作,而且很出色。倘若这一切发生在两个月前该多好。那次事故之后,我们订立了更严格的代码审查制度,所有代码均由部门技术最好的人审查后才进代码库;之后再来的新人,均指派师傅,并由师傅保证其代码质量;将人员划分为需指导的/免于指导的/可指导的/可培训的四级(10年后我在NEC参观交流时发现了几乎完全相同的分级制度)。
前检查点的工作作用是打下设计的基础,保证工作顺利进行。如果一切按照前检查点的设计进行,徒弟可以继续独立工作,如果有偏离,要询问师傅。
前检查点的学习作用是显而易见的,师傅平时工作的精华都展示在徒弟面前。而且这种展示是动态的,在结对编程的状态下,徒弟可以完整地看到师傅是怎样入手工作,怎样思考,怎样解决问题的。
后检查点
后检查点就是某事做完后,师傅检查一下徒弟的结果,保证达到验收标准。
曾经分配给我一个刚毕业半年的组员,刚来没多久就经常看到他上网玩,过去一问,原来工作做完了(真的非常快),惊奇之余赶紧看看结果:功能是有了而且实现得也很好,就是总有点瑕疵:要么按钮不正,要么界面上有错字。后来就改成每次任务完成都赶紧喊我去看看,修正后继续下一个。他后来能力超群,在此公司作为“台柱子”10年,现在还在。
其实多数新人在大学中都形成了“能运行就行”的概念,并不懂商业软件开发的标准。本人也一样,毕业5年还不知道delete内存(C++),每次都是多预留点C盘空间,这样程序就能多运行一段时间,下班之后关机重启就可以了……这样的软件肯定无法在服务器上长期运行的。
在后检查点,师傅可以提出改进要求,也可以当场改动。徒弟在此过程中会发现自己和师傅的差距,并因此而得到改进机会。
后检查点的工作作用是可用来进行代码审查,以确保软件产品的质量,之后会提到。
后检查点的学习作用是帮助新人学习商业软件的开发标准,逐步养成好的习惯。
日常工作
除了在任务前后的时间点外,日常8小时也应该保持良好的沟通。在一次极端的环境中,我们曾经将其发挥到极致。
当时我们以很高的日薪临时聘用了两个不错的程序员。他们技术虽然很好,但是却对业务一无所知,也没有提前看过文档。因为总共也没有多少天,当然不能把任何一分钟花费在熟悉业务上,所以……
1. 每天早上(包括第一天)
整个软件被大致分为三类功能区,互相关联。组长(我)也自己编程,负责其中一类功能。
有20分钟的晨会,组长会把一个简单的设计文档的一部分拿出来讲解给两个人,同时指出今天要做的工作要给予其中的哪些内容,他们提问我回答。散会前我们会就每人的工作做一个简单的估算(当年还不会扑克牌估算,太可惜了),确保当日是可以完成的。
晨会会提到技术问题,而不是每日立会中说的只说进度。但技术问题一般只涉及到要求,比如“做分段计价模型的时候,不要在C++里边做For循环,看能不能在SQL里边解决,如果解决不了来找我”“好,我试试。(或)这可能吗?”凡是有问题的就会稍微深入一点;凡是“我试试”的,都放过,但如果试验的结果不通就必须找组长讨论而不能自行解决。
小组加组长只有3个人,所以所有人都参加这个20分钟会,包括肯定不做某任务的人,也听组长和别人的讨论。
2. 每天下午1:30点左右
就是吃饱饭犯困的时候,组长会分别和大家在计算机前碰头一下,主要是看当日的工作是否可能在下班前完成(坚持不加班);另外就是看是否和晨会上预想的一样。
其实就算是短短的半天时间,事情就可能有变。有一次其中一个程序员在一上午写了大约4屏幕的代码(一般每天才写这么多),而功能却遥遥无期。原来他不知道有个函数可以快速实现这些功能,正在自己造轮子,他本应该告诉组长所遇到的困难。
程序员很少在这个时候求助,他们总是相信自己能最终解决问题……因此在转型为自组织团队的时候,担心程序员会偷懒的想法整体上是多余的,更需要预防的是蛮干/过于乐观/激进/需求镀金/消息闭塞/无法互相学习等问题。
3. 每天下午下班前
当时6点钟有《七龙珠》(工作场所有台电视),两位对此都很着迷,所以我们基本到点就看片,看完后散伙回家。
因为也不能让电视台调整播出时间,基本上下午5点就要开始打扫战场:组长分别找两位,看最终结果是否完成,并做一下修改。同时还要做代码审查(请看下一篇详述)。
由于估算不会太准确,我们专门把所有三不管的小功能梳理出来,谁提前做完了,谁就找其中一个把剩下的闲工夫占上,结果其中一位几乎包揽了全部。
4. 晚上
对,组长晚上还要工作。在他们走后组长会在晚上做个集成,把几个人做的功能合成在一起运行。当时也没有持续集成工具,所以只能手工。
在正常项目的正常团队中,这个工作应该在工作时间完成,也就是说或者找专人(或轮流),或者让组长做,或者让自动工具做最好。推荐小组内轮流负责此事,因此可以让大家理解别人的工作、整体的工作,乃至与组外人员的集成工作等内容,为组员成长为组长打下基础。
5. 随时
可能已经注意到我们没有“每日立会”,一则当年还不知道Scrum,二则感觉一个3~5人的团队还要靠开会交流实在迂腐。比如在篇首提到的两次事故中,团队都没有少开会,但都因为缺少随时的沟通而导致大错。
其实任何伸伸懒腰的时间都可以进行沟通。不过一般不要“太随时”,应该以师傅的时间为主,也就是如果徒弟遇到了问题,但可以绕过去先走着,就先来一句“我这有问题,有空帮忙看看”+“好,再过15分钟”。这样既不会让徒弟被卡住,也不会让师傅因为经常被打断而导致无法工作。但师傅可以随时发起交流,因为他们是去帮助徒弟的,聊的也是徒弟的事情,不存在打扰的说法。
在多数情况下无论徒弟学得多好,小组的主要产出仍然可能一大半来自师傅。因此不能把师徒团队变成一个简单的学习团队,而要通过保证师傅的时间,来保证其首先是一个工作团队。
这个工作习惯一直保持到后来我管理一个市场/销售/支持团队的时候:我选择坐在开放空间的最中央的一张大桌上(各部门经理也都在中央桌上而非独立办公室里),如果有人有事来找,都会问:“有空么?”答案是有空,或者某个时间之后。尤其是每天有10个以上不同的人会找你的时候,时间管理方法是很关键的。
注:上述部分内容仅限于特定环境中,但思路很多时候都是可取的。
-------------------------------------------------------
前检查点的基本作用是保证后续工作有大致的方向,而且徒弟能从师傅的设计过程中受益。
后检查点的基本作用是保证完成的工作符合要求,而且徒弟能从师傅做出的改进中受益。
在日常工作中,师傅要经常过问徒弟的工作,但以保证自己的产出为前提。不能因为已经进行了共同设计和估算,或开了例会就放弃日常跟踪,问题往往出在小处。
ref:http://blog.csdn.net/cheny_com/article/details/6590360
2001年,一位招聘考试前三名(一共120员工)的程序员的两个月的成果被彻底放弃重写,原因是里边包含3000多个常数,而且很难修改(码流参数),重写的人座位距离他只有4米,重写也只花费了2周;2002年,一位月薪7000(那时候北京房价才3000多)的程序员编写了一个月的4000多行代码,在一个下午被重写为50多行,座位距离他只有5米的项目经理疑惑加惊讶地问:“你真的没学过c++ template?”。
这就是团队的距离,即使是高薪聘请来的程序员也难免犯错。难道我们只能避免下一次问题发生,而不能避免这次问题发生?
-----------------------------------------
前检查点
前检查点就是在做某功能的最初一段时间,师傅与徒弟结对编程,完成最初最重要的设计。
“开始做X功能的时候叫我一声,咱们敲定一下具体怎么做。”这个是师傅的前检查点标准语法。尽管在共同估算的时候大家还是略有共识,但是限于计划会的有限时间,徒弟未必真的知道怎么做。在刚开始的一两个小时里边,师傅带领徒弟一起把基本的结构理清楚,最好写上一些基本代码,让徒弟有一个直观的概念。
在上面提到的2周的重写工作中,重写者和被重写者一起工作了1.5天,重新设计了打包类、递归函数等最难缠的部分;被重写者在剩下的两周里边完成了工作,而且很出色。倘若这一切发生在两个月前该多好。那次事故之后,我们订立了更严格的代码审查制度,所有代码均由部门技术最好的人审查后才进代码库;之后再来的新人,均指派师傅,并由师傅保证其代码质量;将人员划分为需指导的/免于指导的/可指导的/可培训的四级(10年后我在NEC参观交流时发现了几乎完全相同的分级制度)。
前检查点的工作作用是打下设计的基础,保证工作顺利进行。如果一切按照前检查点的设计进行,徒弟可以继续独立工作,如果有偏离,要询问师傅。
前检查点的学习作用是显而易见的,师傅平时工作的精华都展示在徒弟面前。而且这种展示是动态的,在结对编程的状态下,徒弟可以完整地看到师傅是怎样入手工作,怎样思考,怎样解决问题的。
后检查点
后检查点就是某事做完后,师傅检查一下徒弟的结果,保证达到验收标准。
曾经分配给我一个刚毕业半年的组员,刚来没多久就经常看到他上网玩,过去一问,原来工作做完了(真的非常快),惊奇之余赶紧看看结果:功能是有了而且实现得也很好,就是总有点瑕疵:要么按钮不正,要么界面上有错字。后来就改成每次任务完成都赶紧喊我去看看,修正后继续下一个。他后来能力超群,在此公司作为“台柱子”10年,现在还在。
其实多数新人在大学中都形成了“能运行就行”的概念,并不懂商业软件开发的标准。本人也一样,毕业5年还不知道delete内存(C++),每次都是多预留点C盘空间,这样程序就能多运行一段时间,下班之后关机重启就可以了……这样的软件肯定无法在服务器上长期运行的。
在后检查点,师傅可以提出改进要求,也可以当场改动。徒弟在此过程中会发现自己和师傅的差距,并因此而得到改进机会。
后检查点的工作作用是可用来进行代码审查,以确保软件产品的质量,之后会提到。
后检查点的学习作用是帮助新人学习商业软件的开发标准,逐步养成好的习惯。
日常工作
除了在任务前后的时间点外,日常8小时也应该保持良好的沟通。在一次极端的环境中,我们曾经将其发挥到极致。
当时我们以很高的日薪临时聘用了两个不错的程序员。他们技术虽然很好,但是却对业务一无所知,也没有提前看过文档。因为总共也没有多少天,当然不能把任何一分钟花费在熟悉业务上,所以……
1. 每天早上(包括第一天)
整个软件被大致分为三类功能区,互相关联。组长(我)也自己编程,负责其中一类功能。
有20分钟的晨会,组长会把一个简单的设计文档的一部分拿出来讲解给两个人,同时指出今天要做的工作要给予其中的哪些内容,他们提问我回答。散会前我们会就每人的工作做一个简单的估算(当年还不会扑克牌估算,太可惜了),确保当日是可以完成的。
晨会会提到技术问题,而不是每日立会中说的只说进度。但技术问题一般只涉及到要求,比如“做分段计价模型的时候,不要在C++里边做For循环,看能不能在SQL里边解决,如果解决不了来找我”“好,我试试。(或)这可能吗?”凡是有问题的就会稍微深入一点;凡是“我试试”的,都放过,但如果试验的结果不通就必须找组长讨论而不能自行解决。
小组加组长只有3个人,所以所有人都参加这个20分钟会,包括肯定不做某任务的人,也听组长和别人的讨论。
2. 每天下午1:30点左右
就是吃饱饭犯困的时候,组长会分别和大家在计算机前碰头一下,主要是看当日的工作是否可能在下班前完成(坚持不加班);另外就是看是否和晨会上预想的一样。
其实就算是短短的半天时间,事情就可能有变。有一次其中一个程序员在一上午写了大约4屏幕的代码(一般每天才写这么多),而功能却遥遥无期。原来他不知道有个函数可以快速实现这些功能,正在自己造轮子,他本应该告诉组长所遇到的困难。
程序员很少在这个时候求助,他们总是相信自己能最终解决问题……因此在转型为自组织团队的时候,担心程序员会偷懒的想法整体上是多余的,更需要预防的是蛮干/过于乐观/激进/需求镀金/消息闭塞/无法互相学习等问题。
3. 每天下午下班前
当时6点钟有《七龙珠》(工作场所有台电视),两位对此都很着迷,所以我们基本到点就看片,看完后散伙回家。
因为也不能让电视台调整播出时间,基本上下午5点就要开始打扫战场:组长分别找两位,看最终结果是否完成,并做一下修改。同时还要做代码审查(请看下一篇详述)。
由于估算不会太准确,我们专门把所有三不管的小功能梳理出来,谁提前做完了,谁就找其中一个把剩下的闲工夫占上,结果其中一位几乎包揽了全部。
4. 晚上
对,组长晚上还要工作。在他们走后组长会在晚上做个集成,把几个人做的功能合成在一起运行。当时也没有持续集成工具,所以只能手工。
在正常项目的正常团队中,这个工作应该在工作时间完成,也就是说或者找专人(或轮流),或者让组长做,或者让自动工具做最好。推荐小组内轮流负责此事,因此可以让大家理解别人的工作、整体的工作,乃至与组外人员的集成工作等内容,为组员成长为组长打下基础。
5. 随时
可能已经注意到我们没有“每日立会”,一则当年还不知道Scrum,二则感觉一个3~5人的团队还要靠开会交流实在迂腐。比如在篇首提到的两次事故中,团队都没有少开会,但都因为缺少随时的沟通而导致大错。
其实任何伸伸懒腰的时间都可以进行沟通。不过一般不要“太随时”,应该以师傅的时间为主,也就是如果徒弟遇到了问题,但可以绕过去先走着,就先来一句“我这有问题,有空帮忙看看”+“好,再过15分钟”。这样既不会让徒弟被卡住,也不会让师傅因为经常被打断而导致无法工作。但师傅可以随时发起交流,因为他们是去帮助徒弟的,聊的也是徒弟的事情,不存在打扰的说法。
在多数情况下无论徒弟学得多好,小组的主要产出仍然可能一大半来自师傅。因此不能把师徒团队变成一个简单的学习团队,而要通过保证师傅的时间,来保证其首先是一个工作团队。
这个工作习惯一直保持到后来我管理一个市场/销售/支持团队的时候:我选择坐在开放空间的最中央的一张大桌上(各部门经理也都在中央桌上而非独立办公室里),如果有人有事来找,都会问:“有空么?”答案是有空,或者某个时间之后。尤其是每天有10个以上不同的人会找你的时候,时间管理方法是很关键的。
注:上述部分内容仅限于特定环境中,但思路很多时候都是可取的。
-------------------------------------------------------
前检查点的基本作用是保证后续工作有大致的方向,而且徒弟能从师傅的设计过程中受益。
后检查点的基本作用是保证完成的工作符合要求,而且徒弟能从师傅做出的改进中受益。
在日常工作中,师傅要经常过问徒弟的工作,但以保证自己的产出为前提。不能因为已经进行了共同设计和估算,或开了例会就放弃日常跟踪,问题往往出在小处。
ref:http://blog.csdn.net/cheny_com/article/details/6590360
发表评论
-
测试驱动开发
2012-11-11 14:21 0测试驱动开发的一般流 ... -
Kent Beck : 领导的敏捷潮
2012-10-15 10:29 923Beck全家似乎都弥漫着技术的味道。生长在硅谷, 有着一个对无 ... -
什么是敏捷(下)(无住,不住于空,破空执,非法,非非法)
2012-10-09 14:23 902破除法执之后,很容易 ... -
什么是敏捷(上)(无住,不住于法,破法执)
2012-10-09 14:20 993所谓无住,包括两个含义:不住于法,不住于空。前者比较好理解, ... -
敏捷开发与本能反应
2012-10-09 14:12 743经常听到有人提到敏捷开发与“本能反应”非常近似,比如凡事都需 ... -
敏捷的未来会怎样?
2012-10-09 13:49 343正法,像法,末法 任 ... -
敏捷开发之大型团队切分
2012-10-09 11:00 1036大型团队的切分 如果 ... -
敏捷开发加班吗?
2012-10-08 17:43 1666问题 敏捷开发加班吗? 楼下有人问到“敏捷和加班有什么关系 ... -
敏捷适合什么类型项目?
2012-10-08 16:44 1409问题 原来问题是这么写的:“一家企业既要过CMMI,又要过I ... -
敏捷开发智慧之:定不定流程和模板?
2012-10-08 15:45 892缘起 (立项时) 甲:“你们的设计文档打算怎么写?” 乙 ... -
敏捷开发智慧之写不写文档?
2012-10-08 15:17 677缘起 “我们产品已经做完了,客户说要补上需求文档,可我们只有 ... -
敏捷开发松结对编程之七问题集锦
2012-10-05 19:06 831人员与结构 在团队中使用层级结构,是否阻碍了个体与外界的沟通 ... -
敏捷开发松结对编程之五代码检查
2012-10-05 18:32 824松结对和紧结对不一样 ... -
敏捷开发松结对编程之三共同估算
2012-10-05 14:58 787估算是经久不衰的管理 ... -
敏捷开发松结对编程之二计划设计
2012-10-03 22:30 720新人其实很少偷懒,因 ... -
敏捷开发松结对编程之一人员结构
2012-10-03 12:11 781传说中的结对编程,大致结构是两个人共用一台电脑,一个开发,一 ... -
敏捷开发心法之共振
2012-10-03 11:42 669共振 共振是以无我、 ... -
敏捷开发心法之无住
2012-10-03 11:33 804无住 在般若敏捷系列 ... -
敏捷开发心法之无我
2012-10-02 21:54 636做敏捷开发时间长了, ... -
敏捷开发松结对编程之六大型团队
2012-09-28 16:49 757松结对编程是小型团队 ...
相关推荐
结对编程——敏捷开发.pdf
2011-10-12在微软tech ed大会上的讲稿
结对编程开发人员之间若干关系问题的探讨,王鹏生,,本文介绍了敏捷软件开发方法XP中关键实践之结对编程在实践中的应用,并指出了结对双方在人员关系问题上的若干问题,给出处理的参�
交换编程-结对编程的延伸实践 交换编程-结对编程的延伸实践
, 本书为敏捷的计划、开发、交付和管理提供了严谨的建议,这些建议来自于作者多年的极限编程(Extreme Programming,XP)经验。你将看到敏捷开发过程的全景图,包括为非技术类读者准备的全面指导,以及为开发者和测试...
介绍分布式结对编程技术和组织策略、存在问题和实验研究
这本综合性、实用性的敏捷开发和极限编程方面的指南,是由敏捷开发的创始人之一所撰写的。 ·讲述在预算和实践要求下,软件开发人员和项目经理如何使用敏捷开发完成项目。 ·使用真实案例讲解如何用极限编程来...
是软件工程中结对编程与应用的描述与实现方法
2020级计算机系软件工程第二次结对编程作业.zip 2020级计算机系软件工程第二次结对编程作业.zip 2020级计算机系软件工程第二次结对编程作业.zip 2020级计算机系软件工程第二次结对编程作业.zip 2020级计算机系软件...
在开发软件项目时,不仅写出相应功能的模块很重要;确保写出的模块的易维护性(bug 修复,代码重构)也同样重要。 主打互联网技术和门户...为了避免这种情况发生,他们决定在开发复杂模块时试验性地使用结对编程。
原则模式与实践》是综合性、实用性的敏捷开发和极限编程方面的指南,讲述了在预算和时间要求下软件开发人员和项目经理如何使用敏捷开发完成项目:使用真实案例讲解如何用极限编程来设计、测试、重构和结对编程;...
XP实践demo for http://blog.csdn.net/nomad2
这本综合性、实用性的敏捷开发和极限编程方面的指南,是由敏捷开发的创始人之一所撰写的。 [b][font color="#ff6600"]特色内容: ●讲述在预算和时间要求下,软件开发人员和项目经理如何使用敏捷开发完成项目。 ●...
结对编程
这本综合性、实用性的敏捷开发和极限编程方面的指南,是由敏捷开发的创始人之一所撰写的。1.讲述在预算和实践要求下,软件开发人员和项目经理如何使用敏捷开发完成项目;2.使用真实案例讲解如何用极限编程来设计、...
这本综合性、实用性的敏捷开发和极限编程方面的指南,是由敏捷开发的创始人之一所撰写的。 ·讲述在预算和实践要求下,软件开发人员和项目经理如何使用敏捷开发完成项目。 ·使用真实案例讲解如何用极限编程...
原则模式与实践》是综合性、实用性的敏捷开发和极限编程方面的指南,讲述了在预算和时间要求下软件开发人员和项目经理如何使用敏捷开发完成项目:使用真实案例讲解如何用极限编程来设计、测试、重构和结对编程;...
原则模式与实践》是综合性、实用性的敏捷开发和极限编程方面的指南,讲述了在预算和时间要求下软件开发人员和项目经理如何使用敏捷开发完成项目:使用真实案例讲解如何用极限编程来设计、测试、重构和结对编程;...
Pivotal公司的Edward Hieatt和他的同事都是从事敏捷开发培训,指导结对编程工作,在跟客户合作中,他们发现有大量的创业公司在成长壮大的过程中,都会经历不同程度的企业开发文化上的变质侵蚀。跟Pivotal公司合作过...
介绍结对编程方法、技术和策略。包括结对编程定义、好处。结对策略与组织方法,存在的问题与注意事项等