[IT/리뷰] 애자일 마스터 : 프로젝트 인셉션, 추정과 계획 그리고 실행

애자일 마스터 : 네이버 도서 (naver.com)

애자일 마스터 : 네이버 도서

애자일 방식으로 프로젝트를 진행해보고 싶었던 와중에 눈에 띄어서 책을 읽어보게 되었다.

 

나와 같이 애자일 방식을 사용한 적이 없던 사람이 읽어도 괜찮은 책이지만, 이미 애자일 방식을 사용하고 있었으나 어려움을 겪고 있는 곳에서 읽었을 때 더욱 도움이 될만한 책이다. 애자일을 수행하는 방법과 더불어 왜 애자일 방식으로 실패를 했을지에 대해서 다루고 있다. 기존 조직과 회사에서의 문제점들과 이를 애자일 방식으로 접근했을 때의 방법과 장점을 설명한다.

 

애자일을 시작하는 방법, 사용자 스토리를 수집하는 방법, 일정에 대한 추정 방법, 애자일 수행 중 발생하는 어려움을 어떻게 해결해야 하는지 등에 대해서 다룬다.

마지막에는 애자일을 잘 활용하기 위한 실천법들에 대해 간단하게 설명한다.

그리고 책 전반에 걸쳐서 애자일이 무엇이며 목적은 무엇인지를 반복해서 설명한다.

 

애자일에 대한 이론적으로 전문적 지식을 쌓기 위한 책으로는 좋지 않은 것 같다. 하지만 이 책을 통해 해본적 없던 나도 애자일 방식으로 프로젝트를 진행할 수 있을 것 같은 생각이 들게 된다.

 

올해 안에 사이드 프로젝트를 진행하되 애자일 방식으로 진행할 것이다. 애자일을 하는 동안 만나는 어려움들을 아래에 정리한 책의 내용들을 통해 해결해보도록 해야겠다.

오늘도 정리한 내용들은 많다.. 애자일을 제대로 경험해보지 못했으니 그럴만도 하다..

---

애자일의 핵심은 매주 고객에게 가치있는 것을 전달하는 것이다. '매주'라는 개념이 부담스럽다면 걱정할 필요 없다. 대부분의 애자일 팀은 2주(정말 큰 팀은 3주)마다 소프트웨어를 출시하는 것으로 시작한다.

사실 이 주기는 여러분으로 하여금 제대로 작동하는 소프트웨어를 정기적으로 고객에게 전달하고 피드백을 받도록 하기 위한 틀일 뿐이니, 필요하다면 언제든지 수정해도 좋다.

 

애자일 프로젝트에서 일을 처리하는 엔진은 '이터레이션(스프린트)'이다. 프로젝트 팀원들은 팀의 속도(한 이터레이션 동안 할 수 있는 작업량)를 보면서 자신들이 얼마나 많은 일을 할 수 있는가 알 수 있다.

해야 할 일이 너무 많다면 여러분이 할 수 있는 건 더 적게 맡는 것 밖에 없다. 프로젝트 범위를 유연하게 잡으면 계획의 균형을 유지하고 여러분이 맡은 일에 책임도 질 수 있을 것이다.

현재 처한 상황이 이미 계획과 맞지 않다면 계획을 바꿔라. 유연한 계획 세우기야말로 애자일의 초석이다.

 

프로젝트에 관한 아주 단순한 세 가지 진실을 소개하겠다. 이 세 진실을 겸허히 인정하고 받아들인다면 프로젝트에서 마주하는 여러 우여곡절이나 걸림돌들을 수월히 피할 수 있을 것이다.

1. 프로젝트 초기에 요구사항을 모두 수집하기는 불가능하다.
2. 수집한 요구사항들이 무엇이든 반드시 변하기 마련이다.
3. 시간이나 비용이 허락하는 것보다 해야 할 일들이 항상 더 많다.

이 세 가지만 받아들여도, 소프트웨어 출시와 관련된 수많은 스트레스와 고민들은 확실히 줄어들 것이다. 그러면 한층 더 높은 집중력과 명쾌함으로 혁신을 일으킬 수 있다.

 

애자일 팀은 여러 면에서 기존 프로젝트 팀과 차별화된다. 전형적인 애자일 프로젝트는 팀원 각각의 역할을 미리 정의하지 않는다. 누구나 무슨 일이든 할 수 있다. 그런데 이런 혼란스럽고 체계적이지 않은 것 같은 틀 속에서 높은 품질의 소프트웨어가 끊임없이 생산된다.

 

애자일 팀을 애자일답게 하는 것에서 갖추어야 할 것들은 다음과 같다.

• 같은 공간에서 일하기
  • 같은 공간에서 일하는 팀은 질문에 대한 답을 빨리 얻을 수 있다.
  • 팀원간 교류할 때 생기는 문제도 적고 서로 간에 믿음도 빨리 생긴다.
  • 분산된 공간에서 일해도 차이를 줄이기 위한 방법은 프로젝트 초반에라도 모이는 방법이다. 후에는 여러 의사소통 도구로 소통을 지속하면 된다. 
• 참여하는 고객
  • XP나 스크럼 같은 애자일 방법론이 현장 고객(on-site customer)이나 제품 책임자와 같은 역할을 통해 중요성을 강조한다.
  • 그런 고객이 없다면, 그 고객은 과거에 이런 시도가 실패한 경험이 있을 수도 있다. 고객의 골치 아픈 문제를 해결해주고 신뢰를 얻으면 고객이 당신 편에 설 날이 온다.
• 자기 조직화(self-organizing)
  • 자기 조긱화된 팀은 팀원 각자가 자존심이나 자신만이 옳다는 식의 태도를 버리고 자신의 기술, 열정, 재능을 사용해 한 팀으로써 프로젝트를 성공적으로 전달하기 위해 최선의 방법을 모색한다.
  • 팀원 스스로 계획하고 추정치를 정하면서 프로젝트의 주인이 되어라.
  • 누가 어떤 직책과 역할을 맡는지 보다는 제대로 작동하고 테스트를 통해 검증된 소프트웨어를 만드는 일에 신경 써라.
  • 가만히 앉아 임무가 맡겨지기를 기다리기보다는 진취적으로 자신의 운명을 개척해나갈 인재를 찾아라.
  • 참고 : 자기조직화 - 위키백과, 우리 모두의 백과사전 (wikipedia.org)
• 책임감과 자율성
  • 책임감 있는 작업은 팀에게 실질적인 권한이 주어졌을 때만 이루어진다.
  • 때때로 실수를 할 수 있지만 이를 통해 얻는 이득이 훨씬 크기 때문에 실수를 감수할 만하다.
  • 자율적이고 책임감 있는 팀을 구성한다는 것은 생각처럼 쉽지 않다. 그저 출근해서 시키는 일만 하면 쉽다 생각하는 사람들이 있기 때문이다.
  • 팀이 책임감이 없다 생각이 든다면 고칠 수 있는 쉬운 방법은 자신들이 만든 소프트웨어를 데모하도록 하는 것이다.
• 교차기능팀(cross-functional team)
  • 전반적인 분야에 걸쳐 고객에게 도움을 제공할 수 있는 팀으로, 고객이 어떤 기능을 요구하든 제대로 전달할 만한 충분한 역량을 팀 내에 갖추고 있다.
  • 다방면에 걸쳐 많이 알고 관심을 갖는 사람(generalist)을 구하도록 하자. 그저 프런트 엔드나 백 엔드만 아는 사람이 아니라 기술 전반적 분야를 아우르는 사람을 구하라.
  • 테스터나 애널리스트를 구한다면 요구사항을 심도 깊게 분석하면서도 테스트를 부담스러워하지 않는 사람을 구하라.
  • 팀 내 특정한 기술에 대한 지식이 부족해 간혹 전문가(specialist)가 필요한 경우도 있지만, 대부분 프로젝트가 진행되는 동안 팀 사람들과 그 내에서 문제를 해결할 수 있다.

 

참여하는 고객이 있는 팀은 소수에 불과하다. 참여하는 고객이 없이도 애자일을 사용해 프로젝트를 성공시킬 수 있다. 여기서 중요한 것은 고객의 참여를 많이 이끌어 낼수록 좋은 것은 변함없다. 그러니 최대한 참여를 많이 이끌어내고 그들이 스스로 필요한 결정을 내리고 자신들의 역할이 프로젝트를 성공시키는 데 얼마나 중요한지 이해하도록 해야 한다.

 

애자일 개발팀은 여러 기증을 지닌 교차검증 기술자로 이루어진 그룹이다. 아무리 애자일 팀에는 특정한 역할이 없다고 주장해도 여태 전통적인 방법으로만 일하던 개발팀에게 갑자기 '제일 잘하고 재미있어하는 일을 스스로 책임지고 하라(self-organize)'고 요구하는 방법이 먹히지는 않는다.

애자일에서 역할은 구체적이지 않으며 누구나 여러 역할을 수행할 수 있다고 이해시키는 것은 분명히 필요하다. 하지만 저자는 사람들이 이미 이해하고 있는 용어를 사용해 애자일을 소개했을 때 오히려 더 쉽게 애자일로 변해가는 것을 보았다. 알면 도움이 될 만한 애자일 역할을 배워보자.

• 애자일 애널리스트
  • 고객과 가장 가까이 일하며 고객이 정말 원하는 것이 무엇인지 캐내기 위해 끊임없이 질문하는 역할을 한다.
  • 고객이 사용자 스토리 쓰는 것을 도우며, 세부적인 사항을 분석한다.
• 애자일 개발자
  • 바람을 현실로 이루어지게 하는 역할을 한다.
  • 스토리에 대한 추정치를 정한다.
  • 기술적 사항(도구/아키텍처, 설계, 개발 실천법 등)에 대한 결정을 내린다.
  • 소프트웨어의 품질을 매우 중요하게 여기는 전문가다.
  • 더 높은 품질의 코드를 생산하려고 부족한 부분을 끊임없이 탐색하는 테스터라고 할 수 있다.
• 애자일 테스터
  • 기능이 기대한 것처럼 작동하는지 확인하는 작업이 다른 종류의 일이라는 것을 아는 사람이다.
  • 프로젝트 일찍 합류해 사용자 스토리가 정확히 정의되었는지, 개발된 후에는 스토리가 기대한 바와 같이 작동하는지를 확인한다.
  • 다음에 개발할 스토리의 테스트를 작성하며 큰 맥락에서 테스트(탐색적 테스트, 성능 테스트, 보안, 통합 등)를 생각한다.
• 애자일 프로젝트 관리자
  • PM으로, 프로젝트가 어떻게 진행되고 있는지 확인하며, 프로젝트 상태에 관해 필요한 사람들과 논의해야 한다.
  • 팀원들의 행복(개발 환경 개선 등)과 프로젝트의 성공을 위해 일해야 한다.
  • 필요하다면 외부 인사나 압력으로부터 팀을 보호하는 것 등이 PM이 하는 역할이다.
  • 훌륭한 애자일 PM은 팀원들에게 직접 일을 지시하지 않는다. PM이 일주일이나 출근하지 않아도 아무도 알아채지 못했다면 그건 그만큼 훌륭한 애자일 PM이라는 증거다.
• 애자일 UX 디자이너
  • 여러 도구나 기법을 사용해 편리한 사용자 경험을 할 수 있도록 한다.
• 이 외의 사람들
  • DBA(데이터베이스 관리자), SA(시스템 관리자), Technical Writer(기술문서 담당자), 교육 훈련 전문가 등

 

많은 프로젝트는 제대로 시작도 하기 전에 다음과 같은 이유들로 인해 실패하고는 한다.

• 적절한 질문을 하지 못해서
• 물어보기 껄끄러운 질문을 할 용기를 내지 못해서

따라서, 적절한 기대치를 세우기 위해 사용되는 최고의 도구인 인셉션 덱(inception deck)이 무엇인지 알아야 한다. 인셉션 덱은 버스에 적합한 사람이 탑승했는지, 이 버스가 바른 방향으로 가고 있는지 알게 해준다.

 

프로젝트 처음에는 성공의 의미가 서로 다르게 해석되는 경우가 많다. 이런 착각은 치명적이지만 처음부터 모두가 같은 생각을 가지지 않았다는 게 문제는 아니다. 오히려 자연스러운 현상이다. 문제는 의견이 일치되지 않은 상태에서 프로젝트가 시작된다는 사실이다. 따라서, 다음과 같은 것들이 필요하다.

• 현명한 선택을 위해 목표, 비전, 프로젝트 현재 상태에 대해 다른 팀원들과 소통하기
• 이해 관계자가 적절한 결정을 내릴 수 있도록 프로젝트에 관해 알아야 할 만한 정보 제공하기

이를 위해서는 부담스럽더라도 반드시 질문이 필요하다.

인게이지먼트(engagement)나 세일즈 초반에 어려운 질문을 최대한 해야 한다. 이때는 질문을 하면 무엇이든 별로 잃을 게 없다.

• 팀의 프로젝트 경험은 얼마나 되나요?
• 이런 작업을 해본 적이 있나요?
• 예산은 얼마나 배정되어 있나요?
• 프로젝트는 누가 지휘하나요?
• 애널리스트 둘에 개발자가 서른 명 있다는데 문제가 없을까요?
• 객체지향 언어를 사용해 본 경험이 없는 주니어 개발자들로 이루어진 팀으로, 애자일 방법론을 사용해 레거시 메인 프레임 시스템을 루비온레일스로 재구축 해봤습니까?

이런 질문들을 쉽게 할 수 있도록 하는 도구가 '인셉션 덱'이다.

 

인셉션 덱은 프로젝트를 시작하기 전에 반드시 물어야 하는 열 개의 까다로운 질문으로 이루어져있다. 저자가 근무하던 쏘트웍스에서는 프로젝트를 정의하는 단계(proejct chartering)에서 인셉션 덱을 사용했다. 전형적인 인셉션 덱은 며칠에서 2주 정도 소요된다. 약 6개월 기한의 프로젝트 계획을 세우기에 적당하다. 이때 세운 계획은 어느 때고 프로젝트의 방향이나 목표에 중요한 변화가 생기면 수정해야 한다.

인셉션 덱은 '프로젝트와 관련이 있는 사람들을 모아, 모든 사람들이 프로젝트에 기대하는 바가 동일하도록 서로 적절한 질문을 통해 생각을 공유한다면 프로젝트가 성공할 확률이 높을 것이다'라는 아이디어에서 시작되었다.

1. 우리가 여기 왜 모였는지 물어보라.
2. 엘리베이터 피치를 만들라.
3. 제품의 광고를 디자인하라.
4. NOT 리스트를 작성하라.
5. 프로젝트와 관계된 다양한 사람들과 알고 지내자.
6. 해결책을 보여주라.
7. 미리 야근 거리가 될 만한 것을 찾아보자.
8. 규모를 정하라.
9. 우선순위를 파악하라.
10. 기회비용이 무엇인지 파악하라.

 

인셉션 덱의 반은 왜 우리가 이 프로젝트를 하려는지 이해하기 위한 질문이다. (1~5번)

엘리베이터 피치는 짧은 시간 안에 핵심을 피력하는 방식이다. 좋은 엘리베이터 피치는 프로젝트에 다음과 같은 영향을 줄 수 있다.

• 프로젝트의 핵심을 분명히 이해할 수 있다.
• 팀원으로 하여금 고객의 입장에서 생각하도록 한다.
• 핵심을 공략한다.

엘리베이터 피치 템플릿과 예시는 다음과 같다.

[고객이 필요로 하는 사항]을
[목표로 하는 고객]에게
[제품의 카테고리]인
[제품의 이름]은
[제품이 주는 혜택이나 구매해야만 하는 이유]이다.
[경쟁사 제품의 기능과 다르게]
우리 제품은 [우리 제품이 가지는 특별한 점]이다.

[건설 현장에서 어떤 작업이 이루어지는지 알아야] 하는
[현장 관리자]를 위해
[안전에 필요한 작업 허가증 발부 시스템(safety work permit system)]인
[CWSP]는,
[작업을 할 수 있도록 새로 허가증을 발부하거나, 이를 통해 작업의 진행사항을 추적, 감찰할 수 있]다.
[지금처럼 종이문서로 작업하는 것]과는 달리
우리 제품은 [웹에 기반을 두고 있어 언제 어디서든 사용이 가능하다].

제품 광고를 제작하게 되면 누가 왜 이 제품을 살지 스스로에게 묻는 과정에서 고객에게 끌릴만한 점이 무엇인지, 제품만이 가진 남다른 기능이 무엇인지 생각하게 해 줄 것이다.

창의적이지 않고 광고를 전공하지 않아도 괜찮다. 제품이 제공하는 혜택이 무엇인지 브레인스토밍하라. 이때, 어떤 기능이든 기능 자체보다는 이를 통해 고객이 얻을 혜택이 무엇인지를 설명하라.

프로젝트와 관련된 다양한 사람들을 만나 친분을 쌓는 것은 프로젝트 진행을 훨씬 수월하게 해준다. 뭔가 필요할 때만 얄밉게 도움을 청하는 사람이 아니라 평소에 친절하게 인사도 하고 안부를 물으며 지내야 한다. 그래야 신뢰를 쌓을 수 있을 테니 말이다.

저자는 첫 실수로 프로젝트에 관련된 사람들을 잘 파악하지 못했다. 이로 인해 프로젝트 막판에 일정에 영향을 미칠 정도로 다양한 곳에서 다양한 요구를 해왔다.

 

인덱션 덱의 나머지 반은 우리가 목표를 어떻게 이룰 것인지에 대해 이야기한다. (6~10번)

규모 정하기는 이 프로젝트가 얼마나 기간이 소요될 프로젝트인지 예측하는 것이다. 지금 정확히 몇 달 걸릴지 예측하기는 힘들지만, 추측이라 부정확하더라도 스폰서에게 언제쯤 소프트웨어가 출시될지 알려주어야 한다.

여기서는 작은 단위로 생각하는 것이 중요하다. '랜디 모트(Randy Mott)'는 어떤 프로젝트도 6개월보다 길어서는 안 된다고 주장한다. 6개월보다 긴 프로젝트는 너무 위험하다. 그렇다고 그가 주도했던 모든 프로젝트가 6개월 안에 출시할 수 있었던 것은 아니다. 단지 충분히 실패해 봤기 때문에 이제는 정말 큰 프로젝트를 출시하고자 할 때, 작고 다룰 수 있을만한 크기로 나눠야 한다는 것을 깨달은 것뿐이다.

규모를 정하는 것에는 추정치를 보고 개발에 걸릴 기간을 예상해서 알려주는 과정도 포함이다. 이때 사용자 인수 테스트, 교육 훈련 등의 모든 과정을 염두해야 한다. 하지만 이것은 현재 가능한 정보를 모두 이용해 추측한 가장 합리적인 프로젝트의 기간을 이해관계자에게 알려주는 것뿐이다. 대략적인 스케줄을 제시할 때는 정확한 출시 날짜를 약속하는 방법이나 핵심적인 기능을 고정하고 일정에는 융통성을 가지는 방법이 있다. 단, 어떤 상황에서도 이 계획이 반드시 지켜진다는 약속을 해서는 안 된다. 실제로 개발을 해보고 얼마나 걸릴지 측정을 하면서 계획을 수정해 나가야 한다.

우선순위 정하기에는 프로젝트에서 지켜야 하는 규정들을 조율하는 것을 말한다. 흔히 프로젝트를 위협하는 4개를 시간, 비용, 품질, 범위로 볼 수 있다. 시간은 애자일에서 소프트웨어를 출시하기 위해 하는 모든 활동에 타임 박싱(time boxing)을 정해둔다. 비용은 애자일에서는 시간과 마찬가지로 정해져있고 생각보다 대부분 충분하지 않아 시간과 마찬가지로 미리 정해놓는다. 품질은 기준을 미리 정해놓고 항상 최고로 유지해야 한다. 범위는 유동적이어야 한다. 계획된 것처럼 현실이 따라주지 않는다면 현실이 아니라 계획을 바꿔라.

트레이드오프 슬라이드는 고객과 함께 시간, 비용, 품질, 범위에 대해 논의하는 도구 중 하나다. 우선, 범위는 변할 수 있다는 점을 고객이 이해하도록 해야 한다. 시간, 비용, 품질, 범위 중 고객에게 뭐가 제일 중요한지 우선순위를 정하도록 해야 한다. 이때 모두 우선순위를 1번으로 혹은 동일하게 맞출 수 없다. 모두 다 중요한 항목이지만 우선순위만 정하는 것이다.

시간과 비용이 다가 아니다. 게임을 개발하더라도 재미가 없다면 무슨 소용인가? 그러니 시간, 비용, 품질, 범위 외에도 프로젝트 흥망성쇠에 영향을 미칠만한 요소들을 모두 나열해 우선순위를 정해보도록 하자.

 

사용자 스토리를 수집하는 법에 대해 살펴보자. 기존 문서 작성에는 문제점이 있다. 고객은 원하던 소프트웨어를 얻는 경우가 드물었고 개발팀은 필요로 하는 것을 개발하지 못했다. 개발하는 것보다는 문서에 무엇이 적혀 있나 따지느라 엄청난 양의 시간과 에너지가 낭비되곤 했다. 이처럼 소프트웨어를 개발할 때 두터운 서류뭉치에 의존하면 다음과 같은 문제가 생긴다.

• 변화를 받아들이지 못한다.
• 고객이 원하는 것이 아닌, 적혀있는 스펙에 따라 개발한다.
• 잘못된 추측과 가정이 난무한다.
• 많은 시간을 낭비한다.

무엇보다 문서에 적힌 요구사항은 실제 요구사항이 아닐 수 있다. 반드시 해야 하는 '요구사항'이 아닌 '하면 좋은 것들'일뿐이다.

 

애자일 사용자 스토리란 고객이 자신의 소프트웨어에 원하는 기능을 짧게 표현해 놓은 것이다. 사용자 스토리는 대부분 작은 인덱스카드에 적는데, 이는 모든 것을 다 받아 적지 말라는 것을 상기 시켜준다. 지금 그 기능에 대해 모든 것을 다 알아내려고 에너지를 소비하고 나중에 또다시 같은 일을 반복하는 일을 방지하기 위해 세부사항들은 나중을 위해 미뤄두라는 것이다.

 

좋은 사용자 스토리 요소를 살펴보자. 빌 웨이크(Bill Wake)의 INVEST를 살펴보자.

1. 고객에게 가치(Valuable)가 있어야 한다는 점이다. 고객이 비용을 지불해서라도 갖고 싶은 것이 가치 있는 것이라 볼 수 있다. 
   • 업무와 관련해 가치가 있어야 하기 때문에 고객이 쉽게 이해할 수 있도록 어려운 기술용어보다는 간단명료하게 작성해야 한다.
2. 필요한 모든 분야를 아우르는 정보를 포함해야 한다.
   • 생크림을 바르지 않은 케이크는 상품 가치가 없다. 비록 케이크 한 조각이지만 모든 레이어가 갖춰 있을 때 상품으로써의 가치가 있다.
3. 사용자 스토리는 독립적(Independent)이어야 한다.
   
   • 모든 스토리가 긴밀히 연결되어 의존도가 높으면, 스토리를 트레이드오프하며 계획을 변경하기 어려울 수 있다.
4. 협상 가능(Negotiable) 해야 한다.
   
   • 비용에 맞춰 변화를 줄 수 있는 여유를 허락해 주기 때문에 좋다.
5. 테스트 가능(Testable) 해야 한다.
   
   • 스토리가 잘 개발되어 제 기능을 하는지 확인하도록 모든 스토리는 테스트가 가능해야 한다. 이로써 이 스토리에 대한 개발이 끝났는지 알 수 있게 해준다.
6. 작고(Small) 추정가능(Estimatable) 해야 한다.
   
   • 스토리를 한 이터레이션 안에 완료할 수 있도록 해야 한다. 그렇게 되면 조금 더 자신 있게 추정치도 정할 수 있다.

 

이론적으로는 고객이 사용자 스토리를 작성하도록 해야 한다. 하지만 현실적으로는 여러분이 직접 스토리를 써야하는 경우가 훨씬 더 많을 것이다. 그러니 여러분이 너무 많이 고객을 돕고 있다고 생각이 들더라도 걱정할 필요는 없으며, 그저 고객이 스토리 수집하는 과정에 열심히 참여하도록 유도하면 된다.

 

사용자 스토리를 작성할 때 아래와 같은 것들은 너무 추상적이다. 이런 것들은 제약사항(constraints)라고 부른다. 이런 스토리들은 보통 일주일 안에 전달할 수 있는 것이 아니며, 고객이 바라는 소프트웨어의 성향을 설명해 놓은 것이다.

• 웹사이트는 반드시 엄청 빨라야 한다.
• 디자인은 보기 좋아야 한다.

가끔은 이런 스토리들을 테스트가 가능하도록 전환할 수 있기도 하다. 그래서 위의 제약사항들은 '모든 웹 페이지가 2초 내로 로딩되어야 한다.'와 같은 식으로 정확해져야 한다. 이래야 테스트도 쓸 수 있다.

제약사항은 중요하지만 이런 스토리가 사용자 스토리의 주류를 이뤄서는 안 된다.

 

애자일에서 처음 정한 추정치는 정말 대략적인 추측으로 이루어진다. 초기에 측정한 추정치는 확실한 추정치가 아니다. 하지만 애자일 방식으로 추정하는 방법을 배우면 선행 추정에서 기대할 수 없는 정밀함과 정확성을 얻으려는 노력은 그만두게 된다. 대신 정말 중요한 일, 여러분과 고객이 실천할 수 있고 믿을 수 있는 계획을 세우는 일에 집중하게 된다.

"소프트웨어 추정의 주된 목적은 프로젝트의 결과를 예측하는 것이 아니다. 프로젝트의 목표가 통제가 가능할 만큼 충분히 현실적인지 알아보기 위한 것이다."
- 스티브 멕코넬(Steve McConnell), <Software Estimation: Demystifying the Black Art>

대부분의 사람들은 추정치가 절대 제공할 수 없는 것을 추정치를 통해 알고 싶어 한다. '미래에 대한 정확한 예측'을 말이다. 이렇게 정확하지도 않고 대략적으로 정해진 추정치가 반드시 지켜야 하는 약속으로 바뀔 때, 대부분의 프로젝트에 문제가 생긴다.

스티브 맥코넬은 이렇게 제대로 기능하지 않는 행위를 불확실성의 원추(dysfunctional behavior)라고 부르는데, 프로젝트 인셉션 기간에 정한 첫 추정치가 많게는 400%까지 달라질 수 있다로 강조한다. 추정치는 단순히 주어진 시간과 자원으로 프로젝트가 가능할지 측정할 뿐이다. 다음의 기능을 제공하는 추정치가 필요하다.

• 미래 계획을 짤 수 있는 정보를 제공한다.
• 추정치는 추측일 뿐이라는 것을 상기시켜 준다.
• 소프트웨어 개발에는 본래 복잡성이 있다는 것을 인지하게 해준다.

애자일에서 처음 개괄적으로 정한 추정치가 믿을 만하지 못하다는 것은 사실이다. 하지만 비용이 얼마나 들고 기대하는 바가 무엇인지 정해져야 한다는 사실 또한 변함없다. 그렇게 하기 위해 다음과 같은 두 가지가 필요하다.

• 상대적 크기로 측정된 스토리
• 진행 상황을 추적하기 위한 점수 시스템

바위가 정확히 얼마나 더 큰지 말하기는 쉽지 않다. 하지만 상대적으로 큰지는 정확히 말할 수 있다. 이 원리가 애자일에서 추정치를 정하는 기초가 된다. 다른 스토리와 비교해 상대적 크기를 정하고, 우리 팀의 속도를 측정하면, 애자일 계획을 짜기 위한 요소가 모두 준비된 것이다.

상대적 추정치를 정할 때의 문제점은 우리가 추정치를 정할 때 고려하는 하루의 개념과 계획을 짤 때의 하루의 개념이 항상 같지는 않다는 것이다. 이런 모순을 피하고 스토리를 다시 추정하는 번거로움을 없애기 위해 애자일에서는 점수(point)에 기반해 측정한다.

점수 기반 시스템을 사용하면 추정치가 변하지 않고 달력에 나타난 시간에 목매지 않아도 된다. 상대적 크기를 정하기만 할 뿐이다. 그렇다면 추정치를 매우 신경 쓰는 것으로 보이지만, 결국 추정치도 그렇게 중요한 것이 아니게 된다. 스토리들을 비슷한 방법으로 추정하면 어떤 스토리는 좀 크게 추정될 수 있고, 또 다른 스토리는 실제보다 더 작게 추정되곤 하기 때문이다. 점수 기반 시스템은 다음과 같은 장점이 있다.

• 추정치가 추측일 뿐이라는 것을 상기시켜준다.
• 오직 크기만 정한다. 시간이 지난다고 바뀌지 않는다.
• 빠르고 쉽고 간단하다.

 

스토리에 적합한 크기를 정하기 위해 사용되는 기법 두 가지는 다음과 같다.

• 삼각측량(triangulation)
  • 비교 기준으로 삼을 스토리를 정할 때는 다음의 조건이 필요하다.
  • 작은 크기부터 큰 크기의 스토리가 골고루 포함 / 논리적인 그룹으로 분류 / 프로젝트 시작부터 끝까지 맥락을 이어가는 스토리(스토리를 구현함으로써 아키텍처를 확인할 수 있는) / 프로젝트 전반에 걸쳐 볼 수 있는 전형적인 스토리
  • 도저히 크기를 추정할 수 없다면 스파이크(spike)라는, 정해진 시간 동안 추정치를 정할 수 있을 만큼의 정보를 탐색하는 기간을 갖자.
• 플래닝 포커(planning poker)
  • 개발 팀원들 각각 스토리 추정치를 모두와 비교하는 것이다. 모두의 추정치가 비슷하면 유지하되 많이 다르면 논의를 통해 일치될 때까지 계속 추정하는 것이다. 팀원들간 값진 토론의 시간을 갖는다는 것이 가장 중요한 부분이다.
  • 투표 시스템이 아니며 누구나 자신의 의견을 피력할 수 있는 기회를 제공해 보다 나은 추정치를 얻기 위한 과정이다.

 

현실은 항상 계획대로 진행될 수 없다. 이런 현실에 대응하기 위해 다음과 같은 조건을 만족하는 계획을 세워야 한다.

• 고객에게 중요한 가치를 전달하는 계획
• 가시성 높고 투명하며 정직한 계획
• 현실적으로 실행 가능한 약속만을 하는 계획
• 필요하다면 계획을 조정하고 변경할 수 있는 유연함을 가진 계획

 

애자일 계획을 세운다는 것은 팀이 사용자 스토리를 얼마나 신속하게 잘 작동하면서도 출시 가능한 소프트웨어로 만들 수 있는지를 측정해 언제쯤 소프트웨어가 완성될지 추측하는 작업에 불과하다. 프로젝트 초기에 세운 계획이 반드시 따라야만 하는 계획으로 여기는 게 바로 대부분의 프로젝트가 시작도 하기 전에 실패하는 이유다.

개발이 시작되었다면 두 가지 중 하나의 경우가 생길 것이다. a) 예상보다 빠르게 진행되거나 b) 원래 계획보다 느리게 진행되거나 말이다.

예상보다 빠르다면 팀이 계획보다 일을 빠르게 처리한다는 뜻이고, 느린 경우라면 할 것은 많은데 시간이 부족하다는 뜻이다. 해야 할 일이 많은 애자일 팀은 작업량을 줄인다. 처음 계획을 그대로 실행하는 대신, 범위를 줄여 계획을 다시 세우도록 하자.

 

범위에 유연해야 한다. 애자일 프로젝트에서 본래 계획의 취지를 유지할 수 있는 이유는 범위에 유연하기 때문이다. 고객이 새로운 스토리를 추가할 때마다 오래된 스토리를 없애도록 하면서, 애자일 팀은 고객이 엄청난 비용을 지불하지 않고도 언제든지 마음을 바꿀 수 있는 기회를 제공한다. 이렇게 하면 고객은 쓸데없는 요구사항을 최소화해서 모든 요구사항을 한 번에 다 쏟아내야 한다는 생각에서 벗어난다. 사전에 완벽하게 얻으려 노력하기보다는 프로젝트를 진행하면서 배울 수 있도록 해준다.

사실 기술적으로 새로운 스토리를 추가했다고 반드시 이전의 스토리를 버려야 하는 건 아니다. 출시 날짜를 조금 연기할 수도 있으니 말이다. 하지만 고객이 기대해선 안 되는 게 있다. 새로운 스토리를 추가하고도 그만한 크기의 다른 스토리를 포기하지 않으려는 것이다. 그건 희망사항일 뿐, 애자일 계획에선 그런 방식이 먹히지 않는다.

보통 출시 날짜를 늦추기보다는 범위를 줄인다. 현실에서 출시 날짜를 끊임없이 연기하면서 제대로 작동하는 소프트웨어는 제때 출시하는 일은 잘하지 못한다.

 

릴리스는 함께 묶어 전달(deploy)했을 때 고객에게 가치가 있는 스토리들을 논리적으로 분류해 놓은 그룹이다. '출시할 만한 최소한의 기능을 모아놓은 세트(MMF, Minimal Marketable Feature set)'라고도 부른다.

Minimal은 신속하게 고객에게 가치를 전달하자는 걸 기억하기 위해 사용된다. 첫 릴리스에서는 고객에게 가장 많은 가치를 전달할 최소한의 기능만을 선별하자. Marketable은 출시한 기능들은 반드시 고객에게 가치가 있어야 한다는 걸 기억하기 위해 사용된다.

 

실제 출시할 때는 '날짜에 맞춰 출시하기'와 '기능 세트 별로 출시하기'의 두 가지 방법이 있다.

'날짜에 맞춰 출시하기' 방법은 데드라인을 반드시 정하는 것이다. 중요한 사용자 스토리가 나중에 새로 발견된다면 그만한 크기의 조금 덜 중요한 스토리를 범위에서 빼야 한다. 이는 범위와 관련해 어려운 선택과 트레이드오프를 해야한다. 그런 와중에도 개발은 계속 진행되어야 한다는 걸 모두가 알도록 해야 한다.

'기능 세트 별로 출시하기'방법의 경우 핵심 기능 세트가 출시되는 것이 출시일 변경보다 중요하다고 여긴다면 가능하다. 이 방법도 범위에 유연성을 갖도록 해야 한다. 새로운 기능은 언제나 발견될 수 있기 때문이다. 이 방법은 핵심 기능을 출시할 수 있으면 출시일과 관련한 리스크 비용을 알아볼 수 있다는 장점이 있다. 리스크를 얼마나 감내할 것인지는 고객과 스폰서가 결정해야 한다.

 

번다운 차트는 사용자 스토리를 완성하는 속도를 보여주는 그래프로써, 대략 언제쯤 프로젝트가 완성되는지 알려줄 수 있다. 남아있는 일의 양과 프로젝트에 무슨 일이 발생했음을 시각적으로 보여준다.

번업 차트는 앞뒤를 바꿔놓았을 뿐, 같은 차트다. 다만 새로 추가되는 스토리를 별도로 표현하기 쉬워 더 선호하는 사람들도 있다.

 

시작한 프로젝트를 애자일로 변화시키는 방법은 여러 가지가 있다. 먼저, 바꾸려는 이유는 다음과 같을 것이다.

• 지금 하고 있는 일이 잘 되지 않는다.
• 무엇이든 빨리 출시해야 된다.

그렇다면, 인셉션 덱을 작성하라.

뭔가 빨리 출시해야 한다면, 지금 갖고 있는 계획은 버리고 믿을 수 있는 계획을 새로 세우도록 하자. 애자일 계획과 마찬가지로 할 일 목록을 만들고 스토리의 크기와 우선순위를 정한다면 최소한의 기능을 빠른 시일 내에 출시할 수 있다. 프로젝트의 진척을 보여주어야 할 뿐 아니라 예정된 일정 내에 작업을 마쳐야 한다면, 매주 가치 있는 기능을 조금씩 전달하는 것부터 시작하자.

 

실제 실천을 하기 전에 시나리오별로 살펴보자.

고객이 새로운 요구사항을 찾았다고 해보자. 이런 대화를 나눌 때 감정적이 되지 않도록 조심해야 한다. 선택은 여러분이 아니라 고객이 하는 것이다. 여러분은 이 선택이 프로젝트에 어떤 영향을 미칠지에 대해 고객이 충분히 이해하도록 도와주고 선택을 내릴 때 필요한 정보를 제공해야 할 책임이 있다. 고객이 모든 기능을 다 원한다면 '있으면 좋은 기능(nice to have)' 리스트를 작성하라. 프로젝트 후반에 시간이 남는다면, 이 리스트에 있는 스토리들을 제일 먼저 개발하겠다고 하자. 이때 핵심 기능에 포함되지 않는다는 것을 반드시 고객에게 인지시켜 주어야 한다.

프로젝트가 예상보다 빠르게 진행되지 않는다고 해보자. 서너 번의 이터레이션이 지난 후 깨달을 것이다. 처음부터 고객에게 계획을 맹신하지 말라고 당부해 두었으니 괜찮다. 지금이라도 알게 된 것을 다행이라 생각하고 필요한 부분을 수정하자. 추가 인력을 물색하거나 날짜를 미루는 방법은 좋은 방법이 아닐 수 있다. 여기서 중요한 점은 고객과 대화해 그들에게 선택권을 제공한다는 점이다. 좋지 않을 소식일수록 되도록 투명하게 빨리 알려야 한다.

중요한 팀원을 프로젝트 중 잃었다고 해보자. 이는 프로젝트에 미치는 영향을 객관적으로 측정하기 쉽지 않다. 고객에게 프로젝트에 영향이 있을 것이라 말하고, 팀의 업무 속도에 끼친 영향을 재측정 후 말해주면 될 것이다.

시간이 다 되었다고 해보자. 교과서적인 답이지만 범위를 조정해야 한다. 하지만, 교과서적이지 않은 답을 하자면 고객과 마주앉아 혁신적인 방법으로 고객을 도울 방법을 모색하라. 이는 여러분과 고객이 오래도록 지속되는 관계를 형성하도록 해줄 것이다. 믿을 수 있는 조언자가 되기 위해서는 몇 가지 선택지를 주도록 하자. 단, 무작정 팀이 할 수 없는 것을 하겠다는 헛된 약속은 제발 하지 말도록 하자.

 

어떤 사용자 스토리든 제대로 작동하는 소프트웨어로 바꾸기 위해 거쳐야 할 세 단계가 있다.

1. 분석과 설계 (작업 준비)
2. 개발 (작업 실행)
3. 테스트 (작업 확인)

분석과 설계에서는 두 가지 주요한 개념이 있다. 적당한(Just Enough)과 적시(Just in Time, JIT)이다. 적당한 분석이란 작업을 하기 위해 필요한 정보를 불필요하게 너무 많지도, 부족하지도 않게 준비하는 것이다. 필요할 때만 살을 붙여라. 얼마나 상세해야 할 것이냐에 대한 답이 하나만 있는 게 아니며, 여러분의 팀과 그 프로젝트에 적합한 종류의 분석을 말하는 것이다.

적시 분석은 그 작업이 필요할 때(보통 이터레이션 전)가 왔을 때 깊이 있게 하라는 것이다. 한 달 뒤 상황은 어떻게 변할지 모르기 때문에 너무 앞서나가 모든 것을 준비하려고 해봐야 심각한 낭비로 끝난다. 적시 분석은 다음과 같은 장점이 있다.

• 가장 최신의, 가장 좋은 정보로 분석할 수 있다.
• 여러분과 고객 모두 개발하면서 배우고 혁신할 기회를 갖는다.
• 재작업을 많이 할 필요가 없다.

하는 일이 너무 복잡하고 많은 시간을 필요로 한다면, 지금 시작하라. 작업을 준비해 놓기 위해 필요한 것은 다 하도록 하자. 그저 너무 앞서가지 말아라.

스토리 분석 기준에는 훌륭한 순서도와 페르소나와 같은 것들이 도움이 된다. 디자인까지 정해졌다면 고객과 마주 앉아 테스트 기준을 정해야 한다. 스토리가 성공적으로 완성되려면 무엇을 만족해야 하는지 분명히 이해해야 한다. 자세한 답을 원한다면 그런대로, 대략적인 정보를 원한다면 또 그런대로 대답을 얻어내면 된다.

분석을 어떻게 하는지 학교에서 배운 사람은 없다. 창의적이면 된다. 정답이 하나만 있는 것은 아니니까.

 

애자일 프로젝트에서 개발 단계에서는 다음과 같은 사항이 이루어져야 한다.

• 자동화 테스트를 써야 한다.
• 설계를 지속적으로 발전시키고 개선시켜야 한다.
• 제대로 작동하는 소프트웨어를 생산하기 위해 코드를 지속적으로 통합시켜야 한다.
• 고객이 시스템에 관해 이야기할 때 사용하는 언어가 코드에서 사용되는 언어와 매치되어야 한다.

흔히 '이터레이션 0'은 첫 이터레이션으로, 개발을 시작하기 전에 작업환경을 세팅하는 기간이다. 버전 관리 도구, 자동화 빌드 도구, 개발 환경과 테스트 환경, 아키텍처와 같은 것들을 결정하게 된다.

 

애자일 프로젝트에서 테스트 단계에서는 고객에게 작업의 내용을 피드백받는 과정이다. 개발 중 테스트 과정이 많아도 인수 테스트를 해야 한다. 한 번에 높은 품질을 갖는 팀은 거의 없다. 그러니 최고의 코드를 완성했다는 것을 자신과 스폰서에게 증명해 더이상 인수 테스트가 필요 없다고 느껴질 때까지 이를 계속 노력하라.

 

간반(Kanban)은 도요타사가 개발한 카드 기반의 신호 시스템이다. 이 시스템은 애자일의 또 다른 종류라 불리며, 몇 가지를 제외하고는 애자일에서의 스토리보드와 매우 흡사하다. 다른 점은 작업이 WIP(작업 중)이라는 개념에 제약을 둔다는 것이다. 한 팀은 오직 정해진 수만큼의 작업만 동시 수행이 가능하다. 또 하나의 다른 점은 이터레이션이 필요하지 않다는 것이다. 여력이 생길 때마다 리스트에서 다음으로 가장 중요한 것을 선택해 작업하면 된다.

간반의 목적은 '흐름'이다. 정해진 만큼의 일만큼만 해나가면서 간반 보드에 오른 작업을 끊임없이 빠르게 흐르도록 하는 것이다. 간반의 장점은 다음과 같다.

• 이터레이션에 의한 스트레스를 받을 필요가 없다.
  • 이터레이션 중 방해를 받는 일에 스트레스를 받지 않아도 된다.
• 하나의 이터레이션 기간 동안 할 수 있는 과제만 선택하지 않아도 된다.
  • 최대한 작은 과제로 나누어 해결하는 것이 좋긴 하지만, 종종 너무 큰 작업은 몇 주 걸리는 일이 있을 수 있다.
• 간반은 기대치를 관리하기 좋은 방법이다.
  • 간반에서도 대부분의 팀들이 여전히 추정치를 측정하거나 최소한 간반 보드에 있는 과제들에 대해 대략적인 크기를 정한다.

 

애자일 이터레이션은 오늘날과 같이 연간 예산이 미리 정해지는 산업 환경에서 시간과 비용의 제약이 따르는 프로젝트를 할 때 여전히 좋은 해결책으로 매우 강력한 힘을 가지고 있다. 하지만 애자일은 단순히 이터레이션의 집합만은 아니다. 애자일화 된다는 것은 내게 맞는 것을 찾아야 한다는 뜻이다. 이터레이션 없이 일하는 것이 더 낫다면 굳이 고집할 필요가 없다.

 

애자일 방식은 한 팀을 같은 공간에서 일하게 하고 정기적으로 고객에게 제대로 작동하는 소프트웨어를 전달하라는 것 이외에는 딱히 이터레이션을 어떻게 구성해야 하는지에 관한 지침이 없다. 작업을 어떻게 체계화할지, 팀원간에 커뮤니케이션은 어떻게 해야 하는지, 피드백은 어떻게 받아 목표를 성취할 것인지 등 전적으로 여러분과 팀원들에게 달려있다.

애자일 프로젝트에서는 반드시 해야 하는 두 가지가 있는데, '기대치 세우기'와 '피드백받기'이다. 비슷한 맥락에서 각 이터레이션을 운영하기 위해 규칙적이고 의식적으로 해야 할 네 가지 활동이 있다.

1. 다음 이터레이션에 할 작업 준비하기(스토리 계획 회의, SPM)
   • JIT 방식으로 다음 이터레이션을 위한 준비를 검토하는 회의다.
   • 고객과 다음 이터레이션의 스토리들의 테스트 기준을 재확인하고, 개발자와 추정치가 적정한지 검토하는 등 개발 준비가 되었는지 확인하는 자리다.
2. 지난 이터레이션에서 작업했던 스토리에 대한 피드백받기(쇼케이스)
   • 지난 이터레이션 동안 개발한 스토리들을 데모하는 자리다.
   • 그저 사진이나 아이디어를 보여주는 게 아니라 필요하다면 당장 오늘에라도 배치해 실전에 내보낼 수 있는 코드를 사용해야 한다.
3. 다음 이터레이션에서 스토리들을 어떻게 작업할지 계획 세우기(이터레이션 계획 회의, IPM)
   • 고객과 함께 다음 이터레이션에서 무엇을 할지 계획을 세우는 자리다.
   • 팀의 속도를 재검토하고 어떤 스토리가 준비되어 있는지 확인한 후 다음 이터레이션 동안 얼마만큼의 스토리를 개발할 수 있다고 약속할 수 있는지 알아본다.
   • 출시일은 번다운 차트를 활용해 얼마나 현실적인지 말하는 방법이 있다.
4. 향상될 부분이 있는지 지속적으로 찾아보기(미니 회고, mini retrospective)
   • 프로젝트가 끝날 즈음이나 주요 릴리스의 마지막에 큰 행사로도 할 수 있으나, 여기서 말하는 것은 그런 회고가 아니다.
   • 10~15분 정도의 짧은 시간 동안 정기적으로 팀이 잘하고 있는 것과 그렇지 못한 것에 대해 이야기하는 것이다.
   • 좋은 회고를 진행하기 위한 규칙으로, 팀원들은 어떤 이야기를 해도 안전하다는 느낌이 들어야 한다. 회고는 마녀사냥이 아니다.

하루 시작을 빠른 현황 파악으로 진행하기 위해서는 '일일 스탠드업' 회의도 방법이 있다. 이때 영감을 주거나 행동에 변화를 일으킬 만한 정보도 같이 주도록 아래와 같이 역동적인 질문을 하도록 해보자.

• 세상을 바꾸기 위해 어제 무엇을 했는가
• 오늘 그 작업을 어떻게 끝낼 것인가
• 불행히도 지금 내 앞을 가로막고 있는 이 장애물을 어떻게 없앨 것인가

 

만약 IPM 중 스토리 하나가 반 밖에 완성되지 않았다면 팀 작업 속도에 절반을 반영해야 할까? 정답은 안 된다. 바퀴가 하나만 달린 마차가 달릴 수는 없다. 다음 이터레이션에서 완성된다면 그때 반영해야 한다.

 

시각적인 작업 환경을 조성하라. 시간이나 비용과 같은 것에 제한이 생기게 된다면 임원들을 당장 작업 공간에 모셔라. 형식적인 회의와 파워포인트로 설득하는 대신 프로젝트의 상황을 직접 보여주도록 하자. 벽에 붙어있는 인셉션 덱부터 시작해, 릴리스 상황판(release wall)으로 옮겨간 뒤, 자세한 내용으로는 이터레이션 스토리보드(storyboard)로 옮겨가 설명하자. 마지막으로 번다운 차트를 보여 팀 속도와 프로젝트에 발생 가능한 문제를 설명하라.

 

공통된 도메인 언어를 만들어 팀원들과 공유하자. 소프트웨어를 개발할 때 사용하는 언어들이 비즈니스를 하는 사람들의 언어와 맞지 않다면 여러 문제점이 생길 수 있다.

 

출시하기 직전에 버그가 너무 많다고 놀라지 않으려면, 프로젝트 첫날부터 버그를 관리해야 한다. 매 이터레이션마다 10퍼센트의 시간은 버그를 고치고 기술적 부채를 해결하도록 하자.

 

소프트웨어에서 버그를 발견했다면 바로 고치고 싶을 것이다. 하지만 그러지 말고 실패하는 단위 테스트를 먼저 써야 한다. 이 방법은 다음과 같은 점들을 보장해준다.

• 버그의 본질을 이해했다는 것을 증명한다.
• 버그를 고쳤다고 확신할 수 있다.
• 같은 버그가 소프트웨어에 재발하지 않을 거라고 확신할 수 있다.

단위 테스트는 코드가 어떻게 작동할지 조금이라도 미심쩍거나, 결과가 기대하는 대로 나오는지 확인하고 싶을 때마다 쓰도록 하자. 자동화되어 실행되기 쉬운 단위 테스트의 가치는 헤아릴 수 없다.

만약 쉽게 테스트를 할 수 없는 상황에 부딪혔다면, 어쩌면 설계에 문제가 있을지도 모른다. 그게 아니라면 정말 테스트하기 힘든 레거시 코드를 상속받았을 것이다. 그런 경우라면, 어쩔 수 없다. 그저 모든 것을 다 테스트할 수 없다는 사실을 그대로 받아들이자. 하지만 반드시 꼼꼼히 수동 테스트와 탐색적 테스트로 보완한 뒤 넘어가야 한다.

 

리팩터링은 기술적 부채(technical debt)를 갚는 것이다. 기술적 부채란 임기응변, 난도질, 복사 붙여넣기 같이 우리가 생산성과 일정이라는 미명 아래 코드 베이스에 저질러 놓은 죄악들이 오랫동안 누적된 결과다.

리팩터링은 겉으로 보이는 결과에 변화를 주지 않으면서 조금씩 점진적으로 설계를 향상하는 실천법이다. 코드를 리팩터링 할 때는 새로운 기능을 추가하거나 버그를 고치지 않는다. 단지 코드를 더 잘 파악하고 변화를 받아들일 수 있도록 만들어, 코드의 이해력 향상에 주력한다.

코드를 작성하는 것은 마치 훌륭한 산문을 작성하는 것과 비슷하다. 분명하고 쉽게 이해할 수 있으면서도 의도하는 바가 무엇인지 파악하는 데 많은 노력이 필요해서는 안 된다. 리팩터링은 객체 지향 프로그래머들이 그런 목적 달성을 위해 사용하는 비밀병기다. 잘 지어진 메서드와 변수를 선택해 코드를 읽는 사람에게 불필요한 상세 사항은 숨기면서 이해하기 쉽고 변경하기 용이하게 만들기 때문이다.

적극적으로 리팩터링 했다면, 프로젝트 막바지에 개발속도가 느려지지 않고 오히려 빨라질 것이다. 좋은 설계를 유지했기 때문에 어려운 작업들은 이미 다 해결되었으니 말이다. 적극적인 리팩터링이란 이터레이션이 끝나기 전에 한 에 몰아서 하는 것이 아니라 매일매일 지속적으로 하는 것을 말한다. 리팩터링을 제대로 하고 있다면 눈에 잘 띄지 않을 것이다. 리팩터링 단계는 매우 작고 개선되는 부분 또한 미세하기 때문에 리팩터링 하는 작업과 새 기능을 추가하는 작업 사이의 차이를 거의 구별할 수 없다.

리팩터링을 크게 해야 할 때 애매한 상황이라면 이를 진행할지 결정하기 위해 두 가지 질문을 해보라.

• 프로젝트가 거의 끝났는가?
• 이 리팩터링을 점차적으로 늘려가면서 진행할 수 있는가?

거의 끝나가는 프로젝트에서 큰 리팩터링은 별 의미가 없다. 그러니 이런 경우라면 리팩터링을 하지 않는 것도 좋은 생각이다. 점차적으로 리팩터링 하는 작업은 고객의 동의를 얻기 쉽다. 리팩터링을 하는 동안 고객은 소프트웨어에 계속 새로운 기능이 추가되는 것을 볼 수 있으니까.

 

테스트 주도 개발은 매우 짧은 개발 주기를 사용해 소프트웨어의 설계를 점진적으로 향상하는 소프트웨어 개발 기법이다. 언제 그만해야 하는지에 대한 질문에, 에릭은 코드가 사용자 스토리의 요구사항을 모두 만족시킨다는 확신이 들 때까지 반복하라고 한다.

개발자는 코딩할 때 복잡성(complexity)에 자주 부딪친다. TDD는 코딩하면서 부딪히는 복잡성에 잘 대응할 수 있게 해준다.

 

지속적인 통합이란 개발자가 지속적으로 소프트웨어를 변경하고 변경사항들을 계속해서 통합하는 활동을 말한다.

지속적인 통합을 할 때는 여러 문제(설정, 실수, 버그, 팀원간 의사소통, 배포환경 차이, 오래된 문서)가 있을 수 있다. 이런 문제들을 제거하거나 최소한 관리하게 해준다. 언제든 출시할 수 있는 개발 문화를 만들어서 언제 어디에서 누구에게든 제품을 데모할 수 있도록 말이다.

지속적인 통합 구축을 위해서는 다음의 사항이 필요하다.

• 소스코드 저장소
• 체크인 프로세스
• 자동화된 빌드
• 작은 단위로 일하려는 마음가짐

자동화된 빌드는 지속적인 통합을 지탱하는 뼈대와 같다. 잘 자동화된 빌드는 컴파일, 테스트를 진행하며 빌드 프로세스에서 정기적으로 필요한 기본적인 사항들을 처리한다. 개발자들은 자동화된 빌드를 TDD 생명주기의 한 과정으로 여겨 사용한다. 빌드 에이전트는 소스 저장소에 변화가 있다는 것을 감지할 때마다 자동화된 빌드를 실행한다.

빌드의 핵심은 자동화다. 게다가 모든 팀원이 하루에도 몇 번씩 항상 실행해야 하기 때문에 빨라야(보통 10분 미만) 한다.

현대 언어의 대부분은 자동화된 빌드 프레임워크를 갖는다. 만약 사용하는 언어에서 제공되는 게 없다면 DOS bat 파일이나 Unix scripts를 이용해야 할 것이다.

하지만 아무리 좋은 체크인 프로세스와 자동화 빌드가 있다고 하더라도 정말 중요한 것은 작은 단위로 작업하려는 마음가짐이다. TDD 테스트처럼 코드 통합도 작은 단위로 하는 것이 훨씬 쉽다.

 

 

실천법이 수행되지 않는다면 애자일 프로젝트는 잘 운영되지 않을 뿐 아니라 코딩하고 수정하는 과정만 반복하는 옛날 운영 방식으로 금세 되돌아가게 될 것이다.

 

마지막으로 애자일을 시도할만한 힘이 없다면, 그건 본인의 선택이다. 높은 품질의 소프트웨어를 생산하려는 것도, 진행상황을 고객에게 정직하게 말하려는 것도, 막을 사람은 없다. 물론, 쉽게 일하는 방법은 아니다. 하지만, 결국은 여러분의 선택에 달렸다. 누구를 설득하려고 하지 말자.

 

애자일화 되었는지 걱정하지 마라. 본인들이 애자일로 잘하고 있는지 궁금할 수 있으나, 누구도 애자일로 일하고 있는 것에 대한 체크리스트를 만들어 줄 수 없다. 애자일은 목적이 아니라 과정이기 때문이다.

'애자일화 되는 것'이 목적이 아니라 '훌륭한 제품을 개발해 고객에게 최상의 서비스를 제공하는 것'이 목표라는 것을 꼭 기억하자.

그러니 너무 실천법에 목매는 것도 하지 않아야 한다. 실천법도 결국 과정이다.

그래도 궁금하다면 다음 두 질문을 스스로에게 해보자.

• 우리는 매주 가치 있는 것을 고객에게 인도하는가?
• 우리는 계속 발전하기 위해 노력하고 있는가?