클린 애자일 다시 읽기 - 3장 비즈니스 실천 방법

 

개요

3장은 비즈니스 실천 방법(Business Practices), 4장은 팀 실천 방법(Team Practices), 5장은 기술 실천 방법(Technical Practices) 이다.

비즈니스 실천 방법이란 이들을 실천하면 비즈니스에 이득이 된다는 것을 말한다.

비즈니스 실천 방법

책에서 소개하는 비즈니스 실천 방법은 다음 4가지이다. 다시 말하지만 이를 실천하면 비즈니스에 이득, 도움이 된다는 말이다.

• 계획 세우기(Planning)
• 작은 릴리즈(Small Releases)
• 인수 테스트(Acceptance Tests)
• 전체 팀(Whole Team)

계획 세우기(Planning)

프로젝트를 실제로 완성하지는 않고, 프로젝트가 대략 얼마나 걸릴지 알고 싶은 것이다. - p72

소프트웨어 개발자를 위한 좋은 추정 요령은, 확실할 시간 범위를 고르되 이 시간 범위를 가능한 한 좁히기 위해 약간의 시간을 투자하는 것이다. - p73

 

삼변량 추정(trivariate estimation)은 전체 프로젝트의 장기 추정을 할 수는 있지만, 한 프로젝트 내 일상적 관리 용도로는 스토리 포인트가 좋다.

스토리 포인트(Story Point)

스토리 문구는 단순해야 한다. 세부사항을 정하기에는 아직 이르기 때문에, 세부 사항은 생략해야 한다. 세부 사항을 정하는 일은 늦추면 늦출수록 좋다. 스토리를 개발하기 직전까지 미뤄 두어도 좋다. 스토리를 요양한 형태로 놔둠으로써 나중에 대화하기로 약속하는 것이다.
- p74, 론 제프리스가 정의한 스토리

 

세부사항이란 software를 hard 하게 만든다. 세부사항은 인수 테스트 형태로 작성한다.

스토리는 자리를 마련한 것뿐이지 요구 사항이 아님을 명심하자. - p76

스토리는 프로젝트 전체에 걸쳐서 언제나 만들어지고, 바뀌고, 버려지고, (가장 중요하게는) 개발된다. - p76

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

 

“이것도 챙겨야 할것 같은데?” 정도의 메모인 것이다. 나중에 이야기 해볼만한 것을 잊지 않도록 적어두는 것이다. 그렇기에 수시로 생성, 수정, 삭제, 개발된다.

포인트는 추정한 노력의 단위이지 실제 시간을 나타내지 않는다. 시간을 추정한 것이 아니라, 노력을 추정한 것이다. - p78

 

따라서 시니어에게는 30분의 노력이 들어갈 일이면서도, 주니어에게는 세 시간의 노력이 들어갈 일이 될 수 있다.

속도는 약속이 아니라는 점을 꼭 기억해야 한다. 반복 주기 동안 30포인트를 처리하겠다고 약속하는 것이 아니다. 30포인트를 처리하도록 노력하겠다고 약속하는 것도 아니다. 그저 반복 주기 동안 포인트를 얼마나 처리할 수 있을지 짐작해 본 것 뿐이다. - p79

 

일정을 예상하는 데이터로 쓰는 것이다. 약속이 아니라 짐작이다. 일정에 대한 짐작의 데이터이다.

반복 주기에 실패란 없다. 반복 주기의 목표는 관리자에게 데이터를 제공하는 것이다. - p81

각 반복 주기의 목표는 스토리를 처리하여 데이터를 얻는 것이다. - p88

 

다시 한 번, 반복이다. 스토리 포인트를 많이 하고 적게 하는 것은 성공과 실패의 기준이 아니다. 팀의 속도를 가늠하는 데이터일 뿐이다. 따라서, 여러 스토리를 80% 완료하는 것 보다, 80%의 스토리를 완료하는 게 낫다. 그리고, 그 완료의 기준은 인수 테스트 통과이다.

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

스토리 중에서 투자 수익률이 높은 것을 우선하여 작업한다.

스토리 작성에 지켜야할 여섯 가지 - INVEST

1. Independent: 가능한 스토리간에 의존성이 없어야 한다. 그래야 비즈니스 가치의 우선 순위에 따라 개발할 수 있다.
2. Negotiable: 세부사항이 없는 이유이다. 사업 부서와 개발자가 협상할 수 있어야 한다.
3. Valuable: 개발하면 어떤 가치를 얻게 되는지 명확하게 측정할 수 있어야한다. 따라서 리팩터링은 스토리가 될 수 없다.
4. Estimable: 작업량을 추정할 수 있을 만큼 구체적이어야 한다.
5. Small: 반복주기 내에 한, 두명이 수행 가능해야 한다.
6. Testable: 테스트로 완료 여부를 증명할 수 있어야 한다.

스토리의 크기를 추정하는 방법

플라잉 핑거(Flying Finger): 간편하게 추정한다.

계획 포커(Planning Poker): 큰 스토리를 추정할 수 있다.

쪼개거나, 합치거나, 스파이크

스토리가 너무 작은 크기면 몇 개를 합치고, 너무 크면 INVEST를 지키며 쪼갠다.

스토리가 미지의 영역이라면 스토리에 대해 공부하는 메타스토리를 만든다. 스파이크이다.

속도

속도가 빨라진다고 꼭 좋은 것은 아니다. 속도를 측정하는 것이 목표이지, 속도가 빨라지는 것이 목표가 아니다. 팀이 더 빨리 해야한다는 압박에 스토리 포인트 인플레이션이 벌어지는 것일 수 있다.

속도가 느려진다면 코드 품질에 문제가 생긴 것일 수 있다. 마틴 파울러의 디자인 스테미너 가설을 떠올려보자.

작은 릴리즈(Small Releases)

최대한 자주 릴리즈하자.

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

 

릴리스와 배포의 차이를 이제야 인식했다!

인수 테스트(Acceptance Tests)

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

업무 분석가(business analyst)는 정상적으로 성공하는 경로만 기술한다. (중략) QA는 정상에서 벗어난 경로를 담당한다. - p102, 103

(QA의 역할은) 프로젝트가 끝날 즈음에야 테스트하는 역할에서 프로젝트 초기에 명세를 작성하는 역할로 바뀐다. - p103

업무 분석가와 QA가 작성한 인수 테스트를 구현하고 실제로 돌려보고 통과하는 지 확인하는 것은 개발자의 몫이 된다.

전체 팀(Whole Team)

같은 방에 모든 구성원이 함께 앉아서 일하는 것이 가장 이상적이다. - p106

전체 팀이 같은 공간에 함께 앉아 있으면, 마법이 일어난다. -p106

이 실천 방법은 팀 실천 방법이 아니라 비즈니스 실천 방법에 속한다. 전체 팀을 실천해서 얻을 수 있는 이득이 주로 비즈니스 쪽에 있기 때문이다. - p106

결론

계획 세우기, 작은 릴리즈, 인수 테스트, 전체 팀 - 네 항목을 곰곰이 생각해보자. 이러한 비즈니스 실천 방법을 사용하면 사업 부서와 개발 부서가 단순, 명확한 의사소통을 할 수 있다. 부서간의 신뢰를 낳는다.