박성철 박성철 / Platform SW / Platform SW 개발개발 11 팀팀

Work with Engineer & Team building

http://www.flickr.com/photos/ivyfield/8154073189/

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

生卽苦

Software Crisis

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

- 에츠허르 데이크스트라

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

- 에츠허르 데이크스트라

x

SW 개발 = 문제 해결 + 복잡도 처리

규모 + 섬세함 = 복잡도

SW 개발 프로젝트의 목표 ?

SW's 결함● 비싼 가격

● 빈번하고 과한 예산 초과

● 출시 지연

● 부실한 문서

● 통합 불가

● 환경 이전 , 기능 개선 불가

● 유지보수가 어렵고 오류가 쉽게 발생

● 불안정한 성능

● SW 가 요구사항과 맞지 않음

● 조기에 용량 한계에 다다름

● 사용하기 어려움

● SW 요구사항이 사용자의 필요에 부합하지 않음

SW 개발은 무엇인가?

http://www.flickr.com/photos/wackymacs/113838729/

工場工場

과학적 관리법

지침 , 측정 , 예측 , 평가

공장 같은 개발 절차

분석 설계구현

( 코딩 )배치

( 배포 , 납품 )

정교한 설계 단순한 코딩 작업

테스트

단계별 산출물

설계 제조

분석

설계

구현( 코딩 )

배치( 배포 , 납품 )

테스트

폭포수 개발 방법론

폭포수 개발 방법론

Factory

ComponentsAssembly line

Centralized Control

Engineering

EstimationPerfect Planning

ControlScience

Model/Architecture

Architect is “GOD” Coding is simpleCode Generation

UML

Process

Repeatable ProcessPM = Process Champions

Good Process = Good Product

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

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

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

http://www.flickr.com/photos/jasonteale/1675863028/

● 단순하고 우아하고 숙련단순하고 우아하고 숙련 (( 수련수련 )) 에 초점에 초점

● 도구 상자 접근법도구 상자 접근법

● 숙련자 숙련자 / / 대가 대가 / / 구루 모델구루 모델

사람에 매우 의존적사람에 매우 의존적

● 설계는 해법을 선택하는 지침을 제공설계는 해법을 선택하는 지침을 제공

무술 / 장인

http://www.flickr.com/photos/olivander/58499153/sizes/z/in/photostream/

저술저술 // 작곡작곡● 반복반복 , , 초고초고 , , 다듬기다듬기 , , 교정교정 // 교열교열

● 정해진 구조 안에서 창의성에 집중정해진 구조 안에서 창의성에 집중

● 목적은 알지만 결과는 정해지지 않음목적은 알지만 결과는 정해지지 않음

● 창의적인 절차를 정해진 범위창의적인 절차를 정해진 범위 , , 마감마감 , , 예산에 맞추는 것이 예산에 맞추는 것이 어려움 어려움

http://commons.wikimedia.org/wiki/File:British_and_Irish_Lions_scrum.jpg

단체 스포츠 경기단체 스포츠 경기● 목표를 위해 협력목표를 위해 협력● 사전에 정해진 지시 없는 프로세스사전에 정해진 지시 없는 프로세스● 경기 규정은 있지만 결과는 불명경기 규정은 있지만 결과는 불명● 협력하는 활동인 협연과 춤도 포함협력하는 활동인 협연과 춤도 포함

SW 개발=

집단적이고종료가 있는

목표 추구 경기

닝겐 ...

강점● 문제를 알아서 해결한다

● 소통한다

● 스스로 결정한다

● 모방한다

약점● 일관성이 없다

● 훈련하기 어렵다

● 지침을 기계적으로 따르는데 익숙하지 않다

드레이퍼스dreyfus 기술 습득 모델1단계: 초보자배운 규칙을 기계적으로 충실하게 잘 따른다. 상황의 특수성은 전혀 고려되지 않는다.

2단계: 상급 입문자 규칙을 적용한 경험이 쌓여가고 상황을 인식하게 된다. 규칙 외에 상황에 따른 격언을 배우고 이를 적용한다. 지금까지는 일이 잘못되더라도 자기가 배운 지식의 문제라고 생각한다.

3단계: 중급자 당면한 상황에 맞는 목표를 선택하고 계획을 세워 실행한다. 초보 시절에 따라하기에 급급하던 규칙이나 격언들을 상황에 맞게 선택적으로 사용한다. 자신의 선택에 어느 정도 책임을 느낀다.

4단계: 숙련자 기술 보다는 해결해야 하는 과제에 집중한다. 많은 경험으로 얻는 특별한 시각을 갖고 있어 직관적으로 과제의 특성을 이해하고 조직화 한다. 하지만 대응할 때에는 분석적으로 사고한다.

5단계: 대가상황을 이해하는 것 뿐만 아니라 어떻게 행위해야 하는지도 직관적이다. 마치 자신의 몸을 움직이듯 모든 것이 직관적일 뿐이다.

SW 개발 방법론

결국 폭포수 모델은...

Feedback

움직이는 타겟

SW 개발 방법론

반복 개발 (Iterative Development)

Light v.s Heavy ?

Light Weight : Heavy Weight

Running SW : Plan Driven

Lean : Fat

대안 개발 방법론

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

Agile? Waterfall?

Factor Agile Characteristic Waterfall Characteristic

Size Optimal for small projects and teams, reliance on domain knowledge

Tailored for large projects and teams

Mission Critical Projects

Untested, general lack of documentation

Long history of use in such implementations

Stability and complexity of existing environment

Continuous refactoring used, suitable for dynamic and simple environments

Structured baselines used, suitable for more static and complex environments

Skills Continuous involvement of highly skilled individuals, difficult to cope with many lower skilled resources

Highly skilled resources needed in early phases, designed to cope with many lower skilled resources in later phases

Organizational Culture

Chaotic, dynamic, empowered Roles well defined, procedures in place

스크럼 (Scrum)

스프린트 (Sprint)

제품 백로그

● 제품이 살아 있는 동안 완료되지 않고 갱신됨● 요구사항 , 변경사항 , 결함● 우선순위 , 시급성 , 가치에 따라서 정렬● ( 관리자가 아닌 ) 개발팀이 개발 기간을 추정

제품에 적용될 요구사항의 단일한 원천

스프린트 백로그

● 현 스프린트에서 처리할 작업 목록● 제품 백로그의 최우선 항목을 상세화해서 도출● 스프린트 계획 회의에서 상세화● 개발팀이 항목 당 개발 비용 추정

스프린트 계획 회의

순서에 따라 제품 백로그 선택 스프린트 백로그 ( 목표 )

● 스프린트 시작 전에 시행● 시간 제한● 해당 스프린트에서 전달할 제품 증분 ( 목표 ) 을 결정

● 제품 백로그에서 기능 항목을 선택해서 스프린트 목표를 정의● 제품 증분을 달성할 방법 협의

● 기능 항목에서 세부 작업을 도출하고 개발 비용을 추정

작업판

제품 책임자

스크럼 마스터

이해 관계자개발자

역할

개발자

● 자기 조직화● 자기 종결적 (Cross Functional)

동작하는 SW 를 Iteration 마다 출시 가능한 상태로 인도할 책임이 있음

스크럼 마스터

● 프로젝트 장애 제거● 스크럼 진행 촉진● 소통 촉진● 프로젝트 관리자가 아님

스크럼 진행 담당자

제품 책임자

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

제품 비전

● 프로젝트 헌장 (Project Charter)● 모든 팀원이 작성에 참여하고 동의해야 함● 비전 = 프로젝트를 시작하는 이유와 추구하는 목적● 프로젝트의 방향을 잡아주는 나침반● 팀 빌딩의 핵심 도구● PRD의 확장● 단순 명료 (엘리베이터 테스트 )

프로젝트를 시작하는데 필요한 최소한의 계획으로 비전 , 필수 정보 , 제약 사항 , 초기 제품 백로그 등으로 구성된다 .

기타 ...

http://www.flickr.com/photos/wackymacs/113838729/

新工場新工場

God is in the detail

Devil also is in the detail

공장 같은 개발 절차

분석

설계

구현 ( 코딩 ) 설계 문서인 코드

테스트

컴파일러가 제품을 제조

SW 제품

단순 반복적인 작업은 사람보다 컴퓨터가 잘 하는 일 ...

설계 제조

개발자는 누구 ?

People over Process

THX