개발생산성과품질향상을위한 글로벌기업의애자일도입및적용사례 LG 젂자생산성연구원 심우곤선임 http://www.wgshim.com @wgshim woogon.shim@lge.com wgshim@gmail.com
1/27 LG 전자소개 현지법인 117 임직원 82,000 자회사 89 연락사무소 28 R&D 센터 31 디자인센터 6
LG 전자소개 ( 계속 ) 2/27
3/27 사내홗동내역 표준품질시스템도입 ISO, 6σ, NPI, TQM, SPICE, TPS, 5S, CMM(I), PTP/TSP (SW 6σ), 등 SW 부문 Infra 확보추짂 IT 시스템구축, 형상관리, 결함관리, 테스트자동화, 개발 / 설계도구, 검증도구, 등 NPI: New Production Introduction, TQM: Total Quality Management, TPS: Toyota Production System CMM: Capability Maturity Model, PSP: Personal Software Process, TSP: Team Software Process
4/27 전 홖 지원 / 관찰결과기존홗동에대한저항자발적지속이어려움제읷중요한것은사람 / 역량기술 / 홖경변화에싞속대응필요 대안모색 Survey - 최귺 SE 동향조사 경쟁사비교 - NOKIA, Motorola, Yahoo, Google, MS,.. 전문가초빙교육 - 김창준 - James W. Grenning Agile 방법롞
5/27 도대체 Agile 이란? Harvard Business Review John R. Wells, Strategic Agility: Managing Continuous Change, Faculty Seminar Series, 2005. 2010 년가트너그룹젂망 2012 까지모듞 SW 개발프로젝트의 80% 에 Agile 개발방법이적용될것
6/27 Agile Manifesto 우리는직접개발하면서, 또남이개발하는읷을도와주면서소프트웨어개발의더나은방법을발견하고있다. 이작업을통해우리는아래것들을가치있게여기게되었다 : 프로세스와도구보다, 개인과상호소통을포괄적읶문서화보다, 제대로동작하는소프트웨어를계약협상보다, 고객과의협력을계획을준수하는것보다, 변화에대응하는것을더중요시한다. 다시말해서, 왼쪽에있는것들이비록가치있긴하지만, 우리는오른쪽에있는것들에더큰가치를둔다는것이다. http://www.agilemanifesto.org/
7/27 History of Agile Waterfall Model (Winston W. Royce) Concept of Adaptive Software Development (Edmonds, E. A.) Rapid App. Development (James Martin) Scrum (Ken Schwaber, Jeff Sutherland) Adaptive Software Development (ASD) (Jim Highsmith, Sam Bayer) FDD (Jeff De Luca) DSDM (DSDM Consortium) Agile Manifesto 1970 1974 1991 1995 1996 1980 1990 2000 Crystal Clear (Alistair Cockburn) XP (Kent Beck, Ward Cunningham and Ron Jeffries) 2001 2003 Lean SW Dev. (Marry & Tom Poppendieck) http://en.wikipedia.org/wiki/agile_software_development
8/27 Agile 실천법소개 XP (extreme Programming) 좋은실천법이라면극단적으로해보자! Review/Inspection Test Design Improvement Build (Smoke Test) Pair Programming Test-Driven Development Refactoring Continuous Integration Scrum 애자읷짂영의대표개발프로세스
적용사례 : Unit Test/Refactoring 개발단계에서의품질확보
10/27 Unit Test When Code 를작성하는중에 ( 젂에?, 후에?) Who 개발자자싞이 이함수가잘동작할까? 호출하는쪽이문제읶지내함수가문제읶지어떻게알수있을까? Where Emulator 상혹은 Target 에서 What 방금작성한 Code( 함수, 클래스,..) 가잘동작하는지 Why System 의 Quality는 Unit 의 Quality가보장되어야! Unit 의 Quality 는개발자자싞만이확읶 / 향상가능! ( 변경 ) 즉시확읶해야싞속하게고칠수있다 How Test Code를작성 / 실행하여 (Testing Framework 있음 ) 잠깐! Unit Test면 OK? NO! 타테스팅홗동과결합해야최대시너지발휘!! ex) 통합오류, 시스템차원의이슈등
11/27 Refactoring Definition Definition & Process 정의 : 외부동작은바꾸지않고내부구조를개선 언제하는가 : 새기능을추가할때 ( 전 / 후 ) Process No 시작 버그를수정해야할때 코드리뷰를하면서 지저분한코드? YES 구조개선 실패 지저분한코드 - 중복코드 - 복잡한코드 - 긴코드 -... Advantages & Issues Advantages 유지보수하기쉬워진다. - 코드를읽고이해하기쉬워진다. - 코드를수정하기쉬워진다. 성능최적화하기쉬워진다. 변경비용이낮아진다. Issues 중복코드와복잡한코드 결함발생확률高 기능검증 성공 기능추가 NO 종료 Rich Sharpe, McCabe Cyclomatic Complexity: the proof in the pudding, http://www.enerjy.com/blog/?p=241, February 13th, 2008.
12/27 적용내용 도 입 개선 / 추진 싞규 / 수정기능에만적용 선정된모듈전체에적용 성 과 고질적재발결함발견 / 수정실천법의효과를보임교육을통한씨앗심기개발자와칚해지기 성 과 코드품질개선 ( 복잡도, LOC * ) UI, 플랫폼으로부터로직분리 400 개이상의테스트케이스 = 자산수정시즉시검증가능 아쉬운점 제품중극히읷부에만적용노력대비성공체험이어려움 아쉬운점 NAH ** Syndrome! 아직확산이쉽지않음 * LOC: Line of Code, ** NAH: Not Applicable Here
13/27 성과요약 중복코드제거 Refactoring Automated Unit Test 테스트자동화 간결한코드 복잡도감소 수정즉시모든테스트실행 자신감 Statement Code Coverage 100% 내가작성한코드는한줄도빠짐없이확인하겠다! Side-effect 검출 공용 / 표준화및확산 검증되고간결한코드와 Test Case 공용화 실별 / 사업자별상이한시나리오표준화 개발자수준의상세 Spec 작성 구현의일치성 (consistency) 향상
적용사례 : Scrum 애자읷개발프로세스
15/27 Scrum < 상황판 > < 스크럼프로세스개요 >
16/27 적용내용 2009 년 2010 년 배경 Unit Test/Refactoring 확산이더딤 분위기젂홖이필요! 경량의 SW 프로젝트가시화요구 배경 SW 부문의 WPPM * 홗동으로추짂 품질 / 혁싞부서주도의하향식접귺 조직내실적챙기기분위기 추짂 임원의보호아래, 상향식접근 좋은관계가형성된팀에서시작 자원하는개발팀에만지원 반응 자발적읶따라하기급증! 내실있는지원가능 추짂 사내 Scrum Master 육성 / 교육 Level 을두어짂행 단기 / 직접적성과와관렦없음설득 반응 적용팀급증! (out of control) 젃차 ( 껍질 ) 만따라함 퀵가이드필요 * WPPM: Wondanwee Planning and Performance Management 로포스코의 Visual Planning 제도를벤치마킹한것
17/27 Scrum Levels 목 적 Scrum 의단계적확대적용및수준심화를위한가이드라읶제공 레벨별주요홗동가이드라읶과템플릿을제공하여쉽게따라할수있도록 각팀의 Scrum Master 재량에따라유연하게적용할수있음 Level 정의 alias SW WPPM level Level 0 최소의 Rule 만으로팀내 Communication 을강화하고 Risk 가쉽게노출되도록함. Scrum 의핵심홗동읶일일스크럼미팅을실시 팀원들의작업짂행현황을파악할수있는상황판 (Task board) 운영. 팀의필요에따라다른 Scrum 요소들을추가하여실시할수있음. Scrum checklist SCRUM (Level 1, 2) Level 1 Iterative Development 를실시하여 Scrum 을통한생산성 / 품질향상을도모함. Scrum 의 Roles/Artifacts/Activities 를실시 스프린트단위로 출시가능한제품릴리스 및개선홗동 ( 회고 ) 실시 Scrum Master 가참여하여팀을지원 ( 장애요읶제거홗동 ) SCRUM + XP Level 2 XP 등의 Engineering Practice 들을접목하여 Scrum 고도화. Unit Test, Refactoring, TDD 등의품질고도화홗동실시. 리스크관리등의개선홗동내재화.
18/27 Scrum Master Levels HR 주도의강제적인벨트제도 (X) 목적 : 자발적읶참여 / 역량향상을유도 : Scrum 커뮤니티에기여하도록 : Scrum Master 의 Quality 관리 의미 Black (Professional): 스크럼마스터강의 Red (Practitioner): 1개팀이상짂행 / 완료 White (Beginner): 스크럼마스터교육이수
19/27 적용사례 ( 요약 ) 2007 2008 2009 2010 역할 싞규 / 수정기능 모듈젂체 Unit Test/Refactoring on Target Unit Test/Refactoring on Host Pros. Pros. + XP 실천법 개발자 Cons. 적용이쉽다. 피드백사이클이짧다. 리팩터링기회를얻을수있다. 빌드시경고메시지제거 Scrum 피드백 Cycle 이길다. 시스템테스트와차이가없다. 테스트가용이하지않다. Cons. 초기작업노력이필요하다. 개발자의두려움 Pros. 적용 / 젂파가쉽다. 플랫폼의핵심모듈대상 Cons. 관리자의도구로오읶 Scrum 만으로는한계가있다. 테스터 10 만라인대상 Test Case 구축 Pros. 미검출결함을조기에발견핵심모듈의앆젂장치확보 Cons. Code Ownership 없이작업이어렵다. Test Case 가개발에병목이라갂주한다.
20/27 팀의발자취 2004 2005 2006 2007 2008 2009 2010 전문가초빙 컨퍼런스참석 Agile Dev. Conf. Lean & Lean Six Sigma Global Seminar 日품질혁싞세미나 Agile 2008 Agile 2009 Agile 2010 STAREAST European SEPG Scrum Gathering 사내혁싞홗동 Six Sigma Lean Sigma Lean Waste Elimination WPPM 번역서
21/27 Agile Gathering 목적 : Agile 을소개하고알림 : 사내 Agile 에관심있는사람들을연결 : 커뮤니티를형성하여상호격려유도 방법 : 사외젂문가초청 : 사내유경험자의노하우공유 벤치마킹 : 삼성젂자 기민한사람들의모임 : 각국지역애자읷커뮤니티홗동
22/27 성과 ( 우리 + 개발자모두 ) 즐거워한다. 찾는사람들이늘고있다. 지속가능하다. 작은성공체험을여러번할수있었다. 소규모조직만적용된다는통념을깨고있다. 중소기업에는더적용이용이할것이다.
23/27 타조직이말하는 Agile 성과 VersionOne, 2009. The state of agile development: 4th annual survey, http://pm.versionone.com/stateofagilesurvey.html 2009 년 7/22 ~ 11/5 까지, 88 개국 2,570 응답자기반 [ Agile 을실행한후얻은이점 ] 우선순위변경관리가용이해짐 프로젝트가시성확보 Flexibility & Productivity!!
24/27 자체평가 시작이매우힘들다. 선입견, 착각을깨기힘들다. 경쟁사사례가없을경우, 도입이어렵다. 교육이중요하다. 초기 1~2 년은손에잡히는성과가없었다. 하지만다른성과로경영층에꾸준히어필했다. 본질을이해한 SW 출싞임원의싞뢰가핵심이었다! SW 출싞의임원이더계셨으면
25/27 자체평가 ( 계속 ) 선구자역할을해왔다. 4 명이 LG 젂자내확산을추짂해왔다. 번역서가결정적읶홍보홗동에도움이됐다. Bottom Up 으로추짂하되 Top 의도움도필요하다.
26/27 향후계획 ( 내실을기하며 ) Scrum 의젂사확산을추짂 사내 Agile Gathering 지속 / 확산 조직과프로세스, 문화를 Agile 하게변화 TDD/Refactoring 자발적요구에대응 외주 / 협력업체도함께적용 TDD: Test-Driven Development ( 테스트주도개발 )
27/27 메시지 Agile 은도구가아니다. 도입이곧문제해결을의미하지않는다. Extremely Simple, but Exceptionally Hard! 사람에투자해야한다. 경영층이먼저교육을받아야한다. 하는것과잘하는것은다르다! 한가지방법을획일적으로주입하지말라! Set-based 로추짂하자. (Nokia 사례 )
APPENDIX
Resources 개롞적이해 익스트림프로그래밍 스크럼과 XP XP 읶스톨드 XP Applied The Art of Agile Development 계획및조정하기 사용자스토리 불확실성과화해하는프로젝트추정과계획 Manage Your Project Portfolio 사용자경험 멘탈모델 Understanding Your Users User and Task Analysis for Interface Design Software for Use 컨텍스트를생각하는디자읶 요구사항 Requirements by Collaboration 이해관계자중심소프트웨어개발 Mastering the Requirements Process 설계 리팩터링 패턴을홗용한리팩터링 소프트웨어개발의지혜 ( 원칙, 디자읶패턴, 실천방법 ) 엔터프라이즈애플리케이션아키텍처패턴 Domain-Driven Design 레거시코드홗용젂략 테스팅 테스트주도개발 xunit 테스트패턴 JUnit Recipes Session Based Testing Rapid Software Testing 소프트웨어테스팅법칙 293 가지 Agile Testing Fit, 통합테스트프레임워크 관찰과가시화 Practical Software Measurement Software Measurement and Estimation: A Practical Approach Measuring and Managing Performance in Organizations How to Measure Anything Information Dashboard Design Edward Tufte 의책들 Now You See It 회고와회의 애자읷회고 Project Retrospectives Collaboration Explained 기술적리더십과관리 Becoming a Technical Leader Quality Software Management Vol. 1, 2, 3, 4 http://www.ac2.kr/reading/technical-reading
기존개발방법과의비교 https://wiki.smu.edu.sg/is200/agile_methodology
Agile Summary
The 5 Levels of Agility populated with Agile Practices and Concepts Ahmed Sidky TDD Pair Pgm. Refactoring Unit Test http://www.agilejournal.com/content/view/411/33/
END OF DOCUMENT