Successfully reported this slideshow.

Work With Engineer

772 views

Published on

Product Manager 대상으로 개발자와 일하려면 어떻게 해야 하는지 설명하는 발표이고 주로 SW 개발 과정이 어떻게 되고 PM은 어떤 역할을 해야 하는지 설명했음

  • Be the first to comment

Work With Engineer

  1. 1. Work with Engineer & Team building http://www.flickr.com/photos/ivyfield/8154073189/ 박성철 / Platform SW 개발 1 팀
  2. 2. (-.-) (_ _) (-.-)
  3. 3. 生卽苦
  4. 4. Software Crisis
  5. 5. 소프트웨어 위기의 주요한 위기는 컴퓨터 성능이 몇 수십 배나 더 강력해졌기 때문입 니다 ! 심하게 말하면 , 컴퓨터가 없었을 때는 프로그래밍에는 전혀 문제가 없었습니 다 . 느린 컴퓨터 몇 개 뿐이었을 때는 프로그래밍이 조금 문제가 되었고 , 이제는 거 대한 컴퓨터에 프로그래밍도 따라서 거대한 문제가 되었습니다 . - 에츠허르 데이크스트라
  6. 6. 소프트웨어 위기의 주요한 위기는 컴퓨터 성능이 몇 수십 배나 더 강력해졌기 때 문입니다 ! 심하게 말하면 , 컴퓨터가 없었을 때는 프로그래밍에는 전혀 문제가 없었습니다 . 느린 컴퓨터 몇 개 뿐이었을 때는 프로그래밍이 조금 문제가 되었고 , 이제는 거대한 컴퓨터에 프로그래밍도 따라서 거대한 문제가 되었습니다 . - 에츠허르 데이크스트라
  7. 7. x
  8. 8. 규모 + 섬세함 = 복잡도 SW 개발 = 문제 해결 + 복잡도 처리
  9. 9. SW 개발 프로젝트의 목표 ?
  10. 10. SW's 결함 ● 비싼 가격 ● 빈번하고 과한 예산 초과 ● 출시 지연 ● 부실한 문서 ● 통합 불가 ● 환경 이전 , 기능 개선 불가 ● 유지보수가 어렵고 오류가 쉽게 발생 ● 불안정한 성능 ● SW 가 요구사항과 맞지 않음 ● 조기에 용량 한계에 다다름 ● 사용하기 어려움 ● SW 요구사항이 사용자의 필요에 부합하지 않음
  11. 11. SW 개발은 무엇인가 ?
  12. 12. 工場 http://www.flickr.com/photos/wackymacs/113838729/
  13. 13. 과학적 관리법 지침 , 측정 , 예측 , 평가
  14. 14. 공장 같은 개발 절차 단순한 코딩 작업 계 한설 정교 산출물 별 단계 분석 설계 설계 구현 ( 코딩 ) 테스트 제조 배치 ( 배포 , 납품 )
  15. 15. 폭포수 개발 방법론 분석 설계 구현 ( 코딩 ) 테스트 배치 ( 배포 , 납품 )
  16. 16. 폭포수 개발 방법론 Factory Model/Architecture Components Assembly line Centralized Control Architect is “GOD” Coding is simple Code Generation UML Engineering Estimation Perfect Planning Control Science Process Repeatable Process PM = Process Champions Good Process = Good Product
  17. 17. http://www.fotopedia.com/items/flickr-4698936102
  18. 18. http://warsongdeathmark.deviantart.com/art/No-acting-experience-required-170992014
  19. 19. Waterfall 의 문제 ● ● ● ● ● ● Big Design Up Front(BDUF) 완벽한 문서화 강조 단방향 ( 학습 / 피드백 불가 ) 변경이 어려움 고비용 / 저효율 프로세스 = 경직성
  20. 20. 무술 / 장인 ● 단순하고 우아하고 숙련 ( 수련 ) 에 초점 ● 도구 상자 접근법 ● 숙련자 / 대가 / 구루 모델 ● 사람에 매우 의존적 설계는 해법을 선택하는 지침을 제공 http://www.flickr.com/photos/jasonteale/1675863028/
  21. 21. 반복 , 초고 , 다듬기 , 교정 / 교열 ● 정해진 구조 안에서 창의성에 집중 ● 저술 / 작곡 ● 목적은 알지만 결과는 정해지지 않음 ● 창의적인 절차를 정해진 범위 , 마감 , 예산에 맞추는 것이 어려움 http://www.flickr.com/photos/olivander/58499153/sizes/z/in/photostream/
  22. 22. 단체 스포츠 경기 ● ● ● ● 목표를 위해 협력 사전에 정해진 지시 없는 프로세스 경기 규정은 있지만 결과는 불명 협력하는 활동인 협연과 춤도 포함 http://commons.wikimedia.org/wiki/File:British_and_Irish_Lions_scrum.jpg
  23. 23. SW 개발 = 집단적이고 종료가 있는 목표 추구 경기
  24. 24. 닝겐 ... 강점 ● 문제를 알아서 해결한다 ● 소통한다 ● 스스로 결정한다 ● 모방한다 약점 ● 일관성이 없다 ● 훈련하기 어렵다 ● 지침을 기계적으로 따르는데 익숙 하지 않다
  25. 25. 드레이퍼스dreyfus 기술 습득 모델 1단계: 초보자 배운 규칙을 기계적으로 충실하게 잘 따른다. 상황의 특수성은 전혀 고려되지 않는다. 2단계: 상급 입문자 규칙을 적용한 경험이 쌓여가고 상황을 인식하게 된다. 규칙 외에 상황에 따른 격언을 배우고 이를 적용한다. 지금까지는 일이 잘못되더라도 자기가 배운 지식의 문제라고 생각한다. 3단계: 중급자 당면한 상황에 맞는 목표를 선택하고 계획을 세워 실행한다. 초보 시절에 따라하기에 급급하던 규칙이나 격언들을 상황에 맞게 선택적으로 사용한다. 자신의 선택에 어느 정도 책임을 느낀 다. 4단계: 숙련자 기술 보다는 해결해야 하는 과제에 집중한다. 많은 경험으로 얻는 특별한 시각을 갖고 있어 직 관적으로 과제의 특성을 이해하고 조직화 한다. 하지만 대응할 때에는 분석적으로 사고한다. 5단계: 대가 상황을 이해하는 것 뿐만 아니라 어떻게 행위해야 하는지도 직관적이다. 마치 자신의 몸을 움 직이듯 모든 것이 직관적일 뿐이다.
  26. 26. SW 개발 방법론
  27. 27. 결국 폭포수 모델은...
  28. 28. Feedback
  29. 29. 움직이는 타겟
  30. 30. SW 개발 방법론
  31. 31. 반복 개발 (Iterative Development)
  32. 32. Light v.s Heavy ? Light Weight : Heavy Weight Running SW : Plan Driven Lean : Fat
  33. 33. 대안 개발 방법론 경량 프로세스 ● 초단기 반복 개발 주기 ● 쾌속 프로토타이핑 , 쾌속 개발 ● 주도적이고 모두 모여 일하는 팀 ( 고객 포함 ) ● 팀의 도메인 지식 강조 ( 프로젝트 = 학습 ) ● 점진적 출시 ● 자기 조직적 팀 ● 정확한 예측 보다는 빠른 적응 ● 단순한 설계 ●
  34. 34. Agile? Waterfall? Factor Size Mission Critical Projects Stability and complexity of existing environmen t Skills Organizatio nal Culture Agile Characteristic Optimal for small projects and teams, reliance on domain knowledge Untested, general lack of documentation Waterfall Characteristic Tailored for large projects and teams Continuous refactoring used, suitable for dynamic and simple environments Structured baselines used, suitable for more static and complex environments Continuous involvement of highly skilled individuals, difficult to cope with many lower skilled resources Chaotic, dynamic, empowered Highly skilled resources needed in early phases, designed to cope with many lower skilled resources in later phases Roles well defined, procedures in place Long history of use in such implementations
  35. 35. 스크럼 (Scrum)
  36. 36. 스프린트 (Sprint)
  37. 37. 제품 백로그 제품에 적용될 요구사항의 단일한 원천 ● ● ● ● 제품이 살아 있는 동안 완료되지 않고 갱신됨 요구사항 , 변경사항 , 결함 우선순위 , 시급성 , 가치에 따라서 정렬 ( 관리자가 아닌 ) 개발팀이 개발 기간을 추정 스프린트 백로그 ● ● ● ● 현 스프린트에서 처리할 작업 목록 제품 백로그의 최우선 항목을 상세화해서 도출 스프린트 계획 회의에서 상세화 개발팀이 항목 당 개발 비용 추정
  38. 38. 스프린트 계획 회의 ● ● ● ● 스프린트 시작 전에 시행 시간 제한 해당 스프린트에서 전달할 제품 증분 ( 목표 ) 을 결정 ● 제품 백로그에서 기능 항목을 선택해서 스프린트 목표를 정의 제품 증분을 달성할 방법 협의 ● 기능 항목에서 세부 작업을 도출하고 개발 비용을 추정 순서에 따라 제품 백로그 선택 스프린트 백로그 ( 목표 )
  39. 39. 작업판
  40. 40. 역할 스크럼 마스터 제품 책임자 이해 관계자 개발자
  41. 41. 개발자 동작하는 SW 를 Iteration 마다 출시 가능한 상태로 인도할 책임이 있음 ● 자기 조직화 ● 자기 종결적 (Cross Functional) 스크럼 마스터 스크럼 진행 담당자 ● ● ● ● 프로젝트 장애 제거 스크럼 진행 촉진 소통 촉진 프로젝트 관리자가 아님
  42. 42. 제품 책임자 사람이 아닌 제품을 관리 ● 프로젝트의 핵심 이해 관계자 ● 프로젝트 비전 제시 ● Product Backlog 작성 책임 ● 사용자 대리인 ● Backlog Item 을 명확하게 표현 ● 가치에 따라 Backlog Item 의 우선 순위를 결정 ●
  43. 43. 제품 비전 프로젝트를 시작하는데 필요한 최소한의 계획으로 비전 , 필수 정보 , 제약 사항 , 초기 제품 백로그 등으로 구성된다 . ● ● ● ● ● ● ● 프로젝트 헌장 (Project Charter) 모든 팀원이 작성에 참여하고 동의해야 함 비전 = 프로젝트를 시작하는 이유와 추구하는 목적 프로젝트의 방향을 잡아주는 나침반 팀 빌딩의 핵심 도구 PRD 의 확장 단순 명료 ( 엘리베이터 테스트 )
  44. 44. 기타 ...
  45. 45. 新工場 http://www.flickr.com/photos/wackymacs/113838729/
  46. 46. God is in the detail Devil also is in the detail
  47. 47. 공장 같은 개발 절차 분석 SW 제품 설계 설계 문서인 코드 구현 ( 코딩 ) 테스트 컴파일러가 제품을 제조 단순 반복적인 작업은 사람보다 컴퓨터가 잘 하는 일 ... 설계 제조
  48. 48. 개발자는 누구 ?
  49. 49. People over Process THX

×