Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

위대한개발문화

위대한 개발문화를 만드는 방법

  • Sé el primero en comentar

위대한개발문화

  1. 1. 15년 전 경험담
  2. 2. 4개월 간 야근
  3. 3. D-14 사용자 교육
  4. 4. 1개 시스템, 4개 사업부 4개 시스템, 4개 사업부
  5. 5. 담당자가 하는 말 저도 왕년에 개발해 봤는데요...
  6. 6. 프로그램 별 거 있나 요? if하고 for면 다 되죠. 고쳐 주세요.
  7. 7. 벚꽃 엔딩
  8. 8. SW에 대한 인식 바꾸기가 쉽다!
  9. 9. 초가집 빌딩
  10. 10. 다차자 구글 다차자 검색
  11. 11. 초가집에서 빌딩으로 바꾸기 위해서 무엇을 고쳐야 할지 명확히 보인다.
  12. 12. 다차자에서 구글로 바꾸기 위해서 무엇을 고쳐야 할지 명확히 보이지 않는다.
  13. 13. 자동차 개발 과정
  14. 14. 소프트웨어 개발 과정
  15. 15. 설계(도면) → 제조(제품)
  16. 16. 설계(UML) → 제조(코딩)??
  17. 17. 소프트웨어 설계와 개발(제조)을 분리할 수 있다? 없다?
  18. 18. 구글 검색 한국어 영어 검색어 결과 건수 검색어 결과 건수 기구 설계자 8,440 mechanical designer 368,000 기구 개발자 8,400 mechanical developer 39,500 하드웨어 설계자 8,190 hardware designer 295,000 하드웨어 개발자 19,800 hardware developer 185,000 소프트웨어 설계자 13,300 software designer 377,000 소프트웨어 개발자 692,000 software developer 10,100,000
  19. 19. 설계와 개발(제조)의 분리를 통한 장점 설계 → 검증 → 제조(개발) 제조(개발) → 검증
  20. 20. 설계와 개발(제조)의 분리를 통한 장점 가시성이 확보됨! 비가역적이지 않음을 알 수 있음!
  21. 21. 공학 = 과학 + 기술
  22. 22. 파이프 설계 재료역학 유체역학 열역학
  23. 23. 소프트웨어 개발 Cohension Coupling
  24. 24. Architecture Patterns Design Patterns
  25. 25. Is TDD dead? David Heinemeier Hansson Martin Fowler Kent Beck
  26. 26. 기술빚
  27. 27. 프로그래밍은 일반인도 배워야 한다 기본을 철저히 배우는 언어? 배우기 쉬운 언어? C? Python?
  28. 28. 공사와 제사 벼락과 종치기 종교전쟁
  29. 29. 소프트웨어 엔지니어링 기반 과학??
  30. 30. 소프트웨어 엔지니어링은 로망?? 혹은 공학??
  31. 31. Empirical Software Engineering Mining Software Repository
  32. 32. 소프트웨어 개발이 어려운 이유 소프트웨어 공학의 미성숙
  33. 33. DB팀, ASW팀 → DB, ASW구조 서버 사이드 전문가 → 클라우드 제품 엑셀 전문가 → 매크로 기반 엑셀
  34. 34. 비스타 윈도우 종료 메뉴 Switch User, Log Off, Lock, Restart, Sleep, Hibernate, Shut Down으로 7가지 (Function키와 아이콘을 조합하면 15가지 방법)
  35. 35. 맥 OS X 종료 메뉴
  36. 36. MS 조직도(발머 시절)
  37. 37. 애플 조직도(잡스 시절)
  38. 38. 콘웨이 법칙
  39. 39. 소프트웨어 구조는 조직(사람)의 구조를 반영한다
  40. 40. 소프트웨어 개발의 난제 1. 비가시성 2. 소프트웨어 공학의 미성숙성 3. 조직(사람)의 특성에 큰 영향을 받음
  41. 41. 합당한 문제 Righteous Problem
  42. 42. 수학 문제 풀이
  43. 43. OJT 샘플 프로그램
  44. 44. 고약한 문제 Wicked Problem
  45. 45. 터널
  46. 46. 해결책
  47. 47. 그리고 호수
  48. 48. 그리고 방전
  49. 49. 누구의 문제?
  50. 50. 1) 운전자 2) 승객 3) 엔지니어 4) 경찰관 5) 주지사 6) 답없음 7) 6)번까지 답없음
  51. 51. 어떤 문제가 고약한 문제가 되는 경우
  52. 52. 1. 누구의 문제냐에 따라서 그 해법이 달라 짐 2. 비가시성(해결과정이 명확하지 않고) 3. 도구가 불안전할 때 (소프트웨어 엔지니어링의 한계)
  53. 53. 소프트웨어는 전형적인 고약한 문제
  54. 54. 고약한 문제(소프트웨어 난제)를 해결하는 방법 프로세스?
  55. 55. 고약한 문제(소프트웨어 난제)를 해결하는 방법 프로세스?
  56. 56. 프로세스 3요소 사람, 도구, 절차
  57. 57. ISO/TS16949 ISO26262 CMMI PMBOK
  58. 58. 정해진 업무, 반복적인 업무엔 프로세스가 효과적일 수도 있다.
  59. 59. 사일로 프로세스의 실패
  60. 60. 구멍난 프로세스 예외가 필요한 프로세스 꽉 막힌 프로세스
  61. 61. 프로세스 무용론???
  62. 62. 프로세스를 보완하는 그 무엇
  63. 63. 사회 초년생일 때 경험담
  64. 64. 시간 단축을 위한 지름길 화단 화단 화단 화단 화단 빌딩 주차장(퇴근 버 스)
  65. 65. 우리에 갇힌 원숭이 다섯 마리
  66. 66. 기둥 위에 바나나 올라가면 물대포
  67. 67. 한 마리를 바꾸면?
  68. 68. 모두 물대포를 맞지 않은 원숭이들로 채워진다면?
  69. 69. 문화란 무엇인가? 절차, 매뉴얼, 규율, 당위를 모두 압도함
  70. 70. 프로세스는 모두 동일하다 문화에서 답을 찾다
  71. 71. 위대한 개발문화란? 소프트웨어의 난제를 잘 다루는 것 어떻게? 조직적으로
  72. 72. 그렇다면 어떻게 위대한 개발문화를 만들 수 있을까?
  73. 73. 많은 오해와 반감을 갖게 하는 단어
  74. 74. 정치
  75. 75. 인간 사람과 사람 사이 → 사람이라면 정치는 필수
  76. 76. 구성원을 한 곳을 바라보게 함 부족한 역량을 살피고 키움 구성원 간의 문제를 파악하고 해결 부족한 자원을 찾고 제공 도전적인 목표에 도전하게 함 이런 것을 총합하는 단어는?
  77. 77. 관리 Management
  78. 78. 관리만 잘 하면 끝?
  79. 79. 성과를 내기 위해서 방향성과 추진력이 필 요 즉 구성원의 높은 역량이 필요
  80. 80. 위대한 개발 문화 = 훌륭한 관리 + 뛰어난 역량
  81. 81. 누군가의 실패 혹은 나의 실패
  82. 82. 네이버 지식인 DBDic ahnice
  83. 83. Win XP Win95 Win3.1
  84. 84. 콜럼버스 달걀
  85. 85. 실패는 최고의 피드백이다!
  86. 86. 성공을 추구한다는 건… 만성적인(날마다) 실패를 경험한다는 뜻
  87. 87. 시스템이란… 날마다 무언가를 한다는 뜻 그리고 장기적으로 무언가를 추구하는 것
  88. 88. 1958년 헨리 크레머 사람의 힘만으로 작동하는 비행기 제작 영국해협을 건너면 40억을 주기로 함
  89. 89. 20년 동안 모두 실패
  90. 90. 폴 맥크래디 박사
  91. 91. 다른 팀들은 비행기 제작 1년 즉 실패 한 번 하는 데 1년
  92. 92. 폴 맥크레디 박사 비행기 제작 몇 시간 즉 실패 한 번 하는 데 몇 시간
  93. 93. 소프트웨어 개발의 난제인 비가시성을 가장 잘 다루는 방법 실패를 극대화하는 시스템을 갖추는 것
  94. 94. agile scrum prototype 80/20
  95. 95. 실패 시스템의 가장 큰 적 모호함 그리고 거짓
  96. 96. 그리고 사람이 개발한다!
  97. 97. 프로젝트는 근본적으로 모호한 것
  98. 98. 프로젝트 삼각형 비용 시간 품질
  99. 99. 모호함 + 꽉 막힌 프로젝트 삼각형
  100. 100. 프로젝트 실패!!
  101. 101. 관리자들의 가장 큰 실수
  102. 102. 모호함을 더 큰 모호함으로 승화시킴
  103. 103. 사장님 지시사항
  104. 104. 부장님 지시사항
  105. 105. 명확한 메시지도 왜곡됨
  106. 106. 관리자의 역할 모호함을 명확함으로 바꾸는 것
  107. 107. 프로젝트 삼각형에서 타협을... 비용 시간 품질
  108. 108. ‘소중한 것 먼저하기’ ‘80/20’ 모호함을 해결하는 가장 효과적인 방법
  109. 109. 모호한 문제(SW 개발)에 대해서 개발자와 잘 일하고 싶다면
  110. 110. 망치를 들고 있다면?
  111. 111. 개발자는 개발로 문제를 해결하려고 한다
  112. 112. 초보 프로젝트 관리자 일화
  113. 113. 관리자형 관리자 테크니컬 리더형 관리자
  114. 114. 팀원과 관리자가 방법론을 두고 충돌할 때
  115. 115. 초보 관리자 딱지를 벗고난 경험담 ‘Fast fail’
  116. 116. 에고의 승리가 중요한 게 아님 실패에서 조직적으로 무얼 배웠는가?
  117. 117. 최고의 엔지니어란?
  118. 118. 고자질쟁이
  119. 119. 많은 문제는 초기에 해결 가능
  120. 120. 결국 의사소통
  121. 121. 헬스 클럽 이야기
  122. 122. 수년 동안 거래해 온 안경점의 배신감을 토로하는 여성
  123. 123. 좋은 가게를 알려주는 남성
  124. 124. 이들은 서로 즐거운 대화를 했다고 기억할까?
  125. 125. 상사의 입장은 완전히 다르다 윗사람의 지시 그리고 밑에 사람의 실행력(성과)
  126. 126. 부하의 입장은 완전히 다르다 적은 일 칼퇴근?
  127. 127. 죄수의 딜레마
  128. 128. 컴퓨터 죄수의 게임 대회
  129. 129. 항상 호의?
  130. 130. 호구
  131. 131. 항상 배신?
  132. 132. 돌+I 이기주의자
  133. 133. Tit For Tac 눈에는 눈, 이에는 이
  134. 134. 상호 협력이 가장 효과적인 전술
  135. 135. 모호함을 처리하기 위해선 상사와 부하의 협력이 가장 중요함
  136. 136. 상사와 부하 중 누가 유리할까?
  137. 137. 결국 상사가 손을 내밀어야 함
  138. 138. 개발자 시절 경험담 만성 야근에 시달릴 때
  139. 139. 사발면 한 꾸러미
  140. 140. 외국 회사 이야기
  141. 141. D-day + 몸살 치킨 수프
  142. 142. 명확한 피드백
  143. 143. 지각
  144. 144. 성과에 대한 명확한 평가
  145. 145. 애플 컴퓨터 리사 일화 -2,000 라인
  146. 146. 레고 조립에 대한 실험 1
  147. 147. 레고 조립에 대한 실험 2
  148. 148. 어떤 실험에 더 많이 응모했을까?
  149. 149. 모호함을 해결하는 최고의 수단 피드백 따라서 성과 평과는 명확하게!
  150. 150. 효과적인 피드백! 이메일 Standing Meeting 일대일 회의
  151. 151. 모호함을 아무리 잘 관리해도 실패는 늘 발생하기 마련 → 정직이 생명이다!
  152. 152. 신뢰의 중요성 엔론 사태
  153. 153. 정직하지 않은 조직은 오래가지 못한다
  154. 154. 두 그룹으로 나눔 90점이나 그 이상을 받으면 보상 사실은 63이상은 불가능
  155. 155. 그룹1 리더 : 점수 조작 주장 그룹2 리더 : 있는 그대로 문제를 풀게 했을 때 결과는?
  156. 156. 점수 조작 그룹1 팀의 점수가 그룹2 팀보다 20점 낮음
  157. 157. 그룹을 바꿀 기회를 줌
  158. 158. 그룹2는 반만 바꾸길 원함 그룹1은 80퍼센트가 바꾸길 원함 → 정직하지 않은 조직은 대량의 인원 이동 유발
  159. 159. 조직적인 이유로 그룹을 바꾸지 못함 개인에게 과제를 냄 개인이 충분히 점수를 속일 수 있는 환경 결과는?
  160. 160. 비윤리적인 그룹에 남겠다고 말한 20퍼센트가 50퍼센트 이상 점수를 속임
  161. 161. 모호함이 많은 경우 비윤리적인 관리는 더 많은 모호함을 생성하고 조직을 위험에 빠트림
  162. 162. 소프트웨어 공학이 완전하지 않지만, 우리가 이만한 생산성을 얻게 된 이유는?
  163. 163. 도구의 발달 서버 급의 PC, 잘 알아야 하지만 엄청난 오픈소스
  164. 164. 흔히 생각하는 개발자의 역할은?
  165. 165. 소프트웨어 개발
  166. 166. 자신이 필요한 소프트웨어를 직접 만든다
  167. 167. 개발자의 가장 큰 특권!! DIY!!
  168. 168. 진정한 개발역량이 있는 조직 그냥 그런 조직의 차이는?
  169. 169. 자동화율 그리고 자신들이 만든 도구를 사용하느냐
  170. 170. 도구를 만드는 데 필요한 규칙 #1
  171. 171. 두 번 이상 같은 작업을 수작업으로 한다면?
  172. 172. 도구를 만들어라! 혹은 자동화하라!
  173. 173. 도구를 만드는 데 필요한 규칙 #2
  174. 174. 이런 거 있지 않을까?
  175. 175. 바퀴를 다시 만들지 마라! 검색하고 설치하고 사용하자! 그리고
  176. 176. SW분야의 청테이프(Duct tape) 파이선!! 등등
  177. 177. 도구를 만드는 데 필요한 규칙 #3
  178. 178. 예전의 일화
  179. 179. CRT 모니터의 백케이스
  180. 180. Critical path
  181. 181. 부분 최적화의 오류를 피하라!
  182. 182. 도구를 만드는 데 필요한 규칙 #4
  183. 183. 효율성
  184. 184. 효과성
  185. 185. 효율적인 것보다 효과적인 게 더 나을 수 있다
  186. 186. 진정 효과적인 SW개발은 효율이 떨어질 수 있다
  187. 187. 효율화의 덫에 빠지지 말자
  188. 188. 정리 소프트웨어 개발 특성 소프트웨어 개발 문화 문화를 만드는 관리와 개발

×