위대한개발문화

1개 시스템, 4개 사업부
4개 시스템, 4개 사업부

담당자가 하는 말
저도 왕년에 개발해
봤는데요...

프로그램 별 거 있나
요?
if하고 for면 다 되죠.
고쳐 주세요.

SW에 대한 인식
바꾸기가 쉽다!

다차자 구글
다차자 검색

초가집에서 빌딩으로 바꾸기 위해서
무엇을 고쳐야 할지 명확히 보인다.

다차자에서 구글로 바꾸기 위해서
무엇을 고쳐야 할지 명확히 보이지 않는다.

설계(도면) → 제조(제품)

설계(UML) → 제조(코딩)??

소프트웨어 설계와 개발(제조)을
분리할 수 있다? 없다?

구글 검색
한국어 영어
검색어 결과 건수 검색어 결과 건수
기구 설계자 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

설계와 개발(제조)의 분리를 통한 장점
설계 → 검증 → 제조(개발)
제조(개발) → 검증

설계와 개발(제조)의 분리를 통한 장점
가시성이 확보됨!
비가역적이지 않음을 알 수 있음!

위대한개발문화

파이프 설계
재료역학
유체역학
열역학

소프트웨어 개발
Cohension Coupling

Architecture Patterns
Design Patterns

Is TDD dead?
David Heinemeier Hansson
Martin Fowler
Kent Beck

프로그래밍은 일반인도 배워야 한다
기본을 철저히 배우는 언어?
배우기 쉬운 언어?
C? Python?

공사와 제사
벼락과 종치기
종교전쟁

소프트웨어 엔지니어링
기반 과학??

소프트웨어 엔지니어링은
로망?? 혹은 공학??

Empirical Software Engineering
Mining Software Repository

소프트웨어 개발이 어려운 이유
소프트웨어 공학의 미성숙

DB팀, ASW팀 → DB, ASW구조
서버 사이드 전문가 → 클라우드 제품
엑셀 전문가 → 매크로 기반 엑셀

비스타 윈도우 종료 메뉴
Switch User, Log Off, Lock, Restart, Sleep, Hibernate, Shut Down으로 7가지
(Function키와 아이콘을 조합하면 15가지 방법)

애플 조직도(잡스 시절)

소프트웨어 구조는
조직(사람)의 구조를 반영한다

소프트웨어 개발의 난제
1. 비가시성
2. 소프트웨어 공학의 미성숙성
3. 조직(사람)의 특성에 큰 영향을 받음

합당한 문제
Righteous Problem

고약한 문제
Wicked Problem

1) 운전자
2) 승객
3) 엔지니어
4) 경찰관
5) 주지사
6) 답없음
7) 6)번까지 답없음

어떤 문제가 고약한 문제가 되는 경우

1. 누구의 문제냐에 따라서 그 해법이 달라
짐
2. 비가시성(해결과정이 명확하지 않고)
3. 도구가 불안전할 때
(소프트웨어 엔지니어링의 한계)

소프트웨어는 전형적인 고약한 문제

고약한 문제(소프트웨어 난제)를
해결하는 방법
프로세스?

프로세스 3요소
사람, 도구, 절차

ISO/TS16949
ISO26262
CMMI
PMBOK

정해진 업무,
반복적인 업무엔
프로세스가 효과적일 수도 있다.

사일로
프로세스의 실패

구멍난 프로세스
예외가 필요한 프로세스
꽉 막힌 프로세스

프로세스를
보완하는 그 무엇

사회 초년생일 때 경험담

시간 단축을 위한 지름길
화단 화단 화단 화단
화단
빌딩
주차장(퇴근 버
스)

우리에 갇힌 원숭이 다섯 마리

기둥 위에 바나나
올라가면 물대포

모두 물대포를 맞지 않은 원숭이들로
채워진다면?

문화란 무엇인가?
절차, 매뉴얼, 규율, 당위를 모두 압도함

프로세스는 모두 동일하다
문화에서 답을 찾다

위대한 개발문화란?
소프트웨어의 난제를 잘 다루는 것
어떻게? 조직적으로

그렇다면 어떻게 위대한 개발문화를
만들 수 있을까?

많은 오해와 반감을 갖게 하는 단어

인간
사람과 사람 사이
→ 사람이라면 정치는 필수

구성원을 한 곳을 바라보게 함
부족한 역량을 살피고 키움
구성원 간의 문제를 파악하고 해결
부족한 자원을 찾고 제공
도전적인 목표에 도전하게 함
이런 것을 총합하는 단어는?

성과를 내기 위해서 방향성과 추진력이 필
요
즉 구성원의 높은 역량이 필요

위대한 개발 문화
=
훌륭한 관리 + 뛰어난 역량

누군가의 실패
혹은
나의 실패

네이버 지식인
DBDic
ahnice

실패는 최고의 피드백이다!

성공을 추구한다는 건…
만성적인(날마다) 실패를 경험한다는 뜻

시스템이란…
날마다 무언가를 한다는 뜻
그리고 장기적으로 무언가를 추구하는 것

1958년 헨리 크레머
사람의 힘만으로 작동하는 비행기 제작
영국해협을 건너면 40억을 주기로 함

다른 팀들은 비행기 제작
1년
즉 실패 한 번 하는 데 1년

폴 맥크레디 박사 비행기 제작
몇 시간
즉 실패 한 번 하는 데 몇 시간

소프트웨어 개발의 난제인
비가시성을 가장 잘 다루는 방법
실패를 극대화하는 시스템을 갖추는 것

agile
scrum
prototype
80/20

실패 시스템의 가장 큰 적
모호함
그리고
거짓

그리고
사람이 개발한다!

프로젝트는
근본적으로
모호한 것

프로젝트 삼각형
비용
시간 품질

모호함
+
꽉 막힌 프로젝트 삼각형

관리자들의
가장 큰 실수

모호함을
더 큰 모호함으로 승화시킴

명확한 메시지도 왜곡됨

관리자의 역할
모호함을 명확함으로
바꾸는 것

프로젝트 삼각형에서 타협을...
비용
시간 품질

‘소중한 것 먼저하기’
‘80/20’
모호함을 해결하는
가장 효과적인 방법

모호한 문제(SW 개발)에 대해서
개발자와 잘 일하고 싶다면

개발자는 개발로
문제를 해결하려고 한다

초보 프로젝트 관리자
일화

관리자형 관리자
테크니컬 리더형 관리자

팀원과 관리자가
방법론을 두고 충돌할 때

초보 관리자 딱지를 벗고난 경험담
‘Fast fail’

에고의 승리가 중요한 게 아님
실패에서 조직적으로 무얼 배웠는가?

많은 문제는
초기에 해결 가능

수년 동안 거래해 온 안경점의
배신감을 토로하는 여성

좋은 가게를 알려주는 남성

이들은 서로 즐거운 대화를 했다고
기억할까?

상사의 입장은 완전히 다르다
윗사람의 지시
그리고
밑에 사람의 실행력(성과)

부하의 입장은 완전히 다르다
적은 일
칼퇴근?

컴퓨터 죄수의 게임 대회

Tit For Tac
눈에는 눈, 이에는 이

상호 협력이
가장 효과적인 전술

모호함을 처리하기 위해선
상사와 부하의
협력이 가장 중요함

상사와 부하 중 누가
유리할까?

결국 상사가 손을 내밀어야 함

개발자 시절 경험담
만성 야근에 시달릴 때

성과에 대한 명확한 평가

애플 컴퓨터 리사 일화
-2,000 라인

레고 조립에 대한 실험 1

레고 조립에 대한 실험 2

어떤 실험에 더 많이 응모했을까?

모호함을 해결하는 최고의 수단
피드백
따라서
성과 평과는 명확하게!

효과적인 피드백!
이메일
Standing Meeting
일대일 회의

모호함을 아무리 잘 관리해도
실패는 늘 발생하기 마련
→
정직이 생명이다!

신뢰의 중요성
엔론 사태

정직하지 않은 조직은
오래가지 못한다

두 그룹으로 나눔
90점이나 그 이상을 받으면 보상
사실은 63이상은 불가능

그룹1 리더 : 점수 조작 주장
그룹2 리더 : 있는 그대로
문제를 풀게 했을 때
결과는?

점수 조작 그룹1 팀의 점수가
그룹2 팀보다 20점 낮음

그룹을 바꿀 기회를 줌

그룹2는 반만 바꾸길 원함
그룹1은 80퍼센트가 바꾸길 원함
→ 정직하지 않은 조직은 대량의 인원
이동 유발

조직적인 이유로 그룹을 바꾸지 못함
개인에게 과제를 냄
개인이 충분히 점수를 속일 수 있는 환경
결과는?

비윤리적인 그룹에 남겠다고 말한
20퍼센트가
50퍼센트 이상 점수를 속임

모호함이 많은 경우
비윤리적인 관리는
더 많은 모호함을 생성하고
조직을 위험에 빠트림

소프트웨어 공학이
완전하지 않지만,
우리가 이만한 생산성을 얻게 된
이유는?

도구의 발달
서버 급의 PC,
잘 알아야 하지만 엄청난 오픈소스

흔히 생각하는
개발자의 역할은?

자신이 필요한 소프트웨어를
직접 만든다

개발자의 가장 큰 특권!!
DIY!!

진정한 개발역량이 있는 조직
그냥 그런 조직의 차이는?

자동화율
그리고
자신들이 만든 도구를 사용하느냐

도구를 만드는 데 필요한 규칙 #1

두 번 이상 같은 작업을
수작업으로 한다면?

도구를 만들어라!
혹은
자동화하라!

바퀴를 다시 만들지 마라!
검색하고 설치하고 사용하자!
그리고

SW분야의 청테이프(Duct tape)
파이선!! 등등

부분 최적화의 오류를
피하라!

효율적인 것보다 효과적인 게
더 나을 수 있다

진정 효과적인 SW개발은
효율이 떨어질 수 있다

효율화의 덫에 빠지지 말자

정리
소프트웨어 개발 특성
소프트웨어 개발 문화
문화를 만드는 관리와 개발

위대한개발문화

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to 위대한개발문화 (20)

위대한개발문화