2009年08月26日 星期三 10:35
叠飞机与敏捷项目知识传递 作者 * Vikas Hazrati<http://www.infoq.com/cn/bycategory.action?authorName=Vikas-Hazrati> * 译者 * 郑柯<http://www.infoq.com/cn/bycategory.action?authorName=%E9%83%91%E6%9F%AF> * 发布于 2009年8月19日 下午12时3分 标签结对编程 <http://www.infoq.com/cn/pairprogramming>,教练和指导<http://www.infoq.com/cn/coaching_mentoring> 将某种情形下的知识从一个单位(可以是个人、团队、部门、组织)传递到另一个单位,这就是知识传递。很多组织用了很多时间将自己积累的知识记录成文 档,希望知识传递过程能由此变得更顺利、高效。而敏捷并不鼓励文档,它强调“可工作的软件胜过全面的文档”。在在一系列有趣的试验中,Steve Bockman<http://agilefocus.com/author/stevebockman/> 试图找出在敏捷项目中传递知识的最佳途径。 在试验中,Steve试图将一只不寻常的纸飞机作为产品,并将其相关的知识通过三种方式传递。他使用了下面三种策略:<http://agilefocus.com/2009/08/avoiding-the-knowledge-transfer-bottleneck/> - *文档*:工作者们得到写下的纸飞机制作说明(包括22个步骤)。 - *反向工程*:工作者们得到一个已完成的纸飞机,他们可以用之学习如何重现制作纸飞机的步骤。 - *指导*:“首席设计者”按步骤制作一只纸飞机,而工作者们重复完成的每一步。 参与实验的共有8个人,每种方式各用5分钟。实验结果令人惊讶不已。 只有*12.5%*的人能够按照文档完成任务。使用反向工程方法,有*25%*的参与者成功做出飞机,而指导方法则可以让*100%*的参与者全部成功做出飞机。 这毋容置疑地指出:健康的沟通和指导,是传递和分享知识的最佳方式。Steve还认为:对于需要经常沟通和反馈的软件开发来说,这个原则更具价值。在他看来: 假如我是一个开发人员,我发现了一个技巧,可以将一些数据绑定到某个用户界面里的控件中,而且写出了代码实现。这个 技巧构成了一种模式,与我一起开发的同事们希望了解具体做法。如果你是我的同事,有三种方法:a)我给你一个说明该技巧的相关文档;b)我告诉你代码在哪 里,建议你自己弄明白;c)我跟你结对编程,通过一组新数据实现该模式;你会选哪一种? Young Ye和Royce Fay建议使用另外一种使用不均衡结对编程(<http://www.agilealliance.org/system/article/file/1409/file.pdf>Asymmetric pair Programming<http://www.agilealliance.org/system/article/file/1409/file.pdf> )高效传递知识的方法。该方法的本质在于:它除了在开发人员之间结对之外,还可以在开发人员和领域用户之间结对。这样做的重点也在于人与人之间的沟通,而不是文档。 结对编程有一个广为人知的好处,就是快速的知识分享和传递。Alan Skorkin同意这个观点,同时指出:<http://www.skorks.com/2009/07/effective-vs-ineffective-pair-programming/> 我认为:最重要的好处在于,结对对于有机的知识传递效果非常好,尤其是大型系统中,这是关键,因为根本没有其他方式能够做好这一点。 因此,大家都同意传递知识的最好方式就是通过沟通、指导和一起工作。虽然,有些文档确实有用,但单单依赖文档能带来的好处很有限。 *查看英文原文:*How to Transfer Knowledge in an Agile Project<http://www.infoq.com/news/2009/08/agile-knowledge-transfer> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 太现象了!而且有实验作证! -- http://zoomquiet.org 人生苦短,Pythonic!-) 一个人如果力求完善自己,就会看到:为此也必须同时完善他人. 一个人如果不关心别人的完善,自己便不可能完善! -------------- 下一部分 -------------- 一个HTML附件被移除... URL: <http://www.zeuux.org/pipermail/zeuux-universe/attachments/20090826/fede240c/attachment.html>
2009年08月27日 星期四 09:26
On Wed, 2009-08-26 at 10:35 +0800, Zoom.Quiet wrote: > 叠飞机与敏捷项目知识传递 > 作者 Vikas Hazrati 译者 郑柯 发布于 2009年8月19日 下午12时3分 > > > 标签 > 结对编程, > 教练和指导 > > 将某种情形下的知识从一个单位(可以是个人、团队、部门、组织)传递到另一 > 个单位,这就是知识传递。很多组织用了很多时间将自己积累的知识记录成文 > 档,希望知识传递过程能由此变得更顺利、高效。而敏捷并不鼓励文档,它强 > 调“可工作的软件胜过全面的文档”。在在一系列有趣的试验中,Steve Bockman > 试图找出在敏捷项目中传递知识的最佳途径。 > > 在试验中,Steve试图将一只不寻常的纸飞机作为产品,并将其相关的知识通过 > 三种方式传递。他使用了下面三种策略: > > * 文档:工作者们得到写下的纸飞机制作说明(包括22个步 > 骤)。 > > * 反向工程:工作者们得到一个已完成的纸飞机,他们可以用之 > 学习如何重现制作纸飞机的步骤。 > > * 指导:“首席设计者”按步骤制作一只纸飞机,而工作者们重复 > 完成的每一步。 你们知道我们的策略吗? 我总结了一下,就是这个: *反向文档指导:"首席设计者"要工作者们设计飞机,同时把详细的文档写 出来给他看…… > 参与实验的共有8个人,每种方式各用5分钟。实验结果令人惊讶不已。 > > 只有12.5%的人能够按照文档完成任务。使用反向工程方法,有25%的参与者成功 > 做出飞机,而指导方法则可以让100%的参与者全部成功做出飞机。 > > 这毋容置疑地指出:健康的沟通和指导,是传递和分享知识的最佳方式。Steve > 还认为:对于需要经常沟通和反馈的软件开发来说,这个原则更具价值。在他看 > 来: > > 假如我是一个开发人员,我发现了一个技巧,可以将一些数据绑定到某 > 个用户界面里的控件中,而且写出了代码实现。这个 技巧构成了一种 > 模式,与我一起开发的同事们希望了解具体做法。如果你是我的同事, > 有三种方法:a)我给你一个说明该技巧的相关文档;b)我告诉你代码 > 在哪 里,建议你自己弄明白;c)我跟你结对编程,通过一组新数据实 > 现该模式;你会选哪一种? > > > Young Ye和Royce Fay建议使用另外一种使用不均衡结对编程(Asymmetric pair > Programming)高效传递知识的方法。该方法的本质在于:它除了在开发人员之 > 间结对之外,还可以在开发人员和领域用户之间结对。这样做的重点也在于人与 > 人之间的沟通,而不是文档。 > > 结对编程有一个广为人知的好处,就是快速的知识分享和传递。Alan Skorkin同 > 意这个观点,同时指出: > > 我认为:最重要的好处在于,结对对于有机的知识传递效果非常好,尤 > 其是大型系统中,这是关键,因为根本没有其他方式能够做好这一点。 > > 因此,大家都同意传递知识的最好方式就是通过沟通、指导和一起工作。虽然, > 有些文档确实有用,但单单依赖文档能带来的好处很有限。 > > 查看英文原文:How to Transfer Knowledge in an Agile Project > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 太现象了!而且有实验作证! > > -- > http://zoomquiet.org 人生苦短,Pythonic!-) > 一个人如果力求完善自己,就会看到:为此也必须同时完善他人. 一个人如果不关 > 心别人的完善,自己便不可能完善! > _______________________________________________ > zeuux-universe mailing list > zeuux-universe在zeuux.org > http://www.zeuux.org/mailman/listinfo/zeuux-universe > > ZEUUX Project - Free Software, Free Society! > http://www.zeuux.org
Zeuux © 2024
京ICP备05028076号