SlideShare une entreprise Scribd logo
1  sur  95
Télécharger pour lire hors ligne
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
LG전자 글로벌 네트워크
      현지 법인 117       임직원 82,000




          자회사 89      연락 사무소 28
          R&D 센터 31   디자인 센터 6
LG전자 제품군
Objectives

• 애자일 적용배경과 사례
 – 적용 경험과 성과, 조언


• 간략한 애자일 및 기법 소개
 – 품질, 생산성과 애자일의 관계


• 팀의 여정
N PI
개발자의 두려움

•   확정되지 않은 요구사항
•   일정/업무로드
•   복잡하고 더러운 코드
•   Side effect
•   …
테스터의 두려움

• 촉박한 일정
• 재발/Reopen
• 미검출 è 품질사고
근본적인 문제는?
Looooooooooong
feedback cycle!
3~4 month             2 week            2 week

Development   Devel.   Devel.   Devel.   Devel.   Devel.   Devel



               QA                QA                 QA


              2 week            2 week            2 week
우리 모두의 공통된 경험
              내가 짰구나?!!
 어떤 X가
이렇게 짰어!!
???          ???      ???


 3~4 month                   2 week            2 week

Development         Devel.   Devel.   Devel.   Devel.   Devel.   Devel



                     QA                QA                 QA


                    2 week            2 week            2 week
Brian Marick’s Test Categorization
                                Business Facing
 Support Programming

                                          Usability Test
                       Acceptance Test




                                                            Critique Product
                                         Exploratory Test




                          Unit Test      Performance Test



                              Technology Facing
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
시사점!!

• 개발<-> 품질 feedback 이 너무 길다!

• 개발에서 품질을 확보! Build Quality In

• 시험환경/방법을 개발에 미리 제공
 – 기출문제를 미리 풀어보도록!
What is   Agile?
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
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
                             작명
         중복코드 제거



메소드 추출
                          불필요한 코드 삭제
         복잡도 감소
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
개발   테스트




개발   테스트




개발   테스트
Tests ≡ Asset!
           Spec.
        Past defect

Safety Net (Regression Test)
R     DD          I    I   T   T
      Requirement #1


R     D           I        T
      Requirement #2

          ……
R R   D           I D      T       I   T
      Requirement #N
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
R                        R
            R
                           D
  D         D              I
                    ……
   I         I
                           T
  T         T
Req. #1   Req. #2        Req. #N
Scrum
Iterative & Incremental



                Inspect & Adapt
                   관 찰과 적응
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!



                      Stub
                      Mock




  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 관리 기법 필요!
Scrum
  < 상황판 >




            <스크럼 프로세스 개요>   67/121
적용 내용
           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 제도를 벤치마킹 한 것
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
Scrum Master Levels

  ※ HR 주도의 강제적인 벨트 제도 (X)

           목적
            : 자발적인 참여/역량향상을 유도
            : Scrum 커뮤니티에 기여하도록
            : Scrum Master의 Quality 관리


           의미
            Black (Professional): 스크럼 마스터 강의
            Red (Practitioner): 1개 팀 이상 진행/완료
            White (Beginner): 스크럼 마스터 교육 이수




                                         70/121
적용 가이드!

• 자원하는 팀만 지원

• 최소한의 Rule 만 제공
 –팀을 믿어라!!
내가 해봤는데
내가 해봤는데
도움도 안되고..
도움도 안되고..
 귀찮기만 해!
 귀찮기만 해!




"나쁜 소문이 좋은 소문보다 확산 속도가 네 배 더 빠르다“
"불안감이 높은 사람일수록 소문을 더 많이 듣고 더 많이 전한다"
팀이 걸어온 길
조직과 팀에 대한 소개
Engineering
Practice
                                             CTO
                            생산성
                                             R&D
                            연구원
                                             Lab
                                   사업부
                                  R&D Lab.




                                    SW
                      Process/     Center
              Cultural Change
2004      2005   2006         2007       2008      2009   2010




  2004      2005   2006         2007       2008      2009   2010




Six Sigma                              Lean
                   Lean Sigma                                WPPM
  6σ                             Waste Elimination
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시간 이내에 첫 답
       변을 드리는 것을 목표로 함.
Contact Information



           LG전자 생산성연구원
              심우곤 선임

http://www.wgshim.com   woogon.shim@lge.com
              @wgshim   wgshim@gmail.com
END OF PRESENTATION

Contenu connexe

Tendances

Flusso Continuous Integration & Continuous Delivery
Flusso Continuous Integration & Continuous DeliveryFlusso Continuous Integration & Continuous Delivery
Flusso Continuous Integration & Continuous DeliveryJoost van der Griendt
 
JavaのテストGroovyでいいのではないかという話
JavaのテストGroovyでいいのではないかという話JavaのテストGroovyでいいのではないかという話
JavaのテストGroovyでいいのではないかという話disc99_
 
Smarter deployments with octopus deploy
Smarter deployments with octopus deploySmarter deployments with octopus deploy
Smarter deployments with octopus deployThibaud Gravrand
 
소프트웨어 테스팅
소프트웨어 테스팅소프트웨어 테스팅
소프트웨어 테스팅영기 김
 
Ansible Tutorial.pdf
Ansible Tutorial.pdfAnsible Tutorial.pdf
Ansible Tutorial.pdfNigussMehari4
 
협업도구 및 주요 Agile practices 적용사례 v1.0
협업도구 및 주요 Agile practices 적용사례 v1.0협업도구 및 주요 Agile practices 적용사례 v1.0
협업도구 및 주요 Agile practices 적용사례 v1.0Sangcheol Hwang
 
Boost your App with Gatling
Boost your App with GatlingBoost your App with Gatling
Boost your App with GatlingKnoldus Inc.
 
Ksug2015 - JPA3, JPA 내부구조
Ksug2015 - JPA3, JPA 내부구조Ksug2015 - JPA3, JPA 내부구조
Ksug2015 - JPA3, JPA 내부구조Younghan Kim
 
我的 DevOps 故事
我的 DevOps 故事我的 DevOps 故事
我的 DevOps 故事Poy Chang
 
メトリクスによるソフトウェア品質把握と改善- 演習を交えた品質測定評価の落とし穴とコツの習得 -
メトリクスによるソフトウェア品質把握と改善- 演習を交えた品質測定評価の落とし穴とコツの習得 -メトリクスによるソフトウェア品質把握と改善- 演習を交えた品質測定評価の落とし穴とコツの習得 -
メトリクスによるソフトウェア品質把握と改善- 演習を交えた品質測定評価の落とし穴とコツの習得 -Hironori Washizaki
 
katalon studio 툴을 이용한 GUI 테스트 자동화 가이드
katalon studio 툴을 이용한 GUI 테스트 자동화 가이드katalon studio 툴을 이용한 GUI 테스트 자동화 가이드
katalon studio 툴을 이용한 GUI 테스트 자동화 가이드SangIn Choung
 
[기본과정] 코드 테스트와 커버리지 기본 교육(개념)
[기본과정] 코드 테스트와 커버리지 기본 교육(개념)[기본과정] 코드 테스트와 커버리지 기본 교육(개념)
[기본과정] 코드 테스트와 커버리지 기본 교육(개념)SangIn Choung
 
Agile 방법론
Agile 방법론Agile 방법론
Agile 방법론Astin Choi
 
Jenkins使ってみた~Windows編~
Jenkins使ってみた~Windows編~Jenkins使ってみた~Windows編~
Jenkins使ってみた~Windows編~Yuta Matsumura
 
Intro to Docker November 2013
Intro to Docker November 2013Intro to Docker November 2013
Intro to Docker November 2013Docker, Inc.
 
低レイヤー入門
低レイヤー入門低レイヤー入門
低レイヤー入門demuyan
 
VMの歩む道。 Dalvik、ART、そしてJava VM
VMの歩む道。 Dalvik、ART、そしてJava VMVMの歩む道。 Dalvik、ART、そしてJava VM
VMの歩む道。 Dalvik、ART、そしてJava VMyy yank
 

Tendances (20)

Flusso Continuous Integration & Continuous Delivery
Flusso Continuous Integration & Continuous DeliveryFlusso Continuous Integration & Continuous Delivery
Flusso Continuous Integration & Continuous Delivery
 
JavaのテストGroovyでいいのではないかという話
JavaのテストGroovyでいいのではないかという話JavaのテストGroovyでいいのではないかという話
JavaのテストGroovyでいいのではないかという話
 
Smarter deployments with octopus deploy
Smarter deployments with octopus deploySmarter deployments with octopus deploy
Smarter deployments with octopus deploy
 
소프트웨어 테스팅
소프트웨어 테스팅소프트웨어 테스팅
소프트웨어 테스팅
 
Ansible Tutorial.pdf
Ansible Tutorial.pdfAnsible Tutorial.pdf
Ansible Tutorial.pdf
 
Selenium with java
Selenium with javaSelenium with java
Selenium with java
 
협업도구 및 주요 Agile practices 적용사례 v1.0
협업도구 및 주요 Agile practices 적용사례 v1.0협업도구 및 주요 Agile practices 적용사례 v1.0
협업도구 및 주요 Agile practices 적용사례 v1.0
 
Boost your App with Gatling
Boost your App with GatlingBoost your App with Gatling
Boost your App with Gatling
 
Ksug2015 - JPA3, JPA 내부구조
Ksug2015 - JPA3, JPA 내부구조Ksug2015 - JPA3, JPA 내부구조
Ksug2015 - JPA3, JPA 내부구조
 
"DevOps > CI+CD "
"DevOps > CI+CD ""DevOps > CI+CD "
"DevOps > CI+CD "
 
我的 DevOps 故事
我的 DevOps 故事我的 DevOps 故事
我的 DevOps 故事
 
メトリクスによるソフトウェア品質把握と改善- 演習を交えた品質測定評価の落とし穴とコツの習得 -
メトリクスによるソフトウェア品質把握と改善- 演習を交えた品質測定評価の落とし穴とコツの習得 -メトリクスによるソフトウェア品質把握と改善- 演習を交えた品質測定評価の落とし穴とコツの習得 -
メトリクスによるソフトウェア品質把握と改善- 演習を交えた品質測定評価の落とし穴とコツの習得 -
 
katalon studio 툴을 이용한 GUI 테스트 자동화 가이드
katalon studio 툴을 이용한 GUI 테스트 자동화 가이드katalon studio 툴을 이용한 GUI 테스트 자동화 가이드
katalon studio 툴을 이용한 GUI 테스트 자동화 가이드
 
[기본과정] 코드 테스트와 커버리지 기본 교육(개념)
[기본과정] 코드 테스트와 커버리지 기본 교육(개념)[기본과정] 코드 테스트와 커버리지 기본 교육(개념)
[기본과정] 코드 테스트와 커버리지 기본 교육(개념)
 
Agile 방법론
Agile 방법론Agile 방법론
Agile 방법론
 
Jenkins使ってみた~Windows編~
Jenkins使ってみた~Windows編~Jenkins使ってみた~Windows編~
Jenkins使ってみた~Windows編~
 
Intro to Docker November 2013
Intro to Docker November 2013Intro to Docker November 2013
Intro to Docker November 2013
 
CICD with Jenkins
CICD with JenkinsCICD with Jenkins
CICD with Jenkins
 
低レイヤー入門
低レイヤー入門低レイヤー入門
低レイヤー入門
 
VMの歩む道。 Dalvik、ART、そしてJava VM
VMの歩む道。 Dalvik、ART、そしてJava VMVMの歩む道。 Dalvik、ART、そしてJava VM
VMの歩む道。 Dalvik、ART、そしてJava VM
 

En vedette

코드 리뷰 시스템 소개
코드 리뷰 시스템 소개코드 리뷰 시스템 소개
코드 리뷰 시스템 소개Young-Ho Cha
 
깨끗한 코드 (클린 코드, Clean Code)
깨끗한 코드 (클린 코드, Clean Code)깨끗한 코드 (클린 코드, Clean Code)
깨끗한 코드 (클린 코드, Clean Code)Jay Park
 
카카오스토리 웹팀의 코드리뷰 경험
카카오스토리 웹팀의 코드리뷰 경험카카오스토리 웹팀의 코드리뷰 경험
카카오스토리 웹팀의 코드리뷰 경험Ohgyun Ahn
 
우리가 몰랐던 크롬 개발자 도구
우리가 몰랐던 크롬 개발자 도구우리가 몰랐던 크롬 개발자 도구
우리가 몰랐던 크롬 개발자 도구Jae Sung Park
 
KGC2007 Scrum And Xp
KGC2007 Scrum And XpKGC2007 Scrum And Xp
KGC2007 Scrum And Xp기룡 남
 
스크럼, 이걸 왜 하나요
스크럼, 이걸 왜 하나요스크럼, 이걸 왜 하나요
스크럼, 이걸 왜 하나요Insub Lee
 
애자일 개발 프로세스를 이용한 고품질 소프트웨어 개발
애자일 개발 프로세스를 이용한 고품질 소프트웨어 개발애자일 개발 프로세스를 이용한 고품질 소프트웨어 개발
애자일 개발 프로세스를 이용한 고품질 소프트웨어 개발Jaehoon Oh
 
애자일 도입과 사례 공유
애자일 도입과 사례 공유애자일 도입과 사례 공유
애자일 도입과 사례 공유agilekorea
 
애자일 스크럼과 JIRA
애자일 스크럼과 JIRA 애자일 스크럼과 JIRA
애자일 스크럼과 JIRA Terry Cho
 
애자일활용사례
애자일활용사례애자일활용사례
애자일활용사례Dexter Jung
 
Agile - SCRUM을 통한 개발관리
Agile - SCRUM을 통한 개발관리Agile - SCRUM을 통한 개발관리
Agile - SCRUM을 통한 개발관리SangJin Kang
 
DevOps와 자동화
DevOps와 자동화DevOps와 자동화
DevOps와 자동화DONGSU KIM
 
DEVOPS 에 대한 전반적인 소개 및 자동화툴 소개
DEVOPS 에 대한 전반적인 소개 및 자동화툴 소개DEVOPS 에 대한 전반적인 소개 및 자동화툴 소개
DEVOPS 에 대한 전반적인 소개 및 자동화툴 소개태준 문
 
개발 생산성 향상 기법 V1.2
개발 생산성 향상 기법 V1.2개발 생산성 향상 기법 V1.2
개발 생산성 향상 기법 V1.2Daniel Lim
 
스크럼 리뷰 이지원 발표용
스크럼 리뷰 이지원 발표용스크럼 리뷰 이지원 발표용
스크럼 리뷰 이지원 발표용지원 이
 
Social commerce
Social commerceSocial commerce
Social commerce김은선
 
Managers Role In Scrum Kor
Managers Role In Scrum KorManagers Role In Scrum Kor
Managers Role In Scrum KorPaul Jung
 
Scrum - Agile Development Process
Scrum - Agile Development ProcessScrum - Agile Development Process
Scrum - Agile Development ProcessKook Maeng
 
Enterprise agile in real world
Enterprise agile in real worldEnterprise agile in real world
Enterprise agile in real worldagilekorea
 

En vedette (20)

코드 리뷰 시스템 소개
코드 리뷰 시스템 소개코드 리뷰 시스템 소개
코드 리뷰 시스템 소개
 
깨끗한 코드 (클린 코드, Clean Code)
깨끗한 코드 (클린 코드, Clean Code)깨끗한 코드 (클린 코드, Clean Code)
깨끗한 코드 (클린 코드, Clean Code)
 
애자일의 모든것
애자일의 모든것애자일의 모든것
애자일의 모든것
 
카카오스토리 웹팀의 코드리뷰 경험
카카오스토리 웹팀의 코드리뷰 경험카카오스토리 웹팀의 코드리뷰 경험
카카오스토리 웹팀의 코드리뷰 경험
 
우리가 몰랐던 크롬 개발자 도구
우리가 몰랐던 크롬 개발자 도구우리가 몰랐던 크롬 개발자 도구
우리가 몰랐던 크롬 개발자 도구
 
KGC2007 Scrum And Xp
KGC2007 Scrum And XpKGC2007 Scrum And Xp
KGC2007 Scrum And Xp
 
스크럼, 이걸 왜 하나요
스크럼, 이걸 왜 하나요스크럼, 이걸 왜 하나요
스크럼, 이걸 왜 하나요
 
애자일 개발 프로세스를 이용한 고품질 소프트웨어 개발
애자일 개발 프로세스를 이용한 고품질 소프트웨어 개발애자일 개발 프로세스를 이용한 고품질 소프트웨어 개발
애자일 개발 프로세스를 이용한 고품질 소프트웨어 개발
 
애자일 도입과 사례 공유
애자일 도입과 사례 공유애자일 도입과 사례 공유
애자일 도입과 사례 공유
 
애자일 스크럼과 JIRA
애자일 스크럼과 JIRA 애자일 스크럼과 JIRA
애자일 스크럼과 JIRA
 
애자일활용사례
애자일활용사례애자일활용사례
애자일활용사례
 
Agile - SCRUM을 통한 개발관리
Agile - SCRUM을 통한 개발관리Agile - SCRUM을 통한 개발관리
Agile - SCRUM을 통한 개발관리
 
DevOps와 자동화
DevOps와 자동화DevOps와 자동화
DevOps와 자동화
 
DEVOPS 에 대한 전반적인 소개 및 자동화툴 소개
DEVOPS 에 대한 전반적인 소개 및 자동화툴 소개DEVOPS 에 대한 전반적인 소개 및 자동화툴 소개
DEVOPS 에 대한 전반적인 소개 및 자동화툴 소개
 
개발 생산성 향상 기법 V1.2
개발 생산성 향상 기법 V1.2개발 생산성 향상 기법 V1.2
개발 생산성 향상 기법 V1.2
 
스크럼 리뷰 이지원 발표용
스크럼 리뷰 이지원 발표용스크럼 리뷰 이지원 발표용
스크럼 리뷰 이지원 발표용
 
Social commerce
Social commerceSocial commerce
Social commerce
 
Managers Role In Scrum Kor
Managers Role In Scrum KorManagers Role In Scrum Kor
Managers Role In Scrum Kor
 
Scrum - Agile Development Process
Scrum - Agile Development ProcessScrum - Agile Development Process
Scrum - Agile Development Process
 
Enterprise agile in real world
Enterprise agile in real worldEnterprise agile in real world
Enterprise agile in real world
 

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

TDD&Refactoring Day 02: TDD
TDD&Refactoring Day 02: TDDTDD&Refactoring Day 02: TDD
TDD&Refactoring Day 02: TDDSuwon Chae
 
Advanced nGrinder
Advanced nGrinderAdvanced nGrinder
Advanced nGrinderJunHo Yoon
 
제13회컨퍼런스 조대협 서버사이드개발
제13회컨퍼런스 조대협 서버사이드개발제13회컨퍼런스 조대협 서버사이드개발
제13회컨퍼런스 조대협 서버사이드개발Terry Cho
 
애자일과 애자일 테스트 소개 (테스트기본교육 3장 2절)
애자일과 애자일 테스트 소개 (테스트기본교육 3장 2절)애자일과 애자일 테스트 소개 (테스트기본교육 3장 2절)
애자일과 애자일 테스트 소개 (테스트기본교육 3장 2절)SangIn Choung
 
111 n grinder-deview_day1_track1_session_1_ver_2
111 n grinder-deview_day1_track1_session_1_ver_2111 n grinder-deview_day1_track1_session_1_ver_2
111 n grinder-deview_day1_track1_session_1_ver_2NAVER D2
 
테스트 자동화와 TDD(테스트 주도 개발방법론)
테스트 자동화와 TDD(테스트 주도 개발방법론)테스트 자동화와 TDD(테스트 주도 개발방법론)
테스트 자동화와 TDD(테스트 주도 개발방법론)KH Park (박경훈)
 
투비웨어 AgitarOne Junit 단위테스트자동화 솔루션소개_201608_v1.2
투비웨어 AgitarOne Junit 단위테스트자동화 솔루션소개_201608_v1.2투비웨어 AgitarOne Junit 단위테스트자동화 솔루션소개_201608_v1.2
투비웨어 AgitarOne Junit 단위테스트자동화 솔루션소개_201608_v1.2tobeware
 
[H3 2012] 스마트모바일 환경에서의 App.품질관리전략
[H3 2012] 스마트모바일 환경에서의 App.품질관리전략[H3 2012] 스마트모바일 환경에서의 App.품질관리전략
[H3 2012] 스마트모바일 환경에서의 App.품질관리전략KTH, 케이티하이텔
 
[Hello world 오픈세미나]n grinder helloworld발표자료_저작권free
[Hello world 오픈세미나]n grinder helloworld발표자료_저작권free[Hello world 오픈세미나]n grinder helloworld발표자료_저작권free
[Hello world 오픈세미나]n grinder helloworld발표자료_저작권freeNAVER D2
 
최우성 구별하여 사용하면 좋은 프로젝트 관련용어
최우성 구별하여 사용하면 좋은 프로젝트 관련용어최우성 구별하여 사용하면 좋은 프로젝트 관련용어
최우성 구별하여 사용하면 좋은 프로젝트 관련용어drandom
 
How Google Tests Software (구글의 소프트웨어 테스팅)
How Google Tests Software (구글의 소프트웨어 테스팅)How Google Tests Software (구글의 소프트웨어 테스팅)
How Google Tests Software (구글의 소프트웨어 테스팅)Ye Joo Park
 
EMOCON 2015 - 품질과 테스트는 다르다
EMOCON 2015 - 품질과 테스트는 다르다EMOCON 2015 - 품질과 테스트는 다르다
EMOCON 2015 - 품질과 테스트는 다르다이상한모임
 
Growing object oriented software guided by test
Growing object oriented software guided by testGrowing object oriented software guided by test
Growing object oriented software guided by test라한사 아
 
발표자료 1인qa로살아남는6가지방법
발표자료 1인qa로살아남는6가지방법발표자료 1인qa로살아남는6가지방법
발표자료 1인qa로살아남는6가지방법SangIn Choung
 
스마트 모바일 앱 개발 방법론(2)
스마트 모바일 앱 개발 방법론(2)스마트 모바일 앱 개발 방법론(2)
스마트 모바일 앱 개발 방법론(2)mosaicnet
 
VSTS와 Azure를 이용한 팀 프로세스 관리
VSTS와 Azure를 이용한 팀 프로세스 관리VSTS와 Azure를 이용한 팀 프로세스 관리
VSTS와 Azure를 이용한 팀 프로세스 관리Gyuwon Yi
 
SonarQube와 함께하는 소프트웨어 품질 세미나 - 소프트웨어 품질의 중요성
SonarQube와 함께하는 소프트웨어 품질 세미나 - 소프트웨어 품질의 중요성SonarQube와 함께하는 소프트웨어 품질 세미나 - 소프트웨어 품질의 중요성
SonarQube와 함께하는 소프트웨어 품질 세미나 - 소프트웨어 품질의 중요성CURVC Corp
 

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

TDD&Refactoring Day 02: TDD
TDD&Refactoring Day 02: TDDTDD&Refactoring Day 02: TDD
TDD&Refactoring Day 02: TDD
 
Advanced nGrinder
Advanced nGrinderAdvanced nGrinder
Advanced nGrinder
 
제13회컨퍼런스 조대협 서버사이드개발
제13회컨퍼런스 조대협 서버사이드개발제13회컨퍼런스 조대협 서버사이드개발
제13회컨퍼런스 조대협 서버사이드개발
 
애자일과 애자일 테스트 소개 (테스트기본교육 3장 2절)
애자일과 애자일 테스트 소개 (테스트기본교육 3장 2절)애자일과 애자일 테스트 소개 (테스트기본교육 3장 2절)
애자일과 애자일 테스트 소개 (테스트기본교육 3장 2절)
 
111 n grinder-deview_day1_track1_session_1_ver_2
111 n grinder-deview_day1_track1_session_1_ver_2111 n grinder-deview_day1_track1_session_1_ver_2
111 n grinder-deview_day1_track1_session_1_ver_2
 
테스트 자동화와 TDD(테스트 주도 개발방법론)
테스트 자동화와 TDD(테스트 주도 개발방법론)테스트 자동화와 TDD(테스트 주도 개발방법론)
테스트 자동화와 TDD(테스트 주도 개발방법론)
 
투비웨어 AgitarOne Junit 단위테스트자동화 솔루션소개_201608_v1.2
투비웨어 AgitarOne Junit 단위테스트자동화 솔루션소개_201608_v1.2투비웨어 AgitarOne Junit 단위테스트자동화 솔루션소개_201608_v1.2
투비웨어 AgitarOne Junit 단위테스트자동화 솔루션소개_201608_v1.2
 
[H3 2012] 스마트모바일 환경에서의 App.품질관리전략
[H3 2012] 스마트모바일 환경에서의 App.품질관리전략[H3 2012] 스마트모바일 환경에서의 App.품질관리전략
[H3 2012] 스마트모바일 환경에서의 App.품질관리전략
 
[Hello world 오픈세미나]n grinder helloworld발표자료_저작권free
[Hello world 오픈세미나]n grinder helloworld발표자료_저작권free[Hello world 오픈세미나]n grinder helloworld발표자료_저작권free
[Hello world 오픈세미나]n grinder helloworld발표자료_저작권free
 
최우성 구별하여 사용하면 좋은 프로젝트 관련용어
최우성 구별하여 사용하면 좋은 프로젝트 관련용어최우성 구별하여 사용하면 좋은 프로젝트 관련용어
최우성 구별하여 사용하면 좋은 프로젝트 관련용어
 
How Google Tests Software (구글의 소프트웨어 테스팅)
How Google Tests Software (구글의 소프트웨어 테스팅)How Google Tests Software (구글의 소프트웨어 테스팅)
How Google Tests Software (구글의 소프트웨어 테스팅)
 
TDD
TDDTDD
TDD
 
EMOCON 2015 - 품질과 테스트는 다르다
EMOCON 2015 - 품질과 테스트는 다르다EMOCON 2015 - 품질과 테스트는 다르다
EMOCON 2015 - 품질과 테스트는 다르다
 
Growing object oriented software guided by test
Growing object oriented software guided by testGrowing object oriented software guided by test
Growing object oriented software guided by test
 
Game qa
Game qaGame qa
Game qa
 
발표자료 1인qa로살아남는6가지방법
발표자료 1인qa로살아남는6가지방법발표자료 1인qa로살아남는6가지방법
발표자료 1인qa로살아남는6가지방법
 
Tdd ver.2
Tdd ver.2Tdd ver.2
Tdd ver.2
 
스마트 모바일 앱 개발 방법론(2)
스마트 모바일 앱 개발 방법론(2)스마트 모바일 앱 개발 방법론(2)
스마트 모바일 앱 개발 방법론(2)
 
VSTS와 Azure를 이용한 팀 프로세스 관리
VSTS와 Azure를 이용한 팀 프로세스 관리VSTS와 Azure를 이용한 팀 프로세스 관리
VSTS와 Azure를 이용한 팀 프로세스 관리
 
SonarQube와 함께하는 소프트웨어 품질 세미나 - 소프트웨어 품질의 중요성
SonarQube와 함께하는 소프트웨어 품질 세미나 - 소프트웨어 품질의 중요성SonarQube와 함께하는 소프트웨어 품질 세미나 - 소프트웨어 품질의 중요성
SonarQube와 함께하는 소프트웨어 품질 세미나 - 소프트웨어 품질의 중요성
 

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

  • 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
  • 4.
  • 5. Objectives • 애자일 적용배경과 사례 – 적용 경험과 성과, 조언 • 간략한 애자일 및 기법 소개 – 품질, 생산성과 애자일의 관계 • 팀의 여정
  • 6.
  • 7.
  • 9.
  • 10.
  • 11. 개발자의 두려움 • 확정되지 않은 요구사항 • 일정/업무로드 • 복잡하고 더러운 코드 • Side effect • …
  • 12. 테스터의 두려움 • 촉박한 일정 • 재발/Reopen • 미검출 è 품질사고
  • 15. 3~4 month 2 week 2 week Development Devel. Devel. Devel. Devel. Devel. Devel QA QA QA 2 week 2 week 2 week
  • 16. 우리 모두의 공통된 경험 내가 짰구나?!! 어떤 X가 이렇게 짰어!!
  • 17. ??? ??? ??? 3~4 month 2 week 2 week Development Devel. Devel. Devel. Devel. Devel. Devel QA QA QA 2 week 2 week 2 week
  • 18. Brian Marick’s Test Categorization Business Facing Support Programming Usability Test Acceptance Test Critique Product Exploratory Test Unit Test Performance Test Technology Facing
  • 19. 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
  • 20. 시사점!! • 개발<-> 품질 feedback 이 너무 길다! • 개발에서 품질을 확보! Build Quality In • 시험환경/방법을 개발에 미리 제공 – 기출문제를 미리 풀어보도록!
  • 21. What is Agile?
  • 22. 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
  • 23. 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
  • 26.
  • 27. Refactoring 작명 중복코드 제거 메소드 추출 불필요한 코드 삭제 복잡도 감소
  • 28. 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
  • 29. 개발 테스트 개발 테스트 개발 테스트
  • 30. Tests ≡ Asset! Spec. Past defect Safety Net (Regression Test)
  • 31. R DD I I T T Requirement #1 R D I T Requirement #2 …… R R D I D T I T Requirement #N
  • 32. 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
  • 33. R R R D D D I …… I I T T T Req. #1 Req. #2 Req. #N
  • 34. Scrum Iterative & Incremental Inspect & Adapt 관 찰과 적응
  • 36.
  • 37.
  • 39. 다른 시스템의 경우… • 1996 Windows NT: 11-12 MLOC • 2001 Windows XP: 40 MLOC • 1996 Boeing 777: 4 MLOC (Ada)
  • 40. Answer is … 10,000,000 LOC (10 Million LOC)
  • 42.
  • 43. The Boy Scout Rule! “Leave the campground cleaner than you found it” -- Robert C. Martin, “Clean Code”
  • 44. TDD (Unit Test), Refactoring
  • 47. 일정지연 책임질 거냐!! 귀찮게 하지 마라!
  • 48. 오해 마세요~ 나쁜 살암 아니예효~ 저..정말요?
  • 49. 결함/문제 해결위주 접근 현업에 필요한 세미나를 제공하며 개발자와 친밀하게
  • 51. 진행 결과 • 테스트 자동화에 대한 우호적 반응 – 하지만, “여전히 남이 해줬으면…” • 개발자와의 관계형성이 최우선! – 실질적인 도움 • 걸음마 단계…
  • 52. Step 2. 조금 더!!
  • 53. 신규 & 변경되는 기능에 집중 (결함 해결 Task도 지원)
  • 54.
  • 55. Emulator 에서 Unit Testing Framework 사용!
  • 56. Hard to test! Stub Mock Refactoring 필요! Testable Design 필요!
  • 57. 진행 결과 • Refactoring 사례 발굴 – 코드 50% 감소, 설계 개선을 통한 속도↑ • Test Code 가 자산으로 존재하는 기능들 • 결함 해결을 위한 도구 개발 • ROI 측면, A-Ha! 경험제공 필요
  • 58. ME
  • 59. Step 3. 모듈을 통째로! With Test-Driven Development!
  • 60.
  • 61. • Ownership이 있는 담당자와 함께! • 플랫폼, UI 와 Logic 을 분리!! • Test-Driven Development! – 완전히 새로 작성! • Host 에서 확인!
  • 62. 진행 결과 • Best Practice 사례 확보 – 사내 표준 모듈로 선정 – 즉시 모든 기능, 과거 결함 확인가능 • 테스트케이스 400 개 이상 • Statement Coverage 100% • 복잡도 급감
  • 63.
  • 64. 진행 결과 (계속) • 초기 투입노력 ç 도움 필요 • 소수의 변화된 개발자 • 하지만 Practice 확산은 여전히 어렵다! • 여전히 NAH(Not Applicable Here) 신드롬!!
  • 65. 적용 가이드! • Practice 측면 – Unit Test 부터!! à Refactoring!! – 하지만 반드시 같이! • 대상 측면 – Legacy 에 Unit Test 는 어렵다!! – 신규/고질 불량부터 – 쉬운 것부터 출발하라!
  • 67. 경량의 SW Project 관리 기법 필요!
  • 68. Scrum < 상황판 > <스크럼 프로세스 개요> 67/121
  • 69. 적용 내용 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 제도를 벤치마킹 한 것
  • 70. 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
  • 71. Scrum Master Levels ※ HR 주도의 강제적인 벨트 제도 (X) 목적 : 자발적인 참여/역량향상을 유도 : Scrum 커뮤니티에 기여하도록 : Scrum Master의 Quality 관리 의미 Black (Professional): 스크럼 마스터 강의 Red (Practitioner): 1개 팀 이상 진행/완료 White (Beginner): 스크럼 마스터 교육 이수 70/121
  • 72. 적용 가이드! • 자원하는 팀만 지원 • 최소한의 Rule 만 제공 –팀을 믿어라!!
  • 73. 내가 해봤는데 내가 해봤는데 도움도 안되고.. 도움도 안되고.. 귀찮기만 해! 귀찮기만 해! "나쁜 소문이 좋은 소문보다 확산 속도가 네 배 더 빠르다“ "불안감이 높은 사람일수록 소문을 더 많이 듣고 더 많이 전한다"
  • 75. 조직과 팀에 대한 소개 Engineering Practice CTO 생산성 R&D 연구원 Lab 사업부 R&D Lab. SW Process/ Center Cultural Change
  • 76. 2004 2005 2006 2007 2008 2009 2010 2004 2005 2006 2007 2008 2009 2010 Six Sigma Lean Lean Sigma WPPM 6σ Waste Elimination
  • 77. You’re not alone. Meet you at agile gathering!
  • 79. 성과 • (우리 + 개발자 모두) 즐거워 한다. • 찾는 사람들이 늘고 있다. • 소규모 조직만 적용 된다는 통념을 깨고 있다. • 중소기업에는 더 적용이 용이할 것이다.
  • 80. 자체 평가 • 시작이 매우 힘들다. – 선입견, 착각을 깨기 힘들다. – 경쟁사 사례가 없을 경우, 도입이 어렵다. – 교육이 중요하다. – 초기 1~2년은 손에 잡히는 성과가 없었다. • 하지만 다른 성과로 경영층에 꾸준히 어필했다. – 본질을 이해한 SW출신 임원의 신뢰가 핵심이었다! • SW출신의 임원이 더 계셨으면…
  • 81. 자체 평가 (계속) • 선구자 역할을 해왔다. – 4 명이 LG전자 내 확산을 추진해왔다. – 번역서가 결정적인 홍보활동에 도움이 됐다. – Bottom Up으로 추진하되 Top 의 도움도 필요하다.
  • 82. 향후 계획 • (내실을 기하며) Scrum 의 전사 확산을 추진 • 사내 Agile Gathering 지속/확산 • 조직과 프로세스, 문화를 Agile 하게 변화 • TDD/Refactoring 자발적 요구에 대응 • 외주/협력업체도 함께 적용
  • 84. 에이~~~ 에이~~~ 우리 팀이 하던 거랑 우리 팀이 하던 거랑 별로 차이가 없네!! 별로 차이가 없네!!
  • 87.
  • 88.
  • 89. 꼭 전달하고픈 메시지 • Agile 은 도구가 아니다. – 도입이 곧 문제 해결을 의미하지 않는다. – Extremely Simple, but Exceptionally Hard! • 사람에 투자해야 한다. – 경영층이 먼저 교육을 받고 해봐야 한다. • 하는 것과 잘 하는 것은 다르다! • 한 가지 방법을 획일적으로 주입하지 말라! – Set-based 로 추진하자. (Nokia 사례)
  • 90. 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/
  • 93. 한국 Agile Community • Xper – Korea eXtreme Programming Users' Group – http://xper.org/ (위키) – http://groups.google.com/group/xper (메일링) • 초보자를 위한 메일링 리스트 – http://groups.google.com/group/abqna • 애자일을 시작하시는 분들을 위한 질의응답 메일 링 리스트. 어떤 질문이든지 48시간 이내에 첫 답 변을 드리는 것을 목표로 함.
  • 94. Contact Information LG전자 생산성연구원 심우곤 선임 http://www.wgshim.com woogon.shim@lge.com @wgshim wgshim@gmail.com