프로젝트 쾌속 개발 전략(RAPID Development)

제 1 장 쾌속 개발 소개

1.1. 쾌속 개발이란

쾌속 개발이란, 어떤 사람에게는 즐겨 애용하는 도구나 방법을 적용하는 과정 또는 단순히 “느리고 전형적인 개발”에 반하는 문구

1.2 쾌속 개발 달성 하기

효율적인 개발법

- 특정 프로젝트에서 사용하는 개발법 집합

- 일정위주 개발법

• 속력위주 개발법

• 일정 위험위주 개발법

• 가시성위주 개발법

비효율적인 개발법

제 2 장 쾌속 개발 전략

더 빨리 개발하려는 사람이 가장 쉽게 빠지는 함정 중 하나가 한가지 일정위주 개발법에만 지나치게 치중하는 것이다.

2.1 일반적인 쾌속 개발 전략 : 일정위주 개발법에 너무 치중하지 말아라.

• 전형적인 실수를 피하라.

• 개발 기본에 충실히라.

• 위험을 관리하여 재난을 피하라.

• 일정위주 개발법을 적용하라

2.2 사차원에 걸치 개발 속력

사람

피플웨어는 다른 어떤 요소보다 생산성과 품질에 크게 영향을 미친다. 피플웨어는 잠재적으로 가장 큰 이익을 준다.

- 팀 프로젝트에 맞는 인재 선발

배리 뵘은 software Engineering Economics에서 인재선발 원리을 제시했다. 1. 최고 재능 – 더 우수한 소수 인재를 활용하라. 2. 적합한 임무 – 개인별 동기와 기술에 적합한 업무를 맡겨라. 3. 경력 관리 – 업무를 강요하지 말고, 스스로 자아를 실현하도록 도와라. 4. 팀 조화 – 서로 보완하고 화합하는 사람을 선택하라. 5. 부적격자 배출 – 문제 팀원을 빨리 퇴출 시키고 대체하라.

- 팀 구성 : 프로젝트의 크기, 제품 특성, 일정 목표에 맞게 팀을 구성

- 동기 부여

생산성 변화율 - 경력이 다른 개인 사이의 생산성 차이 10 대 1이상 - 경력이 비슷한 개인 사이의 생산성 차이 10 대 1 - 경력이 다른 팀 사이의 생산성 차이 5 대 1 - 경력이 비슷한 팀 사이의 생산성 차이 2.5 대 1

공정

공정이 개발 일정에 미치는 영향은 사람이 미치는 영향보다 평가하기 쉽다. 공정은 사람 만큼 개발 속력 향상에 크게 기여한다.

• 재작업 회피 : 재작업을 피하도록 공정 방향을 잡는 일이 프로젝트에서 시간을 아끼는 가장 직접적인 방법이다.

• 품질 보증 : 출시할 제품의 품질이 합격할 수준인가?, 최소 시간과 비용으로 고칠 수 있는 단계에서 오류를 발견하려는 목적

• 개발 기본 : 소프트웨어 공학 표준 기법을 적용한 방법론

• 위험 관리 : 결함 회피에 초점을 두는 개발법

• 자원 목표 설정 : 자원의 효과적인 활용으로 전반적인 생산성을 향상

• 생명주기 계획 : 생명주기 모델을 통해 프로젝트에 필요한 활동을 쉽게 찾아내고 조직화하여 가장 효율적으로 처리할 수 있다.

• 고객 중심 : 단계적 출시, 발전적인 출시, 발전적인 프로토타이핑, 일회성 프로토타이핑, 원칙적인 협상 같은 우수 개발법이 이 분야에서 큰 효과를 발휘한다.

제품

제품 기능을 줄일 수 있다면, 일정을 단축할 수 있다. 기능이 유연하다면 80/20 규칙을 적용해 20% 시간에 80% 기능을 구현할 수 있다. 나머지 20%는 나중에 개발 하면 된다.

• 제품의 크기 : 제품의 크기가 증가하면, 개발에 드는 노력은 훨씬 빠르고 불균형적으로 증가한다. 가장 필수적인 기능에만 집중하여, 크기를 바로 줄일 수 있다. 또는 제품을 단계적으로 개발하여, 크기를 일시적으로 줄일수 있다. 고급 언어나 도구를 이용하여 코드량을 줄이고 크기 또한 줄일수 있다.

• 제품 특징 : 진짜로 쾌속 개발이 가장 우선이라면 너무 많은 항목에 우선순위를 부여해서 개발자를 속박해서는 안된다.

기술

효율적으로 도구를 선택하고 도구에 관한 위험을 관리하는 일은 쾌속 개발을 주도하기 위한 핵심 요소다.

※ 상승작용 재사용 가능한 컴포넌트를 관리하는 그룹을 둔다면, 그 그룹이 코드 표준을 확립하여 전체 프로젝트에서 활용하도록 관리할 수 있다.

2.3 일반적인 빠른 개발 분류

개발법	일정	비용	제품
보통개발법	보통	보통	보통
균형있는 효율적 개발법	보통보다 나음	보통보다 나음	보통보다 나음
일정을 강조한 효율적 개발	보통보다 훨씬 나음	보통보다 다소 나음	보통보다 다소 나음
전면적인 쾌속 개발	가장 빠름	보통보다 나쁨	보통보다 나쁨

효율적인 개발 : 비용, 일정, 제품 특성을 분별있게 최적화 하는 활동이다. 효율적인 개발은 전형적인 실수회피, 개발 기본, 위험 관리를 포함한다.

전면적은 쾌속 개발 : 단순히 인력을 추가함으로써 프로젝트 개발 일정을 25% 줄일수 있다. 그러나 의사소통과 관리 부하가 증가하므로 25%라는 일정 단축을 얻으려면 팀 크기를 75%키워야 한다. 일정을 줄이고 팀 크기를 키울 경우, 그 순효과를 따지면 프로젝트 비용은 일반 프로젝트보다 35% 증가한다.

2.4 미친듯이 개발법

미친듯이 개발법	쾌속 개발 전략
지지자는 개발 시간에 있어 즉각적으로 놀라운 향상을 주장한다.	지지자는 즉각적으로 적당한 향상과 장기적으로 큰 향상을 주장한다.
구현 지식외에는 전문적 지식이 거의 필요없다.	구현 지식외에도 상당한 전문적 지식이 필요한다.
고위험:효율적으로 수행해도 실패한다.	저위험:효율적으로 수행하면 거의 실패하지 않는다.
남들이 극단적으로 튄다고 한다.	남들이 보수적이고 따분하다고 한다.
스스로 모든 것을 바쳐 일한다고 느낀다.	스스로 열심히 일하는 것 같지 않다고 느낀다.
인력을 엄청나게 낭비한다.	인력을 효율적이고 인간적으로 사용한다.
가시성이나 제어력을 제공하지 못한다. 해봐야 안다.	원하는 만큼 가시성과 제어력을 제공하도록 조절이 가능하다.
이 개발법은 소프트웨어 역사 만큼이나 오래되었다.	이 개발법 중 핵심 부분은 15년이상 성공적으로 사용해왔다.

제 3 장 전형적인 실수

사람

- 동기 저하

- 저급 인력

- 문제 인물 방치

- 영웅적 행동

- 프로젝트 후반에 인력 추가

- 시끄럽고 붐비는 사무실

- 개발자와 고객 사이 마찰

- 비현실적인 기대

- 효과적인 프로젝트 후원 부족

- 관련자 참여 부족

- 사용자 참여 부족

- 실속 보다는 정치

- 막연한 기대

공정

- 지나치게 낙관적인 일정

- 불충분한 위험관리

- 하청업체 실패

- 불충분한 계획 수립

- 압력에 따른 계획수립 포기

- 애매한 시작으로 낭비한 시간

- 건너 뛴 초기 활동

- 불충분한 설계

- 부족한 품질 보증

- 불충분한 관리 감독

- 너무 이르거나 지나치게 잦은 통합

- 세부업무 누락

- 나중에 따라잡을 계획

- ‘미친듯이 구현하기’ 개발

제품

- 요구사항 치장

- 기능 변형

- 개발자 치장

- 조삼모사식 협상

- 연구중심 개발

기술

- 특효약 증후군

- 새로운 도구나 방법에 대한 과대평가

- 프로젝트 도중에 도구 변경

- 자동화된 소스코드 관리 부족

제 4 장 소프트웨어 개발 기본

4.1 관리 기본

계획 수립 절차

- 예측과 일정 수립

- 프로젝트 팀 인원 수, 필요한 기술 능력, 인력 투입 시점, 실제 참여할 개발자 결정

- 팀 조직 결정

- 사용할 생명주기 모델 선택

- 위험 관리

- 제품 기능 집합 통제 전략 결정, 제품 일부에 대한 구매 또는 구현 전략 결정

4.2 기술 기본

요구사항 관리: 요구사항을 수집하고 문서, 이메일, 사용자 인터페이스 스토리보드, 실행 가능한 프로토타입, 그외 여러 형식을 이용해 요구사항을 기록하고, 요구사항과 맞지 않는 설계나 코드를 조사하고, 프로젝트 전반에 걸쳐 변경 사항을 관리하는 과정을 말한다. 요구사항관리는 두가지 측면에서 개발을 가속화 한다. 첫째, 요구사항 수집은 다른 개발 활동에 비해 느긋하게 진행하는 경향이 있다. 질을 떨어뜨리지 않고 조금만 서두른다면 전체 개발 기간을 단축 할수 있을 것이다. 둘째, 처음에 요구사항을 제대로 는 데 드는 비용은 구현이나 유지보수 단계에서 처리할 때 드는 비용보다 1/50, 1/200까지 적다. 보통 프로젝트는 약 20%정도는 요구사항이 변한다. 요구사항의 변경 자체를 줄이는 것이 요구사항에 드는 비용을 줄이는 길이다.

설계 : 설계를 하지 않고도 시스템을 개발 할수 있다. 체계적인 설계 없이 순수한 구현과 디버깅, 강한 의욕, 엄청난 초과근무만으로 여러 중요한 시스템을 구현해 오기는 했다. 하지만 설계는 구현, 일정수립, 감독, 관리를 위한 바탕이며 효과적인 설계는 개발 속력을 최대화하는데 필수적이다.

구현 : 처음부터 코드 질이 형편없다면 나중에 다시 돌아가 고치기는 거의 불가능하다. 두 번 손대는 행위는 확실히 비효율적이다.

4.3 품질보증 기본

개발자 단계에서 수행해야 할 품질보증을 건성으로 하기 쉽다.

지나친 일정 압력에 개발한 제품에서 보통보다 네배까지 많은 결함을 발견할 수 있다.

프로젝트 초기에 결함 발견에 치중하지 않겠다는 결정은 비용과 시간이 많이 드는 프로젝트 막판까지 그것을 미루겠다는 결과나 마찬가지다.

결함을 막거나 초기에 없앤다면 상당한 일정 단축을 경험할 것이다.

오류 유발성 모듈 : 비정상적으로 많은 결함을 일으키는 모듈을 말한다.(20%모듈에서 전체 80%의 오류가 나온다.) 오류 유발성 모듈은 다른 모듈보다 복잡하고, 비구조적이며, 주로 과도한 일정압력에서 개발한 모듈이나 충분한 테스트를 거치지 못한 모듈이다.

• 테스트 : 개발자가 자신의 코드가 정확하게 동작하는지 검사하는 단위 테스트와 별도 테스터가 시스템의 의도대로 확인하는 시스템 테스트가 있다.

• 검토 회의: 개발자 둘이상이 품질 향상을 목적으로 기술 업무를 검토하는 회의를 말한다. 테스트 전에 결함을 발견할 수 있는 좋은 방법이다.

• 코드 검사: 검토회의보다 다소 공식적인 검토과정

• 정밀 검토 : 공식적인 검토의 한 종류로 결함 발견에 매우 효과적이다.

제 5 장 위험 관리

5.1 위험 관리 구성요소

위험 관리 단계

1. 위기관리 – 발등에 떨어진 불을 끈다. 위험이 문제가 된 경우에 한해서 처리한다.

2. 실패시 해결 – 위험을 발견하면 즉각적으로 대응한다. 그러나 발생한 경우에 한해서다.

3. 위험 완화 – 위험이 발생할 경우를 대비해 자원 할당을 계획 한다. 그러나 그 전에 위험을 제거하는데 비용을 쓰지 않는다.

4. 예방 – 프로젝트의 일부로 위험을 인지하여 문제로 변하지 않게 막을 계획을 세우고 실행한다.

5. 근본 원인 제거 – 위험을 유발할 가능성이 있는 요인을 찾아내 제거한다.

위험 인지

1. 기능 변형 2. 요구사항 치장 또는 개발자 치장 3. 낮은 품질 목표 설정 4. 지나치게 낙관적인 일정 5. 불충분한 설계 6. 특효약 증후군 7. 연구중심 개발 8. 저급인력 9. 하청업체 실패 10. 개발자와 고객 사이 마찰

가장 흔한 일정 위험

위험 분석 : 위험을 분석해 그 파급효과를 결정하는 과정

위험 노출도 : (예상 못한 손실이 일어날 확률 * 손실 크기 = 위험 노출도)

위험 우선순위화 : 위험 목록을 작성후 우선순위화를 통하여 상위 20%에 집중한다.

위험 처리

• 위험을 피하라.

• 위험을 옮겨라.

• 위험 관련 정보를 구매하라.

• 위험 근본원인을 제거하라.

• 위험 발생을 가정하라.

• 위험을 공지하라.

• 위험을 통제하라.

• 위험을 기억하라.