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

1. Work with Engineer & Team building
http://www.flickr.com/photos/ivyfield/8154073189/
박성철 / Platform SW 개발 1 팀

2. (-.-) (_ _) (-.-)

3. 生卽苦

7. Software Crisis

8. 소프트웨어 위기의 주요한 위기는 컴퓨터 성능이 몇 수십 배나 더 강력해졌기 때문입
니다 ! 심하게 말하면 , 컴퓨터가 없었을 때는 프로그래밍에는 전혀 문제가 없었습니
다 . 느린 컴퓨터 몇 개 뿐이었을 때는 프로그래밍이 조금 문제가 되었고 , 이제는 거
대한 컴퓨터에 프로그래밍도 따라서 거대한 문제가 되었습니다 .
- 에츠허르 데이크스트라

12. 소프트웨어 위기의 주요한 위기는 컴퓨터 성능이 몇 수십 배나 더 강력해졌기 때
문입니다 ! 심하게 말하면 , 컴퓨터가 없었을 때는 프로그래밍에는 전혀 문제가
없었습니다 . 느린 컴퓨터 몇 개 뿐이었을 때는 프로그래밍이 조금 문제가 되었고 ,
이제는 거대한 컴퓨터에 프로그래밍도 따라서 거대한 문제가 되었습니다 .
- 에츠허르 데이크스트라

13. x

15. 규모 + 섬세함 = 복잡도
SW 개발 = 문제 해결 + 복잡도 처리

16. SW 개발 프로젝트의 목표 ?

18. SW's 결함
●
비싼 가격
●
빈번하고 과한 예산 초과
●
출시 지연
●
부실한 문서
●
통합 불가
●
환경 이전 , 기능 개선 불가
●
유지보수가 어렵고 오류가 쉽게 발생
●
불안정한 성능
●
SW 가 요구사항과 맞지 않음
●
조기에 용량 한계에 다다름
●
사용하기 어려움
●
SW 요구사항이 사용자의 필요에 부합하지 않음

19. SW 개발은 무엇인가 ?

21. 工場
http://www.flickr.com/photos/wackymacs/113838729/

22. 과학적 관리법
지침 , 측정 , 예측 , 평가

23. 공장 같은 개발 절차
단순한 코딩 작업
계
한설
정교
산출물
별
단계
분석
설계
설계
구현
( 코딩 )
테스트
제조
배치
( 배포 , 납품 )

24. 폭포수 개발 방법론
분석
설계
구현
( 코딩 )
테스트
배치
( 배포 , 납품 )

25. 폭포수 개발 방법론
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

26. http://www.fotopedia.com/items/flickr-4698936102

27. http://warsongdeathmark.deviantart.com/art/No-acting-experience-required-170992014

29. Waterfall 의 문제
●
●
●
●
●
●
Big Design Up Front(BDUF)
완벽한 문서화 강조
단방향 ( 학습 / 피드백 불가 )
변경이 어려움
고비용 / 저효율
프로세스 = 경직성

30. 무술 / 장인
●
단순하고 우아하고 숙련 ( 수련 ) 에 초점
●
도구 상자 접근법
●
숙련자 / 대가 / 구루 모델
●
사람에 매우 의존적
설계는 해법을 선택하는 지침을 제공
http://www.flickr.com/photos/jasonteale/1675863028/

31. 반복 , 초고 , 다듬기 , 교정 / 교열
●
정해진 구조 안에서 창의성에 집중
●
저술 / 작곡
●
목적은 알지만 결과는 정해지지 않음
●
창의적인 절차를 정해진 범위 , 마감 , 예산에 맞추는 것이
어려움
http://www.flickr.com/photos/olivander/58499153/sizes/z/in/photostream/

33. 단체 스포츠 경기
●
●
●
●
목표를 위해 협력
사전에 정해진 지시 없는 프로세스
경기 규정은 있지만 결과는 불명
협력하는 활동인 협연과 춤도 포함
http://commons.wikimedia.org/wiki/File:British_and_Irish_Lions_scrum.jpg

34. SW 개발
=
집단적이고
종료가 있는
목표 추구 경기

38. 닝겐 ...
강점
●
문제를 알아서 해결한다
●
소통한다
●
스스로 결정한다
●
모방한다
약점
●
일관성이 없다
●
훈련하기 어렵다
●
지침을 기계적으로 따르는데 익숙
하지 않다

40. 드레이퍼스dreyfus 기술 습득 모델
1단계: 초보자
배운 규칙을 기계적으로 충실하게 잘 따른다. 상황의 특수성은 전혀 고려되지 않는다.
2단계: 상급 입문자
규칙을 적용한 경험이 쌓여가고 상황을 인식하게 된다. 규칙 외에 상황에 따른 격언을 배우고
이를 적용한다. 지금까지는 일이 잘못되더라도 자기가 배운 지식의 문제라고 생각한다.
3단계: 중급자
당면한 상황에 맞는 목표를 선택하고 계획을 세워 실행한다. 초보 시절에 따라하기에 급급하던
규칙이나 격언들을 상황에 맞게 선택적으로 사용한다. 자신의 선택에 어느 정도 책임을 느낀
다.
4단계: 숙련자
기술 보다는 해결해야 하는 과제에 집중한다. 많은 경험으로 얻는 특별한 시각을 갖고 있어 직
관적으로 과제의 특성을 이해하고 조직화 한다. 하지만 대응할 때에는 분석적으로 사고한다.
5단계: 대가
상황을 이해하는 것 뿐만 아니라 어떻게 행위해야 하는지도 직관적이다. 마치 자신의 몸을 움
직이듯 모든 것이 직관적일 뿐이다.

41. SW 개발 방법론

42. 결국 폭포수 모델은...

43. Feedback

44. 움직이는 타겟

45. SW 개발 방법론

46. 반복 개발 (Iterative Development)

47. Light v.s Heavy ?
Light Weight : Heavy Weight
Running SW : Plan Driven
Lean : Fat

48. 대안 개발 방법론
경량 프로세스
● 초단기 반복 개발 주기
● 쾌속 프로토타이핑 , 쾌속 개발
● 주도적이고 모두 모여 일하는 팀 ( 고객 포함 )
● 팀의 도메인 지식 강조 ( 프로젝트 = 학습 )
● 점진적 출시
● 자기 조직적 팀
● 정확한 예측 보다는 빠른 적응
● 단순한 설계
●

52. 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

53. 스크럼 (Scrum)

54. 스프린트 (Sprint)

56. 제품 백로그
제품에 적용될 요구사항의 단일한 원천
●
●
●
●
제품이 살아 있는 동안 완료되지 않고 갱신됨
요구사항 , 변경사항 , 결함
우선순위 , 시급성 , 가치에 따라서 정렬
( 관리자가 아닌 ) 개발팀이 개발 기간을 추정
스프린트 백로그
●
●
●
●
현 스프린트에서 처리할 작업 목록
제품 백로그의 최우선 항목을 상세화해서 도출
스프린트 계획 회의에서 상세화
개발팀이 항목 당 개발 비용 추정

57. 스프린트 계획 회의
●
●
●
●
스프린트 시작 전에 시행
시간 제한
해당 스프린트에서 전달할 제품 증분 ( 목표 ) 을 결정
● 제품 백로그에서 기능 항목을 선택해서 스프린트 목표를 정의
제품 증분을 달성할 방법 협의
● 기능 항목에서 세부 작업을 도출하고 개발 비용을 추정
순서에 따라 제품 백로그 선택
스프린트 백로그 ( 목표 )

58. 작업판

60. 역할
스크럼 마스터
제품 책임자
이해 관계자
개발자

61. 개발자
동작하는 SW 를 Iteration 마다 출시 가능한
상태로 인도할 책임이 있음
● 자기 조직화
● 자기 종결적 (Cross Functional)
스크럼 마스터
스크럼 진행 담당자
●
●
●
●
프로젝트 장애 제거
스크럼 진행 촉진
소통 촉진
프로젝트 관리자가 아님

62. 제품 책임자
사람이 아닌 제품을 관리
● 프로젝트의 핵심 이해 관계자
● 프로젝트 비전 제시
● Product Backlog 작성 책임
● 사용자 대리인
● Backlog Item 을 명확하게 표현
● 가치에 따라 Backlog Item 의 우선 순위를 결정
●

63. 제품 비전
프로젝트를 시작하는데 필요한 최소한의 계획으로 비전 , 필수 정보 , 제약
사항 , 초기 제품 백로그 등으로 구성된다 .
●
●
●
●
●
●
●
프로젝트 헌장 (Project Charter)
모든 팀원이 작성에 참여하고 동의해야 함
비전 = 프로젝트를 시작하는 이유와 추구하는 목적
프로젝트의 방향을 잡아주는 나침반
팀 빌딩의 핵심 도구
PRD 의 확장
단순 명료 ( 엘리베이터 테스트 )

65. 기타 ...

66. 新工場
http://www.flickr.com/photos/wackymacs/113838729/

67. God is in the detail
Devil also is in the detail

68. 공장 같은 개발 절차
분석
SW 제품
설계
설계 문서인 코드
구현 ( 코딩 )
테스트
컴파일러가 제품을 제조
단순 반복적인 작업은 사람보다 컴퓨터가 잘 하는 일 ...
설계
제조

70. 개발자는 누구 ?

72. People over Process
THX