애자일 초보자를 위한 교재 스크럼 실습 포함 스마트앱창작터 창업팀 멘토링 용

1. 모바일 앱 개발을 위한 Agile Adoption
김형채 (chaeya@gmail.com)
http://yes.imhappyo.com

2. 목차
1. 개요
2. SW개발방법론
3. Agile
4. SCRUM
5. 회고

3. 3
소개
•
•
•
•
•
•
아비도스 스크럼마스터
15년간 100여개의 SW개발 프로젝트 수행(개발, PM)
SW 테스트 전문가(TTA)
한중일 공개SW활성화포럼 표준화분과 한국위원
한국정보통신기술협회(TTA) 공개SW 표준화 분과위원
정보통신산업진흥원 SW공학센터 자문위원
• blog : http://yes.imhappyo.com
• Facebook : http://fb.com/hyeongchae
“저는 오픈소스SW기술과 SW개발방법론을 이용하여 기업의 비즈니스 전략
과 잘 연계하는 성장모델에 관심이 많습니다.”

4. 4
SW 공학의 탄생
1960년대에도 소프트웨어 개발은 미 국방부와 새로운 컴퓨터의 출현으로 가속화되었다.
그러나 그때까지는 코딩을 하고, 요구조건을 이해하고, 성공적으로 프로젝트를 완성시키
는 것 사이에 명확한 구분이 없었다. 그 당시의 시스템은 일반적으로 단순했으며 일괄처리
중심(batch-based)이었다.
불행히도 명확한 시스템의 제약사항 없이 작동하게만 만들자라는 철학은 프로젝트 실패
로 귀결된다. 1968년 NATO 회의에서 소프트웨어의 위기를 타개해야 한다는 의견이 나
왔고 처음으로 소프트웨어 공학이라는 용어가 사용되었다.
소프트웨어 공학(SE, Software Engineering)은 소프트웨어의 위기를 극복하기 위한 방
안으로 연구된 학문이며 여러 가지 방법론과 도구, 관리 기법들을 통하여 소프트웨어의 품
질과 생산성 향상을 목적으로 한다.

5. 5
SW 공학은 누가 배워야 하나?
숙련된 프로그래머
스스로 학습하거나 정규 교육을 통해서 뛰어난 소프트웨어를 배운 계층을 가리킨다.
기술 전문가
초보 프로그래머를 가르치고 있거나 기술적 자문을 하고 있다. 소프트웨어 공학을 가르치
고 있다.
독학으로 배운 프로그래머
자신이 정규교육을 받지 않았다고 해서 프로그래머가 되지 못하는 것은 아니다. 예를 들면,
회계사, 공학자, 교사, 과학자 등과 같은 전문가 그룹에서 발견되곤 한다. 얼마나 정규교육
을 받았는지에 상관없이 효율적인 프로그래밍의 통찰력을 제공한다.
학생
정규교육을 거의 받지 않았지만 실무 경험이 있는 프로그래머와 반대되는 사람이 이제 갓
전문고등교육을 이수한 학생일 것이다. 갓 전문고등교육을 이수한 학생은 이론에는 강하
지만 제품을 개발하는데 실무가 부족하다. 훌륭한 코드를 작성하기 위한 실용적인 지식은
종종 소프트웨어 설계자와 프로젝트 전문가, 분석가, 경험 많은 프로그래머의 행동으로부
터 천천히 전수된다
출처: Code Complete 개정판 중에서

6. 6
방법론에 대한 이해
•
•
•
•
방법론이란 어떤 일에 도움을 주는 일련의 절차, 기법, 원리, 도구들을 의미.
프로젝트관리와 소프트웨어 개발 방법론과의 관계는 영업과 마케팅과의 관계와 매우
흡사.
소프트웨어 개발 방법론은 마케팅과 같이 성공을 위해서 해야 할 여러 일들에 대한 전
략적인 측면의 일(Strategic Discipline)
프로젝트관리는 영업과 같이 성공을 위한 운영적인 측면의 일(Operation Discipline)

7. 7
개발 방법론 vs. 관리 방법론
정보공학, 객체지향, RAD, CBD,
UP, Agile
PMBOK, PRINCE2

8. SW개발방법론

9. 9
폭포수 모델
•
장점
–
–
–
•
시스템 개발에 필요한 태스크들을 한눈에 파악할 수 있다.
각 단계의 완료 정의가 매우 명확하다.
대규모 시스템 개발 프로젝트의 프레임워크를 제공한다.
단점
–
–
–
실제 시스템 개발 패턴에 맞지 않는다.
이전 단계에 대한 오류 수정 및 추가 개선이 용이하지 않다.
종종 엄청난 양의 문서 작업을 야기한다.
소프트웨어개념
요구사항분석
아키텍처설계
상세설계
구현과 디버깅
시스템테스트

10. 10
변형폭포수 모델(사시미(Sashimi) 모델)
일본 후지 제록스 하드웨어개발에
서 따온 이름
소프트웨어개념
요구사항분석
단계 사이를 중복해서 약점을 극
복하려는 모델
아키텍처설계
상세설계
구현과 디버깅
시스템테스트
중간목표가 애매해지므로 감독이
어려움

11. 11
변형폭포수 모델(하위프로젝트 폭포수모델)
소프트웨어개념
쉬운 분야를 우선 구현하는 모델
요구사항분석
상세설계
구현과디버
깅
아키텍처설계
시스템테스
트
상세설계
구현과디버
깅
상세설계
구현과디버
깅
시스템테스
트
시스템테스
트
시스템테스트

12. 12
짜보고 고치기(Code-and-Fix)
•
장점
최소한 프로그램을 개발하여 내놓는 면에서는 가장 빠른 방법이다.
프로그래머들은 이 방법을 가장 선호한다.
관리자의 입장에서 이러한 방법을 사용하는 프로그래머가 가장 능률이 뛰어난 것으로 보인다.
–
–
–
•
단점
–
–
–
–
프로그램의 유지 및 개선이 어렵다.
프로그래머의 시간과 노력이 가장 비효율적인 방법이다.
시스템 상의 오류, 누락, 개선 요구사항이 발견 되었을 때는 이미 늦었다.
오류에 대한 검증 및 수정이 불가능할 정도로 많이 발견되는 경우가 종종 있다
시스템명세서
(없을 수도 있음)
짜보고
고치기
출시
(못할 수도 있음)

13. 13
나선형
•
신중하고 섬세한 관리 필요
위험인지와 처리
위험분석
위험분석
운영
프로토타입
위험분석
시작
요구사항수집과
생명주기계획
개발계획
프로토타입
운영방안
프로토타입2
SW요구사항
구현
요구사항확인
단위테스트
통합과테
스트계획
설계확인
과검증
출시
통합과테
스트

14. 14
발전적 프로토타이핑
•
장점
–
–
–
•
사용자의 요구사항을 보다 빠르게 반영할 수 있다.
오류 또는 보완 사항을 신속히 발견, 제거/반영할 수 있다.
적은 비용과 노력으로 보다 빠른 시스템의 개발이 가능하다.
단점
–
–
프로젝트의 산출물을 정의하기 어렵다.
기존의 일정계획을 적절히 수정하여 적용하여야 한다.
초기개념
초기 프로토타입 승인 받을때까지 프로토타입 개
선
설계와 구현
프로토타입 완
성과 출시

15. 15
단계적인 출시 모델
주의 깊게 계획을 세우지
않으면 실패하기 쉽다
소프트웨어
개념
요구사항분석
아키텍처설
계
1단계: 상세설계, 구현, 디버깅, 테스트, 출시
2단계: 상세설계, 구현, 디버깅, 테스트, 출시
3단계: 상세설계, 구현, 디버깅, 테스트, 출시

16. 16
일정맞춤 설계모델
최종출시여부가 확실하지 않은 상태로 개발
소프트웨어
개념
요구사항분석
아키텍처설계
모든 단계를 거치지 않는다면 출시하지 않을 기능
을 분석하고, 설계하는데 시간을 낭비한 셈이 된
다는 위험
우선순위높음 상세설계, 구현, 디버깅, 테스트, 출시
우선순위조금높음: 상세설계, 구현, 디버깅, 테스트, 출시
시간이나 비용이 바닥나는 시점에서도
출시보장
우선순위보통: 상세설계, 구현, 디버깅, 테스트, 출시
우선순위 조금낮음: 상세설계, 구현, 디버깅, 테스트, 출시
우선순위 낮음: 상세설계, 구현, 디버깅, 테스트, 출시

17. 17
발전적인 출시모델
고객반응에 따라 제품을 개선해나감
소프트웨어
개념
예비 요구사항분석
최종버전출시
아키텍처와 시스템
핵심부분설계
버전개발
고객의견반영
개발버전출시
고객의견유도

18. 18
도구맞춤 설계모델
툴이 지원하지 않는기능은 개발하지 않는 방법
매우 응급한 경우에만 사용하는 극단적인 방법
도구지원기능
개발안되는기능
구현할수있는기능

19. 19
SW개발방법론 정리
•
•
•
•
•
순차적 시스템 개발 (Serial development)
순환적 시스템 개발 (Iterative development)
점진적 시스템 개발 (Incremental development)
병렬 시스템 개발 (Parallel development)
비 절차적 개발 (Hacking, a process antipattern)
개발방법
순차적 시스템 개발
(Serial development)
순환적 시스템 개발
(Iterative development)
장점
단점
시스템 개발에 필요한 태스크들을 한눈에 파악할 수 있다.
각 단계의 완료 정의가 매우 명확하다.
대규모 시스템 개발 프로젝트의 프레임워크를 제공한다.
실제 시스템 개발 패턴에 맞지 않는다.
이전 단계에 대한 오류 수정 및 추가 개선이 용이하지 않다.
종종 엄청난 양의 문서 작업을 야기한다.
사용자의 요구사항을 보다 빠르게 반영할 수 있다.
오류 또는 보완 사항을 신속히 발견, 제거/반영할 수 있다.
적은 비용과 노력으로 보다 빠른 시스템의 개발이 가능하다.
프로젝트의 산출물을 정의하기 어렵다.
기존의 일정계획을 적절히 수정하여 적용하여야 한다.
종종 해킹 개발 방법과 혼동된 개념으로 사용된다.
시스템 개발에 대한 변화에 매우 빠르게 대처할 수 있다.
모든 프로젝트에 적합하지는 않다. (점진적인 개발이 불가능한 경우
점진적 시스템 개발
사용자과의 긴밀한 협동작업을 지원한다.
도 있다. 예, 공항의 Air Traffic Control)
(Incremental development)
대규모의 프로젝트를 소규모의 구성요소로 나누어 용이하게 한다. 초기 적용 시 익숙하지 않다.
병렬 시스템 개발
(Parallel development)
전체 개발 일정을 단축할 수 있다.
형상관리 업무량의 증가에 따라 시스템의 개발이 지연될 수 있다.
프로그램의 유지 및 개선이 어렵다.
최소한 프로그램을 개발하여 내놓는 면에서는 가장 빠른 방법이다.
프로그래머의 시간과 노력이 가장 비효율적인 방법이다.
프로그래머들은 이 방법을 가장 선호한다.
시스템 상의 오류, 누락, 개선 요구사항이 발견 되었을 때는 이미 늦
비 절차적 개발 (Hacking, a
관리자의 입장에서 이러한 방법을 사용하는 프로그래머가 가장 능
었다.
process antipattern)
률이 뛰어난 것으로 보인다.
오류에 대한 검증 및 수정이 불가능할 정도로 많이 발견되는 경우
가 종종 있다.

20. 20
SW개발방법론 어떻게 골라야 하나?
•
•
•
•
•
•
•
개발 대상 시스템의 기능 및 특성에 대한 고려
프로젝트의 일정에 대한 고려
프로젝트 투입 가능 자원 (인력, 시스템, 예산)에 대한 고려
고객의 업무 및 정보기술 이해도에 따른 고려
시스템 개발 기술 분야에 따른 고려
프로젝트 참여 인원의 익숙도에 따른 고려
프로젝트 위험요소에 따른 고려

22. 생각해보기
“제가 개발하는 동안 요구사항은
절대 변경되면 안됩니다!”

23. 23
고민. 누구를 위한 SW인가?
•
•
•
•
소프트웨어 개발은 고객 중심이어야 한다.
문서보다는 잘 동작하는 소프트웨어를 만들어야 한다.
변화에 대한 대응력, 품질 유지, 비용관리의 장점을 유지하면서 시스템을 어떻
게 빠른 시간 내에 개발하나?
이런 질문들에 대해서 90년대에 이르러 새로운 방법론들이 나타나기 시작했다.
이런 경량(lightweight)의 접근 방식들을 통틀어 기민한 개발 방법론(Agile
Methodologies) 이라고 부른다.
XP(Extreme Programming)
DSDM(Dynamic System Development Method)
SCRUM
요구사항 변경에 유연히 대처하고 생산성 향상을 위해 극단적인(extreme) 개발 형태를
취함
http://www.extremeprogramming.org/
RAD를 목적으로 하는 반복 개발방법
http://www.dsdm.org/
팀 기반의 반복적인 점진적 개발방법
가벼운(lightweight) 프로세스
http://www.controlchaos.com/
Cockburn's Crystal
인간 중심의 “Shrink-to-fit” 방식의개발방법론
문서화 작업과 기타 오버헤드를 줄인 “ultra light” 프로세스
http://crystalmethodologies.org/
Highsmith'sASD(Adaptive Software Development)
순차적인 절차를 지양하는 프로세스 중심이 아닌 결과 중심의 개발방법
http://www.adaptivesd.com/
Coad'sFeature Driven Development
도메인 전문가와 협력해 “feature list”를 작성하고 소규모의 팀으로 이를 2주정도의 빠른
시간에 개발하는 반복 개발방법
http://thecoadletter.com/
Pragmatic Programming
개발 전문가인 “pragmatic programmer”를 통해 소프트웨어를 개발하는방법
http://www.pragmaticprogrammer.com/

24. 24
애자일 선언문
http://www.agilemanifesto.org/principles.html
2001년 1월, “애자일 연합(Agile Alliance)”이라는 그룹에서 ‘애자일 선언문’이라는 공동
의 선언서를 만들어 냅니다. 이 문서는 지금까지도 애자일 소프트웨어 개발의 기초 원칙
과 정신으로 이야기 되고 있는 중요한 선언서입니다. 아래는 해당 선언서를 번역한 내용
입니다.
•
•
•
•
•
•
우리는, 소프트웨어를 개발하면서, 그리고 또한 다른 사람의 개발을 도와주면서 소프
트웨 어를 개발하는 더 나은 방법들을 찾아나가고 있다. 이 작업을 통해 다음과 같은
가치를 추 구하게 되었다.
프로세스나 도구 보다는 개인과 상호 작용을,
포괄적인 문서보다는 작동하는 소프트웨어를,
계약에 대한 협상보다는 고객과의 협력을,
계획을 고수하기 보다는 변화에 대응을
더욱 가치 있게 여긴다. 이 말은, 전자도 가치가 있긴 하지만, 우리는 후자 쪽에 더 많
은 가치를 둔다는 것이다.
출처 : 애자일SW개발101

25. 25
Agile 개발방법론의 공통점
•
애자일 소프트웨어 개발은 반복점진적(iterative and incremental) 개발을 기본
스타일로 가집니다. 그리고 이런 스타일의 개발방식을 효과적으로 진행하기 위
해 자기조직화(selforganizing)나 교차기능팀(cross-functional teams)등의 기법
들을 활용.
Why Agile ?
•
•
•
•
팀의 생산성을 높이고 제품을 적기에 출시하기 위해
개발에 들어가는 비용을 줄이기 위해
소프트웨어 품질을 향상시키기 위해
팀의 사기와 업무 만족도 향상을 위해

26. 26
Agile Usage Survey
http://blogs.msdn.com/b/bharry/archive/2011/06/14/agile-project-management-in-visual-studio-alm-v-next.aspx

27. SCRUM

28. 28
스크럼 개요
•
스크럼은 프로젝트 관리를 위한 애자일 방법론으로서 추정 및 조정 기반의 경
험적 관리기 법의 대표적인 형태입니다. 처음 시작은 1986년 타케우지 & 노나
카 교수가 HBR에 기고한 “The New New Product Development Game” 이라는
기사를 그 기원으로 봅니다. 이후 1995년에 켄 슈와버와 제프 서덜랜드가 이 방
법을 소프트웨어 개발에 소개하면서 스크럼 이라 부르게 되었습니다.

29. 29
스크럼 역할
스크럼에는 크게 3가지 역할자가 있습니다.
•
제품 책임자 Product Owner
–
•
스크럼 마스터 Scrum Master
–
–
•
제품 기능목록에 해당하는 제품 백로그(product backlog)를 만들고 우선순위를 조정하거나 새로운
항목을 추가하는 일을 관리합니다. 스프린트에 대한 계획을 수립할 때까지 중요한 역할을 하지만 스
프린트가 시작되면 최대한 팀 운영에 관여하지 않는 걸 권장합니다.
스크럼의 원칙과 가치를 지키면서 스크럼 팀이 개발을 진행할 수 있도록 지원합니다.
스크럼 팀의 업무를 방해하는 요소를 제거하기 위해 노력합니다.
스크럼 팀 Scrum Team
–
보통 5~9명으로 구성되며 하나의 스프린트 기간 동안 구현해야 할 기능을 사용자스토리로 도출하
고 이를 구현합니다. 스프린트 동안 구현해야 하는 기능을 완료하기 위해 노력하며 이를 위한 권한
을 갖습니다.

30. 30
스크럼 프로세스
스크럼의 프로세스를 구성하는 것은 스프린트, 3가지 유형의 미팅과 산출물입니다.
•
스프린트 Sprint
–
•
3가지 미팅
–
•
달력기준 1~4주 단위의 반복개발기간을 가리킵니다.
일일 스크럼, 스프린트 계획, 스프린트 리뷰
3가지 산출물
–
제품 백로그, 스프린트 백로그, 소멸 차트

31. 31
스크럼 프로세스

71. 71
Agile-SCRUM Methodology for mobile Application development

72. 72
주의할 점
•
•
•
•
•
•
•
•
•
•
관리도구로서의 애자일 (무늬만 애자일)
중요한 건 ‘애자일’ 한 마음
NAH(Not Applicable Here) 신드롬: 그 기법은 우리 환경에 맞지 않아요
목표를 잊은 일일 스크럼 미팅
잘못 흘러가는 스크럼 미팅의 징후들
누가 스크럼 마스터인가
분석/설계 없이 코드 개발 바로 하기
스토리 포인트에 의한 생산성 비교
불평이 가득한 회고
야근 불가

73. 회고

74. 좋았던 부분 :)
개선할 점 ><
다음에 하면 좋은 것
기타의견

75. Q&A
김형채 / chaeya@gmail.com