•
성공적인 프로젝트를 위해 반드시 지켜야 하는 애자일 실천 방법 중, 비즈니스와 관련된 것이 많다.
•
계획 세우기, 작은 릴리스, 인수 테스트, 전체 팀이 여기에 속한다.
계획 세우기
•
계획을 세우기 위해 프로젝트를 추정하는 방법은 프로젝트를 작은 조각으로 쪼갠 다음, 각 조각을 추정하는 것이다. 추정하기 어렵다면 더 작은 조각으로 잘게 쪼개면 된다. 이는 코드 한 줄 한 줄까지 쪼개질 수 있다.
•
이렇게까지 정밀하게 추정하면 사실 프로젝트를 끝낸 것이나 다름없다. 이래서는 추정의 의미가 없다. 추정에는 비용이 적게 들어야 한다. 따라서 정밀도를 낮추어 엉성하게 추정해야 한다.
•
소프트웨어 개발자를 위한 좋은 추정 요령은 확실한 시간 범위를 고르되 이 시간 범위를 가능한 한 좁히기 위해 약간의 시간을 투자하는 것이다.
삼변량 분석
•
대형 과제 추정에는 삼변량 추정이 매우 유용하다. 삼변량 추정은 최선, 일반, 최악 이렇게 세 개의 숫자로 이루어져 있다. 이 숫자들은 확신 정도에 따른 추정ㄱ밧이다.
◦
최악의 경우, 그 안에 끝날 것이 95% 확실하다. 일반적인 경우 50%, 최선의 경우는 5% 밖에 안 된다.
◦
삼변량 추정을 관리하기 위한 수학적 방법론도 있다. PERT라 불리는 프로그램 평가 검토 기법이다.
•
삼변량 분석이 전체 프로젝트의 장기 추정에는 적당하지만, 하나의 프로젝트 내에서 일상적 관리 용도로 사용하기에는 너무 정밀도가 낮다. 그래서 일상적 관리 용도로는 다른 방법을 사용한다.
스토리와 포인트
•
스토리 포인트 기법은 매우 엄격한 피드백 루프를 사용한다. 실제 결과를 가지고 추정치를 재조정하여 더 확실하고 정밀하게 추정을 다시 한다.
◦
처음에는 정확도가 엉성하겠지만 몇 번 반복하면 감당할 수 있을만큼 추정 범위가 줄어든다.
•
사용자 스토리는 시스템의 기능을 사용자 관점에서 간략하게 설명한 것이다.
◦
예시는 다음과 같다. 자동차 운전자가 속도를 높이기 위해 가속 페달을 발로 더 세게 누른다.
•
스토리를 작성할 때는 개발자와 이해관계자가 스토리 구현에 관하여 몇 가지 세부 사항을 논의한 후 내용을 요약해서 적는다.
•
스토리 문구는 단순해야 하는데, 세부 사항은 생략해야 한다. 세부 사항을 정하는 일은 늦추면 늦출수록 좋다.
ATM 스토리
•
지금이 반복 주기 0일 때, ATM 스토리를 작성하는 팀에 속해있다고 하자. 어떤 스토리가 있을까?
•
출금, 입금, 이체, 로그인, 로그아웃 등이 있을 수 있다. 다섯 장의 스토리 카드가 생겼다.
•
실제 기계의 동작을 세세히 따져보면 더 많은 스토리가 생길 것이다. 검증 작업도 있고 대출 상환도 있고 온갖 기능이 다 있지만 제쳐두고 다섯 가지만 생각해보자.
•
카드에는 다섯 단어가 적혀있을 것이다. 물론 스토리를 탐색하는 과정에서 다양한 세부 사항들을 얘기했을테지만 이는 확실하지 않기 때문에 쓰지 않는다.
◦
다만 꼭 챙겨야하는 세부사항을 기억할 수 있도록 메모를 조금씩 남기는 것은 괜찮다.
•
반복 주기 0에서 스토리 카드를 모두 만들었다. 새로운 기능이나 아이디어가 나타나면 더 많은 스토리 카드가 생길 것이다.
스토리 추정하기
•
처음으로 하는 추정 회의기 때문에 추정한 스토리도 하나도 없을 것이다.
•
추정을 위해선 중간 정도로 복잡한 것을 고르는 것이 좋다. 그 다음 스토리에 부여할 포인트를 정한다.
•
중간이니 3정도로 부여한다. 이제 로그인이 우리의 기준 스토리가 된다. 다른 스토리를 비교하는 기준이 되는 것이다.
•
이를 토대로 다른 작업들도 추정하여 카드 귀퉁이에 숫자를 적어둔다.
•
포인트는 그 어느것의 단위도 아니다. 그냥 숫자다.
반복 주기 1 계획하기
•
첫 번째 반복 주기를 계획할 시간이 되었다. 반복 주기는 반복 주기 계획 회의로 시작한다. 회의 길이는 전체 반복 주기의 1/20 정도가 좋다.
◦
2주 단위라면 하루 업무 시간의 절반 정도가 된다.
•
팀 전원이 참석해서 추정한 스토리를 읽고 이해관계자는 스토리를 비즈니스 가치 순서로 정리해야 한다.
•
이해관계자는 반복 주기 동안 프로그래머와 테스터가 구현할 스토리를 골라야 한다. 그러려면 먼저 스토리 포인트를 몇 포인트나 처리할 수 있는지 물어보아야 한다. 이 숫자를 속도라고 부른다.
•
처음이니 어느정도 차이가 있을수도 있다. 속도는 약속이 아니라는 점을 기억하자. 반복 주기 동안 30포인트를 쳐내겠다고 약속한게 아니다. 짐작한 것이다.
투자 수익률
•
이제 이해관계자는 다음 투자 수익률 사분면을 놓고 고민해야 한다.
고비용 | 저비용 | |
가치 높음 | 나중에 하자 | 지금 하자 |
가치 낮음 | 하지 말자 | 한참 나중에 하자 |
•
엄밀하게 정의할 필요도 없고 수학도 필요없다. 이해관계자는 그저 카드를 보고 스토리의 가치와 추정된 비용에 따라 판단을 내리면 된다.
•
이런식으로 전체 계획을 짠다. 이해관계자는 스토리 카드 더미를 훑어보면서 가성비가 가장 좋은 스토리를 고른다.
•
고른 스토리의 포인트들을 더해서 30포인트가 되면 멈춘다. 여기까지 골라진 스토리가 이번 반복 주기에 쳐낼 일이다.
중간 확인
•
시간을 돌려서 반쯤 지났다고 해보자.
•
중간 검토 회의를 시작했더니 완료한 스토리 포인트가 10포인트밖에 되지 않는다. 이해 관계자가 계획했던 스토리를 줄여 남아있는 포인트를 10으로 낮추었다.
•
그리고 그 주의 금요일 18포인트만큼 완료할 수 있었다. 이번 반복 주기는 실패일까?
•
그렇지 않다. 반복 주기의 목표는 관리자에게 데이터를 제공하는 것이다.
•
반복 주기 동안 작동하는 코드를 만든 것은 물론 좋은 일이며 그러지 못했더라도 데이터는 만들어냈다.
어제의 날씨
•
이제 우리는 하나의 반복 주기 동안 대략 몇 포인트를 처리할 수 있는지 안다. 약 18포인트다.
•
다음 반복 주기를 시작하게 되는 첫날의 회의에서 이해관계자가 스토리를 몇 포인트나 골라야할까? 당연히 18포인트다.
•
그랬더니 이번엔 중간 검토 회의에서 12포인트를 처리했다면? 이해관계자는 이를 이미 알고 남아있는 포인트를 12포인트로 재조정할 것이다.
프로젝트 종료
•
이렇게 흘러간다. 반복 주기가 끝날 때마다 속도 차트에 반복 주기의 속도를 기록하므로, 누구나 이 팀의 진행속도를 확인할 수 있다.
•
프로젝트는 스토리를 모두 구현해서 끝나지 않는다. 더이상 구현할 가치가 있는 스토리가 없을 때 끝이 난다.
스토리
•
사용자 스토리는 기능을 기억하기 위해 쓰는 짧은 설명이다. 스토리를 쓸 때 너무 많은 세부 사항을 적어선 안 된다. 세부 사항은 쉽게 바뀌기 때문이다.
◦
세부 사항은 나중에 인수 테스트 형태로 작성한다.
•
스토리를 쓸 때는 다음 여섯 가지를 지켜야한다. 각 항목의 앞글자를 따면 외우기 쉬운 INVEST가 된다.
◦
I(Independent)
▪
사용자 스토리는 서로 독립적이어야 한다. 스토리를 어떤 순서로 구현해도 상관없다는 말이다.
▪
로그아웃을 구현하기 전에 로그인을 꼭 구현해야만 하는 것은 아니다.
▪
이 항목을 꼭 지키지는 않아도 된다. 보통은 순서가 존재하기 때문이다. 그럼에도 가능한 의존성을 줄이면서 스토리를 나누어야 한다.
◦
N(Negotiable)
▪
이것이 세부 사항을 전부 쓰지 않는 이유다. 세부 사항은 개발자와 사업 부서가 협상할 수 있어야 한다.
◦
V(Valuable)
▪
스토리는 명확하고 계량할 수 있는 비즈니스 가치가 있어야 한다.
◦
E(Estimable)
▪
사용자 스토리는 개발자가 작업량을 추정할 수 있을만큼 구체적이어야 한다.
◦
S(Small)
▪
사용자 스토리는 개발자 한두 명이 반복 주기 한 번 이내에 구현하기 힘들 정도로 크면 안 된다.
◦
T(Testable)
▪
사업 부서가 스토리 완료를 증명하는 테스트를 제시할 수 있어야 한다.
스토리 추정
•
스토리의 포인트를 추정하는 방법은 다양하다. 일단 개발자만 참여한다.
•
개발자들은 모여서 스토리에 관해 자신이 생각하는 사이즈를 각자 얘기한다. 그리고 그 평균을 내서 스토리로 결정한다.
•
저자는 이 크기의 예로 피보나치 수열이나 5단계로 구분하는 것을 추천한다.
쪼개기, 합치기, 스파이크
•
너무 큰 스토리는 쪼개야 한다. 이때 INVEST를 지키면서 쪼개야 한다.
•
합치기는 그저 스토리 카드를 클립으로 묶어서 하나의 스토리인척 하면 된다.
•
스파이크는 스토리를 추정하는 스토리다. 추정하기 힘든 스토리를 추정하기 위해 필요한 작업들을 스토리로 추가한다. 그 이후 반복주기에선 해당 스토리를 구현할 수 있을 것이다.
반복 주기 관리하기
•
각 반복 주기의 목표는 스토리를 처리하여 데이터를 얻는 것이다.
•
계획 회의에선 프로그래머들이 스토리를 어떻게 나눠가질지 자신이 결정해야 한다.
•
그리고 스토리는 끝낼거면 끝내야 한다. 모든 스토리를 80% 정도 하는 것보다 모든 스토리의 80% 정도를 완료하는 것이 더 낫다.
QA와 인수 테스트
•
QA가 자동화된 인수 테스트를 작성하지 않았다면 계획 회의가 끝나자마자 시작해야 한다.
•
먼저 처리될 것 같은 스토리의 테스트부터 시작해야 한다. 구현이 끝났는데 인수 테스트가 없어서 완료를 기다려서는 안 된다.
데모
•
이해관계자에게 완료한 스토리의 데모를 시연하는 것으로 반복 주기가 끝난다. 이는 한두 시간 내에 끝나는 것이 좋다.
◦
이 데모를 이해관계자가 직접 해보는 것이 제일 좋다.
•
데모 시, 인수 테스트와 단위 테스트 모두를 통과하는 것도 보여주어야 한다.
속도
•
반복 주기를 마치면서 속도 그래프와 번다운 차트를 기록한다. 인수 테스트를 통과한 스토리의 포인트만 기록해야 한다.
•
일정한 반복 주기가 지나면 속도의 가속도는 0이어야 한다. 장기적으로 속도가 오르거나 떨어질 특별한 이유는 없다.
•
속도가 오르는 경우는 아마 프로젝트 관리자가 닦달하는 경우일 수 있다. 압박이 심해지면 팀원들은 스토리 포인트를 과장하여 추정하기 마련이다.
◦
이를 막는 하나의 방법은 스토리 추정 결과를 계속해서 예전의 기준과 비교해보는 것이다.
•
속도가 떨어진다면 코드 품질에 문제가 있을 경우가 있다. 설계가 잘못되어 구현에 문제가 발생하는 것이다.
작은 릴리스
•
작은 릴리스 실천 방법은 개발팀이 소프트웨어를 최대한 자주 배포할 것을 권장한다.
•
이는 매우 짧은 주기를 목표로 해야 한다. 따라서 새로운 목표는 지속적 배포다. 변경 사항이 생길 때마다 코드를 서비스에 배포하는 것이다.
•
지속적 배포를 배포 주기를 짧게 가져가는 것으로 오해할 수 있는데 그렇지 않다. 모든 주기를 줄여야 한다.
•
불행하게도 옛날부터 이어져 온 관성 때문에 주기를 줄이기가 쉽지 않다. 이 관성은 아주 옛날부터 우리가 소스 코드를 관리해 오던 방식 때문에 생겨났다.
소스 코드 관리의 간단한 역사
•
소스 코드 관리 이야기는 프로그램을 수정하는 주기와 그 주기의 길이에 대한 이야기다.
•
이 이야기는 천공 카드를 사용하던 1950 ~ 60년대에 시작한다. 그 당시에는 대부분 천공 카드를 사용했다. 카드에는 80자를 기록할 수 있었고 한 장이 프로그램 한 줄을 의미했다. 전체 프로그램은 이런 카드들을 모은 묶음이었고 고무줄로 묶어 상자에 보관했다.
•
프로그램의 담당자는 카드 묶음을 서랍이나 캐비닛에 보관했고 어떤 사람이 소스 코드를 확인하고 싶다면 말 그대로 담당자의 허락을 받고 소스 코드를 서랍이나 캐비닛에서 꺼내서 빌려가야(Check Out) 했다.
•
소스 코드를 체크아웃하면 소스 코드를 고칠 수 있는 유일한 사람이 된다. 소스 코드를 물리적으로 갖고 있기 때문이다. 다른 사람은 건드릴 수 없다.
테이프
•
70년대부터 소스 코드 저장 매체를 마그네틱 테이프로 조금씩 바꾸기 시작했다. 마그네틱 테이프에는 많은 양의 소스 코드 모듈을 저장할 수 있었고 복제가 간편했다.
•
작업 시에는 마스터 테이프를 작업 테이프에 복사하여 작업 테이프를 변경하고 변경한 내용을 마스터 테이프에 다시 갖다 놓는다.
•
이 과저에서 충돌을 방지하기 위해 자신이 특정 모듈을 작업 중임을 핀을 이용해 게시판에 표시한다.
디스크와 SCCS
•
80년대에는 소스 코드가 디스크로 옮겨갔다. 초기에는 계속해서 체크아웃 현황판을 사용했지만 곧 진정한 의미의 소스 코드 관리 도구가 등장했다.
•
저자의 기억에 가장 처음 나왔던 것은 SCCS였다. SCCS는 체크아웃 현황판과 똑같이 동작했다. 디스크에서 모듈에 잠금을 걸어서 다른 사람이 수정하지 못하게 막는다.
◦
이런 방식의 잠금을 비관적 잠금이라고 한다.
•
SCCS는 RCS로 대체되었고 RCS는 CVS로 대체되었다. 이는 모두 비관적 잠금 방식을 사용했다. 따라서 프로그램의 수정 주기는 여전히 길었다.
서브버전
•
그리고 서브버전이 탄생했다. 서브버전은 낙관적 잠금을 사용했다.
•
SVN은 체크아웃한 내용을 기록해 두었다가 모듈의 변경 내용을 자동으로 합쳐 준다. 만약 충돌이 발생했다면 프로그래머가 충돌을 해결한 후 체크인할 수 있었다.
•
덕분에 조금씩 고치면서 편집, 컴파일, 테스트를 반복하느 데 드는 시간이 급격히 줄었다. 그러나 모듈 사이의 연결은 여전히 문제였다.
•
그러나 느슨하게 연결된 시스템을 개발할 때는 확실히 장점이 있었다. 훨씬 더 빠르게 수정을 반복할 수 있었다.
깃과 테스트
•
이제 우리는 깃을 쓴다. 깃을 쓰면 체크아웃 시간은 0이 된다.
•
사실 체크아웃이라는 개념이 아예 없다. 언제든지 모듈 수정 사항을 커밋할 수 있다. 커밋 간의 충돌은 프로그래머가 원하는 시점에 해결할 수 있다.
•
작고 독립적인 모듈과 빠른 커밋 속도 덕분에 소스 코드 수정 주기는 몇 분 정도로 줄어든다. 여기에 포괄적이고 빠르게 수행되는 테스트를 포함시켜 거의 모든 것을 테스트할 수 있다면 지속적 배포를 달성해낼 수 있다.
오래된 관성
•
불행하게도 조직에서는 관습을 바꾸기 어렵다. 많은 팀의 문화 속, 깊게 자리 잡은 그것들은 당연하게 생각되는 것들이다.
•
이런 상황에서 지속적 배포는 터무니없게 느껴질 것이다.
작은 릴리스
•
애자일은 릴리스 주기를 더 짧게 만들어 이 관성을 깨부수려한다.
•
릴리스 주기를 줄이려면 릴리스와 배포 사이의 관계를 끊어야 한다. 릴리스라는 단어는 소프트웨어가 기술적으로는 배포 가능하다는 것을 의미한다.
•
실제로 배포할 타이밍은 오직 사업 부서에서 결정한다.
인수 테스트
•
인수 테스트는 애자일 실천 방법 중 아는 사람이 가장 적고, 드물게 사용되며 많이들 오해하는 실천 방법이다.
•
그러나 기반이 되는 발상은 엄청 단순하다. 바로 사업 부서가 요구 사항을 명시해야 한다다.
•
인수 테스트는 가능한 한 시스템의 요구 사항을 자동화된 테스트로 작성하는 것이다.
동작 주도 개발
•
댄 노스가 TDD를 새롭게 정의한 BDD의 목표는 테스트에서 개발자 용어를 빼내고 명세처럼 보이게 만들어 사업 부서 사람들이 직관적으로 이해 가능하게 만드는 것이었다.
실천 방법
•
인수 테스트의 실천 방법은 꽤 단순하다.
◦
사업 부서에서는 사용자 스토리의 동작을 설명하는 테스트를 형식에 맞게 작성하고 개발자는 이를 자동화한다.
◦
인수 테스트는 업무 분석가와 QA가 작성한다. 테스트할 스토리를 개발하는 반복 주기의 전반부가 끝나기 전까지 작성해야 한다.
•
개발자는 이 테스트를 지속적 빌드에 통합한다. 인수 테스트로 반복 주기에서 개발하는 스토리의 완료 여부를 판단한다.
•
인수 테스트가 없는 스토리는 명세가 없는 것이며 통과하지 않으면 스토리가 끝난 것이 아니다.
업무 분석가와 QA
•
인수 테스트는 업무 분석가와 QA 그리고 개발자가 함께 작성한다.
•
업무 분석가는 정상적으로 성공하는 경로를 기술한다.
•
QA는 정상에서 벗어난 경로를 담당한다.
QA
•
QA는 이제 프로젝트가 끝날 때쯤야 테스트를 수행하는 역할에서 프로젝트 초기에 명세를 작성하는 역할로 바뀐다.
사라지는 막바지 테스트
•
QA를 앞쪽으로 옮기고 테스트를 자동화하면 심각한 문제가 하나 더 해결된다.
•
QA가 마지막으로 모든 테스트를 수행하면 전 단계의 모든 지연으로 인한 부담이 QA에게 가중되는데 이를 방지할 수 있다.
개발자가 테스트를 돌린다
•
이 모든 병을 고치는 방법이 인수 테스트다.
•
반복 주기에서 처리할 스토리의 인수 테스트를 QA가 작성한다. 하지만 QA는 테스트를 돌리지 않는다.
•
테스트는 프로그래머가 돌려야 한다. 모든 코드가 테스트를 통과하는지도 프로그래머가 담당해야 한다.
지속적 빌드
•
사실, 프로그래머는 지속적 빌드 서버를 구축해서 이 과정을 자동화할 것이다.
•
빌드 서버는 프로그래머가 체크인할 때마다 시스템의 모든 테스트를 수행한다. 모든 단위 테스트와 인수 테스트를 죄다 수행한다는 말이다.
전체 팀
•
전체 팀 실천 방법은 기존에 현장 고객이라고 불렀었다.
•
기본적인 아이디어는 사용자와 프로그래머가 물리적으로 가까이 있을수록 의사소통하기 더 좋을 것이며 이는 개발도 더 빠르고 정확하게 할 수 있을 것이라는 것이었다.
•
여기서 고객은 사용자가 필요로 하는 것을 잘 알면서 개발팀과 같은 곳에서 일하는 사람이나 그룹을 가리키는 은유다.
•
스크럼에서는 이 고객을 제품 책임자라고 부른다. 제품 책임자인 사람 혹은 그룹은 스토리를 고르고 우선순위를 결정한 후 바로바로 피드백을 준다.
•
팀 전체가 같은 곳에서 일을 한다면 비즈니스는 훨씬 순탄하게 돌아간다.
결론
•
사업 부서와 개발 부서 사이의 불화를 치유하는 것이 선언의 목표 중 하나였다.
•
이 목표를 달성하는데 비즈니스 실천 방법이 가장 큰 역할을 할 것이다. 이 실천 방버을 따르면 사업 부서와 개발 부서가 단순하고 명확하게 의사소통할 수 있다.
•
이런 의사소통이 신뢰를 낳는다.
