애자일 개발 프로세스를 이용한 고품질 소프트웨어 개발
TRANSCRIPT
I. Agile 적용 이전
II. 넷스루와 소프트웨어 공학
III.소프트퉤어 공학기술 현장 적용 사업
IV.Agile Training
V. Agile 적용 후의 변화
VI.넷스루의 Agile Practices
VII.Lessons Learned
VIII.향후 과제
IX.참고자료
목차
3 /
0. 넷스루는 ?
웹사이트 방문자
웹사
이트
키워드 검색 방문
검색결과 클릭 방문
탐색카테고리 탐색 , 상품 탐색 , 이미지 확대 , 상품평보기 , 찜하기 ,, 상품문의
전환 ( 구매 )
Offer 확인마케팅 메시지 / 이미지 등
구매 갈등
1
3
6
7 웹 클릭스트림
온라인 마케팅 프레임워크
분석통계
방문자 프로파일링
개인화 추천
방문자 모니터링
실시간 메시징실시간 마케팅
맞춤형 컨텐츠
4
I. 애자일 적용 이전제품 개발 주기
제품 개발 주기가 너무 길어서 , 고객들의 요구사항이 빨리 반영되지 않습니다 .1 년에 4 번은 릴리즈해야 순조롭게 영업할 수 있습니다 .
1 년에 두번 릴리즈하는 것도 힘든데 , 4 번씩 릴리즈하라구요 . 그건 불가능해요 . 안 됩니다 .
5
I. 애자일 적용 이전일정 지연
10 월에 릴리즈하기로 해서 고객들에게 이야기해놨는데…
우리가 노는 줄 아세요 ? 우리도 최선을 다하고 있다구요 . 1 개월만 더 기다리세요 .
6
I. 애자일 적용 이전배포 후 결함
코드가 있는 곳에 버그가 사는 겁니다 . 버그 없는 소프트웨어는 없어요 . 최선을 다하지만 버그가 없을 수는 없다구요 .
또 , 결함이 생겼네요 .벌써 몇 번째인지 모르겠습니다 .제발 결함 없는 소프트웨어를 만들어 달라구요 .
7
I. 애자일 적용 이전개발 문화
개인기에 의한 소프트웨어 개발매너리즘동료간 소통 부족외부 소통 부족
8
CVS AutoBuild
II. 넷스루의 소프트웨어 공학2006 년
9
II. 넷스루의 소프트웨어 공학2008 – 외부 프로젝트 경험
Application Architect
Data ArchitectInformation Architect
Technical Architect
Staging ProductionDevelopment Test
Software Requirement SpecificationUnit Test
Test CaseTest Scenario
User Interface Standard
Data Standard Coding Standard
Service Deploy Process
Code InspectionStatic Code Analysis
10
II. 넷스루의 소프트웨어 공학2012 소프트웨어 공학기술 현장 적용 사업
관심 우연한 기회
공감대 형성 부족
실패에 대한 두려움변화에 대한 저항 무지에서 오는 불안감
SW 공학에 대한 부정적인 인식
11
III. 소프트웨어 공학기술 현장 적용 사업SW 공학과 변화
긍정적수용 / 발전
부정적저항 / 거부
시간변화
명령지시
강압강요
부탁질문
변화의 도구
12
III. 소프트웨어 공학기술 현장 적용 사업변화 - Communication model of speech
http://www.uri.edu/personal/carson/kulveted/solution.html
13
III. 소프트웨어 공학기술 현장 적용 사업2012 년 5 월 ~7 월 : Case Study
나
팀
2011 년SW 공학기술현장적용사업결과 보고서
Sonar
Sele-nium
PMBOK CMMiAgile Scrum
RefactoringDesign Pattern
형상관리요구사항관리
Jira
Confluence
결함밀도 결함율요구사항 준수율일정지연율
TMMi
Bamboo
GreenHopper
Jenkins
TemplateGuide
14
III. 소프트웨어 공학기술 현장 적용 사업프로젝트의 결과물은 ?
Test Scenario Template
Test Guide
이번 프로젝트가 끝나도 지속적으로 실행할 수 있을까 ?
Test Process
도구도입
15
III. 소프트웨어 공학기술 현장 적용 사업프로젝트의 결과물은 ?
이번 프로젝트가 끝이 나도 우리가 지속적으로 실행할 수 있는 것이 무엇일까 ?
개발자들의 성장을 이끌 수 있는
개발자들의 흥미를 유발시킬 수 있는개발자들에게 도전적인
개발 문화를 바꿀 수 있는
Agile!!!
16
III. 소프트웨어 공학기술 현장 적용 사업2012 년 8 월 ~11 월 : Agile 교육 + 스터디
일자 강사 내용8/28 박재호 이사 (INNODS) - 테스트 주도 개발 (TDD) 소개9/11 박재호 이사 (INNODS) - eXtreme Programming(XP)
9/19 채수원 차장 ( ㈜ NHN) - 테스트 주도 설계와 짝 프로그래밍9/26 박재호 이사 (INNODS) - 테스트 주도 설계10/11 박재호 이사 (INNODS) - Scrum
10/18 박재호 이사 (INNODS) - 애자일 기본 철학10/23 박재호 이사 (INNODS) - 린 소프트웨어 개발10/30 박재호 이사 (INNODS) - 애자일 방식의 추정과 계획11/1 황상철 수석 ( ㈜ NHN) - 스펙작성 및 사용자스토리 기반 개발 프로세스
17
III. 소프트웨어 공학기술 현장 적용 사업2012 년 8 월 ~11 월 : Agile 교육 + 스터디
Agile 교육Agile 스터디
Whole Team
Collective Code Ownership
Scrum
XP
Planning PokerSprint
Self Organizing
Daily Scrum Meeting
Commitment
Test Driven Development
User Story
Pair Program-ming
Transparency
Trust
Acceptance Test
Scrum Board
Sprint Review
Retrospective
Kanban
Velocity
나
팀
18
III. 소프트웨어 공학기술 현장 적용 사업2012 년 9 월 : Pilot Project with SCRUM
19
III. 소프트웨어 공학기술 현장 적용 사업2012 년 9 월 : Pilot Project
Story TODO + Progress DONE
12.9.3 29 29 012.9.4 29 29 012.9.5 29 23 612.9.6 29 19 1012.9.7 29 13 16
Story TODO + Progress DONE
12.9.10 19 19 012.9.11 20 15 512.9.12 24 13 1112.9.13 26 13 1312.9.14 29 13 16
Story TODO + Progress DONE
12.9.18 30 29 112.9.19 35 29 612.9.20 35 20 1512.9.21 36 8 28
20
III. 소프트웨어 공학기술 현장 적용 사업2012 년 9 월 : 도구도입
Confluence
JIRA
Git Gerrit
GreenHopper
Gliffy Jenkins
21
III. 소프트웨어 공학기술 현장 적용 사업작은 성공 둘
일정을 예측하고 관리할 수 있었던 경험
코드 리뷰로 결함을 방지했던 경험
22
IV. Agile Training2013 년 4 월 : Professional Scrum Foundation
• 2 일 동안 4 번의 Sprint 진행• Planning – Daily Meeting• Review – Retrospective• Scrum Board Customizing• DoD(Definition of Done)• 팀의 지속적인 변화와 성장 경험• Scrum Role 을 경험
23
IV. Agile Training2013 년 4 월 : Professional Scum Master
Scrum Master 가 되기 위한 교육과정( scrum.org )- Scrum Master 가 되는 길은 멀고 험함
Scrum Alliance 의 CSM 참고
24
IV. Agile Training2013 년 6~9 월 : Agile Coaching Square (http://www.ac2.kr/)
개인의 변화
Intuition and In-sight
Facilitation and Event Design
코칭 접근
코칭 경험
사람 이해하기Communica-tion
회고
리스크 관리
배우기가르치기코칭 받기
측정하고 가시화하기
실험과 연구
Creativity and Problem Solving Ap-proach
Error Manage-ment
즉흥연기
Selecting/Assessing Person-nel
Team Dynam-ics
Motivation in Workplace
Habbit Science
Mind Reading
Stress in Communica-
tion
Nudge Design
Organizing Cul-ture
Influencing without Au-thority
Resilience in Organiza-tions
• 지속적인 학습을 통한 변화의 필요성 절감• 변화의 핵심은 나로부터 시작된다는 걸 깨달음• 팀운영에 있어서 개인별 코칭의 중요성 인식• 변화에 대한 에너지를 지속하기 위한 조력자의 도움
Facilitation and Event Design
25
IV. Agile Training사내스터디 - 학습조직화
상태 스터디 명 스터디 교재 모임일시 [개발본부] 토비의 스프링 3.0 토비의 스프링 3.0 [개발본부] Design Patterns Study 헤드 퍼스트 디자인 패턴
종료 [개발본부] 리팩토링 Study 리팩토링 ( 마틴 파울러 ) 매주 월 , 수 18:00~
종료 Java Performance Fundamental Java Performance Fundamen-tal
매주 화 , 목 13:00~
종료 JAVA CONCURRENCY IN PRACTICE Java Concurrency in Practice 매주 월 , 수 13:00~종료 [개발본부] 기획스터디 로지컬 씽킹
맥킨지식 사고와 기술맥킨지 문제 해결의 기술
매주 수요일 18:30~
종료 애자일 마스터 애자일 마스터 매주 월 / 목 18:00진행중 UX Lab 그룹 UX 디자인 프로젝트 가이드 매주 목요일 16:00
26
V. Agile 적용 후의 성과배포후 결함
2010 년 상반기
2010 년 하반기
2011 년 상반기
2011 년 하반기
2012 년 상반기
2012 년 하반기
2013 년 상반기
2013 년 하반기
합계V1 36 62 33 21 28 20 7 5 212V2 37 49 26 10 5 127V3 3 11 14
2010 년 상반기 2010 년 하반기 2011 년 상반기 2011 년 하반기 2012 년 상반기 2012 년 하반기 2013 년 상반기 2013 년 하반기0
10
20
30
40
50
60
70V1V2V3
V2-V3 비교 : 배포후 결함이 86 건에서 14 건으로 급격히 감소 ( 약 84% 감소 )
27
릴리즈 횟수가 급격히 증가-SeeToc : 166% 증가-WiseLog : 350% 증가
V. Agile 적용 후의 성과릴리즈 주기
SeeToc WiseLog -
1
2
3
4
5
6
7
8
9
10 20122013
28
V. Agile 적용 후의 성과개발문화
커뮤니케이션 빈도 증가
커뮤니케이션 질적인 측면 향상
공통의 경험 공통의 어휘믿음
이해신뢰
예측가능성 향상
SW 공학 인식
사회적 자본커뮤니케이션
가시성 확보
팀워크
협력도움주기
품질에 대한 인식 향상
자신감
신속한 릴리즈
동기부여
SW 공학의 필요성 절감
결함 감소투명성 향상
29
V. Agile 적용 후의 성과새로운 제품 개발 (2013.10.22)
글로벌 업체들과 경쟁할 수 있는 차세대 제품
단시간 내에 핵심 기술을 개발
뛰어난 안정성
효과적인 UI/UX
Interactive Data Discovery
Agile 에 대한 확신
개발자들의 품질에 대한 자신감 경험
VI. Agile Practices넷스루의 Agile Practices
30
참고자료 : 7-th Annual State of Agile Development Survey ( by Version One)
31
VI. 넷스루의 Agile Practices1. Sprint Planning
32
VI. 넷스루의 Agile Practices1. Sprint Planning
일정 예측 가능성 향상
막연한 일정 압박에서 벗어남
일정을 팀이 결정 ( 조율가능 )
일정이 명확해지고 투명함 ( 가시화 ) Sprint 시작 시점에 일감이 정해짐
일감이 상세화 구체화됨
Planning 에 상당한 시간 소요
Planning 후반에 집중력 저하
Planning 시간이 기획시간으로 변질
일감을 다양한 관점에서 검토일감에 대한 이해도 향상
Sprint 기간 안에 일을 끝내야 하는 부담감
일감 구체화 과정에서 새로운 지식 습득
담당자가 1 명이면 추정 정확도가 떨어짐
Interrupt 때문에 일정 지연이 발생
상호간의 업무 이해도 향상
33
VI. 넷스루의 Agile Practices2. Daily Scrum Meeting
어제 한 일 : 어제는 A 를 했습니다 .오늘 할 일 : 오늘은 B 를 할 계획입니다 .장애물 : 장애물이 있습니다 .
34
VI. 넷스루의 Agile Practices2. Daily Scrum Meeting
업무 동기화
동료들이 업무 진행 상태 파악 가능
자신의 상태에 솔직하지 않은 경우
업무 보고 시간으로 변질
장애물 / 문제가 빨리 공개되고 해결됨
문제를 공론화하고 해결책을 쉽게 구할 수 있음
참석자들의 표정이 어두운 경우 있음
자기방어에 에너지를 쏟는 경우 있음
부정적 피드백 : 전체 에너지가 저하됨
감정 표출로 인한 상처
팀원들의 업무에 대한 이해도가 향상
일감 진행이 투명하게 공개됨
지루해지고 매너리즘에 빠짐
출처 : http://hotjungboworld.tistory.com/1151
35
VI. 넷스루의 Agile Practices3. Retrospective
Workig Rule Review
Working Rule 변경
StartStopContinueMore ofLess of
Retrospective
진행 Facilitation
1. 사전 준비2. 자료수집3. 통찰 이끌어 내기4. Working Rule 변경5. 마치기
그림 출처 : http://exercise.sportsxfitness.com/weight-loss-sprint-workouts/
36
VI. 넷스루의 Agile Practices3. Retrospective
작업 프로세스 개선의 기회
팀을 돌아볼 수 있는 기회
해결책이 잘 안지켜지는 경우가 있음
똑같은 잘못을 되풀이하는 경우가 있음
실천가능한 개선책이 나오지 않음
진화 / 학습의 기회
실질적이지 않고 이상적인 해결책
문제를 표면화하고 , 대화와 토론으로 해결책 모색
문제제기시 당사자가 심리적 상처 받음
부정적인 부분에만 집중하는 경향
지루해지고 매너리즘에 빠짐
37
VI. 넷스루의 Agile Practices4. Unit Test
Production Code
Test Code
코드 수정 결함 발생
그림 출처 : http://blog.extreme-advice.com/2013/01/30/create-custom-error-message-by-sys-sp_addmessage-in-sql-server-2012/
38
VI. 넷스루의 Agile Practices4. Unit Test
• 잠재적인 결함 내포• 결함 진동 가능성• 배포시 사후 처리 비용• 개발자들의 자신감 결여
Production Code
Production Code
Test Code
Production Code Only Production Code + Test Code
• Production Code 에 대한 보호막• 결함 조기 발견• 심리적 안정감• 개발자들이 코드 수정에 자신감을 가짐
39
VI. 넷스루의 Agile Practices4. Unit Test
심리적인 안정감
코드 수정에 대한 자신감
코드 품질을 보장하지는 않음 팀 프로세스에 잘 녹아있지 않음
커버리지를 올리기 위한 형식적인 단위 테스트 수행
결함 조기 발견 : 코드 수정 후 테스트 오류가 발생으로 결함을 수정
배포후 결함 처리비용 감소
회귀테스트 / 안전판 구실
가끔 TDD 를 실행하기도 함
테스트 케이스 작성 고민과 시간이 필요함
결함이 획기적으로 감소
시간이 부족한 경우 테스트 작성을 미룸
40
VI. 넷스루의 Agile Practices4. Unit Test
망각곡선
테스트 비용
시간
비용
릴리즈 결함처리 비용테스트 코드 작성 시점은 ?
Production Code 작성시점
41
VI. 넷스루의 Agile Practices4. Unit Test
테스트 작성 시간
디버깅시간
테스트 코드 작성은 얼마나 해야 하는가 ?
효과 > 비용
효과 < 비용
코드해석
코드수정 테스트 디버그 배포비용
결함 처리 비용
42
VI. 넷스루의 Agile Practices5. Collective Code Ownership
기획팀 설계팀 디자인팀 개발팀 테스트팀
제품 A
제품 B
제품 C
기능팀 (Functional Team)
교차기능
팀(C
ross
Fun
ctio
nal T
eam
)
그림 출처 : http://www.lindaslearninglinks.com/gingerbreadmansites.html
43
VI. 넷스루의 Agile Practices5. Collective Code Ownership
Cross Functional Team 으로 충분한가 ?
Personal Ownership Collective Code Ownership
개발자 1모듈 A
개발자 2모듈 B
개발자 3모듈 C
모듈 A
모듈 B
모듈 C
개발자 1 개발자 2 개발자 3
일감을 Pull 방식으로 처리하기 위해서는 Collective Code Ownership 이 선행되어야 함
44
VI. 넷스루의 Agile Practices5. Collective Code Ownership
이해도 향상으로 이슈 해결에 대한 대화 참여 가능
개인 의존도가 줄어들고 , 팀원 부재시 상시 백업 가능
다양한 코딩 스타일 경험으로 중립적인 코딩 스타일 정립
코드에 대한 다른 관점을 학습하는 기회
코드 이해에 많은 시간과 노력이 필요함
시스템 전체에 대한 이해도 향상
자기 계발한다는 마음가짐이 필요함
Planning 시 의견 공유가 활발해짐
시야가 넓어짐
45
VI. 넷스루의 Agile Practices6. Code Review
개발 스킬을 향상시킬 수 있는 기회
리뷰를 고려해서 코드를 작성
시간에 쫓겨 형식적으로 수행
새로운 관점에서 사고할 수 있는 계기
리뷰에서 거를 수 있는 결함이 배포되는 경우 있음
결함이 획기적으로 감소
대안없는 부정적인 리뷰로 심리적인 상처
리뷰가 몰려서 리뷰가 한꺼번에 일어나는 경향
비용이 큼 : 3~4 명에 1명정도
좋은 코딩 스타일을 학습할 수 있는 기회
46
VI. 넷스루의 Agile Practices7. Pair Programming
코드 리뷰가 자연스럽고 상세하게 진행됨
Driver 가 새로운 지식을 빠르게 학습
감정적인 충돌이 발생할 수 있음
코드 공유가 자연스럽게 이루어짐
업무 인수인계시 소통의 질이 매우 높음
비용이 매우 큼
Navigator 도 새로운 관점을 배울 수 있는 기회
동료와 함께 고민을 즉시 해결할 수 있음
47
VI. 넷스루의 Agile Practices7. Pair Progamming
Navigator
효과적이지 않은 경우 효과적인 경우
짝 프로그래밍은 언제 효과적인가 ?
Driver
Driver
Navigator
Driver
Navigator
48
VI. 넷스루의 Agile Practices7. Pair Programming
Case 1 Case 2 Case 3
Naviga-tor
Driver Naviga-tor
Driver Naviga-tor
Driver
Skill 하 하 상 상 상 중Knowledge 하 하 상 상 상 중Domain Knowl-edge
하 하 상 상 상 하생산성 X X X X △ △
품질 X X O O O O
짝 프로그래밍은 언제 효과적인가 ?
49
VII. Lessons Learned변화
SW 공학기술 현장적용 사업
2012.5
11 월8 월
Agile 교육 + 스터디2011 년 결과보고서Case Study
AC2
PSFPSM
CoachingSafeArea
7 월2013.4 6 월12 월 8 월
Facilitation
50
VII. Lessons Learned학습과 성장곡선
시간
Skill
Knowledge
학습곡선졸업후 5 년대학졸업
SkillKnowledge
51
Agile 철학이 일깨워 준 것들 !!!
VII. Lessons LearnedAgile 의 가치
SW 개발의 중심은 사람
SW 개발은 개인이 아니라 팀의 결과물이기 때문에 팀의 협력체제가 중요문서화 , 방법론 , 프로세스보다 협업할 수 있는 의사소통 구조와 방법이 중요
모든 것이 변화한다는 사실을 당연한 것으로 받아들임
문제를 드러내고 조속히 해결하기 위한 사회적 자본 ( 이해 , 신뢰 ) 형성이 필수
개발자들이 실천할 수 있는 프로세스가 필요대부분의 사람들은 자신의 문제를 스스로 해결할 수 있음
52
VII. Lessons LearnedAgile 도입이 실패하는 경우
공감대 형성없이 전격적 / 강압적으로 도입한다 .
팀원들이 변하지 않으면 , 부정적인 피드백을 전달한다 .
방법론 , 프로세스를 따르라고 명령하고 지시한다 .
팀원들이 실수하면 , 화를 낸다 .
조급한 마음으로 조속한 성과를 바란다 .
팀원들이 문제를 해결하지 못하면 직접 해결해서 내 능력을 보여준다 .
팀원들을 믿지 않는다 .
사람보다 문서 , 방법론 , 프로세스를 우선시한다 .
대화의 Common Zone 형성을 고려하지 않는다 .
팀원들을 강제적으로 가르치려 한다 .
53
VII. Lessons LearnedAgile Development Architecture
Engineering Practices
Agile Mindset
Comm
unication
Agile Development Culture
Agile Working Rule
High Quality Software
질문 1: Agile 을 잘 하려면 ?질문 2: 고품질 소프트웨어를 개발하려면 ?
열려있는
의욕적인
자기조직
화된
Skill 과 지식이 풍부한
Social Capital Engineering Power
54
VIII. 향후 과제작업규칙과 품질
작업규칙
품질
현재
2014
초
중
고
대2016
55
VIII. 향후 과제Business Value
Lean StartupCustomer DevelopmentDesign ThinkingUser Experience…
Engineering Power
Business Value C
reation
현재
2014
2016
56
IX. 참고자료7-th Annual State of Agile Development Survey by Version One
57
IX. 참고자료7-th Annual State of Agile Development Survey by Version One
58
IX. 참고자료7-th Annual State of Agile Development Survey by Version One
59
IX. 참고자료7-th Annual State of Agile Development Survey by Version One
60
마무리 . 개발문화
여러분이 농부라면 어느 땅에 씨앗을 뿌리시겠습니까 ?
여러분이 씨앗이라면 어느 땅을 고르시겠습니까 ?
출처 : http://forestertreeservice.com/oak-tree/
사진 출처 : http://blog.daum.net/pykim/8748173
Online Marketing Service Hub
감사합니다 .
61