模块化Java：声明式模块化
本文是模块化Java系列文章的第4篇，介绍的是声明式模块化。文中描述了组件如何以声明的方式来定义并组织在一起，而无需让代码依赖于OSGI API。
新闻
叠飞机与敏捷项目知识传递
作者 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
道理很简单
发表人
xu haixiang
发表于
2009年8月19日 下午8时24分
人走了，咋办？
发表人
husthxd gz
发表于
2009年8月20日 上午1时19分
Re: 人走了，咋办？
发表人
benfei bin
发表于
2009年8月20日 上午9时39分
Re: 人走了，咋办？
发表人
嘉 邓
发表于
2009年8月20日 上午11时24分
Re: 人走了，咋办？
发表人
Yi Xu
发表于
2009年8月25日 下午8时47分
Re: 人走了，咋办？
发表人
Scott Yao
发表于
2009年8月24日 下午10时44分
Re: 人走了，咋办？
发表人
Quiet Zoom
发表于
2009年8月25日 下午9时21分
Re: 人走了，咋办？
发表人
Yi Xu
发表于
2009年8月25日 下午8时50分
如果不是纸飞机而是造汽车呢？
发表人
骏 张
发表于
2009年8月26日 上午9时32分
-
写得非常好，道理很简单，点出来很不容易，非常有用，谢谢
-
谁都知道F2F的沟通方式最高效，但很现实的问题是：人走了？咋办？
这时候如果没有文档是不可想象的。
而且，没有文档积累，来一个新人，培训一遍，再来一个新人，又培训一遍，累不累啊？ -
赞同，文档能起到更长期的经验积累和传递作用。
中国历史上很多“祖传秘方”就是因为使用了人传人的方式，常常传着传着走样了，最后消亡了。
其实敏捷本身并不排斥文档，是强调要写必要的文档。
不过感觉我们很多人在实施的时候过分强调文档的坏处，以近似裸奔的状态进行开发，长期下去令人担心。尤其长期深受CMM“之苦”的开发人员，借敏捷之名彻底抛弃文档，倒是有一时之快。
因此，个人认为敏捷项目必须在初期明确“必要的文档”包括哪些，但在内部交流时可以强调F2F的传递，两者要合理的结合，不能走极端。 -
大部分文档应该是由设计人员而不是开发人员来完成的吧？
-
请问一下，你认为什么是必要的文档，维护问题如何解决？
有些文档确实有用，但单单依赖文档来传递和分享知识能带来的好处很有限。 -
大部分文档应该是由设计人员而不是开发人员来完成的吧？
强大！阁下果然是“敏捷”开发！ -
赞同，文档能起到更长期的经验积累和传递作用。
中国历史上很多“祖传秘方”就是因为使用了人传人的方式，常常传着传着走样了，最后消亡了。
我看很多人都误解了中国师傅带徒弟这个系统的重点所在。
和手工艺一样，软件的设计也是需要不断地磨练才能领悟其精要的。仅仅单靠文档只能说明之前的设计“是什么样子”，但不能说明“为什么是这个样子”，以及“有没有其他可能性”。工程师不断提高自己达到这个水平的过程必然是通过观察使用他人的产物，日积月累才能真正体会别人的设计的。
文档只是辅助而已，人能够领悟这才是最重要的。 -
是也乎，是也乎！这已经是KM 的领域了！
参考KM思維图谱
知识／经验的传承是个流动的过程:- 其中隐性知识的载体是个人
- 其中显性知识的载体是文档／代码等等
- 必须在不断的流通过程中，知识／经验才可能不断的完备和再创新
- 人走了没有关系，只要有机制令不断的有类似的指导者出现就好！
所以:"KM乃是培育可催生自学习型组织的文化氛围!"
- 其中隐性知识的载体是个人
-
5分钟可以叠一只纸飞机
但是如果是用一年的时间造一辆汽车呢？
传递知识采用指导方式固然是最有效的，但知识的沉淀和积累难道也可以吗？
agile界总是喜欢用简单的事情来讲大道理，但现实简单吗？
9 条回复
关注此讨论 回复