개발 생산성과 품질 향상을 위한 글로벌기업의 애자일 도입 및 적용사례
DESCRIPTION
TRANSCRIPT
개발 생산성과 품질향상을 위한글로벌 기업의 애자일 도입 및 적용 사례
LG전자 생산성연구원심우곤 선임
@wgshim [email protected]
[email protected]://www.wgshim.com
2010 Software Quality Insight Conference http://www.sec2010.co.kr/
24 Jun 2010
LG전자 글로벌 네트워크
자회사 89
R&D 센터 31 디자인 센터 6
연락 사무소 28
현지 법인 117 임직원 82,000
LG전자 제품군
Objectives
• 애자일 적용배경과 사례–적용 경험과 성과, 조언
• 간략한 애자일 및 기법 소개–품질, 생산성과 애자일의 관계
• 팀의 여정
NPI
개발자의 두려움
• 확정되지 않은 요구사항• 일정/업무로드• 복잡하고 더러운 코드• Side effect• …
테스터의 두려움
• 촉박한 일정• 재발/Reopen• 미검출 è 품질사고
근본적인 문제는?
Looooooooooongfeedback cycle!
Development
3~4 month
QA
2 week
Devel.
2 week
2 week
QA
2 week
Devel.
2 week
QA
DevelDevel. Devel. Devel.
우리 모두의 공통된 경험내가 짰구나?!!어떤 X가이렇게 짰어!!
Development
3~4 month
QA
2 week
Devel.
2 week
2 week
QA
2 week
Devel.
2 week
QA
DevelDevel. Devel. Devel.
??? ??????
Usability TestExploratory Test
Performance Test
Acceptance Test
Unit Test
Brian Marick’s Test CategorizationBusiness Facing
Technology Facing
Critiq
ue P
roduct
Support
Pro
gra
mm
ing
Usability TestExploratory Test
Performance Test
Acceptance Test
Unit Test
Brian Marick’s Test CategorizationBusiness Facing
Technology Facing
Critiq
ue P
roduct
Support
Pro
gra
mm
ing
AutomatedAutomated
AutomatedAutomated
ManualManual
Tool-basedTool-based
시사점!!
• 개발<-> 품질 feedback 이 너무 길다!
• 개발에서 품질을 확보! Build Quality In
• 시험환경/방법을 개발에 미리 제공–기출문제를 미리 풀어보도록!
What is Agile?
History of Agile
http://en.wikipedia.org/wiki/Agile_software_development
1980 1990 2000
Waterfall Model(Winston W. Royce)
Concept of“Adaptive Software Development”
(Edmonds, E. A.)
Scrum(Ken Schwaber, Jeff Sutherland)
Adaptive Software Development (ASD)(Jim Highsmith, Sam Bayer)
FDD(Jeff De Luca)
DSDM(DSDM Consortium)
1995
1996
Crystal Clear(Alistair Cockburn)
XP(Kent Beck, Ward Cunningham and Ron Jeffries)
2001
Agile ManifestoRapid App. Development
(James Martin)
1974 1991
2003
Lean SW Dev.(Marry & Tom Poppendieck)
1970
Scrum
Lean SW Dev.
XP
Agile Manifesto
개인과 상호 작용을 공정과 도구보다
Individuals and interactions over processes and tools
작동하는 소프트웨어를 포괄적인 문서화보다
Working software over comprehensive documentation
고객과의 협력을 계약 협상보다
Customer collaboration over contract negotiation
변화에 응대하기를 계획을 따르는 것 보다
Responding to change over following a plan
eXtreme Programming(XP) ??
“좋은 실천법이라면극단적으로 해보자!”
Refactoring
중복코드 제거
복잡도 감소불필요한 코드 삭제
작명
메소드 추출
One danger
ous big ste
p
Extract method
Move Method
Replace Conditional with polymorphismTest
Test
Test
TestCleanup names
OR
개발 테스트
개발 테스트
개발 테스트
Tests ≡ Asset!Spec.
Past defect
Safety Net (Regression Test)
Requirement #1
R D I T
Requirement #2
R D I T
Requirement #N
R D I T
……
R D I T
R D I T
R D I T
……
Requirement #1
R D I T
Requirement #2
R D I T
Requirement #N
R D I T
…………
Requirement #1
R D I T
Requirement #2
Requirement #N
R D I T
R D I T
Req. #1
R
D
I
T
……
Req. #2
R
D
I
T
Req. #N
R
DI
T
Scrum
Inspect & Adapt
관찰과 적응
Iterative & Incremental
Case Study
Quiz.
핸드폰 소스코드의 크기는?
다른 시스템의 경우…
• 1996 Windows NT: 11-12 MLOC• 2001 Windows XP: 40 MLOC
• 1996 Boeing 777: 4 MLOC (Ada)
Answer is …
10,000,000 LOC(10 Million LOC)
The key is
Professionalism!
The Boy Scout Rule!
“Leave the campground cleaner than you found it”
-- Robert C. Martin, “Clean Code”
TDD (Unit Test), Refactoring
Step 1. 도입!
당.연.히…
Unit Test 교육 실시!
일정지연책임질 거냐!!
귀찮게하지 마라!
오해 마세요~나쁜 살암 아니예효~
저..정말요?
결함/문제 해결위주 접근
현업에 필요한세미나를 제공하며개발자와 친밀하게
개발팀 부담 최소화!!
진행 결과
• 테스트 자동화에 대한 우호적 반응–하지만, “여전히 남이 해줬으면…”
• 개발자와의 관계형성이 최우선!–실질적인 도움
• 걸음마 단계…
Step 2. 조금 더!!
신규 & 변경되는 기능에 집중
(결함 해결 Task도 지원)
Emulator 에서Unit Testing Framework 사용!
Hard to test!
StubMock
Refactoring 필요!Testable Design 필요!
진행 결과
• Refactoring 사례 발굴–코드 50% 감소, 설계 개선을 통한 속도↑
• Test Code 가 자산으로 존재하는 기능들
• 결함 해결을 위한 도구 개발
• ROI 측면, A-Ha! 경험제공 필요
ME
Step 3. 모듈을 통째로!With Test-Driven Development!
• Ownership이 있는 담당자와 함께!
• 플랫폼, UI 와 Logic 을 분리!!
• Test-Driven Development!–완전히 새로 작성!
• Host 에서 확인!
진행 결과
• Best Practice 사례 확보–사내 표준 모듈로 선정–즉시 모든 기능, 과거 결함 확인가능
• 테스트케이스 400 개 이상• Statement Coverage 100%• 복잡도 급감
진행 결과 (계속)
• 초기 투입노력 ç 도움 필요
• 소수의 변화된 개발자
• 하지만 Practice 확산은 여전히 어렵다!
• 여전히 NAH(Not Applicable Here) 신드롬!!
적용 가이드!
• Practice 측면– Unit Test 부터!! à Refactoring!!–하지만 반드시 같이!
• 대상 측면– Legacy 에 Unit Test 는 어렵다!!–신규/고질 불량부터–쉬운 것부터 출발하라!
Step 4. SCRUM
경량의 SW Project 관리 기법 필요!
67/121
Scrum
< 상황판 >
<스크럼 프로세스 개요>
68/121
적용 내용
2010년2010년2009년2009년
ü Unit Test/Refactoring 확산이 더딤è 분위기 전환이 필요!
ü 경량의 SW 프로젝트 가시화 요구
ü SW 부문의 WPPM* 활동으로 추진ü 품질/혁신부서 주도의 하향식 접근ü 조직 내 실적 챙기기 분위기
ü 자발적인 따라 하기 급증!ü 내실 있는 지원 가능
ü 임원의 보호 아래, 상향식 접근ü 좋은 관계가 형성된 팀에서 시작ü 자원하는 개발 팀에만 지원
배 경
추 진
반 응
배 경
추 진
반 응
ü 사내 Scrum Master 육성/교육ü Level 을 두어 진행ü 단기/직접적 성과와 관련 없음 설득
ü 적용 팀 급증! (out of control)ü 절차(껍질)만 따라 함ü 퀵 가이드 필요
* WPPM: Wondanwee Planning and Performance Management 로 포스코의 Visual Planning 제도를 벤치마킹 한 것
69/121
Scrum Levels
• Scrum의 단계적 확대 적용 및 수준 심화를 위한 가이드라인 제공• 레벨 별 주요 활동 가이드라인과 템플릿을 제공하여 쉽게 따라 할 수 있도록• 각 팀의 Scrum Master 재량에 따라 유연하게 적용할 수 있음
Level 0
Level 1
Level 2
• Scrum의 핵심 활동인 일일 스크럼 미팅을 실시• 팀원들의 작업 진행 현황을 파악할 수 있는 상황판(Task board) 운영.• 팀의 필요에 따라 다른 Scrum 요소들을 추가하여 실시 할 수 있음.
최소의 Rule 만으로 팀 내 Communication 을 강화하고 Risk가쉽게 노출되도록 함.
• Scrum의 Roles/Artifacts/Activities 를 실시• 스프린트 단위로 ‘출시 가능한 제품 릴리스’ 및 개선활동(회고) 실시• Scrum Master 가 참여하여 팀을 지원 (장애요인 제거 활동)
Iterative Development 를 실시하여 Scrum 을 통한 생산성/품질 향상을 도모함.
• Unit Test, Refactoring, TDD 등의 품질 고도화 활동 실시.• 리스크 관리 등의 개선활동 내재화.
XP 등의 Engineering Practice 들을 접목하여 Scrum 고도화.
SW WPPM
SCRUM(Level 1, 2)
SCRUM + XP
목 적목 적
Level 정의Level 정의
alias
level
Scrum checklist
70/121
목 적: 자발적인 참여/역량향상을 유도: Scrum 커뮤니티에 기여하도록: Scrum Master의 Quality 관리
Scrum Master Levels
의 미
Black (Professional): 스크럼 마스터 강의Red (Practitioner): 1개 팀 이상 진행/완료White (Beginner): 스크럼 마스터 교육 이수
※ HR 주도의 강제적인 벨트 제도 (X)
•자원하는 팀만 지원
•최소한의 Rule 만 제공–팀을 믿어라!!
적용 가이드!
"나쁜 소문이 좋은 소문보다 확산 속도가 네 배 더 빠르다“"불안감이 높은 사람일수록 소문을 더 많이 듣고 더 많이 전한다"
내가 해봤는데도움도 안되고..귀찮기만 해!
내가 해봤는데도움도 안되고..귀찮기만 해!
팀이 걸어온 길
CTOR&D Lab
SWCenter
생산성연구원
사업부R&D Lab.
EngineeringPractice
Process/Cultural Change
조직과 팀에 대한 소개
2004 2006 2008 2010200920072005
2004 2006 2008 2010200920072005
Lean SigmaSix Sigma
6σLean
Waste Elimination WPPM
You’re not alone.Meet you at agile gathering!
성과 및 의미
성 과
• (우리 + 개발자 모두) 즐거워 한다.
• 찾는 사람들이 늘고 있다.
• 소규모 조직만 적용 된다는 통념을 깨고 있다.
• 중소기업에는 더 적용이 용이할 것이다.
자체 평가
• 시작이 매우 힘들다.
– 선입견, 착각을 깨기 힘들다.
– 경쟁사 사례가 없을 경우, 도입이 어렵다.
– 교육이 중요하다.
– 초기 1~2년은 손에 잡히는 성과가 없었다.
• 하지만 다른 성과로 경영층에 꾸준히 어필했다.
– 본질을 이해한 SW출신 임원의 신뢰가 핵심이었다!
• SW출신의 임원이 더 계셨으면…
자체 평가 (계속)
• 선구자 역할을 해왔다.
– 4 명이 LG전자 내 확산을 추진해왔다.
– 번역서가 결정적인 홍보활동에 도움이 됐다.
– Bottom Up으로 추진하되 Top 의 도움도 필요하다.
향후 계획
• (내실을 기하며) Scrum 의 전사 확산을 추진
• 사내 Agile Gathering 지속/확산
• 조직과 프로세스, 문화를 Agile 하게 변화
• TDD/Refactoring 자발적 요구에 대응
• 외주/협력업체도 함께 적용
끝으로…
에이~~~
우리 팀이 하던 거랑별로 차이가 없네!!
에이~~~
우리 팀이 하던 거랑별로 차이가 없네!!
성룡 취권
취객 취권
꼭 전달하고픈 메시지
• Agile 은 도구가 아니다. – 도입이 곧 문제 해결을 의미하지 않는다.– Extremely Simple, but Exceptionally Hard!
• 사람에 투자해야 한다.– 경영층이 먼저 교육을 받고 해봐야 한다.
• 하는 것과 잘 하는 것은 다르다!
• 한 가지 방법을 획일적으로 주입하지 말라!– Set-based 로 추진하자. (Nokia 사례)
Agile Manifesto 다시 보기
개인과 상호 작용을 공정과 도구보다
Individuals and interactions over processes and tools
작동하는 소프트웨어를 포괄적인 문서화보다
Working software over comprehensive documentation
고객과의 협력을 계약 협상보다
Customer collaboration over contract negotiation
변화에 응대하기를 계획을 따르는 것 보다
Responding to change over following a plan
http://www.agilemanifesto.org/
고맙습니다.
질의 응답
한국 Agile Community
• Xper– Korea eXtreme Programming Users' Group– http://xper.org/ (위키)– http://groups.google.com/group/xper (메일링)
• 초보자를 위한 메일링 리스트– http://groups.google.com/group/abqna
• 애자일을 시작하시는 분들을 위한 질의응답 메일링 리스트. 어떤 질문이든지 48시간 이내에 첫 답변을 드리는 것을 목표로 함.
END OF PRESENTATION