3.2 개발 방법론
첫째， 방법론에서 제시히는 출물을 어떤 목적으로 활용하는지 잘 따져 보아야 한다.
둘째， 개발 방법론을 개발 기간 내내 그대로 가져가서는 안 된다.
- 평가 개선이 필요
개발 생명주기 (l fecycle)는 개발 단계의 집합이며 제품을 어떤 전략으로 개발 할 것인지 결정하는 접근 방식이다.
3.2.1 폭포수 개발
요구 분석 -> 설계 -> 구현 -> 테스트 -> 이행
고객은 실제 제품을 프로젝트 후반부에 가서야 확인이 가능하고, 후반에 요구사항이 변경되는 단점이 있따.
이를 극복하기 위해 프로토 타입 개발 방법을 사용하기도 한다.
프로토 타입 개발 방법
요구 분석 -> 프로토타입 개발 -> 고객 평가 -> 설계 -> 구현 -> 테스트 -> 이행
3.2.2 점진적 개발
이 방식은 제품을 벌드 단위로 개발하여 위험 요소를 줄이고，
종료 시점에 납품하지 않고 점진적으로 제공함으로써 ROI를높일 수 있는장점이 있다.
3.2.3 진화적 개발
요구사항이 완전히 파악되지 않은 상태에서 알려진 요구사항만으로 개발하는 방식
요구사항을 구체적으로 파악하지 못했을 때 활용할 수 있지만 아키텍처의 변화에는 활요할 수 없다.
3.2.4 스테이지 게이트 개발
R&D, 신제품 개발
개발 단계마다 의사 결정을 하는 체크포인트로 활용
게이트를 통과하지 못하면 개발은 중단
3.2.5 애자일 개발
점진적 개발과 비교를 하고 있음
1. 변화를 수용
점진적 개발과 동일하게 요구사항을 빌드별로 미리 할당
but, 스프린트 단위로 요구사항의 변화를 수용하면서 개발
2.각각의 빌드에서 산출물이 필요한 것은 아니다.
어떻게 중간 산출물을 최소화 하면서 높은 품질물을 만들 수 있는지에 초점을 맞춘다.
3. 개발 주기가 규칙적이다.
프로젝트의 기간을 관리하기 편한 작은 단위로 나누어 일을 예측하는데 도움을 준다.
3.3 요구 사항 이해 관계자 식별
요구사항을 챔임지고 의사 결정할 대표자 필요. -> 제품 책임자
제품 책임자
- 제품을 사용할 고객과 사용자의 니즈를 수렴하여 최종 요구사항을 결정
- 업계의 동향, 경쟁사의 움직임, 새로운 아이디어 등을 지속적으로 관찰하여 제품에 반영
- 각종 계획과 리뷰 미팅에 참석하여 개발팀에 피드백 제공
- 주기적으로 요구사항의 우선순위를 갱신하고 제품 테스트 수행
- 제품의 완료 조건을 작성하고 최종 제품 인수
3.4 요구사항 도출: 린 스타트업과 디자인 씽킹의 활용
3.4.1 린 스타트업의 활용
첫째， 변화에 유연하게 대처하라.
전통적 방법 : 초기 단계에서 요구 사항을 상세히 분석하여 프로젝트의 불확실성을 줄이려고 노력함
=> 현실적으로 어렵고, 중간에 바뀔 변수가 많음
애자일 방법 : 개략적인 일정과 비용을 추정할 수 있는 상위 수준의 요구사항 도출 => 주기적으로 피드백
고객의 피드백을 계속해서 받는 것을 볼 수 있다.
이렇게 스프린트 별로 업무를 하고, 고객에게 피드백을 받고 다음 스프린트에 다시 반영하는 것이 린 스타트업 (벤처 기업에 맞춰서 개발한 경영 기법)이다.
둘째 , 팀 구성원과 고객이 함께 참여하여 요구사항을 도출.
전통적 소프트 웨어 개발 : 소수의 분석가 또는 선임 개발자가 중심이 되어 요구사항 도출
초기에는 고객도 자신이 원하는 것을 모른다는 것을 알고 모두가 참여해서 요구사항을 도출하자.
3.4.2 디자인 씽킹의 활용
시장과 고객 가치가 높은 요구사항을 찾아내는 과제는 매우 중요하고 비즈니스 성공의 핵심이다.
주기적으로 고객의 피드백을 받아서 요구사항을 수정하는 측면에서 린스타트업과 유사하다.
but, 요구사항을 도출할 때 '공감' 이라는 활동을 별도로 추가하여 사용자와 고객의 본질적인 문제를 파악하는데 더욱 중점을 둔다.
공감 활동은 관찰이나 체험, 인터뷰로 진행되지만 기존 방법과는 다르게 고객의 상황을 깊이 이해하고 유대감을 갖는 상태를 말한다.
이런 활동에 시간을 쏟는 것을 아까워해서는 안 된다.
3.5 요구사항 정의와 제품 백로그
크게 다음과 같은 형태로 나눌 수 있다.
제품 백로그는 제품 개발에 필요한 모든 업무를 우선 순위화한 목록이다.
요구사항 정의서와 작업 분류 체계 개념을 합쳐 놓은 상태이다.
애자일은 수행해야 하는 요구 기능 중심으로 기술하고
해당 기능을 수행하는 세부 작업 등은 포함하지 않는다.
대신 프로젝트의 전체 요구사항을 구현하는 데 필요하거나 선행해야 하는 작업은 기술
아래와 같이 버전 1.0 제품을 만들어 고객이나 시장의 피드백을 확인
추가적인 기능은 점진적으로 개발
3.6 백로그 작성 (사용자 스토리, 기술 스토리 완료 조건)
사용자 스토리 : 제품 백로그에서 기능 요구사항을 기술
기술 스토리 : 사용자 스토리를 지원하는 기술적, 관리적 업무를 서술할 때 사용.
3.7 제품 백로그 작성 지침
6가지
1. 상호 독립적이어야 한다.
- 의존성이 있으면 우선순위를 선정할 때 문제가 될 수 있다.
2. 변경이 가능해야 한다.
3. 사용자와 고객에게 가치가 있어야 한다.
4. 개발 규모, 투입 공수 등을 추정 할 수 있어야 한다.
5. 업무 크기가 적절해야 한다.
6. 테스트가 가능해야 한다.
- (X) 사용자는 도서를 쉽게 주문할 수 있어야 한다.
- (O) 단골 고객은 2분 이내에 원하는 책 한 권 찾아서 주문 할 수 있어야 한다.
3.8 제품 백로그 vs 작업 분류 체계
공통점
- 프로젝트 업무 범위를 식별
- 향후 일정과 비용 관리의 기준이 되는 것이다.
차이점
첫째,
- 작업 분류 체계 : 업무를 분할한 수준
- 제품 백로그 : 업무 분할 + 우선 순위 설정
둘째,
- 작업 분류 체계 : 기능 구현 작업 중심
- 제품 백로그 : 기술 스토리 중심
3.9 개발 규모 추정과 스토리 점수
3.10에서 플래닝 포커 기법으로 점수를 추정할 것임
소프트웨어의 규모를 측정하는 단위
- LOC (Line of ocode)
- FP (Function point)
- 단위 화면
- 웹페이지
- 클래스
개략적인 요구사항만으로 LOC나 FP를 추정하기가 쉽지 않기 때문이다.
그래서 많은 개발팀에서는 할 수 없이 투입공수(Man-Days)를 기반으로 일정과 비용을 추정했다
비슷한 요구사항을 개발한 경험이 있는 엔지니어는 비교적 쉽게 투입공수를 예측할 수 있기 때문이다.
스토리 점수를 도입
- 요구사항의 규모를 측정하는 단위로 요구사항에 대한 크기 (복잡도를 감안한 업무량)
- 스토리 점수를 추정할 때는 상대적 개념을 사용
1. 스토리 작성
2. 스토리 점수 책정
- (역량이 중간 정도인 사람이 구현할 때 소요되는 이상적 작업 일 수를 말함)
- (이상적 잡업 일 수 란 디자일, 설계, 구축, 테스트하는 작업 일수)
- (1점짜리 스토리에 평균 투입 공수를 추정해 놓으면 공수 계산을 쉽게 할 수 있다.)
- (1점에 비해 2배 필요한 것은 2점)
3. 스토리 간 규모의 일관성 유지 점검 및 다시 추정
3.10 애자일 추정 기법과 플래닝 포커
추정 기법
- 유사 추정
- 전문가 추정
- 플래닝 포커 기법
3.10.1 유사 추정
- 과거에 수행했던 유사 프로젝트를 기반으로 추정
3.10.2 전문가 추정
개별 추정과 집단 추정 기법으로 나눌 수 있다.
개별 추정
- 경험있는 전문가가 단독으로 추정 (대다수 프로젝트에서 활용하는 기법)
- 장점: 쉽고 빠르다.
- 단점: 신뢰성이 떨어진다.
집단 추정
아래 두가지로 나눌 수 있지만 국내에서는 번거로워 성공적으로 적용하지는 못함
- 명목 집단법
- 와이드밴드 델파이 기법
3.10.3 플래닝 포커 기법
와이드밴드 델파이 기법을 변형
애자일 개발에서 가장 많이 사용
3가지 단계로 나눠짐
- 착수 준비
- 추정 대상 토론
- 추정 수행 단계
첫째, 착수 준비
추정에 참여할 사람들을 모은다.
(외부 전문가도 가능, 개발팀 전원이 참여하는 것이 좋지만 비효율적이라고 생각되면 주요 팀원만 참여해도 무방)
둘째 , 추정 대상 토론
제품 책임자는 개발할 요구 기능의 범위와 제약사항, 완료 조건 등을 설명
개발팀은 궁금한 점을 질의
개발해야 할 기능과 업무 범위를 충분히 이해하는 과정
셋째, 추정 수행
참석자는 자신의 경험을 바탕으로 스토리에 추정을 수행
가장 작은 값과, 가장 큰 값을 제시한 사람이 추정 근거를 말함
참석자는 각각의 주장을 들으면서 자신의 생각을 정리
앞선 주장을 듣고 두번째 추정을 진행
세 번 이상 할 필요는 없다.
공수 산정 값은 아래와 같이 피보나치 수열을 많이 사용한다.
1 ~ 3 MD가 소요되는 요구사항을 추정할 때는 비교적 정확하지만
3MD를 초과하는 요구사항을 예측이 어려움
3.11 가치 점수와 요구사항 우선순위
우선순위를 선정하는 방법
- MosCow
- 가치 점수를 활용
- 가치 점수와 스토리 점수를 활용
3.11.1 MosCow : 우선 순위를 네가지 기준으로 분류
필수, 중요, 선택, 보류
3.11.2 가치 점수 활용
스토리 점수와 유사하게 산정
3.11.3 가치 점수와 스토리 점수를 함께 고려
가치 점수를 스토리 점수로 나눔 (투입 노력 대비 가치가 높은 것을 기준으로 우선순위 산정)
3.12 요구사항 관리 전략
프로젝트 마다 요구사항 관리 전략이 조금씩 다르다고 볼 수 있다.
프로젝트는 크게 두가지 형태로 나눌 수 있다.
업무 범위가 유동적인 프로젝트 : 신제품 서비스 개발
업무 범위가 고정된 프로젝트로 구분할 수 있다. : 업무 내용을 확정한 외주 개발
3.12.1 업무 범위가 유동적인 프로젝트
변화에 유연하게 대처해야 한다.
유동적이기 때문에 우선 순위가 낮은 기능은 개발이 안 될 수 있지만 자연 스러운 것이다.
but, 특정 요구 기능에 너무 많은 변경이 일어나 전체 개발 범위를 충족하지 못할 때는 기능 로드맵을 통해 전체 시스템을 균형 있게 개발할 수 있도록 하자.
3.12.2 업무 범위가 고정된 프로젝트
세부 요구사항을 초기에 모두 확정하기 보다는 필수 요구사항만 확정하고,
나머지는 스프린트 단위로 요구사항의 타당성과 우선순위를 조정하면서 개발한다.
(보통 개발하는 시스템 기능 중 45%는 전혀 사용하지 않고, 19%는 거의 사용하지 않는다.)
3.13 릴리스 계획을 이용한 전체 일정 수립
전통적 일정 계획 : 프로젝트 초기에 세부 활동들을 모두 도출 , PERT / CPM 기법 등을 활용하여 주어진 납기를 만족할 수 있는 최적화된 일정을 수립
애자일 : 상세한 일정 계획을 세우지 않고 뼈대가 되는 전체 일정과 주기적인 상세 일정을 수립
계획은 아래와 같이 6단계로 나눠진다.
1. 제품 백로그 작성
- 스토리, 기술 스토리 도출
2. 스토리 점수 추정
- 플래닝 포커 기법 사용, 해결해야 할 이슈와 리스크를 식별하고 별도로 기록하여 관리한다.
3. 스프린트 기간 설정
- 애자일 처음 적용시 2주일로 설정
4. 평균 개발 속도 추정
- 개발 속도는 개발팀에서 단위 스프린트에 완료할 수 있는 스토리 점수의 합을 의미
5. 전체 일정 추정
- 스토리 점수와 개발 속도를 통해 전체 일정을 추정한다.
6. 스토리 우선 순위 선정
- 우선순위 기반, 스프린트 단위로 스토리 할당
- 평균 개발 속도보다 10~20% 낮춰서 배정
- 작업자를 지정하는 것이 아님
- 어느 스프린트에서 어떤 스토리를 수행할 지 지정
3.14 스프린트 계획을 이용한 단기 일정 수립
스프린트 계획의 목적은 어떤 작업들을 수행하고, 이를 수행하는 최적의 방법은 무엇인지 계획하는 것이다.
* 릴리스 계획 수립 이후, 각각의 스프린트 시작 전에 진행하는 회의인 듯
1. 제품 백로그 정제 미팅
- 새롭게 도출한 요구사항, 이전 스프린트에서 완료하지 못한 스토리 등을 종합하여 스토리 들을 우선 순위대로 정렬하고 릴리스 계획을 갱신
2. 스프린트 목표와 범위 설정
스프린트 별로 개발하려는 업무 목표와 스토리들을 개발팀에 제시한다.
업무의 시나리오와 완료조건, 제약사항등을 확인하고 범위를 확정
스토리 개발 방향이나 완료 조건을 결정하는 것은 매우 중요
3. 스프린트 백로그 도출
제품 백로그가 고객이 이해할 수 있는 언어로 작성되어 있다면
스프린트 백로그는 개발팀이 실제로 수행하는 개발 용어로 작성
(코드 리뷰, 업무 회의, 교육, 세미나 등이 포함)
4. 평균 투입공수 추정
전통적 방식 : 담당자를 할당하고, 해당 담당자가 투입 공수를 추정
애자일 방식 : 팀 공동으로 백로그에 대한 평균 투입 공수 추정 (플래닝 포커 활용)
5. 작업 담당자 할당
- 가용 공수 만큼 스프린트 기간 동안 일을 하기 때문에 자기자 잘할 수 있는 일을 선택
6. 스프린트 목표 업무량 결정
- 이전 스프린트 개발 속도 보다 10~20% 정도 높게 할당하는 것이 바람직
3.15 프로젝트 계획 검토
3.16 프로젝트 킥 오프
다음과 같은 일을 한다.
3.17 전통적, 애자일 일정 계획의 비교
세가지 차이가 있다.
첫째, 프로젝트 일정 계획을 바라보는 관점의 차이
- 전통적 관점 : 요구사항 변경을 최소화
- 애자일 관점 : 언제든지 변경 가능하다.
둘째, 작업 담당자 할당하는 방식
- 전통적 방법 : 리더 중심 할당
- 애자일 방법 : 개발 팀원이 스스로 백로그를 도출하고 작업을 배정
셋째, 프로젝트 추정 방식의 차이
- 전통적 방법 : 리더 단독 추정
- 애자일 방식 : 개발팀이 공동으로 추정