맹 대리 고객 가치를 위한 개발자 마인드 :다카하시 메소드, 프리젠테이션 젠, 그리고 주저리주저리

Presentation on theme: "맹 대리 고객 가치를 위한 개발자 마인드 :다카하시 메소드, 프리젠테이션 젠, 그리고 주저리주저리"— Presentation transcript:

1 맹 대리 고객 가치를 위한 개발자 마인드 :다카하시 메소드, 프리젠테이션 젠, 그리고 주저리주저리
개요, 소프트웨어 공학 관심 배경 (계속되는 프로젝트의 실패, 왜 실패할까?) 제목을 저렇게 한거.. SM 보다는 SI에 해당하는… 뭘할까 고민. 이 발표가 당장 써먹을 수 있는??, 재미가 없을수도, 관심이 없을수도.

2 Frederick Winslow Taylor (1856.3.20~1915.3.21 ), 과학적 관리법(테일러시스템) 창안
사람들이 얼마나 빨리 삽질을할수 있는지 초시계를 들고 삽질의 동작을 수천 번 관찰했다 그리고 마침내 시간-동작의 연구를 통해 삽질을 할때 가장 좋은 방법을 얻어냈다.

3 테일러는 과학적 작업의 예로 한 삽에 21파운드의 석탄을 퍼낼 때 삽질의 효울이 가장 높다고 설명한다.
한가지 오류 : 2명이 삽질을 한다. 효율을 높이기 위해 2명을 더 투입한다. 그럼 과연 효과가 있을까? 삽질 교육, 삽이 두개뿐이라면? 삽질을 위한 구멍이 하나 등등…. 프로젝트 : 성공적인 오픈을 위하여 사람을 투입? 위와 비슷한 문제 발생

4 프로세스? 방법론? (죠낸 많아) … 폭포수(Waterfall)
프로젝트 방법론 : 프로토타이핑 모형, 점증적 모형, 나선형 모형, V모형, 일정중심설계모형, 진화적출시 모형 등………. 현재 폭포수 모델이 대부분.. (분석, 설계, 구현, 테스트..), 각 단계별 산출물 중요. 변경이 힘들다. 그러나 처음의 요구사항과 나중에 요구사항에는 큰 차이가 발생할 수 있다. 아니 대부분 그렇다. 제품을 눈으로 보고 사용해보기 전에는 진정으로 원하는게 뭔지 모름. 예) 아주대 있을 때의 경험. (갔더니 사용자와 개발자가 만난 적이 거의 없어) 소프트웨어 엔지니어링 : 매우 큰 NATO 시스템 프로젝트의 문제들을 처리하기 위해 고안, 1960년대 후반과 70년대 초에 컴퓨터 하드웨어와 그 새로운 하드웨어를 위한 소프트웨어 개발에의 기술 수준을 이끌어갔다. 그 때 이후로 미 국방성의 요구사항들이 소프트웨어 엔지니어링에 관한 대화를 이끌어갔다. 하드웨어 개발과 동시 진행, 소프트웨어 개발자는 분석, 설계에 엄청난 시간 투자, 하드웨어 개발 끝나면 그 문서를 바탕으로 바로 개발 시작, 개발자를 많이 투입하면 된다는 인식.

5 문서화 상당히 어려운 일

6 Donald C. Gause 와 Gerald M. Weinberg
"Mary에게는 작은 양이 하나 있었네."

7 "Mary에게는 작은 양이 하나 있었네." 그것은 Mary의 양이었지 John의 양이 아니었다.

8 "Mary에게는 작은 양이 하나 있었네." 그녀는 이제 그 양을 가지고 있지 않다.

9 "Mary에게는 작은 양이 하나 있었네." 그녀는 단지 한마리의 양만을 갖고 있었다. 다른 사람이 더 갖고 있었다.

10 "Mary에게는 작은 양이 하나 있었네." 그 양은 정말로 작았다.

11 "Mary에게는 작은 양이 하나 있었네." 그녀는 양을 갖고 있었지, 다른 사람처럼 닭을 갖고 있지는 않았다.

12

13 여전히, 사람은 듣네 자기가 듣고 싶은 것만 나머지는 무시한다네 흠… … 라 라 라...
- Simon and Garfunkel, "The Boxer" 보통의 개발자의 습성 : 기술적 Pride, 고집, 혹은 사기꾼 기질까지(하기 싫으면 안 된다고..)

14 우리의 문제??? 진짜 문제(고객이 원하는 것)가 뭔지 모르는 경우가 많다. 개발자도 모르고 고객도 모르고..
뭘 봐야 알지….

15 그렇다면 그 대안은? 사람 & 대화 & 협업 언어로 무엇인가를 완전히 정확하고 분명하게 표현한다는 것은 실제로 불가능하다.
요건 도출은 “고 난이도”의 활용이다. 개발자가 계속 그들의 사용자와 대화하는 것을 확인해야한다. 보통 기계와 기술적으로만 접근. 위의 세가지 모두 사람을 가장 중심으로 해야 한다는.. 기계+기술+사람 => 학습(개발자와 고객의 상호작용) => 진정한 고객의 가치가 반영된 제품 예) Agile 방법론 중 XP에서는 사용자와 개발자가 함께 한다.

16 2차대전 1940년, 나치독일이 승승장구하며 전유럽을 석권할때 영국만이 홀로 싸울때가 있었습니다
2차대전 1940년, 나치독일이 승승장구하며 전유럽을 석권할때 영국만이 홀로 싸울때가 있었습니다. 이때 영국의 체임벌린 수상이 패전의 책임으로 사임하고 처칠이 새로운 수상이 되었습니다. 처칠은 "우리는 다시 유럽으로 돌아간다"라며 기자들앞에서 Victory(승리)의 상징으로 손을 브이자로 하였는데 우리가 흔히 사진을 찍을때 브이를 하는것이 여기서 유래 되었다고 합니다...

17

18 Agile 방법론 Agile 방법론 중 XP에서는 사용자와 개발자가 함께 한다.
XP 적용 룰 예 ) Pair Programming, 이터레이션(스크럼:스프린트), 2~4주 단위의 릴리즈. 테스트 주도 개발, 노 파티션 등..

19

20 개인과 상호작용을 공정과 도구보다 작동하는 소프트웨어를 포괄적인 문서화보다 고객과의 협력을 계약 협상보다
애자일 소프트웨어 선언문 우리는 직접 개발하면서 또 남이 개발하는 일을 도와주면서 소프트웨어 개발의 더 나은 방법을 발견하고 있다. 이 작업을 통해 우리는 아래 것들을 가치있게 여기게 되었다. 개인과 상호작용을 공정과 도구보다 작동하는 소프트웨어를 포괄적인 문서화보다 고객과의 협력을 계약 협상보다 변화에 응대하기를 계획을 따르는 것보다 이 말은, 오른쪽에 있는 것들에 가치가 있긴 하지만, 우리는 왼쪽에 있는 것들에 더 많은 가치를 둔다는 것이다.

21

22

23

24

25

26 질문… 없는거 다 알고 있습니다.