Chapter 3. 애자일 프로젝트 계획

3.1 기존 개발 방법론은 어떻게 활용해야 하는가?

[기존 개발 방법론들]

• 구조적 방법론
• 객체지향
• RUP(Rational Unified Process)
• CBD(Component Based Development)
• SOA(Software Oriented Architecture)

[프로젝트 관리 방법론들]

• PMBOK(Project Management Body Of Knowledge)
• CMMI(Capability Maturity Model Integration)

[문제 의식]

• 복잡한 프로세스와 많은 산출물 때문에 프로젝트에서 따라 하기가 쉽지 않다.
• 이런 방법론들이 강조되는 이유는 좋은 프로세스대로 일하다보면 훌륭한 제품을 만들 수 있다는 가정이 깔려 있기 때문이다.
• 그래서 선도 기업(IBM, Google 등)의 개발 프로세스를 모방하기만 해서는 오래가지 못한다.

[제언]

• 표준 프로세스는 준수보다 개선이 더 중요하며 개발팀 중심으로 진행되어야 효과적이다.
• 프로젝트에 방법론을 적용할 때 고려해야할 2가지 측면
  1. 방법론에서 제시하는 산출물을 어떤 목적으로 활용하는지 잘 따져보아야 한다. 즉, 낭비를 최소화하는 관점에서 개발팀이나 고객에게 별다른 가치를 제공하지 못하는 산출물은 없애거나 줄이는 것이 바람직하다.
  2. 개발 방법론을 개발 기간 내내 그대로 가져가서는 안 된다. 처음에 표준 방법론을 활용하여 프로젝트에 적합한 개발·관리 프로세스를 정했다면 주기적으로 그 효과를 평가하고 개선할 필요가 있다.

 

3.2 애자일은 개발 생명주기와 어떻게 다른가?

[폭포수 개발]

• 일련의 작업 단계에 따라 순차적으로 개발하는 형태로, 대부분의 IT 개발에서 사용하는 방식
• 장점
  • 중간에 요구사항만 변경하지 않는다면 단계가 명확하므로 관리가 쉽다.
• 단점
  • 초반에 요구사항을 모두 분석하기 어렵고, 고객은 실제 제품을 프로젝트 후반부에 가서야 제대로 볼 수 있기 때문에 나중에 요구사항이 많이 변경된다.
• 최근에는 요구사항 분석과 제품의 주요 부분을 프로토타입이나 스토리보드로 만들어 고객의 검증을 받은 후 개발을 본격적으로 시작하는 프로토타입 모델을 많이 사용하여 이 단점을 개선하고 있다.

[점진적 개발]

• 우선 전체 시스템 요구사항을 분석한 후 전체 시스템을 여러 개의 빌드로 나누고, 빌드 하나를 순차적으로 수행하여 점진적으로 기능을 완성해 나가는 방식
• 각 빌드 단위에서는 폭포수 방식을 적용하는데 전체 프로젝트로 보면 여러 개의 폭포수 개발을 순차적으로 진행하는 형태다.
• 장점
  • 제품을 빌드 단위로 개발하여 위험 요소를 줄일 수 있다.
  • 제품을 종료 시점에 납품하지 않고 점진적으로 제공함으로써 ROI(Return On Investment)를 높일 수 있다.

[진화적 개발]

• 개발 초기에 요구사항이 완전히 파악되지 않은 상태에서 알려진 요구사항만으로 개발하는 방식
• 빌드를 사전에 계획하지 못하고 고객에게 피드백을 받아 요구사항이 명확해지면 점진적으로 기능을 개선하여 목표 시스템을 완성한다.
• 전체 프로젝트로 보면 여러 개의 폭포수 개발 방식을 반복적으로 진행하는 형태다.
• 장점
  • 초기에 사용자 요구사항을 구체적으로 파악하지 못했을 때 활용할 수 있다.
• 단점
  • 아키텍처의 변화에 대응하기는 어렵다.

[스테이지 게이트 개발]

• 각 단계별로 게이트를 두고 의사 결정을 하는 체크포인트로 활용하며,  게이트를 통과하지 못하면 제품 개발은 중단되어 더 이상 다음 단계로 진행하지 못 함
• R&D 및 신제품 개발에 많이 사용하는 개발 생명주기로, 상품 기획 단계부터 출시까지 관리한다.
• 신제품을 만드는 제조업에서 많이 활용된다.

[애자일 개발]

• 점진적 개발의 장점을 살리면서 요구사항의 변화를 주기적으로 수용하는 반복적 개발
• 점진적 개발과의 차이
  1. 점진적 개발에서는 요구사항을 빌드별로 미리 할당해서 개발하지만 애자일 개발에서는 스프린트 단위로 요구사항의 변화를 수용하면서 개발한다. 즉, 스프린트를 계획할 때 기존에 계획한 요구사항과 전 스프린트에서 나온 변경사항을 비교하고, 구성원 간의 검토를 거쳐서 우선순위화하여 반영한다.
  2. 점진적 개발에서는 하나의 빌드 안에서 미니 폭포수 개발 형태로 진행하지만 애자일 개발에서는 스프린트에서 폭포수 방식으로 개발하지 않는다. 즉, 스프린트 안에서 분석, 설계, 구현, 테스트 같은 공정은 발생하나, 공식적으로 산출물을 만들고 다음 단계로 넘어가는 형태가 아니라는 말이다.
  3. 점진적 개발에서 빌드 주기는 개발 범위에 따라 주기가 불규칙하지만 애자일 개발에서는 특별한 경우가 아니면 개발 주기가 규칙적이다. 애자일 개발에서는 이를 타임 박싱(time boxing)이라고 표현한다.

※ 점진적 개발에서는 빌드 용어를 사용하지만 애자일 개발에서는 이터레이션(iteration) 또는 스프린트(sprint) 용어를 사용한다. 스프린트는 스크럼에서 사용되는 용어이다.

 

 

3.3 요구사항 이해관계자 식별

[제품 책임자(product owner)]

• 올바른 요구사항을 도출하는 것은 시장과 고객의 가치를 높이는 데 매우 중요하다.
• 이를 위해서는 먼저 요구사항과 관련된 이해관계자를 식별해야만 한다.
• 사용자와 이해관계자를 대표하여 해당 업무 요구사항을 책임지고 의사결정할 대표자를 선정할 필요가 있다. 사람마다 요구사항이 조금씩 다를 수 있으므로 이를 수렴하여 최종적으로 고객 가치가 높은 요구사항을 누군가는 확정지을 필요가 있기 때문이다.
• 애자일 개발에서는 이런 사람을 제품 책임자(product owner)라고 한다.
• 대규모 프로젝트를 수행할 때 제품 책임자는 현업을 수행하는 실무 담당자일 수도 있기 때문에 개발팀과 커뮤니케이션을 하기가 쉽지 않다. 이때는 업무별 제품 책임자를 지정하여 이 사람만이라도 개발팀과 자주 커뮤니케이션하도록 해야 한다.

[제품 책임자의 역할]

• 제품을 사용할 고객과 사용자의 니즈를 수렴하여 최종 요구사항을 결정
• 업계의 동향, 경쟁사의 움직임, 새로운 아이디어 등을 지속적으로 관찰하여 제품에 반영
• 각종 계획과 리뷰 미팅에 참석하여 개발팀에 피드백 제공
• 주기적으로 요구사항의 우선순위를 갱신하고 제품 테스트 수행
• 제품의 완료 조건을 작성하고 최종 제품 인수

 

3.4 요구사항 도출 : 린 스타트업과 디자인 씽킹의 활용

[린 스타트업의 활용]

• 전통적 프로젝트에서는 다양한 기법을 활용하여 사용자와 고객의 문제, 니즈를 파악해 왔다. (고객 인터뷰, 워크숍, 사용자 관찰, 프로토타입 등)
• 애자일 개발에서 요구사항을 도출하는 방법은 전통적 개발과 크게 다르지 않으나 두 가지 면에서 차이가 있다.
  1. 요구사항 도출 과정을 프로젝트 초기에만 국한하지 않고 주기적으로 고객의 피드백을 받아 요구사항을 정제하는 과정을 거친다.
     
     • 린 스타트업은 최소한의 요건만 갖춘 제품(MVP, Minimal Viable Products)을 신속하게 개발하여 시장에 출시한다.
     • 즉, 초기 투자의 낭비를 줄이고 고객의 피드백을 받아 제품을 개선해 나가는 방식으로 개발한다.
  2. 스킬이 다양한 팀 구성원과 고객이 함께 참여하여 요구사항을 도출한다.
     • 애자일 개발은 요구사항을 도출할 때 고객과 다양한 개발팀원이 함께 참여함으로써 고객이 인지하지 못하는 문제를 도출하는 데 좀 더 많은 시간을 할애한다.

[디자인 씽킹의 활용]

• 디자인 씽킹(design thinking) 프로세스는 주기적으로 고객의 피드백을 받아서 요구사항을 수정하는 측면에서 앞에서 언급한 린 스타트업과 유사하다.
• 하지만 요구사항을 도출할 때 '공감(empathy)'이라는 활동을 별도로 추가하여 사용자와 고객의 본질적인 문제를 파악하는 데 더욱 중점을 둔다.
• 공감 활동은 관찰이나 체험, 인터뷰로 진행되지만 기존 방법과는 다르게 고객의 상황을 깊이 이해하고 유대감을 갖는 상태를 말한다.

 

3.5 요구사항 정의와 제품 백로그

[IT 프로젝트에서 정의하는 요구사항의 종류]

• 기능적 요구사항 (시스템이 수행하는 입출력 및 저장 등)
• 성능 요구사항 (응답시간, 동시 처리량, 자원사용률 등)
• 인터페이스 요구사항 (시스템과 사용자 간 인터페이스)
• 품질 요구사항 (신뢰성, 사용성, 이식성, 보안성 등)
• 기타 요구사항 (운영, 데이터, 법규, 표준 등)

[제품 백로그]

• 전통적 개발에서는 요구사항을 '요구사항 정의서'에 기술했지만, 애자일 개발에서는 '제품 백로그(product backlog)'에 기술한다.
• 제품 백로그 : 제품 개발에 필요한 모든 업무를 우선순위화한 목록
• 요구사항 정의서 + 작업 분류 체계(Work Breakdown Structure)
• 소프트웨어와 하드웨어 등 각 업무 파트에서 수행해야 할 요구 기능을 중심으로 기술하고, 해당 기능을 수행하는 세부 작업(상세 분석과 설계, 구현, 단위 테스트 등)은 포함하지 않는다(이런 작업들은 주기적으로 수행되는 스프린트 계획에서 도출된다).
• 대신 프로젝트의 전체 요구사항을 구현하는 데 필요하거나 선행해야 하는 작업(프로젝트 관리와 지원, 요구 분석 등)은 기술한다.

[제품 백로그 구성 항목]

※ 제품 책임자 주도하에 개발팀과 협의하여 주기적으로 우선순위를 갱신한다.

• 요구 기능과 비기능 요구사항
• 기술적·관리적 업무 (아키텍처 수립, 하드웨어 선정과 발주, 교육훈련, 통합 테스트 등)
• 문제 해결 (모듈 안정화, 사용성 개선 등)
• 수정해야 할 버그

 

3.6  사용자 스토리, 기술 스토리, 완료 조건

[사용자 스토리]

• 사용자 스토리(user story)는 제품 백로그에서 기능 요구사항을 기술할 때 사용하는 방식으로, 고객과 사용자에게 가치를 줄 수 있는 기능을 서술한 것이다(문장O, 명사X).
• '(누가)(비즈니스 가치)를 위해 (어떤 기능)을 원한다'의 형태
  • 예시1) 사용자는 회원 가입을 위해 고객 이름, 주민번호, ID, 비밀번호를 입력할 수 있다.
  • 예시2) 교육생은 수강 신청을 위해 신청, 취소, 리스트 보기를 할 수 있다.
• 론 제프리(Ron Jeffries)가 말하는 사용자 스토리의 구성 요소 3가지
  • 카드(card) : 스토리는 보통 포스트잇 같은 카드에 서술 형태로 기술하고, 스토리를 추정하거나 계획하는 데 활용한다.
  • 대화(conversation) : 요구사항은 고객과 개발팀이 서로 대화하여 완성하고, 문서는 보충적인 요소다. 자세한 사용자 스토리 내용은 고객과 대화하여 구체화한다.
  • 확인(confirmation) : 스토리를 완료했다는 것을 확인할 수 있는 완료 조건(acceptance criteria)을 기술한다.
• 완료 조건은 사용자 스토리의 완성 여부를 객관적으로 확인할 수 있는 조건을 기술한 것.
  • 구현 결과가 제품 책임자의 기대사항과 달라지는 것을 예방한다.
  • 초기 제품 백로그에서는 개략적으로 기술하고 해당 스토리를 본격적으로 개발하는 스프린트 계획 미팅에서 상세히 구체화한다.
  • 구체화한 완료 조건을 기반으로 상세 테스트 케이스를 작성할 수 있다.
  • 실제 프로젝트에서는 완료 조건 외에 제약 조건이나 참조 사항 등을 추가로 기술하는 것이 사용자 스토리 이해에 도움이 된다.

[기술 스토리]

• 기술 스토리(technical story)는 제품 백로그 항목 중의 하나로 사용자 스토리를 지원하는 기술적·관리적 업무를 서술할 때 사용한다.
• 포함되는 활동
  • 요구 분석과 아키텍처, 도구 셋업 등 기술적인 활동
  • 비기능 요구사항과 인프라 시스템 개선 활동
  • 코드 리뷰, 리팩토링, 인스펙션 등 품질 개선 활동
  • 버그 수정, 모듈 안정화, 사용성 개선 활동
• 사용자 스토리는 고객과 제품 책임자가 중심이 되어 도출한다면 기술 스토리는 개발팀이 중심이 되어 도출한다.

 

3.7  제품 백로그 작성 지침

[마이크 콘(Mike Cohn)이 제시한 지침 6가지]

1. 상호 독립적이어야 한다(Independent)

• 스토리 간에 의존성이 있으면 추정이나 우선순위를 선정할 때 문제가 될 수 있다.

2. 변경이 가능해야 한다(Negotiable)

 

3. 사용자와 고객에게 가치가 있어야 한다(Valuable)

• 사용자나 고객에게 가치 있는 아이템이어야 하고 고객이 이해할 수 있는 언어로 작성해야 한다.
• 나쁜 예) '공통 클래스를 이용하여 모든 에러를 처리하고 로그를 생성해야 한다' (X)
• 좋은 예) '사용자는 일관된 형태로 모든 에러 메시지를 확인할 수 있다' (O)

4. 추정이 가능해야 한다(Estimable)

• 에픽(epic)이나 피처(feature)처럼 덩어리가 큰 요구사항은 추정이 어려울 수 있으므로 좀 더 분할해야 한다.

5. 크기가 적절해야 한다(Small)

• 스프린트 기간(1~2주일) 안에 완료할 수 있는 수준으로 쪼개거나 합하는 것이 좋다.

6. 테스트가 가능해야 한다(Testable)

• 테스트가 가능한 수준으로 기술해야 한다.
• 나쁜 예) '사용자는 도서를 쉽게 주문할 수 있어야 한다' (X)
• 좋은 예) '단골 고객은 2분 이내에 원하는 책을 한 권 찾아서 주문을 완료할 수 있어야 한다' (O)