모바일 앱 개발을 위한 Agile Adoption

김형채 (chaeya@gmail.com)

http://yes.imhappyo.com

1. 개요

2. SW개발방법론

3. Agile

4. SCRUM

5. 회고

목 차

소개

3

• 아비도스 스크럼마스터

• 15년간 100여개의 SW개발 프로젝트 수행(개발, PM)

• SW 테스트 전문가(TTA)

• 한중일 공개SW활성화포럼 표준화분과 한국위원

• 한국정보통신기술협회(TTA) 공개SW 표준화 분과위원

• 정보통신산업진흥원 SW공학센터 자문위원

• blog : http://yes.imhappyo.com

• Facebook : http://fb.com/hyeongchae

“저는 오픈소스SW기술과 SW개발방법론을 이용하여 기업의 비즈니스 전략과 잘 연계하는 성장모델에 관심이 많습니다.”

SW 공학의 탄생

4

1960년대에도 소프트웨어 개발은 미 국방부와 새로운 컴퓨터의 출현으로 가속화되었다. 그러나 그때까지는 코딩을 하고, 요구조건을 이해하고, 성공적으로 프로젝트를 완성시키는 것 사이에 명확한 구분이 없었다. 그 당시의 시스템은 일반적으로 단순했으며 일괄처리 중심(batch-based)이었다.

불행히도 명확한 시스템의 제약사항 없이 작동하게만 만들자라는 철학은 프로젝트 실패로 귀결된다. 1968년 NATO 회의에서 소프트웨어의 위기를 타개해야 한다는 의견이 나왔고 처음으로 소프트웨어 공학이라는 용어가 사용되었다.

소프트웨어 공학(SE, Software Engineering)은 소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문이며 여러 가지 방법론과 도구, 관리 기법들을 통하여 소프트웨어의 품질과 생산성 향상을 목적으로 한다.

SW 공학은 누가 배워야 하나?

5

숙련된 프로그래머 스스로 학습하거나 정규 교육을 통해서 뛰어난 소프트웨어를 배운 계층을 가리킨다.

기술 전문가 초보 프로그래머를 가르치고 있거나 기술적 자문을 하고 있다. 소프트웨어 공학을 가르치고 있다.

독학으로 배운 프로그래머 자신이 정규교육을 받지 않았다고 해서 프로그래머가 되지 못하는 것은 아니다. 예를 들면, 회계사, 공학자, 교사, 과학자 등과 같은 전문가 그룹에서 발견되곤 한다. 얼마나 정규교육을 받았는지에 상관없이 효율적인 프로그래밍의 통찰력을 제공한다.

학생 정규교육을 거의 받지 않았지만 실무 경험이 있는 프로그래머와 반대되는 사람이 이제 갓 전문고등교육을 이수한 학생일 것이다. 갓 전문고등교육을 이수한 학생은 이론에는 강하지만 제품을 개발하는데 실무가 부족하다. 훌륭한 코드를 작성하기 위한 실용적인 지식은 종종 소프트웨어 설계자와 프로젝트 전문가, 분석가, 경험 많은 프로그래머의 행동으로부터 천천히 전수된다

출처: Code Complete 개정판 중에서

방법론에 대한 이해

6

• 방법론이란 어떤 일에 도움을 주는 일련의 절차, 기법, 원리, 도구들을 의미.

• 프로젝트관리와 소프트웨어 개발 방법론과의 관계는 영업과 마케팅과의 관계와 매우 흡사.

• 소프트웨어 개발 방법론은 마케팅과 같이 성공을 위해서 해야 할 여러 일들에 대한 전략적인 측면의 일(Strategic Discipline)

• 프로젝트관리는 영업과 같이 성공을 위한 운영적인 측면의 일(Operation Discipline)

개발 방법론 vs. 관리 방법론

7

PMBOK, PRINCE2 정보공학, 객체지향, RAD, CBD, UP, Agile

SW개발방법론

폭포수 모델

9

• 장점 – 시스템 개발에 필요한 태스크들을 한눈에 파악할 수 있다.

– 각 단계의 완료 정의가 매우 명확하다.

– 대규모 시스템 개발 프로젝트의 프레임워크를 제공한다.

• 단점 – 실제 시스템 개발 패턴에 맞지 않는다.

– 이전 단계에 대한 오류 수정 및 추가 개선이 용이하지 않다.

– 종종 엄청난 양의 문서 작업을 야기한다.

소프트웨어개념

요구사항분석

아키텍처설계

상세설계 구현과 디버깅

시스템테스트

변형폭포수 모델(사시미(Sashimi) 모델)

10

소프트웨어개념

요구사항분석

아키텍처설계

상세설계

구현과 디버깅

시스템테스트

일본 후지 제록스 하드웨어개발에서 따온 이름

단계 사이를 중복해서 약점을 극복하려는 모델 중간목표가 애매해지므로 감독이 어려움

변형폭포수 모델(하위프로젝트 폭포수모델)

11

소프트웨어개념

요구사항분석

아키텍처설계

상세설계

구현과디버깅 시스템테스

트

쉬운 분야를 우선 구현하는 모델

상세설계

구현과디버깅 시스템테스

트 상세설계

구현과디버깅 시스템테스

트 시스템테스트

짜보고 고치기(Code-and-Fix)

12

• 장점 – 최소한 프로그램을 개발하여 내놓는 면에서는 가장 빠른 방법이다.

– 프로그래머들은 이 방법을 가장 선호한다.

– 관리자의 입장에서 이러한 방법을 사용하는 프로그래머가 가장 능률이 뛰어난 것으로 보인다.

• 단점 – 프로그램의 유지 및 개선이 어렵다.

– 프로그래머의 시간과 노력이 가장 비효율적인 방법이다.

– 시스템 상의 오류, 누락, 개선 요구사항이 발견 되었을 때는 이미 늦었다.

– 오류에 대한 검증 및 수정이 불가능할 정도로 많이 발견되는 경우가 종종 있다

시스템명세서 (없을 수도 있음)

짜보고 고치기

출시 (못할 수도 있음)

나선형

13

시작

출시

운영방안

위험분석

요구사항수집과 생명주기계획

위험분석

위험분석

위험인지와 처리

개발계획

통합과테스트계획

설계확인과검증

구현

단위테스트

통합과테스트

요구사항확인

SW요구사항

프로토타입 프로토타입2

운영 프로토타입

• 신중하고 섬세한 관리 필요

발전적 프로토타이핑

14

• 장점 – 사용자의 요구사항을 보다 빠르게 반영할 수 있다.

– 오류 또는 보완 사항을 신속히 발견, 제거/반영할 수 있다.

– 적은 비용과 노력으로 보다 빠른 시스템의 개발이 가능하다.

• 단점 – 프로젝트의 산출물을 정의하기 어렵다.

– 기존의 일정계획을 적절히 수정하여 적용하여야 한다.

초기개념 초기 프로토타입 설계와 구현

승인 받을때까지 프로토타입 개선

프로토타입 완성과 출시

단계적인 출시 모델

15

소프트웨어 개념

요구사항분석

아키텍처설계

1단계: 상세설계, 구현, 디버깅, 테스트, 출시

2단계: 상세설계, 구현, 디버깅, 테스트, 출시

3단계: 상세설계, 구현, 디버깅, 테스트, 출시

주의 깊게 계획을 세우지 않으면 실패하기 쉽다

일정맞춤 설계모델

16

소프트웨어 개념

요구사항분석

아키텍처설계

우선순위높음 상세설계, 구현, 디버깅, 테스트, 출시

우선순위조금높음: 상세설계, 구현, 디버깅, 테스트, 출시

우선순위보통: 상세설계, 구현, 디버깅, 테스트, 출시

최종출시여부가 확실하지 않은 상태로 개발 모든 단계를 거치지 않는다면 출시하지 않을 기능을 분석하고, 설계하는데 시간을 낭비한 셈이 된다는 위험

우선순위 조금낮음: 상세설계, 구현, 디버깅, 테스트, 출시

우선순위 낮음: 상세설계, 구현, 디버깅, 테스트, 출시

시간이나 비용이 바닥나는 시점에서도 출시보장

발전적인 출시모델

17

소프트웨어 개념

예비 요구사항분석

아키텍처와 시스템 핵심부분설계

고객반응에 따라 제품을 개선해나감

최종버전출시

버전개발

개발버전출시

고객의견유도

고객의견반영

도구맞춤 설계모델

18

툴이 지원하지 않는기능은 개발하지 않는 방법 매우 응급한 경우에만 사용하는 극단적인 방법

도구지원기능

구현할수있는기능 개발안되는기능

SW개발방법론 정리

19

• 순차적 시스템 개발 (Serial development)

• 순환적 시스템 개발 (Iterative development)

• 점진적 시스템 개발 (Incremental development)

• 병렬 시스템 개발 (Parallel development)

• 비 절차적 개발 (Hacking, a process antipattern)

개발방법 장점 단점

순차적 시스템 개발 (Serial development)

시스템 개발에 필요한 태스크들을 한눈에 파악할 수 있다. 각 단계의 완료 정의가 매우 명확하다. 대규모 시스템 개발 프로젝트의 프레임워크를 제공한다.

실제 시스템 개발 패턴에 맞지 않는다. 이전 단계에 대한 오류 수정 및 추가 개선이 용이하지 않다. 종종 엄청난 양의 문서 작업을 야기한다.

순환적 시스템 개발 (Iterative development)

사용자의 요구사항을 보다 빠르게 반영할 수 있다. 오류 또는 보완 사항을 신속히 발견, 제거/반영할 수 있다. 적은 비용과 노력으로 보다 빠른 시스템의 개발이 가능하다.

프로젝트의 산출물을 정의하기 어렵다. 기존의 일정계획을 적절히 수정하여 적용하여야 한다. 종종 해킹 개발 방법과 혼동된 개념으로 사용된다.

점진적 시스템 개발 (Incremental development)

시스템 개발에 대한 변화에 매우 빠르게 대처할 수 있다. 사용자과의 긴밀한 협동작업을 지원한다. 대규모의 프로젝트를 소규모의 구성요소로 나누어 용이하게 한다.

모든 프로젝트에 적합하지는 않다. (점진적인 개발이 불가능한 경우도 있다. 예, 공항의 Air Traffic Control) 초기 적용 시 익숙하지 않다.

병렬 시스템 개발 (Parallel development)

전체 개발 일정을 단축할 수 있다. 형상관리 업무량의 증가에 따라 시스템의 개발이 지연될 수 있다.

비 절차적 개발 (Hacking, a process antipattern)

최소한 프로그램을 개발하여 내놓는 면에서는 가장 빠른 방법이다. 프로그래머들은 이 방법을 가장 선호한다. 관리자의 입장에서 이러한 방법을 사용하는 프로그래머가 가장 능률이 뛰어난 것으로 보인다.

프로그램의 유지 및 개선이 어렵다. 프로그래머의 시간과 노력이 가장 비효율적인 방법이다. 시스템 상의 오류, 누락, 개선 요구사항이 발견 되었을 때는 이미 늦었다. 오류에 대한 검증 및 수정이 불가능할 정도로 많이 발견되는 경우가 종종 있다.

SW개발방법론 어떻게 골라야 하나?

20

• 개발 대상 시스템의 기능 및 특성에 대한 고려

• 프로젝트의 일정에 대한 고려

• 프로젝트 투입 가능 자원 (인력, 시스템, 예산)에 대한 고려

• 고객의 업무 및 정보기술 이해도에 따른 고려

• 시스템 개발 기술 분야에 따른 고려

• 프로젝트 참여 인원의 익숙도에 따른 고려

• 프로젝트 위험요소에 따른 고려

생각해보기

“제가 개발하는 동안 요구사항은 절대 변경되면 안됩니다!”

고민. 누구를 위한 SW인가?

23

• 소프트웨어 개발은 고객 중심이어야 한다. • 문서보다는 잘 동작하는 소프트웨어를 만들어야 한다. • 변화에 대한 대응력, 품질 유지, 비용관리의 장점을 유지하면서 시스템을 어떻

게 빠른 시간 내에 개발하나? • 이런 질문들에 대해서 90년대에 이르러 새로운 방법론들이 나타나기 시작했다.

이런 경량(lightweight)의 접근 방식들을 통틀어 기민한 개발 방법론(Agile Methodologies) 이라고 부른다.

XP(Extreme Programming) 요구사항 변경에 유연히 대처하고 생산성 향상을 위해 극단적인(extreme) 개발 형태를 취함 http://www.extremeprogramming.org/

DSDM(Dynamic System Development Method) RAD를 목적으로 하는 반복 개발방법 http://www.dsdm.org/

SCRUM 팀 기반의 반복적인 점진적 개발방법 가벼운(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

http://www.agilemanifesto.org/principles.html

2001년 1월, “애자일 연합(Agile Alliance)”이라는 그룹에서 ‘애자일 선언문’이라는 공동 의 선언서를 만들어 냅니다. 이 문서는 지금까지도 애자일 소프트웨어 개발의 기초 원칙 과 정신으로 이야기 되고 있는 중요한 선언서입니다. 아래는 해당 선언서를 번역한 내용 입니다.

• 우리는, 소프트웨어를 개발하면서, 그리고 또한 다른 사람의 개발을 도와주면서 소프트웨 어를 개발하는 더 나은 방법들을 찾아나가고 있다. 이 작업을 통해 다음과 같은 가치를 추 구하게 되었다.

• 프로세스나 도구 보다는 개인과 상호 작용을,

• 포괄적인 문서보다는 작동하는 소프트웨어를,

• 계약에 대한 협상보다는 고객과의 협력을,

• 계획을 고수하기 보다는 변화에 대응을

• 더욱 가치 있게 여긴다. 이 말은, 전자도 가치가 있긴 하지만, 우리는 후자 쪽에 더 많은 가치를 둔다는 것이다.

출처 : 애자일SW개발101

Agile 개발방법론의 공통점

25

• 애자일 소프트웨어 개발은 반복점진적(iterative and incremental) 개발을 기본 스타일로 가집니다. 그리고 이런 스타일의 개발방식을 효과적으로 진행하기 위해 자기조직화(selforganizing)나 교차기능팀(cross-functional teams)등의 기법들을 활용.

Why Agile ?

• 팀의 생산성을 높이고 제품을 적기에 출시하기 위해 • 개발에 들어가는 비용을 줄이기 위해 • 소프트웨어 품질을 향상시키기 위해 • 팀의 사기와 업무 만족도 향상을 위해

Agile Usage Survey

26

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

SCRUM

스크럼 개요

28

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

스크럼 역할

29

스크럼에는 크게 3가지 역할자가 있습니다. • 제품 책임자 Product Owner

– 제품 기능목록에 해당하는 제품 백로그(product backlog)를 만들고 우선순위를 조정하거나 새로운 항목을 추가하는 일을 관리합니다. 스프린트에 대한 계획을 수립할 때까지 중요한 역할을 하지만 스프린트가 시작되면 최대한 팀 운영에 관여하지 않는 걸 권장합니다.

• 스크럼 마스터 Scrum Master – 스크럼의 원칙과 가치를 지키면서 스크럼 팀이 개발을 진행할 수 있도록 지원합니다. – 스크럼 팀의 업무를 방해하는 요소를 제거하기 위해 노력합니다.

• 스크럼 팀 Scrum Team – 보통 5~9명으로 구성되며 하나의 스프린트 기간 동안 구현해야 할 기능을 사용자스토리로 도출하

고 이를 구현합니다. 스프린트 동안 구현해야 하는 기능을 완료하기 위해 노력하며 이를 위한 권한을 갖습니다.

스크럼 프로세스

30

스크럼의 프로세스를 구성하는 것은 스프린트, 3가지 유형의 미팅과 산출물입니다.

• 스프린트 Sprint – 달력기준 1~4주 단위의 반복개발기간을 가리킵니다.

• 3가지 미팅 – 일일 스크럼, 스프린트 계획, 스프린트 리뷰

• 3가지 산출물 – 제품 백로그, 스프린트 백로그, 소멸 차트

스크럼 프로세스

31

Agile-SCRUM Methodology for mobile Application development

71

주의할 점

72

• 관리도구로서의 애자일 (무늬만 애자일)

• 중요한 건 ‘애자일’ 한 마음

• NAH(Not Applicable Here) 신드롬: 그 기법은 우리 환경에 맞지 않아요

• 목표를 잊은 일일 스크럼 미팅

• 잘못 흘러가는 스크럼 미팅의 징후들

• 누가 스크럼 마스터인가

• 분석/설계 없이 코드 개발 바로 하기

• 스토리 포인트에 의한 생산성 비교

• 불평이 가득한 회고

• 야근 불가

회고

좋았던 부분 :)

다음에 하면 좋은 것 기타의견

개선할 점 ><

Q&A

김형채 / chaeya@gmail.com