[论文解读] A Multi-dimensional Study of Requirements Changes in Agile Software Development Projects

Kashumi Madampe, Rashina Hoda+1 more|arXiv (Cornell University)|Dec 7, 2020

Software Engineering Research参考文献 27被引用 4

一句话总结

本研究通过新西兰和澳大利亚50名实践者的混合方法研究，提出了一种敏捷软件开发中需求变更（RCs）的多维分类体系。研究发现，RCs主要为功能性变更，以人为本，且最常在每日站会中产生；尽管敏捷团队使用多样的处理技术，但对接受变更普遍持保留态度，这与‘响应变更’是采用敏捷方法主要驱动力的观点相悖。

ABSTRACT

Agile processes are now widely practiced by software engineering (SE) teams, and the agile manifesto claims that agile methods support responding to changes well. However, no study appears to have researched whether this is accurate in reality. Requirements changes (RCs) are inevitable in any software development environment, and we wanted to acquire a holistic picture of how RCs occur and are handled in agile SE teams in practice. We also wanted to know whether responding to changes is the only or a main reason for software teams to use agile in their projects. To do this we conducted a mixed-methods research study which comprised of interviews of 10 agile practitioners from New Zealand and Australia, a literature review, and an in-depth survey with the participation of 40 agile practitioners world-wide. Through this study we identified different types of RCs, their origination including reasons for origination, forms, sources, carriers, and events at which they originate, challenging nature, and finally whether agile helps to respond to changes or not. We also found that agile teams seem to be reluctant to accept RCs, and therefore, they use several mitigation strategies. Additionally, as they accept the RCs, they use a variety of techniques to handle them. Furthermore, we found that agile allowing better response to RCs is only a minor reason for practicing agile. Several more important reasons included being able to deliver the product in a shorter period and increasing team productivity. Practitioners stated this improves the agile team environment and thus are the real motivators for teams to practice agile. Finally, we provide a set of practical recommendations that can be used to better handle RCs effectively in agile software development environments.

研究动机与目标

• 理解真实敏捷软件开发项目中需求变更（RCs）的起源、沟通方式及处理方式。
• 调查敏捷方法是否如《敏捷宣言》所宣称的那样，真正提升了对RCs的响应能力。
• 识别敏捷采纳的主要动因，特别是响应变更是否为关键驱动因素。
• 构建敏捷情境下RCs的综合分类体系，涵盖类型、来源、形式及具有挑战性的度量指标。
• 为敏捷团队提供改善RCs处理实践的实用建议。

提出的方法

• 对来自新西兰和澳大利亚的10名敏捷实践者进行半结构化访谈，以支持研究设计。
• 开展系统性文献回顾，识别现有RC分类体系及敏捷领域研究中的空白。
• 向亚洲、大洋洲、北美洲和欧洲的40名敏捷实践者发放全球深度调查问卷。
• 收集关于RC类型、来源、起源（包括每日站会等事件）、形式、传递者及变更原因的数据。
• 分析定性与定量数据，基于人与非人因素构建RCs的概念框架。
• 提出度量RCs挑战性的指标，包括变更请求到达率与需求波动性。

实验结果

研究问题

• RQ1 在敏捷软件开发项目中，需求变更的主要类型、来源和形式是什么？
• RQ2 需求变更最常在哪些敏捷仪式或事件中产生？
• RQ3 敏捷团队如何看待并处理需求变更？他们采用哪些策略？
• RQ4 响应变更是否是敏捷团队采纳敏捷方法的主要原因？还是存在其他主导动因？
• RQ5 敏捷方法在实践中在多大程度上真正支持更优的需求变更处理？

主要发现

• 大多数需求变更具有功能性特征，以人为本的变更比以软件为中心的变更更为常见。
• 每日站会是最常成为需求变更起源的事件，其次是客户支持讨论和冲刺计划会议。
• 客户是需求变更的主要来源，但产品负责人和其他团队成员也有所贡献。
• 敏捷团队常常对接受新需求持保留态度，因此常采用缓解策略，如待办事项列表梳理和验收标准澄清。
• 响应变更并非敏捷采纳的主要动因；相反，更快交付和提升团队生产力被列为最主要驱动因素。
• 相当大比例的需求变更源于以软件为中心的原因，如文档不充分、分析仓促及初始需求错误，表明敏捷原则可能存在误用。