Your SlideShare is downloading. ×
개발 생산성과 품질 향상을 위한 글로벌기업의 애자일 도입 및 적용사례
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

개발 생산성과 품질 향상을 위한 글로벌기업의 애자일 도입 및 적용사례

4,975
views

Published on

Published in: Technology, Business

0 Comments
13 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,975
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
182
Comments
0
Likes
13
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

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