2010 Software Quality Insight Conference    24 Jun 2010
                             http://www.sec2010.co.kr/




  개발 생산...
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



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

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



      ...
Brian Marick’s Test Categorization
                                Business Facing
 Support Programming

                 ...
Brian Marick’s Test Categorization
                                  Business Facing
Automated
 Automated                 ...
시사점!!

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

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

• 시험환경/방법을 개발에 미리 제공
 – 기출문제를 미리 풀어보도록!
What is   Agile?
History of Agile
                                                     Scrum
                                              ...
Agile Manifesto

   프로세스와 도구 보다      개인과 상호 소통이 더 중요하다
   Individuals and interactions over processes and tools

포괄적인 문서화 ...
eXtreme Programming(XP) ??
“좋은 실천법이라면
극단적으로 해보자!”
Refactoring
                             작명
         중복코드 제거



메소드 추출
                          불필요한 코드 삭제
         복잡도 감소
p
                     g st e
                 i
              usb
          e ro              Test
        ng            ...
개발   테스트




개발   테스트




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

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


R     D           I        T
      Requirement #2

          ……
R ...
RR    D D I            IT   T
     Requirement #1
           Requirement #1


RR    D D I            IT   T
     Requireme...
R                        R
            R
                           D
  D         D              I
                    ……
...
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년
                    ...
Scrum Levels
      목 적
      목 적
           • Scrum의 단계적 확대 적용 및 수준 심화를 위한 가이드라인 제공
           • 레벨 별 주요 활동 가이드라인과 템플릿을 제공...
Scrum Master Levels

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

           목적
            : 자발적인 참여/역량향상을 유도
            : Scrum 커뮤니티에 기여하...
적용 가이드!

• 자원하는 팀만 지원

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




"나쁜 소문이 좋은 소문보다 확산 속도가 네 배 더 빠르다“
"불안감이 높은 사람일수록 소문을 더 많이 듣고 더 많...
팀이 걸어온 길
조직과 팀에 대한 소개
Engineering
Practice
                                  CTO
              생산성
                                ...
2004      2005   2006         2007       2008      2009   2010




  2004      2005   2006         2007       2008      20...
You’re not alone.
Meet you at agile gathering!
성과 및 의미
성과

• (우리 + 개발자 모두) 즐거워 한다.

• 찾는 사람들이 늘고 있다.

• 소규모 조직만 적용 된다는 통념을 깨고 있다.

• 중소기업에는 더 적용이 용이할 것이다.
자체 평가

• 시작이 매우 힘들다.
 – 선입견, 착각을 깨기 힘들다.
 – 경쟁사 사례가 없을 경우, 도입이 어렵다.
 – 교육이 중요하다.
 – 초기 1~2년은 손에 잡히는 성과가 없었다.
   • 하지만 다른 성...
자체 평가 (계속)

• 선구자 역할을 해왔다.
 – 4 명이 LG전자 내 확산을 추진해왔다.
 – 번역서가 결정적인 홍보활동에 도움이 됐다.
 – Bottom Up으로 추진하되 Top 의 도움도 필요하다.
향후 계획

• (내실을 기하며) Scrum 의 전사 확산을 추진

• 사내 Agile Gathering 지속/확산

• 조직과 프로세스, 문화를 Agile 하게 변화

• TDD/Refactoring 자발적 요구에 대...
끝으로…
에이~~~
   에이~~~

우리 팀이 하던 거랑
우리 팀이 하던 거랑
별로 차이가 없네!!
 별로 차이가 없네!!
성룡 취권
취객 취권
꼭 전달하고픈 메시지
• Agile 은 도구가 아니다.
 – 도입이 곧 문제 해결을 의미하지 않는다.
 – Extremely Simple, but Exceptionally Hard!

• 사람에 투자해야 한다.
 – 경...
Agile Manifesto 다시 보기

   프로세스와 도구 보다      개인과 상호 소통이 더 중요하다
   Individuals and interactions over processes and tools

포괄적...
고맙습니다.
질의 응답
한국 Agile Community
• Xper
  – Korea eXtreme Programming Users' Group
  – http://xper.org/ (위키)
  – http://groups.google.co...
Contact Information



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

http://www.wgshim.com   woogon.shim@lge.com
          ...
END OF PRESENTATION
개발 생산성과 품질 향상을 위한 글로벌기업의 애자일 도입 및 적용사례
개발 생산성과 품질 향상을 위한 글로벌기업의 애자일 도입 및 적용사례
개발 생산성과 품질 향상을 위한 글로벌기업의 애자일 도입 및 적용사례
개발 생산성과 품질 향상을 위한 글로벌기업의 애자일 도입 및 적용사례
개발 생산성과 품질 향상을 위한 글로벌기업의 애자일 도입 및 적용사례
개발 생산성과 품질 향상을 위한 글로벌기업의 애자일 도입 및 적용사례
개발 생산성과 품질 향상을 위한 글로벌기업의 애자일 도입 및 적용사례
개발 생산성과 품질 향상을 위한 글로벌기업의 애자일 도입 및 적용사례
개발 생산성과 품질 향상을 위한 글로벌기업의 애자일 도입 및 적용사례
개발 생산성과 품질 향상을 위한 글로벌기업의 애자일 도입 및 적용사례
개발 생산성과 품질 향상을 위한 글로벌기업의 애자일 도입 및 적용사례
개발 생산성과 품질 향상을 위한 글로벌기업의 애자일 도입 및 적용사례
개발 생산성과 품질 향상을 위한 글로벌기업의 애자일 도입 및 적용사례
개발 생산성과 품질 향상을 위한 글로벌기업의 애자일 도입 및 적용사례
Upcoming SlideShare
Loading in...5
×

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

5,317

Published on

Published in: Technology, Business
0 Comments
14 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
5,317
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
201
Comments
0
Likes
14
Embeds 0
No embeds

No notes for slide

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

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

    Clipping is a handy way to collect important slides you want to go back to later.

×