애자일과 생산성측정

단독 “빨라야 살아남는다”…신한금융, 애자일조직 도입한다
금융 빅5, 조직·인력 탈바꿈…신한 ‘사내벤처’ KB ‘애자일’

기사에 따르면 신한은행은 애자일 조직체계에 도입해 직급과 관계없이 일에 적합한 사람을 팀장으로 임명해, 민첩한 의사결정을 통해서 빠른 실행력을 얻을 것이라 기대한다고 전한다. 많은 IT 관련 회사와 조직이 애자일을 도입하는데, 과연 애자일을 실행해서 생산성이 향상됐을까?

Measuring Productivity in Agile Software Development Process: A Scoping Study

애자일 소프트웨어 개발 과정에서 생산성 측정하기: 주제범위 스터디

이 논문은 직접 애자일을 실행하고 생산성을 측정하는 대신, 애자일 방법론대로 소프트웨어를 만들고 생산성을 측정한 12개의 논문을 모아서 각 논문에서 정의한 생산성에 대해 정리했다. 그리고 각 연구에서 생산성을 측정하는데 사용한 방법도 연구했다. 논문에서 몇가지 부분을 번역해봤다.

ABSTRACT
An agile software development process is often claimed to increase productivity. However, productivity measurement in agile software development is little researched. Measures are not explicitly defined nor commonly agreed upon. In this paper, we highlight the agile productivity measures reported in literature by means of a research method called scoping study. We were able to identify 12 papers reporting the productivity measures in agile software development processes. We found that finding, understanding and putting into use agile productivity definitions is not an easy task. From the perspective of common roles in agile software development process and existing knowledge workers’ productivity dimensions, we also emphasize that none of the productivity measures satisfy these fully. We recommend that future effort should be focused on defining agile productivity in measurable, practicable and meaningful form.

초록 애자일 소프트웨어 개발 방법론은 생산성을 향상시킨다고 알려져있다. 그러나 애자일 소프트웨어 개발 방법론에서 생산성 측정 방법에 대해서는 연구가 거의 이뤄지지 않았다. 측정 방법은 명시적으로 정의되거나, 공통적으로 합의되지 않았다. 본 논문에서는, 범위 연구(scoping study)라는 연구 방법을 사용해 논문에 보고된 애자일 생산성 측정 방법을 알아본다. 애자일 소프트웨어 개발 방법 과정에서 생산성을 측정한 12개의 논문을 연구했고, 애자일 개발 과정에서 생산성의 정의를 찾고 이해하고 활용하는 것이 어려운 일이라는 것을 알았다. 애자일 소프트웨어 개발 방법론에서의 역할과 기존 지식 근로자의 생산성 관점은 생산성 측정 방법을 완전히 만족시킬 수 없었다. 미래에는 측정 가능하고 실행 가능하며 의미있는 형식으로 애자일 생산성을 정의하는 데 중점을 두도록 노력해야 한다.

3.3 Stage 3: Study Selection
We scanned all downloaded papers to find evidence in literature of measuring productivity in agile software development processes. This led to a selection of 12 papers in total, out of 124. The inclusion and exclusion criteria employed is defined below. Inclusion Criteria: The inclusion criteria were applied at three subsequent levels. First, the titles were screened. They were selected if the title contained ‘agile’ and ‘productivity’. Second, we analyzed the abstracts of the papers where it had to demonstrate some experience in agile software development concerning productivity compared to other factors, such as quality, cost and schedule. As a third step, we thoroughly read the papers and included only those studies which described/discusses at least one of the following: agile software development process productivity method to calculate productivity, or productivity metrics Exclusion Criteria: The studies that did not satisfy any of the inclusion criteria were excluded.

3.3 3 단계 : 연구 선택
애자일 소프트웨어 개발 방법에서 생산성을 측정에 대한 부분을 찾기 위해 다운로드 받은 모든 문서를 읽었다. 이렇게 해서 124개 중 총 12개의 논문을 선택했다. 채택 및 제외 기준은 아래에 정의했다. 포함 기준 : 포함 기준은 세 가지로 적용했다. 먼저 제목에 애자일과 생산성이 포함되면 선정했다. 둘째, 품질, 비용 및 일정과 같은 다른 요소와 비교하여 생산성에 관한 애자일 소프트웨어 개발 경험을 보여 주는 논문의 초록을 분석했다. 세 번째, 우리는 논문을 처음부터 끝까지 읽고 다음 중 하나 이상을 설명 / 토론 한 연구만 포함했다.

  • 애자일 소프트웨어 개발 프로세스
  • 생산성
  • 생산성 계산 방법 또는 생산성 메트릭

배제 기준 : 포함 기준을 충족시키지 못한 연구는 제외했다.

채택된 연구들

ID 정보
J1 Layman, L.; Williams, L.; Cunningham, L., Motivations and measurements in an agile case study, Journal of Systems Architecture, Volume 52, Issue 11, November 2006, Pages 654-667, ISSN 1383-7621
J2 Tarhan, A.; Yilmaz, S. G., Systematic analyses andcomparison of development performance and productquality of Incremental Process and Agile Process,Information and Software Technology, Volume 56, Issue5, May 2014, Pages 477-494, ISSN 0950-5849,
J3 Moser, R.; Abrahamsson, P., Pedrycz, W., Sillitti, A., and Succi, G., “A Case Study on the Impact of Refactoring on Quality and Productivity in an Agile Team,” inBalancing Agility and Formalism in Software Engineering, vol. 5082, B. Meyer, J. Nawrocki, and B.Walter, Eds. Springer Berlin Heidelberg, 2008, pp. 252–266.
J4 Parrish, A.; Smith, R.; Hale, D.; Hale, J., “A field study of developer pairs: productivity impacts and implications,” Software, IEEE , vol.21, no.5, pp.76,79, Sept.-Oct. 2004
J5 Athanasiou, D.; Nugroho, A.; Visser, J.; Zaidman, A.,”Test Code Quality and Its Relation to Issue HandlingPerformance,” Software Engineering, IEEE Transactions on , vol.40, no.11, pp.1100,1125, Nov. 1 2014
C1 Ramasubbu, N.; Balan, R. K., 2009. The impact of process choice in high maturity environments: An empirical analysis. In Proceedings of the 31st International Conference on Software Engineering (ICSE ‘09). IEEE Computer Society, Washington, DC, USA, 529-539.
C2 Abrahamsson, P.; Koskela, J., “Extreme programming: a survey of empirical data from a controlled case study,” Empirical Software Engineering, 2004. ISESE ‘04. Proceedings. 2004 International Symposium on , vol., no., pp.73,82, 19-20 Aug. 2004
C3 Hu Guang-yong, “Study and practice of import Scrum agile software development,” Communication Software and Networks (ICCSN), 2011 IEEE 3rd International Conference on , vol., no., pp.217,220, 27-29 May 2011
C4 Williams, L.; Brown, G.; Meltzer, A.; Nagappan, N., “Scrum + Engineering Practices: Experiences of Three Microsoft Teams,” Empirical Software Engineering and Measurement (ESEM), 2011 International Symposium on , vol., no., pp.463,471, 22-23 Sept. 2011
C5 Abrahamsson, P., “Extreme programming: first results from a controlled case study,” Euromicro Conference, 2003. Proceedings. 29th , vol., no., pp.259,266, 1-6 Sept. 2003
C6 de Souza Carvalho, W.C.; Rosa, P.F.; dos Santos Soares, M.; Teixeira da Cunha Junior, M.A.; Buiatte, L.C., “AComparative Analysis of the Agile and Traditional Software Development Processes Productivity,” Computer Science Society (SCCC), 201130th International Conference of the Chilean , vol., no., pp.74,82, 9-11 Nov. 2011
C7 Sutherland, J.; Viktorov, A.; Blount, J.; Puntikov, N., “Distributed Scrum: Agile Project Management with Outsourced Development Teams,” System Sciences, 2007. HICSS 2007. 40th Annual Hawaii International Conference on , vol., no., pp.274a,274a, Jan. 2007

생산성 메트릭

연구 생산성측정 지식 근로자 수  
J1 실행가능한 코드 라인 수 / 평균 개발자 1일 평균 업무량  
J1 기능 점수 / 평균 개발자 1개월 평균 업무량  
J2 코드 라인 수 / 1인이 1시간 작업 단위  
J3 기능 점수 / 1인  
J4 시간당 완료된 평균 기능 점수 개발자 2명으로 구성된 팀  
J5 해결된 이슈 수 / 개월 개발자별  
C1 해결된 이슈 수 / 평균 개발자 1일 평균 업무량  
C2 코드 라인 수 / 1인 1시간 업무  
C3 코드 라인 수  
C4 코드 라인 수  
C5 코드 라인 수 / 시간 개발자 4명으로 구성된
C6 기능크기 / 노력 팀(스크럼)  
C7 기능점수 / 개월수 개발자별  

RQ1: How is productivity measured in the agile software development process?

RQ1 : 애자일 소프트웨어 개발 방법에서는 생산성을 어떻게 측정하는가?

SUMMARY
In summary, we could state that the present productivity measures are not efficient enough to satisfy the requirements for defining productivity in agile software development. It is clear that defining agile productivity measures must consider the knowledge dimension. In the future, we have a twofold research direction, first we aim at defining measureable productivity metrics for different agile roles that would also satisfy the knowledge worker dimensions and cover all aspects (from requirements to delivery of working product to a customer) of agile development process.

요약하면, 현재 생산성 측정 방법은 애자일 소프트 웨어 개발의 생산성 정의에 필요한 요구 사항을 충족하지 못한다. 애자일 생산성 측정은 지식 측면을 고려해야 한다. 앞으로는 두가지 연구 방향이 있다. 하나는 애자일에서 다양한 직군과 지식 근로자 또한 만족할만한, 측정가능한 생산성 메트릭을 정의하는 것이다. 그리고 애자일 개발 과정 전 부분(요구사항에서 부터 고객에게 작업물 제공을 전달하는 것 까지)을 포괄하는 것이다.

이 논문으로 알 수 있는 건 다음과 같다. 우선 애자일 생산성에 관한 연구들이 생산성을 측정하는데 코드 라인수, 기능점수를 많이 활용하고 있다. 하지만 사실 애자일 개발 방법론을 접목한다면 리팩토링이 필수적으로 이뤄저야 하는데, 리팩토링을 하게 되면 대체로 코드 라인 수가 짧아진다. 여기서 알 수 있는 것은 코드가 더 길어질수록 생산성이 더 좋아지는 게 아니라는 것이다. 코드 라인 수는 생산성 측정에 사용하기에 부족하다. 또한, 애자일 개발 방법을 도입하면 사람들은 팀을 구성해서 공동의 목표를 위해 일하게 되기 때문에, 개인의 성과 역시 팀 단위에서 측정해야 한다. 스크럼에서는 팀에 개발자 뿐만 아니라 테스터, 스크럼 마스터 등등 다양한 역할이 있다. 이런 직군들은 코드 라인 수로 생산성을 측정할 수 없다. 현재 애자일 생산성 메트릭으로는 같은 팀의 다른 직군 생산성을 측정할 수 없는 것이다.
생산성은 많은 기업이 고민하는 부분이다. 스타트업은 생산성 극대화 효과를 기대하고 애자일을 도입한다. 대부분의 사람들이 애자일이 워터폴보다 더 나은 방법이라고 생각한다. 하지만 애자일을 도입할 경우 생산성이 얼마나 향상되는지에 대해서는 알 수 없다. 각 팀 또는 회사에서는 생산성을 측정 또는 개인의 퍼포먼스 평가를 위해 다른 방법을 도입하는 게 최선인 것 같다.