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

Photo by David Travis on Unsplash

 

클린 애자일 3장은 비즈니스 실천 방법을 다루고 있다. 개발은 결국 비즈니스를 하려고 하는 것이다.

 

"2001년 스노버드 회의 때였다. 켄트 벡은 사업 부서와 개발 부서 사이의 불화를 치유하는 것이 우리의 목표 중 하나라고 말했다. 이 목표를 달성하는데 비즈니스 실천방법이 큰 역할을 할 것이다. 이 실천 방법들을 따르면 사업 부서와 개발 부서가 단순하고 명확하게 의사소통할 수 있다. 이런 의사소통이 신뢰를 낳는다." 109p

 

빼거나 요약할 부분이 없어서 3장의 결론을 그대로 가져왔다. 사업 부서와 개발 부서 사이에 잘 소통하여, 비즈니스적으로 도움이 되게 하는 것. 이게 애자일에서 비즈니스 실천 방법을 쓰는 이유이다.

 

아래 그림은 삶의 순환(Circle of Life)라고도 불리는 론 제프리즈의 XP 실천 방법을 설명하는 그림이며 비즈니스 실천 방법은 가장 바깥의 원을 이룬다.

 

<이미지 출처: https://blog.ynkb.xyz/89/ >

 

비즈니스 실천 방법 다음과 같다.

 

- 계획세우기(Planning Game): 개발팀에서 언제까지 어떤 기능을 구현할지를 계획하고, 예측할 수 있어야 밖에 나가서 비즈니스를 할 것 아닌가?

- 작은 릴리즈(Small Release): 기능을 구현하거나 버그를 잡을 때마다 바로바로 개선사항이 반영된 완전한 결과물이 있다면 비즈니스하기 좋을 것이다. 

- 인수 테스트(Acceptance Test, Customer Test): 사업 부서가 원하는 기능을 개발 부서가 구현했는지 확인하는 테스트이다.

- 전체 팀(Whole Team, Sit Together): 프로젝트와 관련한 모든 사람은 최대한 "물리적으로" 가까이 있는게 좋다는 것

 

네 가지 비즈니스 실천 방법을 하나씩 들여다보자.

 

계획 세우기(Planning Game)

비즈니스를 하려면 뭐가 필요할까? 어떤 기능을 언제까지 개발할지를 알아야 비즈니스를 할 수 있다. "고객님이 원하시는 기능은 이번 달 말까지 해드릴 수 있습니다." 라고 말할 수 있어야 하는 것이다. 계획을 세워야 한다. 애자일하게 계획하는 방법을 알아보자.

 

스토리와 포인트를 사용하는 방법을 써보자. 스토리는 사용자의 관점에서 간략히 적어보는 것이다.

 

"자동차 운전자가 속도를 높이기 위해 가속 페달을 발로 더 세게 누릅니다." 74p

 

이게 전부이다.

 

"스토리 문구는 단순해야 한다. 세부 사상을 정하기에는 아직 이르기 때문에, 세부 사항은 생략해야 한다. 세부 사항을 정하는 일은 늦추면 늦출수록 좋다." 74p

 

 스토리는 요구사항이 아니다. 책에서는 자리를 마련한다고 표현했는데, 해야 할 게 있다는 걸 잊지 않는 메모 정도로 생각해두자. 이러한 스토리는 프로젝트 내내 만들어지고 변경되고 삭제된다. 애자일 개발 선언의 "계획을 따르기보다 변화에 대응하기를"을 떠올리게 한다.

 

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

 

스토리 추정은 스토리를 개발하는데 얼마나 힘들지를 포인트로 점수 매기는 것이다. 다양한 방법이 있는데 하나만 들자면 1-5점을 주는 것이다. 로그인 구현은 3점이라면, 로그아웃은 그보다 많이 쉬우니 1점을 주는 것이다. 1점이면 1주일 소요라는 개념으로 접근하면 안된다. 로그인이 로그아웃보다 제법 어렵다는 그 상대적인 느낌에 집중해야 한다. 상대적인 느낌에 밑줄 쫙 그어보자.

 

포인트 처리 속도

만약 반복 주기내에 구현할 스토리들을 보아보니 30 포인트였다고 하면, 30 포인트/반복주기라는 속도로 표현할 수 있겠다. 속도는 약속이 아니다. 속도는 짐작이다. 반복 주기동안 30 포인트 처리하겠다는 약속이 아니라, 30포인트 정도는 처리 가능하겠는걸? 하는 짐작이다.

짐작하고 실제 결과를 보면 그게 데이터가 된다. 프로젝트를 관리하는데 도움이 될 데이터이다. 반복주기를 여러 번 거치면 데이터가 점점 더 쌓이게 된다.

 

"반복주기의 목표는 관리자에게 데이터를 제공하는 것이다." 81p

 

생각에 관한 생각 국내도서 저자 : 대니얼 카너먼(Daniel Kahneman) / 이창신역 출판 : 김영사 2018.03.30 상세보기

"생각에 관한 생각" 이라는 책을 보면 전문가가 신뢰할 만한 직관을 가질 수 있으려면 빠르고 정확한 피드백이 중요하다는 이야기가 나온다. 애자일을 통해 반복 주기마다 포인트 처리 속도에 대한 피드백을 바로바로 받다 보면 반복 주기에 해낼 수 있는 포인트, 즉 개발 속도를 가늠할 수 있는 직관이 생기게 되는 것이다.

 

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

- 그러므로 여러 스토리를 조금씩 하는 것보다. 하나의 스토리라도 완료하여야 한다. 그래야 데이터가 된다.

 

이렇게 애자일한 비즈니스 실천 방법대로 계획을 세우고 실천하다보면, 우리는 개발의 속도를 예측 가능하게 된다.

 

작은 릴리즈 (Small Release)

예전에는 버전 관리의 기술적 한계, 테스트 및 배포의 과정이 필요하여 한 번 릴리즈하기가 쉽지 않았다.

하지만 이제는 Git과 같은 툴을 이용한 버전 관리, 자동화된 테스트와 배포를 통해 릴리즈가 한결 쉬워졌다.

 

작은 릴리즈는 개발팀이 최대한 자주 소프트웨어를 릴리즈 하라는 것이다. 애자일 초기에는 한두 달을 의미했지만 이는 점점 더 짧아지고, 이제는 아예 지속적 배포(Continuous Delivery)로 변경 사항이 생길 때 마다의 배포를 이야기한다.

 

배포 주기를 줄인다는 말은 결국, 반복 주기를 줄인다는 말이 된다. 궁극의 목표라 생각해두자.

 

인수 테스트(Acceptance Test)

"사업 부서가 요구 사항을 명시해야 한다." 99p

 

이번 개발 반복주기에서 개발 부서가 개발해야 할 사항을, 사업 부서가 잘 명시해서 전달해야 한다는 것이다.

 

"그렇다면 명세란 뭘까? 명세란 그 본질상 테스트다." 99p

 

그런데 이러한 테스트는 요구사항을 가장 잘 아는 사업부서가 작성해야 할 것 같기도 하고, 개발언어로 테스트를 만들고 이를 자동화 해야 하는 걸로 보면 개발자가 해야 하는 것도 같다. 여기에서 다양한 시도가 있었지만 다들 힘들어했다.

 

BDD라는 것도 생겨났다. 동작 주도 개발(Behavior-Driven Development)이다. 개발자의 용어를 빼버린 테스트라고 할까?

BDD는 주어진 상황(Given)에서 특정한 행동을 하면(When) 어떠한 결과(Then)가 나와야 한다는 것이다.

 

다시 (BDD는 잊고) 개론으로 돌아가면, 사업 부서가 개발 반복주기에 어떤 스토리를 할 지를 결정하면, 그것에 대한 명세서를 작성해야 하는데 명세서란 바로 테스트이다. 스토리를 구현한 기능은 인수 테스트를 통과해야 구현을 완료한 것으로 보는 것이다.

 

사업부서가 사용자 스토리의 동작을 설명하는 테스트를 형식에 맞게 작성하면, 개발자가 이를 자동화한다. 스토리와 인수테스트는 쌍이다. 이러한 테스트는 반복주기 전반부 이전에 작성하고 지속적 빌드에 통합해야 한다. 이렇게 되면 QA의 역할은 개발 끝나고 테스트로 조지는(?) 역할에서, 프로젝트 초기에 성공시켜야 할 인수테스트를 짜는 역할로 바뀐다.

 

이와 같이 인수 테스트를 활용하면 기존의, 개발 막바지의 테스트 방식이 가진 많은 문제점들이 해소된다.

 

전체 팀(Whole Team)

애자일 개발 선언 중에서 "공정과 도구보다 개인과 상호작용을" 부분과 관련이 있겠다. 상호작용.

 

프로젝트에는 관련한 다양한 역할의 사람들이 있을 것이다. 고객, 관리자, 테스터, 테크니컬 라이터, 개발자 등등

이 모든 사람을 "물리적으로" 최대한 가까이, 가능하다면 함께 앉아서 일하게 하라는 것이다. "물리적으로" 가까울 수록 다양한 커뮤니케이션이 잘 일어나게 되고 그것이 비즈니스 적으로 많은 유형, 무형이 이익이 된다는 것이다. 예전에 삼성 무선 사업부에서 프로젝트가 시작되면 프로젝트 구성원을 모두 한 공간에 몰아 넣어서 일을 시켰다는 이야기가 생각났다.

 

삶의 순환(Circle of Life)에서 비즈니스 실천 방법을 정리해보았다. 다음 포스팅에서는 남은 팀 실천 방법, 기술 실천 방법 중에서 팀 실천 방법을 정리해 보겠다.