大型分布式软件组织中Scrum实施与工作量估算研究

### 大型分布式软件组织中Scrum实施与工作量估算研究 在大型分布式软件组织中，Scrum方法的实施以及软件开发中的工作量估算都是重要且具有挑战性的议题。下面我们将深入探讨相关内容。 #### 大型分布式软件组织中Scrum实施的挑战与问题 在大型分布式软件组织里，成功实施Scrum面临诸多挑战。这需要客户与软件开发团队之间达成良好契合，而这在很大程度上依赖于产品负责人（PO）角色的成功实施。同时，Scrum可能还需要在协作、知识共享、组织文化和激励等方面进行大量投入。 以往研究发现，Scrum相关问题较为常见，具体如下表所示： |常见问题|对应研究| | ---- | ---- | |协作不足|[6], [10]| |调整优先级困难|[6], [10], [8]| |开发者处理错误任务|[8]| |对需求理解不足|[10]| 针对这些问题，也提出了相应的解决方案，如设置本地客户代表 [6], [7] 和增加PO资源 [7], [8] 。 在实际案例中，该组织在大约一年前进行了敏捷转型，分配了Scrum角色并开展了相关仪式，但Scrum并未完全实施。例如，PO未参加每日站会。PO需要具备面向团队和面向业务的专业知识，理想情况下一个开发团队配备一名PO。然而，当客户需求因复杂的国家特定法规而高度多变时，就需要其他人力资源。Scrum在复杂软件工程环境中，对于提高众多客户高度多变的期望与软件开发成果之间的匹配度帮助有限。除了Scrum，还需要努力制定具体明确的需求并指导团队，PO不能单独负责需求获取，还需要第三方、特定国家的专家、大量协作以及明确的优先级决策。 在该案例组织中，PO由多个团队共享，目的是管理国家特定法规的复杂性并减少地理分布带来的问题，这使开发者在开发冲刺期间至少能与一名PO面对面交流。但PO由于要处理高度多变的客户需求，没有足够时间与开发者会面，导致与开发团队的需求沟通不足。为此，组织决定增加PO数量来解决这些问题。 分析PO期望与开发工作成果之间的匹配率有助于采用Scrum。通过分析“为什么产品负责人的期望与已实现的功能不匹配”，案例组织能够了解哪些改进对自身需求是可行的。根因分析方法在案例组织中很受欢迎，它有助于制定纠正措施，组织在冲刺回顾中持续使用该方法。 不过，根因分析方法的输出有效性与人为因素有关。问题及其根本原因是在公开回顾会议中发现的，因此结果可能受到群体压力和知识不足的影响。为降低这些风险，采取了以下措施： 1. 结果基于三角测量，即三个独立小组的共同发现。 2. 请组织成员评估所发现问题的“正确性”和“影响”，且评价良好。 3. 分析的主要部分由该领域的公司代表专家进行。为确保可靠性，作者重新分析了数据，所有分析人员对发现的问题、根本原因以及可行的流程改进目标得出了相似结论。 #### 软件开发中工作量估算的研究 在Scrum项目中，工作量估算通常在每个冲刺开始时基于开发者经验进行。但多项实证研究表明，参与敏捷流程的开发者通常会低估工作量。 为了探究功能规模度量是否能实现更准确的工作量估算，之前进行了一项关于月光Scrum流程的案例研究。该研究旨在了解是否可以引入功能规模度量来提高估算准确性，并衡量基于专家的估算的准确性。研究结果显示，基于专家的估算比通过功能规模度量计算的模型估算更准确，即功能度量在月光Scrum中无助于开发者提高工作量估算的准确性。 由于该案例研究应用于Scrum的一个略有修改的版本，因此将相同方法应用于全职开发团队的普通Scrum流程时，可能会得到不同结果。为此提出了两个研究问题： 1. 是否可以将原案例研究的结果推广到普通Scrum流程？ 2. 与简化功能点（SiFP）相比，国际功能点用户组功能点（IFPUG Function Points）是否有助于提高工作量估算？ 为回答这些问题，对原案例研究进行了两次精确复制，应用于两个普通Scrum开发流程。新研究的项目在意大利卡利亚里大学的软件工厂实验室开发，开发过程采用Scrum，并借助看板进行支持，没有严格的在制品（WIP）限制，以随时可视化工作流程。开发流程组织如下： - 每个冲刺持续两周。 - 每日会议最长