[논문 리뷰] A Multi-dimensional Study of Requirements Changes in Agile Software Development Projects

Kashumi Madampe, Rashina Hoda외 1명|arXiv (Cornell University)|2020. 12. 07.

Software Engineering Research참고 문헌 27인용 수 4

한 줄 요약

이 연구는 뉴질랜드와 호주에서 활동하는 50명의 실무자들을 대상으로 한 혼합 방법 연구를 통해 애자일 소프트웨어 개발에서 요구사항 변경(RC)의 다차원적 분류 체계를 제시한다. 연구 결과, RC는 주로 기능적이며 인간 중심이며, 가장 자주 일일 스탠드업 미팅 동안 발생하는 것으로 나타났다. 애자일 팀들은 변화 수용에 대한 관성에도 불구하고 다양한 대응 기법을 사용하고 있으나, 변화에 대응하는 것이 애자일 방법론을 채택하는 주요 동기라는 믿음과는 다르게 나타났다.

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.

연구 동기 및 목표

• 실제 애자일 소프트웨어 개발 프로젝트에서 요구사항 변경(RC)이 어떻게 기인하고, 어떻게 전달되고, 어떻게 처리되는지 이해하는 것.
• 애자일 선언서에서 주장하는 바와 같이, 애자일 방법론이 실제로 요구사항 변경에 더 잘 대응하는지 조사하는 것.
• 애자일 채택의 주요 동기가 무엇인지 특정하는 것, 특히 변화에 대응하는 것이 핵심 동기인지 여부를 밝히는 것.
• 기능 유형, 기원, 형태, 도전적 지표를 포함한 애자일 환경에서의 RC에 대한 종합적인 분류 체계를 개발하는 것.
• 실무에서 RC 처리를 향상시키기 위한 실용적 권고 사항을 제공하는 것.

제안 방법

• 뉴질랜드와 호주의 10명의 애자일 실무자들과 진행한 반구조화된 인터뷰를 통해 연구 설계를 지원하는 데 사용함.
• 기존의 RC 분류 체계와 애자일 전용 연구의 격차를 식별하기 위해 체계적 문헌 고찰을 수행함.
• 아시아, 오세아니아, 북미, 유럽에 소재한 40명의 애자일 실무자들을 대상으로 심층적인 글로벌 설문 조사 실시.
• RC 유형, 기원(일일 스탠드업 미팅과 같은 사건 포함), 형태, 전달자, 변경 이유에 대한 데이터 수집.
• 정성적 및 정량적 데이터를 분석하여 인간적 요소와 비인간적 요소를 기반으로 한 RC의 개념적 프레임워크 개발.
• 변경의 도전성 측정을 위한 지표 제안, 예를 들어 변경 요청 도착률 및 요구사항 변동성 등.

실험 결과

연구 질문

• RQ1 애자일 소프트웨어 개발 프로젝트에서 요구사항 변경의 주요 유형, 기원, 형태는 무엇인가?
• RQ2 요구사항 변경이 가장 자주 발생하는 애자일 행사나 이벤트는 무엇인가?
• RQ3 애자일 팀은 요구사항 변경을 어떻게 인식하고 처리하는가? 어떤 전략을 사용하는가?
• RQ4 변화에 대응할 수 있다는 능력이 애자일 방법론을 채택하는 주요 이유인가, 아니면 다른 주요 동기가 존재하는가?
• RQ5 실제로 애자일 방법론이 요구사항 변경 처리에 더 나은 지원을 제공하는 정도는 어느 정도인가?

주요 결과

• 요구사항 변경의 대부분은 기능적 성격을 띠며, 소프트웨어 중심의 변경보다 인간 중심의 변경이 더 흔하다.
• 일일 스탠드업 미팅이 요구사항 변경이 가장 자주 발생하는 이벤트이며, 그 다음으로 고객 지원 대화와 스프린트 계획 회의가 뒤를 이룬다.
• 고객이 요구사항 변경의 주요 기원이지만, 제품 오너나 팀원과 같은 다른 이해관계자들도 기여한다.
• 애자일 팀은 새로운 요구사항 수용에 대해 관성적인 경향을 보이며, 백로그 정리나 수락 기준 명확화와 같은 완화 전략을 사용한다.
• 변화에 대응하는 능력은 애자일 채택의 주요 동기가 아니며, 오히려 더 빠른 배포와 팀 생산성 향상이 주요 동기로 제시된다.
• 요구사항 변경의 상당 부분은 부족한 문서화, 분석 과정의 급작스러움, 초도 요구사항 오류와 같은 소프트웨어 중심의 이유에서 기인하며, 이는 애자일 원칙의 오용 가능성을 시사한다.