애자일 개발 프로세스를 이용한 고품질 소프트웨어 개발

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

애자일 개발 프로세스를 이용한 고품질 소프트웨어 개발

Check these out next

애자일 개발 프로세스를 이용한 고품질 소프트웨어 개발

Recomendados

Más contenido relacionado

Presentaciones para ti(20)

Similar a 애자일 개발 프로세스를 이용한 고품질 소프트웨어 개발(20)

Más de Jaehoon Oh(7)

Último(20)

애자일 개발 프로세스를 이용한 고품질 소프트웨어 개발