클린 애자일(Clean Agile - Back to Basics) - 3장 비즈니스 실천 방법

계획 세우기

프로젝트는 어떻게 추정해야 할까? 프로젝트를 작은 조각으로 쪼갠 다음, 각 조각을 추정하면 된다. 만약 쪼갠 조각도 추정하기에 너무 크다면 더 작은 조각으로 또 쪼갠 다음 추정하면 된다.

추정은 추측이다. 본질적으로 엉성하다. 추정은 가능한 확실해야 한다. 하지만 추정 비용을 낮게 유지하려면, 필요한 만큼만 정밀해야 한다.

스토리와 포인트

사용자 스토리는 시스템의 기능을 사용자 관점에서 간략하게 설명한 것이다.

스토리 문구는 단순해야 한다. 세부 사항은 생략해야 한다.

세부 사항을 남기지 않는 규율을 지켜야 한다. 힘들 것이다. 논의한 모든 세부사항을 어딘가 남기고 싶은 마음은 모두가 갖고 있을 것이다. 이 유혹을 이겨내야 한다!

스토리 예시

스토리 추정하기

스토리 하나를 고르자. 중간 정도로 복잡해 보이는 것이 좋다. 이해관계자에게 세부 사항을 설명해 달라고 요청하다.

그 다음 스토리에 부여할 포인트를 정한다. 중간 정도의 스토리이므로 중간 정도의 포인트를 부여한다.

이 스토리는 이제 “기준 스토리(Golden Story)”다. 다른 스토리는 기준 스토리와 비교해 포인트를 부여한다.

포인트는 추정한 노력의 단위이지 실제 시간을 나타내지 않는다. 일의 능숙도, 기타 업무 등에 따라 구현 시간은 달라진다.

스토리 포인트는 대체로 비례해야 한다. 2포인트인 스토리는 대략적으로 4포인트인 스토리에 비해 절반 정도의 노력이 필요해야 한다.

반복 주기 1 계획하기

반복 주기는 반복 주기 계획 회의(Iteration Planning Meeting, IPM)로 시작한다. 회의 길이는 전체 반복 주기 길이의 1/20 정도가 좋다.

반복 주기 계획 회의에는 팀 전원이 참석해야 한다. 이해관계자, 프로그래머, 테스터, 프로젝트 관리자 등이 모두 참석해야 한다. 이해관계자는 회의에 앞서 추정한 스토리들을 읽고, 비즈니스 가치 순서로 정리해 와야 한다.

반복 주기 계획 회의에서 이해관계자는 반복 주기 동안 프로그래머와 테스터가 구현할 스토리를 골라야 한다. 그러려면 이해관계자는 프로그래머가 스토리 포인트를 몇 포인트나 처리할 수 있다고 생각하는지 알아야 한다. 이 숫자를 속도라고 부른다. 진짜 속도가 어느 정도일지 아무도 모른다. 그러니 적당히 짐작해야 한다. 속도는 약속이 아니라는 점을 꼭 기억해야 한다.

투자 수익률(Return On Investment, ROI)

이해관계자는 투자 수익률 사분면을 놓고 고민해야 한다(그림 3.2).

중간 확인

반복 주기가 반 쯤 지났을 때, 이해관계자와 팀 전체가 모여서 진행 상황을 확인하는 중간 검토 회의를 한다. 진행된 포인트와 남은 포인트를 확인하고, 스토리를 조정한다.

반복 주기에서 예상했던 포인트보다 적게 완료가 되더라도 반복 주기는 실패가 아니다. 반복 주기의 목표는 관리자에게 데이터를 제공하는 것이다.

어제의 날씨

오늘의 날씨를 추측하려면 어제의 날씨를 떠올려보면 되듯이, 이번 반복 주기를 예측하려면 직전 반복 주기를 살펴보면 된다.

프로젝트 종료

반복 주기가 끝날 때마다 속도 차트에 반복 주기의 속도를 기록하므로, 누구나 이 팀이 일을 진행하는 속도를 알 수 있다.

프로젝트는 스토리를 모두 구현함으로써 끝나는 것이 아니다. 프로젝트는 스토리 더미에 구현할 가치가 있는 스토리가 더 이상 없을 때 끝난다.

스토리

사용자 스토리는 기능을 기억하기 위해 쓰는 짧은 설명이다.

스토리를 쓸 때는 다음 여섯가지(INVEST)를 지켜야 한다.

Independent(독립적인): 사용자 스토리는 서로 독립적이다. 스토리를 어떤 순서로 구현해도 상관 없다는 말이다. 이 항목을 꼭 지키지는 않아도 된다. 그래도 가능한 한 의존성을 줄이면서 스토리를 나누어야 한다. 그래야 비즈니스 가치 순서에 맞추어 스토리를 구현할 수 있다.

Negotiable(협상할 수 있는): 개발자와 사업 부서가 세부 사항을 협상할 수 있어야 한다.

Valuable(가치 있는): 스토리는 명확하고 계량할 수 있는 비즈니스 가치가 있어야 한다.

Estimable(추정할 수 있는): 사용자 스토리는 개발자가 작업량을 추정할 수 있을 정도로 구체적이어야 한다.

Small(작은): 사용자 스토리는 개발자 한두 명이 반복 주기 한 번 이내에 구현하기 힘들 정도로 크면 안 된다.

Testable(테스트 가능한): 사업 부서가 스토리 완료를 증명하는 테스트를 제시할 수 있어야 한다.

스토리 추정

스파이크

스파이크는 메타스토리(meta-story)다. 추정하기 힘든 스토리를 추정하는 스토리이다.

반복 주기 관리하기

각 반복 주기의 목표는 스토리를 처리하여 데이터를 얻는 것이다. 팀은 스토리에 속한 세부 작업 하나하나의 처리보다 스토리 전체에 집중해야 한다. 모든 스토리를 각 80%씩만 처리한 것보다는 완료한 스토리 수가 전체 스토리 수의 80%인 것이 훨씬 더 낫다. 스토리를 완료하는 데 집중하라.

QA와 인수 테스트

아직 QA가 자동화된 인수 테스트 작성을 시작하지 않았다면, 계획 회의가 끝나자마자 시작해야 한다. 먼저 끝날 예정인 스토리의 테스트부터 만들어야 한다.

인수 테스트는 빨리 만들어야 한다. 반복 주기의 전반부에 완성하는 것이 좋다. 만약 반복 주기 절반이 지났는데도 아직 인수 테스트를 다 만들지 못 했다면 개발자도 다른 작업을 멈추고 인수 테스트 작성을 도와야 한다.

인수 테스트가 없으면 스토리를 완료할 수 없다.

반복 주기 후반이 되고, 인수 테스트 작성이 끝났다면, QA는 다음 반복 주기에 쓸 테스트를 만든다.

개발자와 QA는 인수 테스트 이야기를 많이 해야 한다.

개발자는 스토리를 완료하도록 노력해야 한다.

‘완료’의 정의는 ‘인수 테스트 통과’다.

스토리 하나를 희생하여 다른 스토리를 하나라도 완료하는 것이 반쯤 만든 스토리 두 대보다 낫다.

데모

이해관계자에게 완료한 스토리의 데모를 간단히 시연하는 것으로 반복 주기가 끝난다. 데모할 때는 모든 인수 테스트를 통과하는 것도 보여 주어야 한다.

속도

반복 주기를 마치면서 속도 그래프와 번다운 차트를 기록한다. 인수 테스트를 통과한 스토리 포인트만 기록해야 한다.

반복 주기가 몇 번 지나고 난 뒤, 속도 그래프의 기울기는 0이어야 한다.

속도가 오를 때

프로젝트 관리자가 일을 더 빨리 하라고 압박하고 있다는 의미일 수 있다. 더 빠르게 일하는 것처럼 보이도록 인플레이션이 일어나는 것이다.

속도는 측정하는 것이지 목표하는 것이 아니라는 점을 마음에 새겨두자.

속도가 떨어질 때

코드 품질에 문제가 있을 가능성이 제일 크다.

기준 스토리

포인트 인플레이션을 막는 한 가지 방법은, 스토리 추정 결과를 계속해서 예전에 정한 기준 스토리와 비교해 보는 것이다.

작은 릴리즈

작은 릴리즈(Small Release) 실천 방법은 개발팀이 소프트웨어를 최대한 자주 릴리스 할 것을 권장한다.

릴리즈 주기를 줄이려면, 조직에서 릴리즈와 배포 사이의 관계를 끊어야만 한다. ‘릴리즈’라는 단어는 소프트웨어가 기술적으로 배포가 가능하다는 것을 의미한다. 실제로 배포를 할지는 오직 사업 부서의 결정에 달렸다.

인수 테스트

기반이 되는 발상은 엄청나게 단순하다. ‘사업 부서가 요구 사항을 명시(specify)해야 한다’는 것이다.

명세(specification)란 뭘까? 명세란 그 본질 상 테스트다.

이 테스트를 자동화할 수 있다는 것도 분명하다.

실천 방법

사업 부서에서 각 사용자 스토리의 동작을 설명하는 테스트를 형식에 맞게 작성하고, 개발자는 이를 자동화한다.

인수 테스트가 없는 스토리는 명세가 없는 것이다. 인수 테스트를 통과하기 전까지는 스토리가 끝난 것이 아니다.

업무 분석가와 QA

인수 테스트는 업무 분석가와 QA, 개발자가 함께 힘을 모아 작성한다.

업무 분석가는 정상적으로 성공하는 경로만 기술한다.

QA는 정상에서 벗어난 경로를 담당한다.

개발자는 테스트가 기술적인 관점에서 타당한지 확인해야 한다.

개발자가 테스트를 돌린다

반복 주기에서 처리할 스토리의 인수 테스트를 QA가 작성한다.

프로그래머가 테스트를 돌린다. 프로그래머가 테스트를 돌려보는 것이 스토리 완료 여부를 알 수 있는 유일한 방법이다.

프로그래머는 지속적인 빌드(Continuous Build) 서버를 구축하여 이 과정을 자동화 한다.

전체 팀

기본적인 생각은 이런 것이었다. 사용자와 프로그래머가 물리적으로 가까이 있을수록 의사소통하기 더 좋을 것이다.

우연히 발생하는 시너지를 우습게 봐서는 안 된다. 전체 팀이 같은 공간에 함께 앉아 있으면, 마법이 일어날 수 있다.

팀 전체가 같은 곳에서 일하면 비즈니스는 훨씬 순탄하게 돌아간다.

결론

이 실천 방법들을 따르면 사업 부서와 개발 부서가 단순하고 명확하게 의사소통할 수 있다. 이런 의사 소통이 신뢰를 낳는다.