Professional Documents
Culture Documents
애자일 개발방법론이 개발직무특성과 업무성과에 미치는 영향에 대한 실증적 분석
애자일 개발방법론이 개발직무특성과 업무성과에 미치는 영향에 대한 실증적 분석
애자일 개발방법론이 개발직무특성과 업무성과에 미치는 영향에 대한 실증적 분석
0 대한민국
Disclaimer
제 85회 박사학위논문
지도교수 김 성 근
중앙대학교 대학원
경영학과 경영정보시스템 전공
황 순 삼
2009년 8월
애자일 개발방법론이 개발직무특성과
업무성과에 미치는 영향에 대한
실증적 분석
2009년 8월
중앙대학교 대학원
경영학과 경영정보시스템 전공
황 순 삼
황순삼의 박사학위논문으로 인정함
심사위원장 김 진 수 (인)
심사위원 이 주 헌 (인)
심사위원 이 국 희 (인)
심사위원 김 성 근 (인)
심사위원 최 명 길 (인)
중앙대학교 대학원
2009년 8월
목 차
제 1 장 서 론 ............................................................................................................................1
제 1 절 연구 배경 및 필요성 ............................................................................................1
제 2 절 연구 목적 ................................................................................................................6
제 3 절 연구 구성 ................................................................................................................7
제 2 장 이론적 배경 ..............................................................................................................10
제 1 절 소프트웨어 개발자의 이론적 동기부여 모델.................................................10
제 2 절 소프트웨어 개발자의 동기부여에 대한 선행 연구.......................................16
제 3 절 애자일 개발방법론 및 실천방법 소개.............................................................18
제 4 절 애자일 개발방법론의 선행 연구.......................................................................35
제 3 장 연구 모형 ..................................................................................................................39
제 1 절 연구모형 ................................................................................................................39
제 2 절 연구가설 ................................................................................................................43
제 1 편 개발방법론과 개발직무의 MPS와 개발업무성과.......................................43
제 2 편 애자일 실천방법과 개발직무의 MPS와 개발업무성과 .............................49
제 3 절 연구변수의 조작적 정의.....................................................................................52
제 4 절 표본 집단과 설문 구성 ......................................................................................59
제 4 장 실증 분석 ..................................................................................................................62
제 1 절 기초통계분석 ........................................................................................................62
제 2 절 상관관계 분석 ......................................................................................................64
제 3 절 신뢰성 분석 ..........................................................................................................66
제 4 절 타당성 분석 ..........................................................................................................67
제 5 절 연구가설의 검증 ..................................................................................................71
제 1 편 개발방법론과 개발직무의 MPS와 개발업무성과의 가설검증 .................71
제 2 편 애자일 실천방법과 개발직무의 MPS와 개발업무성과의 가설검증 .......90
제 6 절 구조방정식 연구모형 ........................................................................................104
제 5 장 결 론 ........................................................................................................................ 117
제 1 절 연구의 시사점 .................................................................................................... 117
제 2 절 연구의 요약 ........................................................................................................122
i
제 3 절 연구의 한계점 및 향후 연구 방향.................................................................125
<참 고 문 헌>........................................................................................................................126
부록 (설문지)..........................................................................................................................131
국 문 초 록 ............................................................................................................................140
ABSTRACT .............................................................................................................................142
ii
그 림 목 차
iii
표 목 차
iv
[표 39] 개발직무의 MPS와 프로젝트 기간 단축 수준의 결정계수
(객체지향/컴포넌트).......................................................................................................................86
[표 40] 개발생산성의 분산분석 평균.........................................................................................87
[표 41] 개발생산성의 분산분석 검증 결과 ...............................................................................87
[표 42] 시스템 품질 수준의 분산분석 평균 .............................................................................88
[표 43] 시스템 품질 수준의 분산분석 검증 결과 ...................................................................88
[표 44] 개발방법론에 따른 프로젝트 기간 단축 수준 순위 .................................................89
[표 45] 프로젝트 기간 단축 수준 검정통계량 .........................................................................89
[표 46] 관리 실천수준과 개발직무의 MPS 관계에서 회귀식 검증 .....................................90
[표 47] 관리 실천수준과 개발직무의 MPS 관계에서 회귀 결정계수 .................................91
[표 48] 개발 실천수준과 개발직무의 MPS 관계에서 회귀식 검증 .....................................91
[표 49] 개발 실천수준과 개발직무의 MPS 관계에서 회귀 결정계수 .................................92
[표 50] 관리 및 개발 실천수준과 개발직무의 MPS 관계에서 회귀식 검증 .....................92
[표 51] 관리 및 개발 실천수준과 개발직무의 MPS 관계에서 회귀 결정계수 .................93
[표 52] 관리 실천수준과 개발생산성 관계에서 회귀식 검증 ...............................................93
[표 53] 관리 실천수준과 개발생산성 관계에서 회귀 결정계수 ...........................................94
[표 54] 관리 실천수준과 시스템 품질 수준 관계에서 회귀식 검증 ...................................95
[표 55] 관리 실천수준과 시스템 품질 수준 관계에서 회귀 결정계수 ...............................95
[표 56] 관리 실천수준과 프로젝트 기간 단축 수준 관계에서 회귀식 검증 .....................96
[표 57] 관리 실천수준과 프로젝트 기간 단축 수준 관계에서 회귀 결정계수 .................97
[표 58] 개발 실천수준과 개발생산성 관계에서 회귀식 검증 ...............................................97
[표 59] 개발 실천수준과 개발생산성 관계에서 회귀 결정계수 ...........................................98
[표 60] 개발 실천수준과 시스템 품질 수준 관계에서 회귀식 검증 ...................................98
[표 61] 개발 실천수준과 시스템 품질 수준 관계에서 회귀 결정계수 ...............................99
[표 62] 개발 실천수준과 프로젝트 기간 단축 수준 관계에서 회귀식 검증 ...................100
[표 63] 개발 실천수준과 프로젝트 기간 단축 수준 관계에서 회귀 결정계수 ...............100
[표 64] 연구 가설검증의 결과 요약.........................................................................................101
[표 65] 애자일 실천수준에 대한 확인적 요인분석 ...............................................................104
[표 66] 확인적 요인분석의 부합지수.......................................................................................106
[표 67] 구조방정식 연구모형의 적합도 지수 .........................................................................109
[표 68] 수정된 구조방정식 연구모형의 경로계수와 t 검정치 및 표준오차 ....................112
v
애자일 개발방법론이 개발직무특성과 업무성과에 미치는 영향에
대한 실증적 분석
제 1 장 서 론
제 1 절 연구 배경 및 필요성
1
한계점도 따른다. 가장 큰 문제점은 개발 과정에서 변경되기 쉬운 고객의
요구사항에 신속하게 대응하기 어렵다는 점이다. 또한 고객 입장에서는
개발이 다 완료된 이후에야 비로소 요구사항과 구현된 기능과의 차이점과
문제점을 확인할 수 있다는 것도 중요한 한계점이다. 이러한 한계점은
폭포수 생명주기가 가지고 있는 구조적 특성에 기인한다. 즉, 앞 단계를
완료해야만 다음 단계를 진행할 수 있기 때문에 변화에 민첩하게 대응하기
어렵고 고객과의 피드백 과정도 느려진다(Deemer & Benefield, 2007).
2
증가하고 있다. Forrester Research는 2007년에 미국과 유럽 기업의 25%가
애자일 개발방법론을 도입하였다고 언급하였다. 기업들이 애자일
개발방법론을 도입하는 속도도 가속화되어 2006년의 2~3배에 달할 정도로
빨라졌다고 한다(Schwaber et al., 2008). 국내에서는 게임 업계와
임베디드(embedded) 업계, SI 업계 등에서 애자일 도입이 활발하게 진행되고
있다(이창준, 2008).
3
소프트웨어 개발자의 업무성과에 대한 연구는 활용하는 방법론에 대한 고려
없이 주로 인적 요인 그 자체에 중점을 두어 오래 전부터 진행되어왔다.
Carmel(1995)은 업무성과 요인으로 크게 기술적 요인과 비기술적
요인(non-technology)으로 구분하였다. 그의 연구에 따르면 기술적 요인보다는
비기술적 요인이 업무 성과에 중요하다고 제시하였다. 소프트웨어 개발에서
비기술적 요인의 중요성은 다른 연구자들에 의해서도 많이 제시되어
왔다(Hall & Wilson, 1997; Wilson & Hall, 1998; Weinberg, 1998, Wilson et al., 2000).
즉, 개발직무와 업무환경, 개발자간의 상호작용과 같은 인적 요인들(human
factors)이 개발자의 동기부여를 높이고 개발업무성과를 향상시키는데
중요하다고 하였다.
4
선행연구에서 애자일 개발방법론을 활용하는 경우, 개발자의 동기부여
향상을 통해 업무성과가 향상된다고 추정하였다(Beck, 2000; Law & Charron,
2005; Mannaro et al., 2004). 그러나 아직까지 이런 관계를 실증적으로 밝힌
연구는 없었다.
5
제 2 절 연구 목적
6
제 3 절 연구 구성
7
설정과 실증 연구를 위한 변수의 조작적 정의, 설문 항목의 구성에 대하여
설명하였다.
제 4장은 실증 분석으로 측정 도구의 신뢰성과 타당성을 검증한 후
가설들을 검증하고 결과를 기술하였다. 또한 애자일 실천방법과 개발직무의
동기부여 수준과 개발업무성과에 미치는 영향을 분석하기 위하여
구조방정식을 이용하여 연구모형의 타당성을 검증하고 수정된 연구모형을
제시하였다.
제 5장은 결론으로 도출된 실증 분석 결과를 바탕으로 연구의 시사점을
제시하고 연구 결과를 요약하였다. 마지막으로 본 연구의 한계점을 밝혀
향후 연구 방향을 제시하였다. 본 연구의 구성 체계는 [그림 1]에
제시되어있다.
8
[그림 1] 연구의 구성 체계
9
제 2 장 이론적 배경
10
[그림 2] 5단계 욕구단계설
11
개념으로 명확하게 구분되는 것이 아니라고 주장하였다. 1960년과 1962년 두
차례에 걸쳐 1,021명의 보험회사 직원을 대상으로 한 연구결과에 따르면,
1960년의 경우 급여가 불만족요인으로 작용했으나 2년 후 급여는 만족요인과
불만족요인을 동시에 유발하는 요인으로 작용하였다(Ewen, 1974). 또한 House
& Wigdor(1967)은 위생요인과 동기요인이 명확하게 구분되는 것이 아니라는
점에서 Herzberg가 제시한 만족요인과 불만족 요인의 구분이 모순임을
주장하였다.
[그림 3] 이중요인이론
12
핵심직무특성은 기술다양성, 업무정체성, 업무중요성, 자율성, 피드백으로
구성된다. 직무특성모형에서는 작업자가 업무 결과를 향상시키기 위해서는
다음과 같은 세 가지 심리 상태를 경험한다고 설명하고 있다. 첫째로
작업자는 수행하는 업무에 대하여 의미를 느껴야 하며 둘째, 수행하는
업무에 대하여 책임의식을 경험해야 하고 셋째로 수행한 일에 대하여 결과를
인식할 수 있어야 한다는 것이다. 그러나 작업자가 세 가지 심리상태를
경험하지 못하면 동기부여와 업무 성과가 낮아진다고 하였다(Hackman &
Oldham, 1975; 1976; 1980).
[그림 4] 직무특성모형(JCM)
기술다양성
업무정체성 의미
업무중요성
동기부여 향상
피드백 결과인식
13
타인이나 자신의 조직에 영향을 미치는 수준을 의미하는 것이다. 개발하는
시스템이 조직에서 핵심적일 경우 업무중요성이 크다고 볼 수 있다.
자율성은 업무를 수행할 때 개발자에게 부여된 권한, 책임, 자유, 독립성
등을 의미하는 것이다. 정의된 명세서에 따라 개발을 해야 하는
개발자보다는 전체 계획을 수립하고 의사결정을 내리는 프로젝트 관리자가
자율성이 크다고 할 수 있다. 피드백은 개발자가 수행한 직무의 결과가
얼마나 효과적으로 적용되었는지를 직접 확인하고 판단할 수 있는 수준이다.
예를 들면, 개발자가 프로그램을 작성하면 자동화된 단위테스트를 통하여
작성된 기능에 오류가 있는지 여부를 즉시 확인할 수 있다.
14
관련이 있다고 제시하였다. 그의 연구에서 직무의 MPS가 높아지면 작업자가
직무로부터 얻는 내부적 동기부여(internal motivation)와 업무만족도가
증가하여 업무성과에 긍정적인 영향을 주는 것으로 나타났다. 또한 직무의
MPS가 높더라도 성장에 대한 욕구(needs for growth)가 낮은 경우 직무의
MPS와 업무만족도와의 상관관계가 적어진다고 하였다.
(기술다양성+업무정체성+업무중요성)
3 업무의 의미
피드백 피드백
15
제 2 절 소프트웨어 개발자의 동기부여에 대한 선행 연구
16
있다고 하였다. Blankerz & Robinson(1996)은 높은 동기부여를 갖고 있는
개발자일수록 높은 업무만족도를 보였으며 업무만족도를 높이기 위한 선행
요인으로써 동기부여의 중요성을 언급하였다. Baddoo et al.(2006)는 동기부여
수준이 높은 조직의 개발자를 대상으로 동기부여에 미치는 영향을 분석한
결과, 업무성과를 인정해 주는 것이 동기부여에 영향을 미치며 개인의
업무성과를 향상시켜줌으로써 전체 조직의 생산성이 증가한다고 하였다.
따라서 개발자의 동기부여는 개인과 조직의 업무성과를 높일 수 있는 핵심적
요인이라고 하였다. Yan et al.(2006)는 오픈 소스 개발자 118명을 대상으로
조사하여 프로젝트의 성공은 프로젝트의 관리자의 관리 방식에 큰 관련이
있다고 하였다. 그는 프로젝트 관리자가 개발자들에게 동기부여를 시켜
업무성과에 기여할 수 있도록 하는 것이 중요하다고 제시하였다. Procaccino et
al.(2005)는 개발자에게 동기부여를 제공하는 것이 고객의 요구사항을
충족시켜 성공적인 프로젝트가 되는데 중요하다고 언급하였다.
17
제 3 절 애자일 개발방법론 및 실천방법 소개
18
개발에 유용한 실천방법을 제공하여 개발자가 가장 많이 사용하고 있는
애자일 개발방법론이라고 할 수 있다. XP 개발방법론이 추구하는 4가지의
핵심가치는 의사소통(communication), 단순성(simplicity), 피드백(feedback),
용기(courage)이다. 개발자는 XP의 4가지 핵심가치를 구현하기 위한 14개의
실천방법을 제공한다. 애자일 실천방법은 구체적인 개발방법으로 효과가
검증된 최상의 실천방법(best practices)이다. 대부분의 애자일 실천방법은
새로운 것이 아니라 기존의 개발방법론에 있던 기법과 방법들로부터 가져온
것들이다(Beck, 1999). 가령, 고객이 비즈니스 가치에 대한 결정을 내리고
개발자가 기술적인 의사결정을 내리는 것은 Alexander(1979)가 제시하였던
방법이다. 또한 빠른 반복적 개발은 스크럼과 Cunningham(1996)의 패턴
언어(pattern language)로부터 기원된 것이며 점진적 배포(evolutionary delivery)는
Gilb(2004)와 나선형 모델(spiral model)에 기반으로 두고 있다.
프로젝트에서 애자일 실천방법을 모두 사용하는 경우는 드물며 XP를
개발한 Beck도 도입 초기에는 이를 부분적으로 적용할 것들을 권장하고 있다.
Grenning(2001)과 Schuh(2001)은 전통적인 개발 프로세스에 익숙하였던
소프트웨어 개발 회사에 XP를 도입함에 있어서 XP의 전체 실천방법 중에서
부분적인 도입을 통하여 프로젝트를 진행하였다고 언급하였다.
동일한 실천방법이라도 조직에 따라 실천방법이 달라질 수 있다. 가령, 짝
프로그래밍이라는 실천방법은 적용하는 팀의 상황에 따라 매일 짝을 바꾸어
수행할 수 있고 매 시간 단위로 짝을 바뀌어 프로그래밍을 할 수도 있다.
XP의 실천방법은 XP 개발방법론의 핵심을 이루며 팀이 프로젝트를 올바른
방향으로 이끌어 갈 수 있도록 만들어 준다. XP의 14개의 실천방법을
이해하는 것은 본 연구모형을 이해하는데 필요하기 때문에 간략하게
설명하고자 한다.
(1) 계획 게임(planning game): 프로젝트 전체 계획과 개발주기 계획으로
나누어지며, 각각의 계획은 비즈니스적인 측면, 기술적인 측면을 고려하여
만들어진다. 계획 게임은 고객과 개발자가 참여하여 고객은 기능 요구사항과
우선순위를 제시하고 개발자는 구현에 필요한 기간을 산정하는 과정을 통해
19
개발주기 동안 만들어질 개발 계획을 수립한다. 계획 게임은 개발주기 동안
반복되며 지속적으로 피드백을 받아 변경할 수 있다.
(2) 작은 배포(small release): 고객이 제품이 어떻게 돌아가는지 확인할 수
있도록 짧은 주기로 기능을 개발한다. 또한 작동하는 소프트웨어를 고객에게
자주 배포하고 고객의 피드백을 받아 반영하도록 한다.
(3) 단순한 설계(simple design): 복잡한 설계를 최대한 단순화하여 표현한다.
결정되지 않은 요구사항보다는 현재까지 정해진 요구사항을 충족시키는데
중점을 둔다. 향후 추가적으로 변경되는 설계 과정은 리팩토링을 통하여
지속적으로 개선해 나간다.
(4) 짝 프로그래밍(pair programming): 동료와 함께 짝을 이루어 개발을 하고
짝을 주기적으로 변경하도록 한다. 한 사람이 개발을 하는 동안 동료는 개발
코드를 실시간으로 검증해주고 조언을 주고 받도록 한다. 이를 통하여 좋은
코드를 생성할 수 있으며 팀 내부의 학습 효과를 높일 수 있다.
(5) 지속적 테스트(continuous test): 개발자들이 자동화된 단위테스트를
작성하고 수행한다. 실제 코드를 작성하기 전에 먼저 테스트를 작성함으로써
무엇을 개발해야 하는지를 스스로 파악해 나가도록 한다. 개발이 완료되면
자동화된 단위테스트를 통하여 개발이 제대로 이루어졌는가를 바로 확인할
수 있다.
(6) 리팩토링(refactoring): 코드의 중복과 복잡성을 제거하면서 시스템의
유연성, 간결성, 의사소통의 효율성을 높이기 위하여 코드의 내부구조와 변수,
호출관계 등을 지속적으로 수정하고 개선한다.
(7) 지속적 통합(continuous integration): 시스템 컴포넌트 혹은 모듈 단위로
개발된 소스 코드들은 작업이 끝날 때마다 지속적으로 통합되도록
테스트한다. 개발 과정에서 새로운 코드를 정기적으로 통합하기 때문에
새로운 코드가 일으킬 수 있는 문제점을 즉시 발견할 수 있다. 또한
개발자들도 통합을 염두에 두고 개발을 하기 때문에 모듈 단위의
인터페이스를 미리 설계하여 변화에 유연한 개발이 가능하도록 해준다.
(8) 코드 공동 소유(collective code ownership): 프로젝트에 참여한 모든
20
개발자들이 코드에 접근할 수 있고 수정할 수 있도록 한다. 이를 통하여
코드는 팀 공동의 노력의 성과라는 것을 인식시키며 많은 사람들의
아이디어를 반영하고 개선할 수 있다.
(9) 코딩 표준(coding standards): 팀에서 코드 표준을 만들어 코드를 관리하고
유지하는데 어려움이 없도록 한다. 코딩 표준은 팀 내부의 코드 일관성과
가독성을 높여줄 뿐만 아니라 코드 품질을 향상시켜 유지보수를 용이하게
만들어 준다.
(10) 은유(metaphor): 고객과 개발자 혹은 개발자 간에 의사소통을 돕기 위해
공통의 언어로 시스템이 어떻게 작동하는가를 설명할 수 있도록 은유나 비유
등을 사용하거나 그림을 활용하여 표현하도록 한다.
(11) 고객 참여(on-site customer): 고객을 포함한 전체 팀이 한 장소에서 함께
일하도록 한다. 개발 현장에 고객을 상주시켜 개발 과정 동안 고객이 함께
참여할 수 있는 환경을 조성하고 고객의 의견을 적극적으로 반영하도록
한다.
(12) 주 40시간 근무(40-hour work): 팀의 성과를 측정하여 언제나 최적의
상태를 유지할 수 있도록 팀을 운영한다. 충분한 휴식과 상태를
유지함으로써 모든 팀이 최고의 효율을 발휘할 수 있는데 이는 프로젝트
전체 과정에서 결과적으로 높은 생산성을 얻도록 만들어 준다.
21
[그림 6] XP 개발방법론 프로세스
22
동작 가능한 제품을 점진적으로 개발해나가는 프로젝트 관리 중심의
방법론이다. 스크럼이란 용어는 럭비 경기에서 반칙이나 중단 이후 경기를
다시 시작할 때 양팀 선수들이 대형을 짜는 것을 의미한다. Takeuchi and
Nonaka(1986)는 제품의 개발주기를 단축시켰던 제품 개발 프로젝트에서 작은
규모의 협업팀(cross functional team)을 럭비의 스크럼과 같은 팀 구성에
비유하였다. 스크럼의 주요한 특징은 가장 중요한 요구사항을 먼저 개발하며
짧은 반복주기(이를 스프린트라고 하며 2~4주 이내)를 통해 고객의 피드백을
자주 반영한다는 점이다. 스프린트의 최종 결과물은 작동하는
소프트웨어이며 이를 사용자와 함께 검토하고 나온 피드백은 다음 스프린트
계획에 반영한다. 이러한 반복과정은 최종 요구사항이 충족될 때까지
반복적으로 수행된다. 스크럼 개발방법론 프로세스는 [그림 7]에
묘사되어있다.
23
개발자들이 수행할 구체적 작업과 예상 시간을 포함하고 있다. 스프린트
개발주기 동안 스크럼 팀은 일일 스크럼 회의(Daily scrum meeting)을 갖는다.
이를 통해 스크럼 마스터는 개별 팀원에 대한 진척 상태를 확인하고 번다운
차트(Burn-down chart)에 진척도와 남은 작업, 진행속도를 업데이트 한다.
스프린트가 종료 되면 전체 팀원들과 스프린트 리뷰(Sprint review) 및
스프린트 회고(Sprint retrospective)를 통해 결과물을 확인하고 문제점과
개선사항 등을 점검한다. 이러한 짧은 반복 개발주기를 통하여 사용자의
변경에 민첩하게 대응할 수 있게 하고 프로젝트의 유연성을 높인다.
24
[그림 8] 제품 백로그
25
프로젝트 관련 정보를 공유하여 팀 내에서 정보가 투명하게 공유될 수
있도록 도와준다.
제품 번다운 완료된
수행할
백로그 차트 작업내역
작업내역
26
않도록 한다. 작업을 완료하지 못하더라도 개발 기간을 연장하지 않고 다음
스프린트 계획에 이를 반영하도록 한다.
(7) 스프린트 회고: 스프린트가 완료되면 개발된 제품을 고객에게 데모하고
고객의 의견을 수렴한다. 스프린트 회고에서는 팀원들과 함께 스프린트
개발주기 동안 발생한 일과 느낀 점, 방해가 되었던 사항, 향후 개선할 사항
등을 토론하고 결과를 다음 스프린트에서 반영할 수 있도록 만들어 주는 팀
내부의 그룹회의이다. 회고를 통해 모든 팀원이 함께 수행한 스프린트로부터
경험을 공유하고 의견을 모을 수 있도록 한다.
27
XP에서의 개발적 측면을 갖추기 있기 때문에 개발방법론으로써 상호
보완적인 관계를 가지고 있다. XP 개발방법론과 스크럼 개발방법론은 반복적
개발주기, 점진적 개발, 고객 가치, 협업과 의사소통을 중시하는 애자일
개발방법론의 공통적인 특성을 기반으로 XP의 개발 실천방법을 스크럼을
통하여 관리하는 방식으로 프로젝트를 수행한다.
28
[그림 12] 기능주도개발 개발방법론 프로세스
29
United Process의 활동을 줄여서 작은 규모의 프로젝트에 적합하도록 하였다.
다만 무거운 방법론으로 알려진 통합 프로세스를 어떻게
테일러링(tailoring)하여 사용하는지에 대한 가이드는 제시하지 못했다.
30
[표 1] 애자일 개발방법론의 주요 특징과 제약사항
애자일
개발방법론 주요 특징 제약사항
- 고객 주도 개발 - 개별 개발자를 위한 다양한
- 작은 개발 팀 개발 실천방법을 제시하고 있
XP
- 개발 위주의 실천방법 으나 관리 실천방법이
- 대표적 애자일 개발방법론 부족하고 전체적인 통합
관점이 제시 되지 못함
- 독립적인 소규모의 - 스프린트 개발주기는 명확
자기조직화 (self-organizing) 하지만 기능을 통합하고 승인
개발 팀 테스트를 어떻게 가져갈 것
스크럼
- 30일 이내의 스프린트 인지에 대해서는 모호함
개발주기 - 시스템 품질과 개발을 위한
- 관리 위주의 실천방법 개발 가이드가 부족함
- 적용하기 용이하며 변화에
유연 하게 대응하기 위한 팀
관리
31
- United process에 기반한 - 통합 프로세스를 어떻게
전체 개발 프로세스를 제공 테일러링(tailoring) 할지에
- 주로 XP 기반의 애자일 대한 가이드 가 없기 때문에
애자일 통합
실천 방법을 United process에 무거운 프로세스가 될 수
프로세스
따라 적용하는 방식 있음
- 대규모 프로젝트에도 적용 - 변화에 대한 대응이나
가능 애자일 실천방법에 대한
명확한 가이드 가 부족함
32
시간이 소모되며 명확한 가이드가 부족하여 도입 초기에 시행착오가 많다고
하였다. 또한 지속적인 수행이 어려워 과거로 복귀하거나 생략하려는 경향이
있다는 점들이 지적되었다.
33
[표 2] 애자일 개발방법론과 실천방법
애자일
관리 실천수준 (7개) 개발 실천수준 (7개)
개발방법론
- 자동화된 승인테스트
- 코드 공유
- 고객참여
XP - 짝 프로그래밍
- 자동화된 단위테스트
- 테스트 주도 개발
- 회고 - 리팩토링
스크럼 - 정보방열기
- 일일 스크럼 미팅
- 게임 계획/스프린트 - 지속적 통합
계획
공통
- 동일 장소 근무
- 짧은 반복 개발주기
34
제 4 절 애자일 개발방법론의 선행 연구
35
방법론에 비해 대규모 조직에 적용하기 어렵기 때문에 고품질 소프트웨어
개발에는 적합하지 않다고 주장하였다. 또한 투입되는 자원의 능력에
지나치게 의존적이며 화면 설계와 같은 사용자 측면의 고려가 부족하다고
제시하였다. Gilb(2004)는 애자일 개발방법론의 한계점을 소프트웨어의 성능과
품질 차원에서 제시하였다. 애자일 개발방법론이 개발 속도를 높이는데
중점을 두고 있기 때문에 요즘과 같이 경쟁이 치열한 환경 속에서 애자일
개발방법론을 적용할 경우 성능과 품질에 대한 정량적 측정이 수반되어야
함을 강조하였다. Marçal et al.(2008)은 세부 프로세스 관점에서 개발방법론을
비교하였다. 그는 무거운 프로세스 개선 모델로 잘 알려진 CMMI(Capability
Maturity Model Integration), 품질개선 프레임워크와 스크럼을 일대일로 비교
평가하여 스크럼 개발방법론의 한계점을 제시하였다. CMMI의 한 영역인
프로젝트 관리 차원에서 보면 스크럼 개발방법론은 프로젝트 산정과 비용
예측, 위험관리, 비용 수립과 통제, 프로젝트 데이터 관리, 프로젝트 통합
관리 등에 대한 실천방법의 부족으로 인하여 Level 3 이상의 프로세스
성숙도를 충족시키기 어렵다고 주장하였다. 그러나 이러한 연구들은 애자일
개발방법론의 한계점을 구체적으로 제시하는데 미흡하였다. 예를 들면,
애자일 개발방법론 측정이 약하다는 주장했을 뿐 구체적으로 어떤 관점과
기준에서 부족한지를 제시하지 못하였다. 또한 CMMI와 애자일 개발방법론을
무거운 개발방법론의 관점에서 비교 평가하였기 때문에 애자일 개발방법론
고유의 특성과 가능성이 간과되기도 하였다(황순삼 등, 2008).
36
생산성, 동기부여가 향상되었다고 제시하였다. Melnik and Maurer(2006)은
459명의 개발자를 대상으로 애자일 개발방법론과 다른 개발방법론을
사용하는 개발자를 구분하여 설문조사를 수행하였다. 그는 애자일
개발방법론을 사용하는 개발자가 다른 개발방법론 사용자보다 높은
업무만족도를 보였으며 애자일 개발방법론을 오래 사용할수록 업무만족도가
증가하였다고 제시하였다. Mann & Maurer(2005)는 한 소프트웨어 업체에서
스크럼을 도입한 이후 2년 간의 프로젝트를 관측하였다. 그 결과 개발자의
초과근무(over-time)가 유의하게 줄어들었으며 개발 속도와 패턴이 안정화되어
프로젝트 진행이 수월해지고 고객만족도가 증가하였다고 언급하였다.
37
실제로 검증하지는 못하였다. 애자일 개발방법론에 대한 선행 연구들은
애자일 개발방법론이 개인뿐만 아니라 조직의 업무성과를 향상시키는데도
기여한다는 점을 제시하고 있다.
38
제 3 장 연구 모형
제 1 절 연구모형
39
유형은 개발접근방식에 따라 구조적/폭포수 개발방법론, 객체지향/컴포넌트
개발방법론, 애자일 개발방법론으로 구분하였다.
40
[그림 14] 개발방법론과 직무 및 업무성과에 대한 연구모형(1단계)
개발업무성과
개발생산성
H1 H2
개발직무의
개발방법론 유형
잠재적 동기지수
(Motivating
Potential Score) 시스템 품질
수준
프로젝트
기간 단축 수준
41
위하여 [그림 15]와 같이 2단계 연구모형을 설정하였다.
H5
개발업무성과
개발생산성
H3
애자일 관리 실천수준 개발직무의
잠재적 동기지수
(Motivating
Potential Score) 시스템 품질
애자일 개발 실천수준 수준
H4
프로젝트
기간 단축 수준
H6
42
제 2 절 연구가설
43
주기가 느리다. 또한 정해진 단계와 계획된 작업 순서에 따라 진행하기
때문에 개발자의 자율성이 줄어들거나 작업 결과에 대한 책임감이 낮아질 수
있다. 애자일 개발방법론과 구조적 개발방법론을 개발직무특성에 따라
비교한 결과는 [표 2]에 정리되었다(Award, 2005).
[표 2] 개발방법론의 개발직무특성 비교
44
테스터가 투입) 처음부터 완료시점까지 고객의
요구사항을 반영할 수 있도록
함
업무중요성 -요구사항을 분석하여 -투명하고 개방된 정보 공유와
시스템 분석가가 설계를 직접적인 의사소통을 통하여
작성하면 개발자 는 이에 개별 작업이 타인과 팀에
따라 정확하게 프로그램을 미치는 영향을 쉽게 인지할 수
개발해야 하는 역할 관계가 있도록 협업 환경을 제공함
명확 하게 구분됨 -고객의 가치를 우선시하며
-정해진 절차와 작업에 따라 개방되고 공유된 업무 환경을
역할별로 업무를 수행하며 통하여 개인의 성과보다는 팀
상위 작업(분석/설계)이 목표를 달성하는 것을 중요시
하위 작업(개발/ 테스트)에 함
큰 영향을 미치며 중요
하게 다루어짐
자율성 -작업자가 업무를 -자기 조직화(self-organizing)를
선택하거나 결정을 내릴 수 통하여 일정 산정과 개발 작업
있는 범위가 적으며 주어진 및 방법에 있어 담당자의
작업을 정해진 절차에 따라 의사결정을 존중하고 책임감을
수행함 높이도록 함
-각 작업의 산출물과 -스크럼 마스터는 지시나
문서화에 대한 부담이 크며 통제보다는 팀원의 참여와
계획 대비 실적에 대한 협업이 이루어질 수 있도록
통제가 강함 배려함
45
이루어짐 -일일 회의를 통하여 매일
-각 단계 종료시점에 진행사항을 확인하고
산출물과 문서에 대하여 정량적으로 진척사항을 공유
검수를 통하여 이해 -개발주기마다 회고를 통하여
관계자의 피드백을 받음 업무 성과에 대한 피드백과
-개발자는 시스템 테스트를 고찰을 통해 프로세스를
통해 구현된 기능을 지속적으로 개선해 나감
통합하고 고객으로부터
피드백을 받음
46
긍정적인 상관관계가 있어 개발직무의 MPS가 높아지면 업무성과가
향상된다고 하였다. Eby & Freeman(1999)는 개발자가 직무에서 동기부여를
느끼게 되면 업무만족도가 증가하고 관리 감독이 덜 요구된다고 하였다.
47
애자일 개발방법론은 기존의 개발방법론과 비교하여 업무만족도와
개발업무성과에서 향상된 결과를 보였다고 제시하였다. 따라서 애자일
개발방법론이 기존 개발방법론과 비교하여 개발업무성과에서 차이가
있는지를 분석하기 위하여 개발방법론에 따라 개발직무의 MPS가
개발업무성과에 미치는 영향을 검증할 필요가 있다.
48
단축 수준에 긍정적 영향을 미칠 것이다.
H 2-10: 객체지향/컴포넌트 개발방법론에서 개발직무의 MPS는
개발생산성에 긍정적 영향을 미칠 것이다.
H 2-11: 객체지향/컴포넌트 개발방법론에서 개발직무의 MPS는 시스템
품질 수준에 긍정적 영향을 미칠 것이다.
H 2-12: 객체지향/컴포넌트 개발방법론에서 개발직무의 MPS는 프로젝트
기간 단축 수준에 긍정적 영향을 미칠 것이다.
49
H 4: 애자일 개발 실천수준은 개발직무의 MPS에 긍정적 영향을 미칠
것이다.
50
Martel, 2002; Muller & Padberg, 2002; Ilieva et al., 2004; Erdogmus & Williams,
2003; Mann & Maurer, 2005)은 애자일 실천방법들이 개발업무성과에 긍정적인
영향을 미치는 결과라고 볼 수 있다. 따라서 이러한 이론적 배경을 바탕으로
다음과 같은 가설을 설정하였다.
51
제 3 절 연구변수의 조작적 정의
1. 개발직무특성
개발직무의 잠재적 동기부여 수준(MPS)을 측정하기 위하여 핵심직무특성의
5가지 변수를 사용하였다. 직무특성모형에서 제시된 직무진단조사(JDS: Job
Diagnostic Survey)를 바탕으로 이수화(2006)가 사용한 항목에서 설문
대상자들이 이해할 수 있도록 수정 및 보완하여 각 핵심직무특성 당 4문항씩
모두 20문항을 측정하였다. 측정을 위한 척도는 리커트(likert)의 5점 척도( 1 =
전혀 아니다, 5 = 매우 그렇다)를 사용하였다.
(1) 기술다양성
기술다양성은 개발자가 직무를 수행하는데 필요한 기능과 지식 그리고
기술의 다양한 수준을 의미한다. 아울러 프로젝트 방법론 사용에 따른 업무
프로세스 및 기술의 다양한 요구 수준으로 정의하였다.
(2) 업무정체성
업무정체성은 개발자가 담당하는 업무가 전체에서 차지하는 정도를
의미하는 것으로 수행하는 업무가 전체 작업 중에서 차지하고 있는 범위의
정도를 의미한다.
(3) 업무중요성
52
개발자의 업무가 조직 내부의 다른 구성원이나 조직 전체에 미치는 영향의
정도를 직무에 대한 중요성이라고 정의하였다.
(4) 자율성
업무를 수행할 때 개발자에게 부여된 권한, 책임, 자유, 독립성으로
개발자가 업무 수행 과정에서 자율적으로 결정할 수 있는 재량권의 정도를
의미한다.
(5) 피드백
개발자가 수행한 직무의 결과가 얼마나 효과적으로 적용되었는지를 직접
확인하고 판단할 수 있는 수준을 의미한다.
3. 애자일 실천방법
애자일 개발방법론을 수행하기 위한 구체적 실행방법이다. 본 설문에서는
국내에서 사용되고 있는 애자일 개발방법론인 스크럼과 XP의 실천방법에서
전문가 및 개발자와의 인터뷰를 통해 실제로 개발자들이 사용하는 공통적인
것을 정리하여 14가지의 실천방법을 선택하였다. 14가지 실천방법은 크게
관리와 개발 실천방법으로 구분된다. 애자일 관리 실천방법에는 고객참여,
회고, 정보방열기, 일일 스크럼 미팅, 게임 계획/스프린트 계획, 동일 장소
근무, 짧은 반복 개발주기가 속하며 애자일 개발 실천방법에는 코드 공유,
자동화된 승인테스트, 짝 프로그래밍, 리팩토링, 자동화된 단위테스트, 테스트
53
주도 개발, 지속적 통합이 포함된다. 각각의 애자일 실천방법에 대하여 5점
척도로 프로젝트에서 적용하고 있는 각 실천방법의 수준을 측정하였다.
4. 개발업무성과
개발업무성과는 소프트웨어 개발 프로젝트를 수행하여 얻게 되는
결과물로써 개발생산성, 시스템 품질 수준, 프로젝트 기간 단축 수준을
사용하였다. 개발생산성은 개발자가 업무를 수행하는데 투입된 노력대비
얻는 산출물(코드 량, 업무 효율)의 수준으로 정의하였다. 시스템 품질 수준은
개발된 제품에 대하여 전반적으로 느끼는 품질 수준(안정성, 신뢰성, 정확성,
반응속도)을 의미한다. 프로젝트 기간은 개발자가 제품을 사용자에게
인도까지 걸리는 기간으로 승인된 계획을 기준으로 하여 지연이나 단축과
같은 수준을 측정하였다. 유지보수는 프로젝트 기간 단축 수준에서
제외하였다. 기존의 연구에서 소프트웨어 개발자의 업무성과 측정으로
일정기간 동안 생성하는 소스코드 라인 수나 코드 라인당 오류율, 개발 등이
사용되었다(Cusumano, 1990). 그러나 Cottel(1994)는 이러한 측정지표는
복잡도나 난이도 차이가 심한 프로젝트 특성이나 개발 내용의 혁신성을
반영하지 못하기 때문에 부적절하다고 제기하였다. Rasch & Tosi(1992)는
객관적 측정도구보다는 개발자가 스스로 업무성과 수준을 측정하는 주관적
측정도구가 효과적이라고 제안하였다. 이에 따라 본 연구에서도 개발생산성,
시스템 품질 수준, 프로젝트 기간 단축 수준을 설문자가 이전에 수행하였던
프로젝트와 비교하여 주관적인 기준으로 측정한 결과를 사용하였다.
[표 3] 설문변수의 조작적 정의
변수 조작적 정의 선행 연구
54
개발방법론 유형 스크럼, XP, 스크럼 + XP (복합), 기우일(1995),
구조적/폭포수 개발방법론,
객체지향 개발방법론, 컴포넌트
개발방법론으로 구분
- 측정방법: 위의 개발방법론
중에서 사용하는 개발방법론
하나를 선택
- 업무의 복잡성 및 기술 다양성, Eby &
55
- 동료 혹은 본인이 업무 결과에
대하여 직접적으로 확인하고
피드백
판단하는 수준
- 측정방법: 리커트식 5점 척도
고객참여 Schwaber(2004),
Beck (2000)
정보방열기
동일 장소
근무
- XP와 스크럼 개발방법론의
애자일
회고 관리 실천방법 중에서
관리
짧은 반복 프로젝트에서 사용하고 있는
실천
개발주기 실천방법의 활용 수준을 평가
방법
일일 - 측정방법: 리커트식 5점 척도
스크럼 미팅
계획 게임/
스프린트
계획
자동화된 - XP와 스크럼 개발방법론의
승인테스트 개발 실천방법 중에서
코드 공유 프로젝트에서 사용하고 있는
56
애자일 짝 실천방법의 활용 수준을 평가
개발 프로그래밍 - 측정방법: 리커트식 5점 척도
실천 자동화된
방법 단위테스트
테스트
주도 개발
지속적
통합
리팩토링
57
- 프로젝트 개발 기간은
개발자가 사용자에게 인도 혹은
출시까지 걸리는 기간으로 승인된
프로젝트
계획을 기준으로 하여 지연이나
기간
단축과 같은 수준을 측정
단축 수준
(유지보수는 프로젝트 기간 단축
수준에서 제외)
- 측정방법: 리커트식 5점 척도
58
제 4 절 표본 집단과 설문 구성
59
데이터가 불완전한 5개를 제외하였다. 온라인 상에서는 38개를 회수하여
데이터를 검증한 뒤에 32개를 통계에 사용하였다. 본 연구의 데이터 분석에
사용된 총 설문은 총 77개이다.
[표 4] 설문항목의 구성
사용하는
I-1 선택형 1
개발방법론 개발방법론
사용 기간 I-2 기입형 1
수행한
프로젝트
프로젝트의 I-3 선택형 1
전체기간
전체기간
고객참여 II. 1-14 5점 척도 14
정보방열기
동일 장소 근무
애자일 관리
회고
실천수준
짧은 반복
개발주기
60
일일 스크럼 미팅
계획
게임/스프린트
계획
자동화된
승인테스트
코드 공유
짝 프로그래밍
애자일 개발
자동화된
실천수준
단위테스트
테스트 주도 개발
지속적 통합
리팩토링
기술다양성
업무정체성
핵심직무특성 업무중요성 III. 1-20 5점 척도 20
자율성
피드백
개발생산성
시스템 품질 수준
개발업무성과 IV. 1-3 5점 척도 3
프로젝트 기간
단축 수준
소속 회사 기입형
성별 선택형
인적 정보 V. 1-4 4
연령 기입형
IT 근무 경력 선택형
61
제 4 장 실증 분석
제 1 절 기초통계분석
62
[표 5] 표본의 기술적 특성
항목 빈도 퍼센트(%)
스크럼 + XP 개발방법론
개발 6 8%
(애자일)
방법론
구조적/폭포수 개발방법론 33 43%
객체지향 개발방법론 4 5%
컴포넌트 개발방법론 2 2%
남자 62 81%
성별
여자 15 19%
야후코리아 46 60%
소속 네이버 12 16%
회사 삼성SDS 11 14%
핸디소프트 8 10%
20대 20 26%
연령 30대 55 71%
40대 2 3%
1년 미만 6 8%
IT 1년 이상 ~ 4년 미만 22 29%
근무 4년 이상 ~ 7년 미만 28 36%
경력 7년 이상 ~ 10년 미만 17 22%
10년 이상 4 5%
63
제 2 절 상관관계 분석
변수 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
1. 고객참여 1
.636
2. 정보방열기 **
1
3. 동일 장소
.295 .174 1
근무
4. 회고 .607 .428 .327 1
** ** *
5. 짧은 반복 .512 .458 .035 .505 1
** ** **
개발주기
6. 일일 스크럼 .557 .503 .457 .574 .463 1
** ** ** ** **
미팅
7. 계획 게임/ .724 .553 .317 .685 .565 .719 1
** ** ** ** **
스프린트 계획
8. 자동화된 .086 -.047 .160 .389 .195 .228 .188 1
*
승인테스트
9. 코드 공유 .014 .052 .009 .430 .379 .169 .220 .514 1
** * **
10. 짝 .039 -.027 .229 .389 .208 .263 .170 .267 .537 1
* **
프로그래밍
11. 자동화된 .181 .138 .047 .605 .386 .342 .465 .449 .661 .267 1
** * * ** ** **
단위테스트
12. 테스트 .231 .269 .142 .477 .361 .486 .401 .369 .312 .261 .524 1
** * ** * * **
주도 개발
13. 지속적 .200 .140 .046 .596 .228 .273 .459 .325 .448 .333 .795 .617 1
** ** * ** * ** **
통합
14. 리팩토링 .313 .291 .214 .556 .235 .458 .408 .164 .232 .396 .395 .279 .516 1
** ** * * * **
15. MPS .102 .217 .214 .522 .392 .399 .327 .553 .723 .586 .551 .400 .464 .442 1
** * * * ** ** ** ** * ** **
16. 개발생산성 .150 .370 -.032 .517 .333 .429 .368 .323 .258 .023 .530 .522 .456 .497 .689 1
* ** * ** * * ** ** ** ** **
17. 시스템 .200 .139 .199 .540 .307 .411 .291 .587 .486 .319 .618 .549 .440 .516 .631 .667 1.
** * ** ** ** ** ** ** ** **
품질 수준
18. 프로젝트 .297 .202 .191 .375 .351 .359 .331 .058 .139 .076 .369 .283 .218 .416 .488 .677 .516 1
* * * * * ** ** ** **
기간 단축 수준
64
*p < .05, **p < .01
65
제 3 절 신뢰성 분석
[표 7] 신뢰성 분석 결과
MPS 20 .924
개발업무성과 3 .831
66
제 4 절 타당성 분석
변수 1 2 3 4 5
1 .812
기술다양성 3 .783
4 .781
5 .730
67
업무정체성 6 .898
8 .819
9 .621
10 .775
업무중요성 11 .575
12 .828
13 .835
14 .868
자율성 15 .722
16 .678
17 .792
18 .636
피드백
19 .521
20 .614
68
[표 9] 애자일 관리 실천수준에 대한 탐색적 요인분석
변수 1(관리)
고객참여 26 .857
정보방열기 27 .803
동일장소근무 28 .701
회고 29 .872
짧은 반복 개발주기 30 .855
일일 스크럼 미팅 31 .864
계획 게임/스프린트 계획 32 .553
아이겐값(Eigen value) 4.415
총 누적분산(Cum.Pet) 63.066
69
각각의 애자일 실천방법을 살펴보면, 애자일 관리 실천수준은 총 설명력의
63% 수준이며 애자일 개발 실천수준은 총 설명력의 51%수준으로 나타났다.
70
제 5 절 연구가설의 검증
95% 평균
신뢰구간
표준오차 표준오차 하한
구분 N 평균 편차 오류 상한 최소값 최대값
1 38 61.824 16.634 2.698 56.357 67.291 30.48 116.77
2 33 29.813 17.406 3.030 23.641 35.985 6.89 69.00
3 6 38.857 14.736 6.016 23.392 54.321 17.08 51.56
Total 77 46.315 22.792 2.597 41.142 51.488 6.89 116.77
1. 애자일, 2. 구조적/폭포수, 3. 객체지향/컴포넌트
71
[표 12] 개발직무의 MPS 분산분석 검증 결과
72
[H 2-1]을 검증하기 위하여 개발직무의 MPS를 독립변수로, 개발생산성을
종속변수로 설정하여 회귀분석을 실시하였다. 개발생산성에 영향을 미치는
개발직무의 MPS에 대한 회귀식의 유의성과 회귀식의 결정계수를 [표 13]과
[표 14]에 기술하였다.
R 수정된 추정값의 R 제곱 F
모형 R 제곱 R 제곱 표준오차 변화량 변화량 유의확률
1
.689(a) .475 .468 .674 .475 67.736 .000
표준화된
비표준화 계수 계수
모형 표준
베타 오차 베타 T 유의확률
상수 2.031 .175 11.611 .000
MPS .028 .003 .689 8.230 .000
73
[표 15] 개발직무의 MPS와 시스템 품질 수준 관계에서 회귀식 검증
R 수정된 추정값의 R 제곱 F
모형 R 제곱 R 제곱 표준오차 변화량 변화량 유의확률
1
.631(a) .399 .391 .641 .399 49.708 .000
표준화된
비표준화 계수 계수
모형 표준
베타 오차 베타 T 유의확률
상수 2.167 .166 13.030 .000
MPS .023 .003 .631 7.050 .000
R 수정된 추정값의 R 제곱 F
모형 R 제곱 R 제곱 표준오차 변화량 변화량 유의확률
1
.488(a) .238 .228 .694 .238 23.419 .000
74
설명하며 통계적으로 유의하였다. 개발직무의 MPS에 따라 프로젝트 기간
단축에 긍정적 영향을 미치는 것으로 나타났다. 이에 따라 [H 2-3]이
채택된다.
표준화된
비표준화 계수 계수
모형 표준
베타 오차 베타 T 유의확률
상수 2.074 .180 11.515 .000
MPS .017 .003 .488 4.839 .000
75
객체지향/컴포넌트 개발방법론으로 구분하고 개발직무의 MPS와 개발생산성,
시스템 품질 수준, 프로젝트 기간 단축 수준과의 상관관계분석을 수행하여
[표 19], [표 20], [표 21]에 각각 기술하였다.
개발생산성 .390* 1
MPS 1
개발생산성 .645** 1
76
[표 21] 객체지향/컴포넌트 개발방법론의 MPS와 개발업무성과의
상관관계
변 수 1 2 3 4
MPS 1
개발생산성 .465 1
77
비하여 매우 적어 통계분석에 사용하기에는 다소 무리가 있다고 판단된다.
다만 객체지향/컴포넌트 개발방법론은 컴포넌트의 재사용을 통해 프로젝트
기간 단축에 유의한 영향을 미치는 것으로 추측된다.
상관관계 분석결과를 보면, 구조적/폭포수 개발방법론이 개발직무의 MPS와
개발생산성과 시스템 품질 수준 간에 매우 높은 상관계수를 보였다. 따라서
애자일 개발방법론뿐만 아니라 구조적/폭포수 개발방법론에서도 개발직무의
MPS를 높여주는 것은 개발업무성과에 긍정적 영향을 미칠 것으로 예측할 수
있다.
R 수정된 추정값의 R 제곱 F
모형 R 제곱 R 제곱 표준오차 변화량 변화량 유의확률
1 .390(a) .152 .129 .681 .152 6.463 .015
78
[표 23] 개발직무의 MPS와 개발생산성의 회귀 결정계수 (애자일)
비표준화 계수 표준화된 계수
모형
베타 표준 오차 베타 T 유의확률
상수 2.757 .431 6.402 .000
MPS .017 .007 .390 2.542 .015
R 수정된 추정값의 R 제곱 F
모형 R 제곱 R 제곱 표준오차 변화량 변화량 유의확률
1 .575(a) .331 .312 .536 .331 17.811 .000
비표준화 계수 표준화된 계수
모형
베타 표준 오차 베타 T 유의확률
79
상수 2.143 .339 6.323 .000
MPS .022 .005 .575 4.220 .000
R 수정된 추정값의 R 제곱 F
모형 R 제곱 R 제곱 표준오차 변화량 변화량 유의확률
1 .235(a) .055 .029 .585 .055 2.111 .155
비표준화 계수 표준화된 계수
모형
베타 표준 오차 베타 T 유의확률
상수 2.638 .370 7.131 .000
MPS .008 .006 .235 1.453 .155
80
[H 2-7] 구조적/폭포수 개발방법론을 사용하는 개발자의 MPS는
개발생산성에 긍정적 영향을 미칠 것이다.
R 수정된 추정값의 R 제곱 F
모형 R 제곱 R 제곱 표준오차 변화량 변화량 유의확률
1 .645(a) .417 .398 .673 .417 22.135 .000
비표준화 계수 표준화된 계수
모형
베타 표준 오차 베타 T 유의확률
상수 1.799 .235 7.655 .000
MPS .032 .007 .645 4.705 .000
81
[H 2-8]을 검증하기 위하여 구조적/폭포수 개발방법론을 사용하는
개발자들을 대상으로 개발직무의 MPS를 독립변수로, 시스템 품질 수준을
종속변수로 설정하여 회귀분석을 실시하였다. 시스템 품질 수준에 영향을
미치는 개발직무의 MPS에 대한 회귀식의 유의성과 회귀식의 결정계수를 [표
30]과 [표 31]에 기술하였다.
R 수정된 추정값의 R 제곱 F
모형 R 제곱 R 제곱 표준오차 변화량 변화량 유의확률
1 .623(a) .389 .369 .701 .389 19.696 .000
비표준화 계수 표준화된 계수
모형
베타 표준 오차 베타 T 유의확률
상수 1.876 .245 7.664 .000
MPS .032 .007 .623 4.438 .000
82
수준에 영향을 미치는 개발직무의 MPS에 대한 회귀식의 유의성과 회귀식의
결정계수를 [표 32]과 [표 33]에 기술하였다.
R 수정된 추정값의 R 제곱 F
모형 R 제곱 R 제곱 표준오차 변화량 변화량 유의확률
1 .309(a) .095 .066 .765 .095 3.267 .080
비표준화 계수 표준화된 계수
모형
베타 표준 오차 베타 T 유의확률
상수 2.005 .267 7.505 .000
MPS .014 .008 .309 1.808 .080
83
[표 34] 개발직무의 MPS와 개발생산성의 회귀식 검증 (객체지향/컴포넌트)
R 수정된 추정값의 R 제곱 F
모형 R 제곱 R 제곱 표준오차 변화량 변화량 유의확률
1
.465(a) .216 .020 .511 .216 1.101 .353
비표준화 계수 표준화된 계수
모형
베타 표준 오차 베타 T 유의확률
상수 2.701 .638 4.233 .013
MPS .016 .016 .465 1.049 .353
84
[표 36] 개발직무의 MPS와 시스템 품질 수준의 회귀식 검증
(객체지향/컴포넌트)
R
R 수정된 추정값의 제곱 F
모형 R 제곱 R 제곱 표준오차 변화량 변화량 유의확률
1 .597(a) .356 .195 .491 .356 2.215 .211
표준화된
비표준화 계수 계수
모형
베타 표준 오차 베타 T 유의확률
상수 4.362 .613 7.115 .002
MPS -.022 .015 -.597 -1.488 .211
85
[표 38] 개발직무의 MPS와 프로젝트기간 단축 수준의 회귀식 검증
(객체지향/컴포넌트)
R
R 수정된 추정값의 제곱 F
모형 R 제곱 R 제곱 표준오차 변화량 변화량 유의확률
1
.891(a) .794 .742 .415 .794 15.399 .017
비표준화 계수 표준화된 계수
모형
베타 표준 오차 베타 T 유의확률
상수 1.415 .517 2.736 .052
MPS .049 .013 .891 3.924 .017
86
차이가 있는 것으로 나타났다. 특히 애자일 개발방법론과 구조적/폭포수
개발방법론은 모두 개발직무의 MPS가 개발생산성과 시스템 품질 수준에
유의한 영향을 미치는 것으로 파악되었다. [H 1]의 검증 결과 개발방법론에
따라 개발직무의 MPS에는 유의한 차이가 있는 것으로 나타났다. 이에 따라
개발방법론에 따라 개발업무성과에 유의한 차이가 있는지를 분석하고자
한다.
95% 평균
신뢰구간
표준오차 표준오차 하한
구분 N 평균 편차 오류 상한 최소값 최대값
1 38 3.82 .730 .118 3.58 4.06 3 5
2 33 2.76 .867 .151 2.45 3.07 1 4
3 6 3.33 .516 .211 2.79 3.88 3 4
Total 77 3.32 .924 .105 3.11 3.53 1 5
1.애자일, 2.구조적/폭포수, 3.객체지향/컴포넌트
87
높다고 파악된다. 따라서 구조적/폭포수 개발방법론은 개발직무의 MPS뿐
아니라 개발생산성에서도 가장 낮은 수준으로 나타나는 것을 알 수 있다.
95% 평균
신뢰구간
표준오차 표준오차 하한
구분 N 평균 편차 오류 상한 최소값 최대값
1 38 3.53 .647 .105 3.31 3.74 3 5
2 33 2.82 .882 .154 2.51 3.13 1 5
3 6 3.50 .548 .224 2.93 4.07 3 4
Total 77 3.22 .821 .094 3.03 3.41 1 5
1.애자일, 2.구조적/폭포수, 3.객체지향/컴포넌트
88
따라서 비모수통계방법인 Kruskal-Wallis test를 이용하여 분석하였다.
개발방법론 N 평균 순위
프로젝트 기간 1 38 46.68
단축 수준 2 33 27.89
3 6 51.42
total 77
1. 애자일, 2.구조적/폭포수, 3.객체지향/컴포넌트
프로젝트 기간 단축 수준
카이제곱 17.226
자유도 2
근사 유의확률 .000
89
제 2 편 애자일 실천방법과 개발직무의 MPS와 개발업무성과의 가설검증
R 수정된 추정값의 R 제곱 F
모형 R 제곱 R 제곱 표준오차 변화량 변화량 유의확률
1
.670(a) .449 .321 13.70780 .449 3.497 .007
90
[표 47] 관리 실천수준과 개발직무의 MPS 관계에서 회귀 결정계수
표준화된
비표준화 계수 계수
표준
모형 베타 오차 베타 T 유의확률
상수 18.117 15.938 1.137 .265
고객참여 -9.791 3.914 -.556 -2.502 .018
정보방열기 2.150 3.387 .116 .635 .530
동일장소근무 1.748 3.082 .091 .567 .575
회고 9.465 3.342 .559 2.832 .008
짧은 반복
5.284 3.468 .271 1.524 .138
개발주기
일일 스크럼
2.911 3.330 .188 .874 .389
미팅
계획
게임/스프린트 -.687 4.849 -.036 -.142 .888
계획
R 수정된 추정값의 R 제곱 F
모형 R 제곱 R 제곱 표준오차 변화량 변화량 유의확률
1
.819(a) .671 .594 10.59852 .671 8.734 .000
91
실천수준 중에서 개발직무의 MPS에 유의한 영향을 미치는 요인은 코드
공유로 파악되었다.
표준화된
비표준화 계수 계수
표준
모형 베타 오차 베타 T 유의확률
상수 28.836 6.267 4.601 .000
자동화된
2.747 1.640 .213 1.675 .104
승인테스트
코드 공유 6.318 2.589 .438 2.440 .021
짝 프로그래밍 2.918 2.124 .194 1.374 .180
자동화된
.292 2.875 .023 .102 .920
단위테스트
테스트
1.320 1.870 .097 .705 .486
주도 개발
지속적 통합 -.775 2.685 -.060 -.289 .775
리팩토링 3.595 2.090 .223 1.720 .096
R 수정된 추정값의 R 제곱 F
모형 R 제곱 R 제곱 표준오차 변화량 변화량 유의확률
1
.881(a) .776 .763 8.10682 .776 60.511 .000
92
베타 계수 값을 비교하여 보면 애자일 개발 실천수준의 베타 값이 0.521로
애자일 관리 실천수준의 베타 값인 0.443보다 높게 나타났다. 이는
개발직무의 MPS에 애자일 개발 실천수준이 애자일 관리 실천수준보다
유의한 영향을 미친다는 것을 의미한다.
표준화된
비표준화 계수 계수
모형
베타 표준오차 베타 T 유의확률
상수 -.713 7.425 -.096 .924
애자일 관리
10.679 2.592 .443 4.120 .000
실천수준
애자일 개발
10.918 2.250 .521 4.852 .000
실천수준
R 수정된 추정값의 R 제곱 F
모형 R 제곱 R 제곱 표준오차 변화량 변화량 유의확률
1
.711(a) .505 .390 .570 .505 4.377 .002
93
[표 52]의 회귀계수는 개발생산성의 총 변동의 50.5%를 설명하고 있으며
통계적으로 유의하였다. 애자일 관리 실천수준이 개발생산성에 긍정적
영향을 미치는 것으로 나타났다. 이에 따라 [H 5-1]이 채택된다. 개별 관리
실천수준 중에서 개발생산성에 유의한 영향을 미치는 요인은 고객참여와
회고이다. [표 53]에서 고객참여는 음(-)의 베타 값으로 고객참여 수준이
늘어날수록 개발생산성에는 부정적 영향을 미치는 것으로 파악되었다.
고객과의 의사소통과 피드백이 증가하면 요구사항의 변경이 늘어난다.
따라서 고객참여는 관련 회의 증가와 같은 업무 이외의 활동이 증가하여
개발생산성에 부정적인 효과가 있는 것으로 보인다.
표준화된
비표준화 계수 계수
표준
모형 베타 오차 베타 T 유의확률
상수 2.700 .663 4.074 .000
고객참여 -.410 .163 -.530 -2.517 .017
정보방열기 .264 .141 .326 1.873 .071
동일장소근무 -.240 .128 -.284 -1.874 .071
회고 .434 .139 .585 3.125 .004
짧은 반복
.003 .144 .003 .019 .985
개발주기
일일 스크럼
.234 .139 .345 1.691 .101
미팅
계획
게임/스프린트 .009 .202 .011 .046 .964
계획
94
[H 5-2] 애자일 관리 실천수준이 시스템 품질 수준에 긍정적 영향을 미칠
것이다.
R 수정된 추정값의 R 제곱 F
모형 R 제곱 R 제곱 표준오차 변화량 변화량 유의확률
1
.616(a) .380 .235 .566 .380 2.622 .031
표준화된
비표준화 계수 계수
표준
모형 베타 오차 베타 T 유의확률
상수 2.340 .658 3.557 .001
고객참여 -.114 .162 -.167 -.708 .484
정보방열기 -.067 .140 -.093 -.480 .634
동일장소근무 -.009 .127 -.011 -.067 .947
회고 .400 .138 .608 2.903 .007
짧은 반복
.090 .143 .118 .627 .536
개발주기
95
일일 스크럼 미팅 .204 .137 .340 1.487 .148
계획
-.194 .200 -.261 -.970 .340
게임/스프린트계획
R 수정된 추정값의 R 제곱 F
모형 R 제곱 R 제곱 표준오차 변화량 변화량 유의확률
1
.448(a) .201 .014 .590 .201 1.076 .403
96
[표 57] 관리 실천수준과 프로젝트 기간 단축 수준 관계에서 회귀 결정계수
표준화된
비표준화 계수 계수
표준
모형 베타 오차 베타 T 유의확률
상수 1.782 .686 2.599 .014
고객참여 .027 .168 .044 .163 .872
정보방열기 -.048 .146 -.072 -.327 .746
동일장소근무 .041 .133 .059 .307 .761
회고 .115 .144 .190 .801 .430
짧은 반복 개발주기 .150 .149 .215 1.004 .324
일일 스크럼 미팅 .098 .143 .177 .681 .501
계획게임/스프린트계획 -.040 .209 -.058 -.192 .849
R 수정된 추정값의 R 제곱 F
모형 R 제곱 R 제곱 표준오차 변화량 변화량 유의확률
1
.743(a) .552 .447 .543 .552 5.271 .001
97
개발과 리팩토링이다. 따라서 개발생산성을 높이기 위해서는 테스트 주도
개발과 리팩토링 실천수준을 높이는 것이 필요하다고 판단된다.
표준화된
비표준화 계수 계수
표준
모형 베타 오차 베타 T 유의확률
상수 2.285 .321 7.118 .000
자동화된
.051 .084 .091 .611 .546
승인테스트
코드 공유 .010 .133 .015 .073 .942
짝 프로그래밍 -.208 .109 -.315 -1.908 .066
자동화된
.213 .147 .381 1.449 .158
단위테스트
테스트 주도
.238 .096 .400 2.488 .019
개발
지속적 통합 .156 .137 .274 1.132 .267
리팩토링 .341 .107 .482 3.189 .003
R 수정된 추정값의 R 제곱 F
모형 R 제곱 R 제곱 표준오차 변화량 변화량 유의확률
1
.839(a) .703 .634 .391 .703 10.151 .000
98
있으며 통계적으로 유의하였다. 애자일 관리 실천수준이 시스템 품질 수준에
긍정적 영향을 미치는 것으로 나타났다. 이에 따라 [H 6-2]가 채택된다. 개별
개발 실천수준 중에서 시스템 품질 수준에 유의한 영향을 미치는 요인은
자동화된 승인테스트, 자동화된 단위테스트, 테스트 주도 개발, 지속적 통합,
리팩토링이다. 자동화된 승인테스트와 자동화된 단위테스트, 테스트 주도
개발은 테스트 관련 활동으로 애자일 프로젝트에서는 테스트 주도 개발로
프로그램을 개발한다. 따라서 지속적인 리팩토링과 단위 및 승인 테스트의
자동화를 통하여 오류를 즉시 발견하여 제거함으로써 시스템 품질 수준을
향상시킬 수 있다.
표준화된
비표준화 계수 계수
표준
모형 베타 오차 베타 T 유의확률
상수 1.927 .231 8.326 .000
자동화된
.159 .061 .316 2.619 .014
승인테스트
코드 공유 -.017 .096 -.029 -.173 .864
짝 프로그래밍 .013 .078 .022 .161 .874
자동화된
.284 .106 .573 2.678 .012
단위테스트
테스트 주도
.189 .069 .357 2.730 .010
개발
지속적 통합 .276 .099 .549 2.788 .009
리팩토링 .263 .077 .420 3.411 .002
99
회귀식의 유의성과 회귀식의 결정계수를 [표 62]과 [표 63]에 기술하였다.
R 수정된 추정값의 R 제곱 F
모형 R 제곱 R 제곱 표준오차 변화량 변화량 유의확률
1
.605(a) .366 .218 .525 .366 2.475 .039
표준화된
비표준화 계수 계수
표준
모형 베타 오차 베타 T 유의확률
상수 2.173 .311 6.998 .000
자동화된
-.071 .081 -.154 -.870 .391
승인테스트
코드 공유 -.078 .128 -.151 -.606 .549
짝 프로그래밍 -.020 .105 -.037 -.189 .852
자동화된
.333 .142 .731 2.338 .026
단위테스트
테스트 주도
.137 .093 .283 1.480 .149
개발
지속적 통합 .297 .133 .642 2.232 .033
리팩토링 .261 .104 .454 2.523 .017
100
[표 64]는 본 연구의 가설 검증 결과를 정리하여 기술하였다. 가설 2-6, 2-9,
2-10, 2-11, 5-3은 기각되었으며 나머지 가설들은 모두 채택되었다. 가설 H 1과
H 2는 개발방법론이 개발직무의 MPS에 미치는 영향과 개발업무성과에
유의한 차이가 있는가에 대한 결과이며 가설 H 3에서 H 6은 애자일
실천수준이 개발직무의 MPS와 개발업무성과에 미치는 영향을 검증한
결과이다.
[표 64] 연구 가설검증의 결과 요약
가설기호 가 설 내 용 결과
개발방법론에 따라 개발직무의 MPS에는 차이가 있을
H1 채택
것이다.
개발직무의 MPS는 업무성과에 긍정적 영향을 미칠 일부
H2
것이다. 기각
101
구조적/ 폭포수 개발방법론에서 개발직무의 MPS는 시스템
H2-8 채택
품질 수준에 긍정적 영향을 미칠 것이다.
구조적/ 폭포수 개발방법론에서 개발직무의 MPS는
H2-9 기각
프로젝트 기간 단축 수준에 긍정적 영향을 미칠 것이다.
객체지향/컴포넌트 개발방법론에서 개발직무의 MPS는
H2-10 기각
개발생산성에 긍정적 영향을 미칠 것이다.
102
영향을 미칠 것이다.
103
제 6 절 구조방정식 연구모형
104
코드공유 <- 개발
1.202 .649** 2.677 .449
짝프로그래밍 <- 개발
.713 .401* 1.984 .359
자동화된단위테스트 <- 개발
1.885 .902** 3.057 .617
테스트주도개발 <- 개발
1.244 .633** 2.642 .471
지속적통합 <- 개발
1.777 .863** 3.021 .588
리팩토링 <- 개발
.839 .507* 2.327 .360
*p < .05, **p < .01, ***p < .001
105
[표 66] 확인적 요인분석의 부합지수
106
구조방정식의 연구모형을 검증하기 위해서는 구조모델의 수용도와 적합도를
확인 해야 한다. 구조방정식 연구모형의 검정에는 카이 제곱 검정을
사용하며 x² 값이 작을수록 모형이 수집된 자료에 적합하다고 본다.
노형진(2002)에 따르면 검정이란 연구모델로의 올바르지 않음을 판단해주는
위험성을 확률적으로 나타내는 것이다. 따라서 연구모델을 판별할 경우 카이
제곱 검정뿐 아니라 몇 가지 다른 복합지수를 고려해야 한다고 제시하였다.
107
연구모형의 수정은 수정지수(modification indices)를 이용한다. 수정지수란
공분산경로를 연결하는 것으로 하나의 경로계수를 증가시켜 자유도와 카이
제곱 값을 감소시킨다. 일반적으로 AMOS 7.0에서는 수정지수의 한계값을
‘4’로 설정하고 있다. 따라서 ‘4’이상의 값을 보이는 오차항들을 연결하여
공분산을 자유롭게 만들고 모델의 적합도를 높인다(김계수, 2004; 홍세희,
2000). 따라서 본 연구 모형에서도 오차항 간의 수정지수가 ‘4’를 초과하는
것들을 대상으로 높은 상관관계와 내용간의 연관성을 고려하여 오차항을
연결하였다. 그 결과 코드 공유와 지속적 통합, 짝 프로그래밍과 자동화된
단위테스트, 자동화된 단위테스트와 지속적 통합, 그리고 개발생산성과
시스템 품질 수준, 시스템 품질 수준과 프로젝트 기간 단축 수준,
개발생산성과 프로젝트 기간 단축 수준의 오차항을 연결하였다. [그림 18]은
설정된 수정모형을 제시하였다.
[표 67]에 따르면 x²(카이 제곱 값): 158.840, df(자유도): 120, x²/df = 1.324라는
비교적 높은 적합도를 보이며 그 밖의 적합도 지수는 GFI: 0.740, AGFI: 0.630,
RMR: 0.388로 일반적인 적합도 기준치보다 낮게 나타났다. 그러나 최근
구조방정식 모형의 적합도를 판별하는 기준으로 강력하게 추천 받고 있는
지수인 CFI와 RMSEA를 살펴보면(홍세희, 2000), CFI: 0.890과 RMSEA:
0.94으로 나타난다. 일반적으로 RMSEA가 0.10이상이면 적합도가 나쁘다고
판단하는데 수정된 연구 모형은 RMSEA가 0.10이하로 나타났다. 따라서 일부
적합도의 지수가 기준치보다 낮게 나타났더라도 본 구조모형의 적합도가
분석에 있어서 무리가 없을 것으로 판단한다.
108
[표 67] 구조방정식 연구모형의 적합도 지수
절대부합지수(Absolute Fit
Measures) 2~3이하 1.868 1.324
- x²/ df(카이 자승 통계량) 0.05이상 .000 .010
-카이 자승검정의 유의확률(P) 0.9 이상 .599 .740
-기초부합지수(GFI) 0 근사치 1.366 .388
-원소간 평균차이(RMR) 0.1 이하 .153 .094
-모집단 원소간 평균차이(RMSEA)
증분부합지수(Incremental Fit
Measures) 0.9 이상 .671 .890
-비교부합지수(CFI)
간명부합지수(Parsimonious Fit
Measures) 0.9 이상 .489 .630
-조정부합지수(AGFI)
109
[그림 17] 구조방정식 연구모형
110
[그림 18] 수정된 구조방정식 연구모형
111
[표 68] 수정된 구조방정식 연구모형의 경로계수와 t 검정치 및 표준오차
자동화된단위테스트 <- 개발
1.537 .832*** 3.373 .456
테스트주도개발 <- 개발
.993 .575** 2.754 .361
지속적통합 <- 개발
1.405 .756** 3.178 .442
리팩토링 <- 개발
.800 .543** 2.643 .303
MPS <- 관리
1.913 .087 .669 2.857
MPS <- 개발
16.707 .702** 2.981 5.604
업무성과 <- MPS
.018 1.000** 2.829 .006
112
시스템 품질 수준 <- 업무성과
1.247 .576** 2.943 .424
프로젝트 기간 단축수준<- 업무성과
.468 .236 1.724 .272
*p < .05, **p < .01, ***p < .001
113
판단된다. 그러나 이와 같은 결과는 제 5절의 가설 H 3 검증 결과와 차이가
있다. 가설 H 3의 경우 애자일 관리 실천수준이 개발직무의 MPS에 유의한
영향을 미치는 것으로 검증되었기 때문이다. 애자일 개발방법론에 대한
구조방정식 연구모형은 관리와 개발 실천수준이라는 잠재변수에 대하여
14가지의 애자일 실천수준을 관측변수로 사용하였다. 반면 가설 H 3에서는
개발과 관리 실천수준으로 나누어 개발직무의 MPS와의 관계만을 파악한
결과이다. 따라서 이러한 차이가 발생한 것으로 파악된다. 구조방정식
연구모형에서도 애자일 개발 실천수준이 개발직무의 MPS에 영향을 미치는
요인으로 확인되어 개발직무의 MPS를 높이기 위해서는 개발 실천수준을
향상시키는 것이 바람직하다고 할 수 있다. 이는 개발 실천방법이
개발직무의 MPS에 직접적인 관련이 있기 때문으로 판단되며 개발자들은
개발 실천방법을 수행하는 경우 직무의 동기부여가 높아지는 것으로
파악된다.
114
개발 실천수준보다 높다는 것을 알 수 있다. 이는 관리 실천방법이 개발
실천방법보다는 수행하기 용이하기 때문으로 파악된다. 실제로 관리 위주의
스크럼 개발방법론은 적용하기 쉬운 애자일 개발방법론으로 최근 들어 XP
개발방법론보다 빠르게 확산되고 있기도 하다.
애자일 관리 실천방법에서는 정보방열기가 높은 실천수준을 나타냈으며
계획 게임/스프린트 계획과 일일 스크럼 미팅이 낮은 실천수준을 보여주었다.
정보방열기는 개발 진척 사항을 관리하고 정보를 공유하는데 사용되며
포스트 잇(post-it)과 같은 메모지에서 자동화된 도구까지 다양한 방식으로
적용하고 있었다. 반면에 계획 게임/스프린트 계획은 팀에서 요구사항의
우선순위를 결정하고 작업을 산정하는데 익숙해지기까지 시행착오와 많은
시간이 요구된다. 또한 일일 스크럼 미팅은 매일 같은 시간에 모든 팀원이
참석하는 것이 어려운 것으로 알려져 있다. 이러한 어려운 점들은 계획
게임/스프린트 계획과 일일 스크럼 미팅의 실행수준이 낮아지는 원인으로
보인다.
115
것을 의미한다. 따라서 애자일 개발 실천방법을 사용하는 것이 개발직무의
MPS를 향상시키는데 중요하다는 것을 알 수 있다.
116
제 5 장 결 론
제 1 절 연구의 시사점
117
개발방법론보다 피드백에서 높은 결과를 보였다.
118
수준에서의 향상을 기대할 수 있다.
119
개발방법론이 XP 개발방법론보다 적용하기 쉽다는 점과도 관련이 있다고
판단된다.
애자일 관리 실천방법에서는 정보방열기가 가장 높은 실천수준을 보였으며
계획 게임/스프린트 계획 수립과 일일 스크럼 미팅은 가장 낮은 실천수준을
나타내었다. 애자일 개발 실천방법에서는 리팩토링이 가장 높은 실천수준을
보였으며 코드 공유가 가장 낮은 실천수준을 보여주었다. 실행 수준이 낮은
애자일 실천방법은 실행 수준이 높은 애자일 실천방법보다 시간과 실행
노력을 많이 투자할 필요가 있다.
120
증가는 요구사항의 변경과 업무 외적 활동을 증가시켜 개발생산성을
떨어뜨리기 때문으로 판단된다. 시스템 품질 수준에서는 회고, 자동화된
승인테스트, 자동화된 단위테스트, 테스트 주도 개발, 지속적 통합,
리팩토링이 유의한 것으로 나타났다. 또한 프로젝트 기간 단축에서는
자동화된 단위테스트, 지속적 통합, 리팩토링이 유의한 요인으로 파악되었다.
애자일 개발 프로젝트에서는 개발업무성과 향상에 유의한 영향을 미치는
애자일 실천방법을 강화하는 것이 효과적이라 할 수 있다.
121
제 2 절 연구의 요약
122
반면, 객체지향/컴포넌트 개발방법론의 경우, 개발직무의 MPS와 프로젝트
기간 단축 수준에는 강한 상관 관계가 있었으나 개발생산성과 시스템 품질
수준에는 유의한 상관 관계가 존재하지 않았다.
123
MPS를 향상시키는데 유의한 것으로 파악되었다. 이는 개발 실천방법이
개발직무의 MPS를 결정하는 개발직무특성에 직접적으로 관련이 있기
때문으로 파악된다.
124
제 3 절 연구의 한계점 및 향후 연구 방향
125
<참 고 문 헌>
<국내문헌>
<국외문헌>
Ambler, Scott W., “Dr Dobb’s 2007 Agile Adoption Survey”,
www.amsbysoft.com/surveys, 2007.
Anselmo, Donald and Ledgard, Henry, “Measuring Productivity in the Software
Industry”, Communications of the ACM, Vol. 46, No. 11, 2003, pp. 121-125.
Awad, M.A. “A Comparison between Agile and Traditional Software Development
Methodologies”, University of Western Australia, 2005.
Baddoo, Nathan, Hall, Tracy and Jagielska, Dorota, “Software Developer Motivation in
a High Maturity Company: A Case Study”, Software Process: Improvement and Practice,
Vol. 11, No. 3, 2006, pp. 219-228.
126
Beck, Kent and Andres Cynthia., Extreme Programming Explained, Addison-Wesley,
2000.
Beecham, Sarah, Sharp, Helen, Baddoo, Nathan, Hall, Tracy, and Robinson, Hugh,
“Does the XP Environment Meet the Motivational Needs of the Software Developer? An
Empirical Study”, AGILE 2007, pp. 37-49.
Brenda L. Mak and Hy Sockel, “A Confirmatory Factor Analysis of IS Employee
Motivation and Retention”, Information and Management 38, 2001, pp. 256-276.
Carmel, E., “Time to completion factors in packaged software development”,
Information and software technology, Vol. 27, No. 9, 1995, pp. 515-520.
Coad, P., Lefebvre, E. and De Luca, J., Java Modeling in Color with UML : Enterprise
Components and Process, Prentice Hall, 2000.
Cockburn, Alistir and Jim Highsmith, “Agile Software Development : The People
Factor”, IEEE Software Vol. 34, No. 11, 2001, pp. 131-133.
Cohn, Mike and Ford, Doris, “Introducing an Agile Process to an Organization”, IEEE
Computer, 2003.
Curtis, B., “Substantiating Programmer Variability”, Proc IEEE 69, 846, 1981.
Cusumano, M. A. and C. F. Kermerer, “A Quantitative Analysis of US and Japanese
Practice and Performance in Software Development, Management Science”, Vol. 36, No.
11, 1990, pp. 1384-1406.
David P. Darcy and Meng Ma, “Exploring Individual Characteristics and Programming
Performance: Implications for Programmer Selection”, IEEE International Conference
on System Sciences, pp. 314-314, 2005.
Demarco Tom and Lister Timothy, “Peopleware: Productive Projects and Teams”,
Dorset House, 1999.
Deemer, Pete and Benefield, Gabrielle, “The Scrum Primer: An Introduction to Agile
Project Management with Scrum”, Good Agile, Scrum training in India and Asia,
www.goodagile.com, 2007.
Eby, L.T. and Freeman, D.M., “Motivational Bases of Affective Organizational
Commitment: A Partial Test of an Integrative Theoretical Model”, Journal of
Occupational and Organizational Psychology, Vol. 72, 1999, pp. 463-483.
Ewen, R.B, “Some determinants of Job Satisfaction : A Study of the Generality of
Herzberg’s Theory”, Journal of Applied Psychology, 59, 1974, pp. 145-15.
Erdogmus, H., and Williams, L., “The Economics of Software Development by Pair
Programmers”, The Engineering Economist, Vol. 48, No. 4, 2003, pp. 283-319.
Fried, Y and Ferris, G., “The Critical Psychological States: An Under-represented
Component in Job Characteristics Model Research”, Journal of Management, Vol. 21,
1987, pp. 279-303.
Gilb, T., “Software Project Management : Adding Stakeholder Metrics to Agile
Projects”, The Journal of Information Technology Management, Vo1. 17, No. 7, 2004,
127
pp. 31-35.
Grenning, J., “Launching XP at a Process-Intensive Company”, IEEE Software 18, 2001,
pp. 3-9.
Hackman, J.R. and Oldham, G.R., “Development of the Job Diagnostic Survey”, Journal
of Applied Psychology, Vol. 60, No. 2, 1975, pp. 159-170.
Hackman, J.R. and Oldham, G.R., “Motivation through the Design of Work: Test of a
Theory”, Organizational Behavior and Human Performance, Vol. 16, 1976, pp. 250-279.
Hackman, J.R. and Oldham, G.R., Work Redesign, New York: Addison-Wesley, 1980.
Hall T, Wilson D., “Views of Software Quality : A Field Report”, IEEE Proceedings-
Software, Vol. 144, No. 2 , 1997, pp. 111-118.
House, R.J. and Wigdor, L.W., “Herzberg’s Dual-factor Theory of Job Satisfaction and
Motivation : A Review of the Evidence and a Critic”, Personnel Psychology, Vol. 20,
No. 4, 1967, pp. 369-389.
H.Kym, and W.Park, “Effect of Cultural Fit/Misfit on the Productivity and Turnover of
is Personnel”, Proceedings of the 1992 ACM SIGCPR conference on Computer
personnel research, pp. 184-190, 1992.
Ilieva, S., Ivanov, P., Stefanova, E., “Analyses of an Agile Methodology
Implementation”, Proceedings 30th Euromicro Conference IEEE Computer Society Press,
2004, pp. 326-333.
Jason B, Yongmei Liu, Lee P., Joseph M., Darren C., “IT Worker Turnover : An
Empirical Examination of Intrinsic Motivation”, The Data Base for Advances in
Information Systems-Spring-Summer 2006.
J.Drew Procaccino, June M. Verner, Katherine M. Shelfer, David Gefen, “What do
Software Practitioners Really Think about Project Success: an Exploratory Study”,
Journal of systems and software, Vol. 78, No. 2, pp. 194-203, 2005.
Law, Amy and Charron, Raylene, “Effects of Agile Practices on Social Factors”,
Proceedings of the 2005 workshop on Human and social factors of software engineering,
2005, pp. 1-5.
L.E. Blankertz, S.E. Robinson, “Who is Psychosocial Rehabilitation Worker?”,
Psychiatric Rehabilitation Journal, Vol. 19, No. 4, 1996, pp. 3-13.
Linberg, K.R., “Software Developer Perceptions about Software Project Failure : A Case
Study”, The journal of Systems and Software 49, Vol. 49, No. 2-3, 1999, pp. 177-192.
Mann, Chris and Maurer, Frank, “A Case Study on the Impact of Scrum on Overtime
and Customer Satisfaction”, Proceedings of the Agile Development Conference, 2005,
pp. 70-79.
Mannaro, Katiuscia, Melis, Marco and Marchesi, Michele, “Empirical Analysis on the
Satisfaction of IT Employees Comparing XP Practices with Other Software
Development Methodologies”, Lecture Notes in Computer Science, Springer Berlin /
Heidelberg, 2004, pp. 166-174.
128
Marçal, Ana, Freitas, Bruno, Soares, Felipe, Furtado, Maria, Maciel, Teresa and Belchoir,
Arnaldo “Blending Scrum Practices and CMMI Project Management Process Areas”,
Innovations in Systems and Software Engineering, Vol 4, No. 1, 2008.
Martin, R.C., The Process. Object Oriented Analysis and Design with Applications,
Addison Wesley, 1998, pp. 93-108.
Maurer, F. and Martel, S., “Extreme Programming: Rapid development for Web-based
Applications”, Internet Computing, Vol. 6, No. 1, 2002, pp. 86-90.
McDermit JA, Bennett KH, “Software Engineering Research : A Critical Appraisal”,
IEEE Process on Software Engineering Vol. 146, No. 4, 1999, pp. 179-186.
Melnik, G. and Maurer, F., “Comparative Analysis of Job Satisfaction in Agile and
Non-Agile Software Development Teams”, XP 2006, LNCS 4044, 2006, pp. 32-42.
Muller, M. M. and Padberg, F., “Extreme programming from an engineering Economics
Viewpoint”, International Workshop on Economics-Driven Software Engineering
Research(EDSER), Orlando, Florida, USA, 2002.
Oldham, Greg R. Kulik, Carol T. Stepina, Lee P, “Strategies for Intrafirm Transfers and
Outside”, Sourcing Academy of Management Journal, Vol. 28, No. 4, 1985.
Palmer, S. R. and Felsing, J.M., A Practical Guide to Feature-Driven Development,
Upper Saddle River, NJ, Prentice-Hall, 2002.
Rasch, R.H. and H. L. Tosi, “Factors Affecting Software Developers’ Performance An
Integrated Approach”, MIS Quarterly, 1992, pp. 395-413.
David F. Rico, “Agile Methods and Links to Customer Satisfaction and Firm
Performance”, 2006.
Rising, Linda and Janoff, Norman S., “The Scrum Software Development Process for
Small Teams”, IEEE Software, Vol. 17, No. 4, 2000, pp. 26-32.
Sasa, M.D., “The Influence of the Information Systems Development Approach on
Maintenance”, MIS Quarterly, 1992.
Schuh, P., “Recovery, Redemption, and Extreme Programming”, IEEE Software, Vol.
18, No. 6, 2001, pp. 34-41.
Schwaber, Ken, “SCRUM Development Process”, Proceeding of the 10th Annual ACM
Conference on OOPSLA, 1995.
Schwaber, Ken, “Controlled Chaos: Living on the Edge”, American Programmer, 1996.
Schwaber, Ken, Agile Project Management with Scrum, Microsoft Press, 2004.
Schwaber, Carey, and Fichera, Richard, “Enterprise Agile Adaption in 2007”, Forrester
Research (http://www.forrester.com/Research/Workbook/0,9126,45015,00.html), 2008.
Schwaber, Ken, Beedle, Mike and Martin, Robert, Agile Software Development with
SCRUM, Prentice Hall, 2001.
Siakas, Kerstin V. and Siakas, Errikos, “The Human Factor Deployment for Improved
Agile Quality”, European Software Process Improvement and Innovation(EuroSPI 2006),
129
International Proceedings Series 6, 11-13 October, Joensuu, Finland, 2006, pp. 4.11-23.
Succi, Giancarlo, Pedrycz, Witold, Marchesi, Michele and Williams, Laurie,
“Preliminary Analysis of the Effects of Pair Programming on Job Satisfaction”, Fourth
International Conference on Extreme Programming and Agile Processes in Software
Engineering, Genova, Italy, 2002.
Subramaniam and Hunt, Practices of an Agile Developer: Working in the Real World
(Pragmatic Programmers), Oreilly and Associates Inc, 2005.
Takeuchi H. and Nonaka I., “The New Product Development Game”, Harvard Business
Review, 1986.
The Standish Group International, Chaos Report 2007: The 10 Laws of Chaos, 2007
Weinberg, M, Gerald, The Psychology of Computer Programming, Dorset House, 1998
Wilson D, Hall T, “Perception of Software Quality : A Pilot Study”, Software Quality
Journal Vol. 7, No. 1, 1998, pp. 67-75.
Wilson D, Hall T, Baddoo N, “The Software Process Improvement Paradox”,
Approaches to Quality Management : Software Quality Management VIII, 2000, pp.
97-101.
Yan Li, Chuan-Hoo Tan, Hock-Hai Teo, A.Talib Matter, “Motivating Open Source
Software Developers : Influence of Transformational and Transactional Leaderships”,
SIGMIS-CPR, 2006.
130
부록 (설문지)
ID
담당자: 황순삼
131
132
133
134
135
136
137
138
139
국 문 초 록
중앙대학교 대학원
경영학과 경영정보시스템전공
황 순 삼
140
2배 이상 높은 차이를 보였다.
둘째, 개발직무의 잠재적 동기지수(MPS)와 개발업무성과와의 관계이다.
개발직무의 MPS가 높아질수록 개발업무성과인 개발생산성, 시스템 품질
수준, 프로젝트 기간 단축에 긍정적인 영향을 미치는 것으로 나타났다. 또한
애자일 개발방법론을 사용하는 개발자의 MPS는 개발생산성과 시스템 품질
수준에는 유의한 영향을 미치는 반면 프로젝트 기간 단축 수준에는 유의한
영향을 미치지 못하는 것으로 나타났다.
셋째, 개발방법론에 따라 개발업무성과에 미치는 영향이다. 애자일
개발방법론은 개발생산성, 시스템 품질 수준, 프로젝트 개발 기간 단축에서
다른 개발방법론에 비하여 유의하게 높은 차이를 보여주었다.
넷째, 애자일 실천수준이 개발직무의 잠재적 동기지수(MPS)에 미치는
영향이다. 애자일 실천수준은 애자일 실천방법을 프로젝트에서 수행하는
수준을 의미하며, 애자일 실천방법은 실행목적과 성격에 따라 개발과 점검을
위주로 하는 개발 실천방법과 프로젝트 관리와 수행을 위주로 하는 관리
실천방법으로 구분할 수 있다. 애자일 개발 실천수준과 관리 실천수준은
모두 개발직무의 MPS에 긍정적인 영향을 주는 것으로 파악되며, 개발
실천수준은 관리 실천수준보다 개발직무의 MPS에 보다 많은 영향을 주는
것으로 나타났다.
다섯째, 애자일 실천수준이 개발업무성과에 미치는 관계이다. 동일한 애자일
개발방법론을 적용하더라도 애자일 실천수준에 따라 개발업무성과에는
차이가 있을 수 있다. 애자일 관리 실천수준은 개발생산성, 시스템 품질
수준에 유의한 영향을 미치는 반면 프로젝트 기간 단축 수준에는 유의한
영향이 없는 것으로 나타났으며, 애자일 개발 실천수준은 개발생산성과
시스템 품질 수준, 프로젝트 기간 단축 수준에서 유의한 영향을 미치는
것으로 파악되었다.
141
ABSTRACT
Hwang Soon-Sam
Major in Management of Information System
Dept of Business Administration
The graduate school Chung-ang University
This study is the influence on development job characteristics and work performance
by Agile methodology. For the empirical analyzing, research data were collected by 77
developers of domestic web portal enterprises - Yahoo Korea, Naver, Samsung SDS,
Handysoft using online and offline.
The aims of this study are the comparison between the existing methodologies and
Agile methodology and look into the influence of Motivating Potential Score(MPS) of
job and work performance – development productivity, system quality, project duration
and analysis the relation among the usage level of Agile practices and development job
characteristic, work performance. In order to examine the descriptive statistics,
correlation with variable and model of study, the statistical package SPSS V.15.0 was
used. And AMOS V.7.0 was used for analyzing a structural equation model explaining
that the influence on MPS of job and work performance by Agile practices.
142
significant impact on development productivity, system quality but it does not have any
significant influence on project duration.
Third, it is about the influence on work performance by development methodology.
Agile methodology shows a significant difference to be high comparing with other
development methodologies in development productivity, system quality, project
duration.
Fourth, it is about the influence on MPS of job by the usage level of Agile practices.
The usage level of Agile practices represent a level to carry out Agile practices at
projects, Agile practices can classify in development practices to focus on development
and check, management practices to focus on management and accomplishment of
project according to objective execution and character. Both of Agile development and
management practices have a significant impact on MPS of job, development practices
have more impact on MPS of job than management practices.
Fifth, it is about the relation with the usage level of Agile practices and work
performance. There can be a difference to work performance according to the usage
level of Agile practice even if applying the same Agile methodology. Agile management
practices have a significant impact on development productivity, system quality but it
does not have any significant influence on project duration. And Agile development
practices have a significant impact on development productivity, system quality, project
duration.
143
<감사의 글>
144