但是，共享库不仅带来重新定义，而且带来了也有责任：与其他团队共享图书馆的人成为这些图书馆的所有者。目的是当其他团队报告错误或功能请求时，由负责这些库的人员负责。有些人轻率地承担这种责任，另一些人则决定不分担责任，以免被新的责任困扰。
我们如何鼓励人们与他人共享测试库并获得它们的所有权？
#1 楼
问题是，拥有这些新库对于这些人来说是额外的工作。他们应如何处理这项额外工作？在解决错误或为这些库添加功能时，是否允许他们推迟其他职责？还是希望他们只是在做这些事情，同时又在同一时间完成自己的常规工作？我要说的是，您应该确保他们拥有获得此所有权所需的时间和其他资源，其中包括在需要时减少他们的其他工作。如果不是这种情况，您是在要求他们免费工作，而唯一的聪明事就是不参加。其次，为自己使用而制作闪亮的新工具始终会更加令人兴奋和挑战。而不是修复错误或在旧工具中添加新的小功能。因此，您需要以某种方式奖励那些这样做的人。要么给使用最好工具的人们加分，要么给他们额外的空闲时间，或者任何使它具有吸引力的方式。如果没有激励措施，大多数人将不会自愿从事基本上是艰苦的工作，而且坦白地说，承认还不足以成为激励措施。
评论
拥有这些工具的所有权绝对是正确的。大约一年前，我在工作场所针对这个主题提出了类似的问题（除了我想分享自己的工具），现在公司中有数十个人每天都在使用它，因此我不得不投入大量的维护能力来进行维护。它并添加新功能。我建议您尝试让人们共享他们的工具，并从他们认为工具准备好共享的角度进行研究。
–悉尼
17年12月4日在19:03
#2 楼
有些公司的结构库和工具开发与开源项目一样，这似乎已被证明是一种实践。它称为InnerSource，例如由PayPal使用。InnerSource是一种开发方法的名称，该方法将开源>软件实践应用于组织内部开发软件的方式。
https://www.infoq.com/news/2015/10/innersource-at-paypal
O'Reilly拥有关于InnerSource的免费电子书，也许值得阅读有关InnerSource的更多想法。
诸如“受信任的提交者”之类的东西可以使您的项目继续进行，唯一的维护者可能会灰心并成为主要的总线因素。
我们如何鼓励人们与他人共享测试库并拥有所有权？
让（思想）领导者加入您的组织解释InnerSource，设置一些示例并记录如何开始使用它。推广它对全体员工都是有益的。甚至尝试开放源代码以获取外部曝光。
#3 楼
鼓励这样做的最简单方法是为所有团队编码标准。这些标准应包括与文档工具配合使用的注释，例如javadoc或XML Sandcastle样式注释。完成后，下一步是要求构建还生成文档（通常是构建过程中的简单标志），并配置部署/测试自动化运行以将文档发布到已定义的网络位置。
有了它，并且库本身在源代码控制中，所有需要的内容都将被半自动共享。团队负责人要做的所有事情就是在代码审查期间检查注释文档。
评论
我们拥有编码标准和跨团队审核-不会鼓励人们对他们共享的工具拥有所有权。人们说：您可以根据需要使用我们的库，但我们不承诺提供任何支持，维护，错误修复或实现功能请求。似乎他们唯一关心的是图书馆为他们的团队工作，如果它对其他团队不工作，那不是他们的事。
– dzieciou
17 Dec 4'在13:28
如果所有团队都可以使用源代码，并且每次构建都更新了文档，则任何团队都可以添加到库中。
–凯特·保罗（Kate Paulk）
17年12月4日在16:47
机械强制执行无济于事。它只会导致人们找到机械执行的方法（自动生成的文档有人吗？），或者根本就没有创建库（因为现在您变得太难了）。 -1
–user253751
17年12月4日在23:13
@immibis我不确定你要去哪里：我的答案是要使用自动生成的文档，并为想要进行更新的任何人共享库源。
–凯特·保罗（Kate Paulk）
17年5月5日在18:49
@KatePaulk您的建议似乎会阻碍人们共享，因为他们需要进行更多工作才能共享。
–user253751
17年5月5日在21:42
#4 楼
由于发明了货币，因此很容易表现出升值。经理当然拥有可任意分配的奖金。让他每个季度为最佳工具库提供几百美元的奖金，这是同行提名的。问题解决了。
#5 楼
在我的小组中，由QA工程师编写的代码与由软件开发人员编写的代码相同：对待代码时将其检查到源代码控制和错误中，并且像对任何代码一样将功能请求分配给它。Bug审查会议由管理层用来确定哪些Bug何时，由谁修复，并据此计划。这样做的好处是，管理层可以决定和安排工作并安排工作的优先级，因此开发人员不会自动执行任何操作。
如果将QA开发视为开发对象，则不应在应用公司已使用的所有开发流程和原则时遇到任何麻烦。
希望这会有所帮助。
#6 楼
选择一种在给定用户环境的约束下能很好地工作的工具/脚本，并使其在更通用和多样化的环境中很好地工作是一项重要的工作。而且，大多数开发人员认为“有趣”是行不通的。激励共享的唯一方法是，如jesm00所述，在评估其性能时（例如，他们被允许延期履行职责吗？）
评论
几年前我在工作场所提出的这个问题可能对您的工作场所有帮助。stackexchange.com/ questions / 57181 /…