软件开发组织的生死取决于他们如何有效地生成、吸收、重用和利用他们的知识。虽然在这样的组织中有大量的知识工件,如代码模块、程序图、系统设计和需求规范,但正是这种过剩使重用成为难以捉摸的银弹。在围绕重用的广泛骚动过去20年之后,它在提高软件质量、效率和开发敏捷性方面的结果一直令人沮丧,看不到灵丹妙药。诸如面向对象的平台库式的可重用对象中独立代码片段存储库之类的创新被吹捧为重用问题的解决方案。当时的想法是,未来的开发人员将从这些“知识仓库”中提取代码,以有效地检索匹配设计问题的现有解决方案。从理论上讲,编写一个复杂的软件就像把现有的乐高积木拼在一起一样。
在这篇文章中,我们提供了来自25个软件开发组织的实地研究的见解,以突出重用知识管理(KM)难题中缺失的两个部分:编码和重新设计[6(参见侧栏“研究如何进行”)。在我们的研究中,所有的组织都有某种系统化的重用计划。我们必须承认重用程序的复杂性在不同的组织中是不同的。有些组织在重用程序和系统方面比其他组织更加先进和成熟。我们在这里展示的发现是那些在这些组织中普遍存在的,不管他们的重用程序有多复杂。我们的发现提供了有趣的见解,让我们了解到即使有组织重用授权,也会发生什么,而不管重用程序是否成熟。如果我们考虑临时软件重用的情况,情况可能会更加糟糕。总的来说,研究结果表明新手更有可能重用软件工件,而专家则不这么做。软件开发组内部的重用比跨软件开发组的重用更多。我们还发现临时项目团队比永久开发团队更有可能参与重用。
图1说明了涉及三个显著动态的知识消费生命周期:重用、重新设计和重新编码。重用是现有软件工件的原样应用;重新设计是改变现有软件工件的行为;编码是通过构建软件代码或系统设计来发现新的软件工件。在这里,我们分别考虑。
在软件开发公司的分析中,一个经常被忽视的概念是多重知识空间的存在。6].知识空间指的是存放知识对象的逻辑或物理位置。例子包括文件夹、数据库、存储库以及经常被忽视的员工的思想和客户名片。软件组织主要关注显性知识空间,而隐性知识空间常常被忽略。我们推论出三个不同的知识空间的重要性:私人的、准公共的和公共的。每个软件工程师都有一个私人的知识空间;它可以是显性的,也就是说,储存在文件夹或个人电脑里,也可以是隐性的,存在于一个人的头脑中。软件工程师与同行协作,并在逻辑工作单元中工作,逻辑工作单元可以采用团队、组或部门的形式。随着时间的推移,通过与同伴的持续和重复的互动,私人知识空间变成了准公共空间。这些类似于共享的心智模式; it is important to remember that simple additive rules do not apply herethe quasi-public space is greater than the sum of private knowledge spaces it represents. Organizations have dedicated "global" knowledge management systems that are accessible by all engineers and these represent the public knowledge space.图2在他的同事和合作者的背景下,为Harry阐述了这三种类型的知识空间。
接下来,我们将把注意力转向我们关于公共知识空间的关键发现,软件重用传统上关注的是公共知识空间。谁重用来自公共知识空间的代码?总而言之:
发现1。专家和老兵避免从公共知识空间重用。与流行的观点相反,我们发现专家不太可能重用公共领域的知识。为什么?专家和老兵拥有丰富的私人知识空间;这些都是在他们在公司的任期内以及随着他们技能的成熟而建立起来的。因此,当面对新的任务时,他们首先会搜索自己的私人知识空间。这可能包括搜索他们过去项目的日志,解析过去的经验,本能地利用他们的直觉。如果找到了所需的知识对象,他们将重用它;如果找到一个接近的替代品,他们将为新任务重新设计它。但是,如果没有找到知识对象,专家在公共知识空间中执行搜索的概率非常低。 Many experts we interviewed claimed they had confidence in the fact that if knowledge was not found in their private space it did not exist in the organization. Moreover, it was also less costly for them to recode the desired artifact than to conduct a global search for one.
发现2。新手和新手从公共知识空间重用。与专家形成鲜明对比的是,新手和新手更有可能在公共空间重用知识。当面对一个问题时,他们更有可能在公共知识空间中搜索。这种行为的一个主要原因是风险规避。多年来对新人心理的研究支持了这一发现。他们发现重用组织中现有的知识工件更安全,如果需要完成任务,则重新设计它们。从零开始编写代码是最不可取的选择,因为这样做,他们会向同行的批评和质疑敞开心扉。此外,他们有更多的理由向他们的同行证明需要一个全新的代码模块或设计。新手也缺乏广泛的系统知识。6].他们拥有一两个小领域的知识,例如Java开发或Oracle,这是他们被组织雇用的原因。然而,他们不具备足够的系统知识,这需要对特定于组织的系统、系统之间耦合的本质和维护相互依赖的本质的理解。因此,对于他们来说,使用对其他模块有调用的现有软件构件、关心实现细节、并且已经对组织系统友好的软件构件更容易、更高效。因此,普遍的软件模块化增强了重用,而完整性则阻碍了重用。因此,与专家不同的是,在全局空间中搜索工件的成本比编写新代码的成本要低。专家拥有这些知识,因此可以相对轻松地对工件进行编码。
发现3.来自公共知识空间的重用更多地发生在软件开发组内部,而不是跨软件开发组。在团队中工作的软件工程师更倾向于重用在工作单元内共享的知识,而不是在工作单元外拥有的知识。这其中有两个明显的原因。其一是与团队中同伴的密切工作关系[5].这种熟悉导致他们欣赏彼此的编码风格和惯例,并导致对小组成员创建的软件工件的更好理解。相比之下,由组之外的成员创建的软件工件是较难理解的,因此也较难重用。对于不同组中的成员来说,理解彼此知识工件的复杂性和微妙的上下文更加困难。此外,由于个人互动较少,这个问题是自我强化的。也就是说,较少的互动意味着更难以理解他人的知识产品,而较少使用他人的知识产品则减少了个人互动的潜力。重用一个小隔间里的同事的知识比重用一个办公室或另一个国家的同事的知识更有效,因为有关显性知识对象的隐性知识很容易获得。这种动态的一个方面是高度的本地化信任;成员信任他们的团队构建的工件,而不是来自外部的工件,这也加强了团队内部的重用。有些令人惊讶的是,我们发现,当一个群体外的成员创造的知识被重用时,这主要是通过非正式的交流和网络来实现的——有人认识另一个群体中的其他人,他们创造了一个知识对象,并将其带到这个群体中。 This finding has important implications for open source development projects as well: the likelihood of reuse across open source public spaces and from such spaces in internal projects is lower.
找到4.临时项目团队比永久项目团队更有可能利用公共知识空间。像团队和部门这样的逻辑工作单元在组织中很常见,软件公司也不例外。在固定的团体中,个人团结一致地长时间工作,以实现共同的目标;特设或动态小组的寿命较短,在完成单个项目或目标后解散。固定群体的特征是一组特定个体之间的重复互动。因此,随着时间的推移,我们看到个人私人知识空间的趋同,关键原因是群体成员的强化。考虑一个例子:如果两个程序员同时在搜索一段代码t,他们很有可能会选择不同的搜索模式和策略。然而,在t+n时,我们会注意到他们的搜索策略有相似之处,因为两位工程师讨论了哪种搜索策略更好。
随着时间的推移,一个永久群体对知识的搜索策略趋同。收敛并不需要完美,在大多数情况下也远非完美;然而,收敛是非常重要的,随着时间的推移,一个组的成员将搜索公共知识空间的相似部分,以寻找知识工件。因此,这导致他们专注于少数领域,并在群体中加强它们,随着时间的推移,降低了重用的可能性,因为在公共空间的其他部门发现的新知识被忽略了。相比之下,瞬态和动态工作单元成员更有可能探索更广泛的公共知识空间。由于他们与一组不同的个体交互,他们更有可能发现知识工件的新位置,因此更有可能找到问题的解决方案,从而导致更大的重用。这一发现为开源开发项目提供了重要的见解:来自开源网络外部的临时项目团队很可能尝试重用来自此类公共空间的代码和模块。
重用一直是一个超前于时代的想法。随着知识管理对软件组织的生存越来越重要,是时候重新发现这个想法的力量了。为了让重用的思想更有意义,软件开发组织必须认识到知识开发是一个动态的、三管齐下的过程,它跨越了公共的、准公共的和私有的知识空间。我们的发现为重用黑箱提供了新的见解,并展示了软件项目团队和环境的类型,在这些类型中,来自公共知识空间库、代码库、可追溯系统和CASE工具的传统重用可能被使用,而在哪里则不被使用。
计算领域最近的两个趋势将重用带到了风口浪尖:开放源码开发项目(如Linux)和基于组件的软件开发。开源开发的成功依赖于个人向与项目相关的公共知识空间贡献代码片段、脚本和想法。我们的发现为此类项目的挑战提供了独特的见解。开源知识和代码最有可能的用户可能是新手而不是专家,临时项目团队而不是与项目直接相关的永久开源社区,尽管知识和代码溢出到其他项目的可能性较小。然而,开源项目的成功取决于专家和资深程序员对公共知识领域的贡献,而不是新手对它的重用。因此,开源模式的长期成功需要新的和不同类型的激励系统(如声誉和财务系统)来在中长期内维持高质量的知识贡献。
接下来考虑从我们的发现中得出的对基于组件的软件的见解。基于组件的软件的成功需要潜在客户从半公共的知识空间进行重用。我们的研究结果表明,新手和临时项目团队最有可能采用这种软件。基于组件的软件应该针对的正是这些用户和项目。
关键要点:传统重用在新手中比在专家开发人员中更有效,并且在临时团队中比在永久团队中更有效。尽管这看起来令人惊讶,但它解释了为什么我们一意孤行的银弹从来没有发光。
1.Adelson, B.和Soloway, E.领域经验在软件设计中的作用。软件工程汇刊, 11(1985), 13511360。
2.软件工程中知识管理系统有效使用的障碍。Commun。ACM 46, 1(2003), 99101。
3.促进隐性知识交流。Commun。ACM, 46岁, 6(2003), 8588。
4.B.格拉泽,A.施特劳斯。扎根理论的发现:定性研究的策略。芝加哥,阿尔丁出版公司,1967年。
©2006 acm 0001-0782/06/0100 $5.00
允许为个人或课堂使用本作品的全部或部分制作数字或硬拷贝,但不得为盈利或商业利益而复制或分发,且副本在首页上附有本通知和完整的引用。以其他方式复制、重新发布、在服务器上发布或重新分发到列表,需要事先获得特定的许可和/或付费。
数字图书馆是由计算机协会出版的。版权所有©2006 ACM, Inc.
没有找到条目