引用：Stol K J , Caglayan B , Fitzgerald B . Competition-Based Crowdsourcing Software Development: A Multi-Method Study from a Customer Perspective[J]. Software Engineering, IEEE Transactions on, 2017.
摘要
众包正在作为一种替代性外包策略而出现，在软件工程界越来越受到关注。但是，众包软件开发涉及复杂的任务，这些任务与在众包平台（例如 Amazon Mechanical Turk）上可以找到的微任务有显着差异，这些微型任务的持续时间短得多，通常非常简单，并且不涉及任何任务间的相互依赖。为了在软件开发环境中实现众包的潜在利益，公司需要了解该策略的工作原理以及可能影响众包参与的因素。我们提出了一种多方法的定性和定量理论构建调查研究。首先，我们从众包文献中得出了一系列关键问题，作为财富 500 强公司中探索性案例研究的初始分析框架。我们通过在非常流行的 Topcoder 众包平台上十年内对 13,602 项众包竞赛的分析来补充案例研究结果。从我们的经验发现和众包文献中，我们提出了一种关于众包兴趣和实际参与众包竞赛的理论模型。我们使用结构方程模型评估该模型。结果发现，观众并不会因为奖品的水平和比赛的持续时间而对比赛增加显著的兴趣。
1 介绍
软件工程不再仅出现在孤立的小型开发人员小组中，而是越来越多地出现在涉及许多人的组织和 区中。全球化趋势日益增长，其重点就是协作方法和基础设施。众包作为一种完成工作的新兴方法，让客户或请求者可以在众包平台上发布工作或任务的广告，供方（即个体工人）在该平台上执行符合其兴趣和能力的任务。
众包已被广泛应用于各个领域，并且有众多众包平台，客户和供应商可以通过它们相互寻找。软件开发任务通常是相互依赖的，复杂的，异构的，并且可能需要大量的时间，认知努力和各种专业知识。但是，也有一些将复杂的任务众包的例子。
研究目标：将众包作为一种软件开发策略，更好的了解它。
考虑到这一目标，我们首先在一家使用 Topcoder 进行大型项目众包的公司中进行了行业案例研究，并针对 ICSE’14 的论文，通过以下几种方式对其进行了扩展：
2 背景
2.1 定位并定义众包软件开发
在早期的工作中，我们将众包定位为与外包和开源分开的策略；表 1 扩展了这种定位，清楚地将众包描述为一种独特的外包形式。我们以自己的定义结束本节。
“众包”一词有很多定义。众包参与的性质不同于开源和外包。尽管存在不同的参与模式，但许多众包平台的典型特征是基于竞争的参与性质。Topcoder 是用于众包软件开发的最大平台，并使用竞争机制，客户通过该平台宣传一项任务，然后由人群成员来承担。收视率最高的人群成员赢得比赛并获得付款。因此，竞争因素和金钱激励往往会阻止合作。Howe 将众包描述为“类固醇外包”，这表明众包仅仅是一种外包形式。但是，并行执行的重复工作不适用于外包。劳动力的性质也将众包作为一种外包策略而与众不同，通常客户并不了解这种人群。“传统”外包方案的特征是在执行工作之前与特定（因此已知）供应商签订了合同协议-随着时间的流逝，这两个当事方之间可能会建立关系。在众包场景中，人群扮演“供应商”的角色，但事先不知道将由谁提交，因此将向人群中的哪个成员付款。
表 1 众包的特点
使众包不同于开放包和外包的其他方面包括参与的持续时间，以及客户和“供应商”（即从事工作的开发商）的动机（见表 1）。根据表中的特征，我们对众包软件开发的定义如下：
通过具有外部奖励的公开电话，由潜在的庞大且通常未定义的具有必要的专业知识的外部人员代表组织来完成指定的软件开发任务。
2.2 众包软件开发中的关键问题
2.2.1 任务分解
众包中的一个关键问题是将工作分解为一组较小的任务。将模块定义为“职责分配而不是子程序”。一个关键的挑战是找到适当的软件产品分解成可以有效地众包的任务，被称为“工作流程设计问题”。更有效的分解会导致并行性提高。在分解软件项目时，一方面要为众包的任务提供足够详细的规范，另一方面要对任务进行优化，这之间存在很好的平衡。
2.2.2 协调与交流
当将复杂的任务众包时（如软件开发中的情况），需要进行协调。协调关注的是指导个人朝着共同的目标和明确认可的目标努力，并将组织的不同部分链接在一起以实现一系列任务。尽管与上面讨论的任务分解有关，但是协调特别涉及通信，相互依赖性以及将各个部分集成为一个整体。协调的这种特征似乎假定活动是在组织内进行的。众包平台的成员不能被分配任务。相反，开发人员可以自行选择要处理的任务。参与的人数越多，交流的开销就越大。是否适用于众包环境取决于工作是以协作还是竞争的方式完成的。
2.2.3 规划和计划
在众包的情况下，将任务分配给未知的劳动力以完成任务，结果，组织放弃了对该特定工作的控制。这可以加快开发速度，因为任务可以并行完成，并且独立于组织内部员工而完成，尤其是在付款取决于及时交付的情况下。众包的承诺之一是缩短产品开发周期。为了实现这一点，重要的是人群可以遵守众包组织的期望时间表。
图 1 两阶段研究的设计
2.2.4 质量保证
众包的另一个建议好处是高质量提交的潜力。同时，如果大多数提交的质量较低，则存在“噪声”的风险，这使得评估提交质量的任务变得更加繁琐。无论软件是内部开发还是由外部各方开发，质量保证都是软件开发中的关键问题。众包中特别需要关注的是，客户几乎不了解交付软件的开发人员，也不了解他们可能遵循的流程，因此对这些方面没有控制权。人群开发人员可以“满意，将他们花费的精力最小化”。同样，对于解决方案可能会有分歧。
2.2.5 知识和知识产权
软件开发是一项知识密集型活动，因此，知识管理是软件工程领域中的一个重要主题。 与传统外包的主要区别在于，没有哪个供应商对众包项目的问题域有深入的了解。相反，工人的持续流动是众包的固有特征。较高的周转率可能会导致进度安排和成本超支，进而危及竞争的成功结果。
表 2 研究策略的主要优势和劣势
表 2 总结了两个阶段采用的研究策略的优缺点（请注意，该表并不详尽）。
2.2.6 动机和 酬
众包中的最终考虑因素是动机和 酬。某些众包任务的补偿应取决于任务的预期持续时间和复杂性。任务的复杂程度可能有所不同。显然，软件开发任务是复杂且耗时的，参赛者将期望获得可观的 酬。众包的一个声称好处是它可以大大降低成本。然而，确定合适的价格是总体上众包以及特定于软件开发的关键挑战。
3 研究设计
3.1 第一阶段：案例研究的设计
3.1.1 设置
TechPlatform Inc.（TPI，化名）是一家财富 500 强公司，在云中提供服务和解决方案。在 2012 年，TPI 试图在一名高级管理人员的鼓动下，调查其软件开发功能中使用众包的情况。
TPI 众包其软件开发的平台是 Topcoder，这是最大的软件开发众包平台。在推广他们的服务时，Topcoder 建议客户可以“尝试更多，成功更多，花费更少”。Topcoder 提供了一个平台，可促进所谓的数字创作的三大支柱：（1）前端创新；（2）软件开发，以及（3）算法和分析。对于本研究，我们重点关注软件开发支柱。
最初，Topcoder 雇用项目经理来监督客户项目并作为项目“联络人”协助客户，但几年前，该平台引入了“自助服务”模型以节省成本。 这种直接模型涉及 Topcoder 区中的“联合飞行员”，充当客户和人群开发人员之间的接口，并帮助选择各种竞赛的获胜者。副驾驶是经验丰富的“精英” Topcoder 区成员，他们过去在 Topcoder 平台上已经证明自己。他们管理技术和竞赛的技术方面，直至成功交付。 Topcoder 建议副驾驶员可以进行技术繁重的工作和流程管理，使客户成为“全球人才库的指挥”。
3.1.2 定性数据收集和分析
表 3 案例研究数据源
3.1.3 定量数据的收集和分析
为了对案例研究的结果进行背景介绍，我们分析了通过 Topcoder 的公共 API 收集的数据。 定量分析的目的是根据案例研究结果进行背景分析，以更好地了解 TPI 竞赛在使用的技术，奖励范围和持续时间方面是“非典型”还是“非典型”。 因此，定量分析提供了比较的背景信息。 我们收集了 2016 年 11 月所有公开可用的数据。所有数据都存储在 SQLite 数据库中，并使用 Python 和 R 统计软件包进行了分析。
我们根据一些标准过滤了数据。首先，我们以低于 100 美元的一等奖消除了挑战。这样做的理由是，我们认为这些挑战是微不足道的，不能代表公司通常发布的竞争。我们发现这些挑战通常的奖励很少（在 0.00-1.00 美元之间）。在分析过程中，我们确定了一个名为“分析”的用户。该用户总共提交了 4,697 个提交，是第二活跃的用户的十倍，占提交总数的 7.3％。此外，只要该用户提交，其他任何人都不会进行其他提交。由于这些比赛不具有代表性，因此我们决定删除这些比赛。最后，我们仅考虑成功完成的竞争，从而进一步减少了数据集。我们的最终 Topcoder 平台样本包含 13,602 个比赛的数据。在分析过程中，我们在提取的数据中遇到了小的不一致之处。在注册为平台会员之前，大约有 1.5％的（明显）注册人注册或参加了比赛。我们将注册日期调整为系统中这些注册者的首次活动日期。鉴于这仅影响了很小的百分比，我们将这些条目保留在数据集中。
3.2 第二阶段：众包软件开发的理论模型
在第二阶段，众包软件开发：使用结构方程模型（下面详细讨论）对模型进行评估。SEM 是一种强大的统计方法，但迄今为止在软件工程研究中很少使用。
SEM 是第二代统计方法。在包括多元回归和方差分析的所谓第一代统计方法中，通常使用普通最小二乘（OLS）估算参数。OLS 的目标是找到使数据点和回归线之间的平均平方距离最小的系数。尽管 SEM 的总体目标是相似的，即用观察到的数据来确定代表最佳拟合的系数，但所谓的“观察到的数据”是变量与其方差之间的观察到的协方差。因此，有时将这种类型的 SEM 称为 CBSEM（基于协方差的 SEM），以区别于偏最小二乘（PLS）SEM。代替 OLS 的是，在 SEM 中估算系数的默认算法是最大似然（ML）。在我们的研究中，我们使用了强大的 ML 变体。
在 SEM 中，研究人员通过定义一些相互关联的假设来指定理论（假设的）模型；基于此，生成了方差-协方差矩阵。根据一组样本数据生成第二个方差-协方差矩阵。因此，SEM 的目标是测试这两个矩阵是否不同：如果它们不同，则样本数据不支持研究人员的理论模型。 因此，两个矩阵之间的非统计显着性差异（使用 x2）表明理论模型适合经验观察。同时估计结构方程模型中的所有系数。因此，应该在整个模型上下文中评估结构方程模型中关系的重要性和强度。只有在模型本身代表良好拟合时，即在理论模型与观察模型没有显着差异的情况下，评估假设关系才有效。
表 4 Topcoder 平台上的十大最受欢迎技术
结构方程模型是通过定义一组构成我们的理论的构架和关系而开发的。具体来说，我们专注于案例研究中确定的许多重要概念，包括竞赛奖励，竞赛持续时间和竞赛的“并行化”程度。 我们使用单一指标来操作我们的构造。从这个意义上讲，我们的模型是路径模型，这是一种结构方程模型。路径模型本质上是回归模型；但是，回归仅限于由一个或多个自变量预测或解释的单个因变量。路径模型没有这种约束，因此不需要复杂的模型。
结构方程模型是使用 lavaan 库实现的，用于统计软件包 R，版本 0.5-23。然后使用一组拟合标准评估结构方程模型。特别是，使用三种类型的标准对理论模型进行了评估：
4 案例研究
TPI 选择用于众包的应用程序是 Titan（化名），这是一个 Web 应用程序，TPI 现场工程师在与客户互动时从一个平台迁移到另一个平台时将使用它。众包的部分最好被描述为前端信息系统，该系统必须与遗留组件集成在一起。在 TPI 中，做出了一项技术决定，即未来的开发应使用 HTML5，这是为前端选择的技术，它将取代当前的桌面应用程序。表 4 列出了 Topcoder 平台上使用最广泛的 10 种技术，其中 HTML5 排名第七。
4.1 任务分解
对于 TPI，选择产品的哪些部分适合于众包的选择并非完全无关紧要。首先，关于众包工作的决定主要基于内部资源（或缺乏内部资源）。其次，独立的代码和可执行文件（没有相互依赖性）将更易于合并，因此更适合于众包。
为了最大程度地减少交付后对 Topcoder 代码进行的修改，TPI 向大量开发人员提供了页眉和页脚浏览器代码。对于 Titan 应用程序，TPI 的政策是仅使用 HTML5。最初，人们开始期望 Topcoder 区将提供一些创新的 HTML5 代码。但是，TPI 要求所有浏览器平台都必须支持 HTML5 功能，导致所有潜在的 HTML5 功能中只有很小一部分可供人群开发人员使用。 TPI 规范排除了“人群”的预期创新。
TPI 项目包含 44 个成功的比赛，分为不同类别。表 5 列出了每个类别的比赛数量，以及我们整体 Topcoder 平台样本中的比赛如何分配。
为了最大程度地减少集成工作量，TPI 希望人群开发人员使用真正的后端核心而不是存根服务。但是，随着 Topcoder 的开发开始，该核心尚未准备好，在大多数开发竞赛中都使用了存根。因此，这种整合努力被推迟到开发过程的后期，这是理想的。
对于传统的内部开发，TPI 开发人员已经内部化了大量有关编码标准和模板以及技术规范的信息。但是，许多编码标准和模板都是非正式记录的，没有集中存储在内部 Wiki 安装中。为了确保在外部人群开发人员的需求说明中明确此信息，需要进行大量的额外工作。TPI 为 44 场 Topcoder 比赛撰写了总共 1,061 页的规范。与之相反的是，如果内部进行开发，几乎不需要编写任何额外的文档。与 Topcoder 保持联系的架构师将情况描述如下：
“感觉好像我们已经制作了 100 万份规格文件，但显然没有。我们对 Topcoder 进行规范的方式与我们在内部进行规范的方式完全不同。”
表 5 比赛类型和频率
4.2 协调和沟通
基于 Topcoder 竞争的方法有效地代表了软件开发的瀑布方法。但是，TPI 正在使用基于 Scrum 的敏捷开发流程。将这些不同的瀑布和敏捷开发过程结合起来是有问题的。来自 Topcoder 的开发贡献必须分配给 TPI 内的 Scrum 团队，并且人群贡献必须随后注入适当的 sprint 中。 TPI 架构师将中心问题总结如下：
“我们是一家敏捷商店，我们习惯于改变主意。 当我们在一场比赛中告诉他们一件事，但在下一场比赛中改变了主意时，Topcoder 可能会遇到问题。”
Topcoder 和 TPI 之间的互动模型中也有很多层。首先在 Topcoder 端，一方面是人群开发人员 区，另一方面是 TPI 人员之间的联合驾驶员。此外，Topcoder 平台专家还参与了与 TPI 的联络，并监督副驾驶并建议在该级别进行更改。
在 TPI 内部，选择与 Topcoder 副驾驶进行交互的人员是一个艰难的决定。在技术方面，TPI 分配了一名高级架构师来协调 Titan 项目的 Topcoder 开发。在 TPI 内，与 Topcoder 区每天接触的 Topcoder 联络员这一角色被认为是有问题的，因为及时回答问题的压力很大。 由于成本高昂，TPI 内有人担心将这样的高级资源分配给这一联络角色。 软件开发经理从资源分配的角度描述了这种情况：
“要提高项目内部的联系点，联系人需要同时具有技术技能和项目管理技能，以便能够管理 Topcoder 技术 区成员的要求，竞赛和问题。 它使用了非常宝贵的资源，在这个项目中，他们不得不用其他开发人员的一些时间来解决 Topcoder 提出的所有问题。”
图 2 Topcoder 平台示例的竞赛持续时间（天）分布（对 X 轴进行了修剪以提高可读性）。
在初始阶段，联络角色涉及在 Topcoder 论坛上回答问题。
“与内部开发相比，还有更多的问题。 但是，没有非正式的沟通机制。 您不能对下一个隔间的人大喊大叫，很快就能得到答案。”
另一个结构协调问题是，TPI 将建筑师分配给产品，并且完成 Topcoder 项目的愿望导致了另外两名建筑师从事该项目。TPI 还拥有一个所谓的“战术” Scrum 团队，可以更灵活地分配给不同的任务，因为它们没有像 TPI 的普通 Scrum 团队那样长期地正式分配给项目。但是，在某些情况下，也会将正常的 Scrum 团队分配给该项目，不需要战术 Scrum 团队的参与。总体而言，项目上存在大量额外的协调开销和重复工作。这两个团队还必须相互交流。为了解决此问题，TPI 放弃了战术团队的使用，而是将计划时间安排在项目打印中。
与涉及同一组织中其他开发人员的分布式开发相反，随着时间的推移，唯一倾向于建立的关系是与 Topcoder 共同驾驶。 由于交互是通过多个层次过滤的，因此没有真正的机会与任何人群开发人员建立关系。
4.3 计划和调度
Titan 项目包括超过 50 个顶尖的 Topcoder 竞赛，其中 44 个竞赛已成功完成。从开发者的角度来看，实际的竞赛时间要短得多，因为这是注册截止日期与提交截止日期之间的差额。图 2 展示了 Topcoder 平台的比赛持续时间的天数分布。
图 3 Topcoder 平台示例的注册人与提交之间的相关性
从 TPI 的角度来看，如果可以实现更灵活的粒度是更好的，因为可以接受交付品的某些部分，并为这些可接受的部分进行部分付款。因为 TPI 不想阻止开发人员竞标未来的竞赛，所以有一种趋势是接受所有提交的内容，甚至包括那些有缺陷的提交内容。当主要应用程序不断发展时，TPI 必须等待比赛结束，这又引起了与计划和日程安排有关的另一个问题。TPI 的日程表也由于缺乏提交而受到损害，导致竞赛失败。图 3 展示了样本中注册人数量与竞赛数量之间的散点图。
4.4 质量保证
软件工程的许多研究都集中在尽早发现和消除开发过程中的错误上，即在开发周期中发现错误的成本成倍增加。但是，Topcoder 开发过程的结构使其难以保留，因为在完成编码后，它会将 QA 问题转移到开发过程的后端。正如开发经理所说的那样：
“众包着眼于需求，并在项目开始时放宽了质量流程，因此，现在所有对质量管理的强调都来自项目后期的质量保证周期，而且往往更加昂贵。”
还存在缺乏连续性的问题。人群开发人员不会在比赛结束时保持闲置状态，因此可能无法在随后的 TPI 比赛中使用。实际上，TPI 遇到了带有错误的问题，该问题先前已被识别和修复，但是在代码返回以与人群进行进一步开发之后重新引入。不可避免地会有不同的开发人员来处理代码，并且通常不会进行组织学习。当他将与开发人员的互动描述为“亲密关系”时，这进一步增强了 TPI 部门 CTO 所表达的批判性看法：
“结转知识有限。 我们将有一些参赛者将参加多个竞赛，但他们不会像内部人员那样积累领域知识。”
鉴于 TPI 认为技术和特定领域专业知识的结合非常罕见，TPI 采取了一些举措来提高众包贡献的质量。人群开发 区在开发过程中使用了它，并作为他们开发的代码的最终测试或演示者。在此之前，代码测试是通过对后端的存根服务调用完成的，但是 TPI 内存在一个担忧，即当完全连接到后端时，众包开发人员交付的代码不一定能平稳运行。当人群产生最初的 HTML5 高级面板应用程序的代码时，就会出现一些质量问题。TPI 采纳了此代码，并按照 TPI 要求的级别将其进一步开发为“黄金标准”。这作为将来开发的模板被传递回 Topcoder 区。扩展了该策略，以准备可作为 Topcoder 区模板的 Web 应用程序的示例代码。
4.5 知识和知识产权
前面提到的“竞争关系”也对知识管理和 IP 产生了影响。表 6 显示了注册者总数，以及每种比赛类型的提交总数。表格显示，潜在的参与者数量很多，但是参赛人数明显减少了。
表 6 每种类型，注册，提交，唯一注册和唯一开发人员的竞赛总数，以及 TPI 竞赛的平均提交率
4.6 激励和 酬
鉴于潜在的发展 区成员超过一百万，Topcoder 会声称拥有足够广泛和深入的专业知识以确保健康的竞争率。但是，TPI 由于缺少参赛作品而不得不取消某些比赛。此外，在 44 个比赛中，有 10 个仅吸引了一个参赛者。TPI 使用化名的事实可能很重要，因为知名公司似乎更容易吸引人群开发人员。为了调查缺乏提交内容的潜在原因，我们还分析了人群中活跃成员的数量。确定“活跃”成员是什么并不容易。Topcoder 的定价结构非常精细。Topcoder 估计，通过重新使用目录中的组件，可以解决大约 60％的客户项目。但是，TPI 无法利用此目录。“我们已经构建了技术栈，并且已经为此编写了很多软件。因此，Topcoder 目录对我们没有太大用处。对于我们这里的人来说，并没有真正的高价。”
5 理论发展与评估
5.1 理论发展和模型
指定 SEM 的第一步是指定一个理论模型，即定义一组假设。借鉴先前有关众包的文献和我们在第 4 节中探索性案例研究，我们提出了许多相互关联的假设（见图 11）。
图 11 拟议的理论模型
假设 1（H1）：在项目中并行进行比赛与人群对该比赛的兴趣负相关。
假设 2（H2）：比赛的 酬与人群对比赛的兴趣增加呈正相关。
假设 3（H3）：比赛时间与人群对比赛的兴趣成正比
假设 4（H4）：人群的兴趣与参加比赛有正相关。
假设 5（H5）：“人群杀手”将与比赛的参与负相关。
在图 11 中，我们还包含许多控制变量。我们在竞赛期间将需求类型因子（“对开发人员的需求”）作为其他并行活动的数量，因为这会稀释开发人员库（如果有）。这有可能减少单个比赛的注册和提交总数。最初打算参加给定竞赛的开发人员可能会被其他活跃竞赛分散。
“技术数量”可能是影响注册人和提交文件数量的因素。显然，如果不检查每个比赛的规格就无法说明比赛的复杂性，但所涉及的技术数量却是开发人员所需知识的粗略指标。
我们考虑了注册人已经在进行的竞赛的数量。在发布新竞赛（即，其注册已公开）时，成员可能已经在其他竞赛中提交了。这可能会降低他们对新广告竞赛的兴趣，但也可能会将他们的注意力从当前竞赛转移到新竞赛。
5.2 估计和评估模型拟合
在指定结构方程模型之后，下一步是评估模型并评估其拟合。也就是说，模型的参数由 SEM 软件程序估算，并且可以评估所生成的模型拟合指数（见图 10）。有多种替代技术可用于处理 SEM 中非正态分布的数据-在我们的研究中，我们使用了两种此类技术。首先，我们使用了鲁棒的 ML 估计，然后我们使用 Bollen-Stine 引导程序来计算标准错误值。
图 10 实施 SEM 的步骤（改编自 Hoyle [115，第 7 页]）。
表 7 模型拟合指数
已经提出了许多拟合指数来评估结构方程模型。对许多研究的批评是，他们只 告了一个拟合指数。遵循有关 告 SEM 的准则，我们讨论了几种常用的拟合指标，还讨论了我们的模型如何在这些指标上评分。重要的是要注意，对于大多数这些指数的临界点尚未达成普遍共识，这一点我们将在下面进行详细介绍。表 7 汇总了拟合索引。
基于上面 告的拟合指数，我们得出结论，我们的理论模型得到了数据的支持。但是，要注意，我们的模型不是唯一可行的模型，并且可能存在替代模型。
5.3 假设检验和解释
表 8 均值，标准偏差和相关性（矛兵）
在各种模型拟合指标的基础上，我们确信我们提出的模型是合理的模型。要注意，这种支持并不意味着我们的模型是最优的，它只是一个模型。理论模型非常适合数据，这是能够解释参数估计值的前提。遵循 SEM 的 告指南，我们在表 8 中列出了模型的构造，相关性，均值和标准差（由于数据不是正态分布的，因此我们使用了非参数 Spearman 的 r 相关系数）。
6 结论和未来研究
要回答这些问题，就需要从众包系统的所有三个关键角度进行进一步研究，即众包平台，众包和众包客户。 我们相信答案将暗示与人群等未知劳动力一起工作的新方法。
致谢
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！