•
2001년 2월, 17명의 소프트웨어 전문가들이 개탄스러운 소프트웨어 개발 현실을 논의하기 위해 유타주 스노버드에 모였다.
◦
당시에는 소프트웨어를 폭포수나 래셔널 통합 프로세스같은 프로세스를 이용해서 개발했는데, 이런 프로세스는 비효율적이고 복잡한 데다 매우 형식적이었다.
◦
그래서 자리에 모인 17명의 전문가들은 더 효율적이고 가벼운 접근 방법을 소개하는 선언문을 작성하고자 했다.
◦
그렇게 탄생한 것이 애자일 선언으로 이는 지금까지도 소프트웨어 분야에서 가장 강력하고 오래 이어져온 운동이 되었다.
•
불행하게도 어떤 운동이 인기를 얻으면 오해나 잘못된 사용 때문에 운동의 이름이 퇴색하기 마련으로 실제 운동과는 아무런 관계가 없는 제품이나 방법론이 이름을 가져다 붙이기 마련이다.
•
여기서는 애자일의 근본적인 내용을 다룬다. 많은 사람이 이 근본적인 아이디어를 더 꾸미고 확장시키는데, 이렇게 꾸미고 확장된 것은 애자일이 아니다.
•
이 책에서는 애자일은 무엇이고, 무엇이었고 앞으로도 영원히 무엇일지를 다룬다.
애자일의 역사
•
애자일은 언제 탄생했을까? 아마 5만여 년 전, 인류가 처음으로 공동의 목표를 위해 힘을 모으기로 한 때였을 것이다.
◦
중간 단계의 작은 목표를 고르고 그 진행 상황을 측정한다는 아이디어는 너무나 직관적이다.
•
현대 산업에서는 언제부터 애자일이 쓰였을까?
◦
저자의 생각으로는 최초의 증기기관, 최초의 제분기, 최초의 내연기관 등이 모두 오늘날 애자일이라고 부르는 방법으로 만들어졌을 것이라고 추측한다.
◦
측정 가능한 작은 단계들을 밟는다는 것은 너무나도 자연스럽고 인간적이어서 다른 방법으로 만들었으리라 생각이 들지 않기 때문이다.
•
소프트웨어에서 애자일은 언제 시작되었을까?
•
애자일이라고 부를 만한 행동들을 쉽게 찾아볼 수 있었으나 그때 당시에는 제조업과 산업 전반에서 상당한 성공을 거둔 과학적 관리법이라는 것이 유행이었다.
◦
이는 하향식, 지휘 및 통제 접근법으로 관리자는 과학적 기법을 써서 목표를 달성하는 최고의 방법을 알아낸 후, 그 계획을 토씨 하나 틀리지 말고 따르라고 하급자한테 시킨다.
•
다시 말해 이는 계획을 세우는 데, 먼저 많은 노력을 기울인 다음 그 계획을 주의 깊고 세세하게 실천하는 것이다.
•
1970년, 소프트웨어 세계가 이 두 가지 기법의 갈림길 앞에 서있었다.
◦
과학적 관리법은 변경 비용이 많이 드는 프로젝트에서 제일 잘 작동했다. 즉, 목표가 극도로 명확한 매우 상세하게 정의된 문제를 잘 풀었다.
◦
선-애자일은 변경 비용이 작은 프로젝트에서 잘 동작했고 목표가 명확하게 세워지지 않은 불완전하게 정의된 문제를 잘 풀었다.
•
이 갈림길에서 던져야 했던 질문은 소프트웨어 프로젝트라는 것이 어떤 종류의 프로젝트인가 하는 것이었다.
◦
변경 비용이 많이 들고 명확한 목표로 상세하게 정의된 것인가? 아니면 변경 비용이 적게 들고 불명확한 목표로 불완전하게 정의된 것인가
•
1970년, 윈스턴 로이스의 논문에서 폭포수 개발의 모델이 된 프로세스 형태가 제안되었다.
◦
이는 과학적 관리법의 이론적인 후예로, 철저한 분석을 하고 상세한 계획을 세우고 계획을 실행하여 완성하는 것에 관한 이야기다.
•
시간이 흐르면서 이론적으로 완벽해보였던 폭포수 방법론은 결과적으로 성공적이지 못했고 소프트웨어 학계의 성장에 따라 점차 새로운 경량 프로세스에 대한 논의가 필요해지던 순간이었다.
스노버드
•
17명의 참가자는 서로 다른 몇 가지 관점을 대표했는데, 먼저 다섯 가지 경량 프로세스가 있었다.
•
XP, 스크럼, 기능 주도 개발, 동적 시스템 개발 방법, 크리스털 계열 프로세스(앨리스터 코오번)이 있었다.
•
회의는 이슈들을 카드에 쓰고 카드를 분류하여 관련된 것끼리 모아 바닥에 늘어놓는 식으로 진행되었다.
•
그런 회의에서 완성된 네 문장은 다음과 같다.
◦
공정과 도구보다 개인과 상호작용
◦
포괄적인 문서보다 작동하는 소프트웨어
◦
계약 협상보다 고객과의 협력
◦
계획을 따르기보다 변화에 대응하기
•
프로세스에 관한 이름 중, 애자일, 적응, 경량 등 다양한 이름들이 거론되었으나 최선은 없었고 애자일로 결정되었다.
애자일 개요
•
소프트웨어 프로젝트를 어떻게 관리해야 할까?
•
수년간 많은 접근 방법이 시도되었지만 결과는 대부분 상당히 좋지 않았다.
철십자
•
그런 기법들이 처절하게 실패하는 이유는 그 기법을 사용하는 관리자가 소프트웨어 프로젝트의 근본적인 물리 법칙을 이해하지 못하기 때문이다.
•
이 물리 법칙은 모든 프로젝트는 일종의 상충 관계를 벗어날 수 없다는 것인데, 이 상충 관계를 프로젝트 관리의 철십자라고 한다.
◦
좋음, 빠름, 저렴함, 완성 이 중 셋만 고를 수 있다. 모두를 고를 수는 없다. 어느 하나는 포기해야하는 것이다.
•
좋은 프로젝트 관리자라면 이 네 가지 속성에 가중치를 둘 수 있다는 것을 이해하고 있다. 좋은 관리자는 프로젝트를 필요한 만큼 좋고, 빠르고, 저렴하고, 완성도 있게 진행한다.
•
좋은 관리자는 네 속성의 가중치를 관리하지 모든 속성이 100%가 되기를 원하지 않는다. 애자일은 이런 관리를 추구한다.
•
애자일은 개발자와 관리자가 프로젝트를 실용적으로 관리할 수 있도록 돕는 체계다. 무조건 좋다는 의미는 아니다. 애자일하더라도 실패할 수 있다.
벽에 걸린 차트
•
애자일은 어떻게 관리를 돕는 것일까? 애자일은 데이터를 제공한다. 애자일 개발팀은 관리자가 좋은 결정을 내리도록 필요한 데이터를 생산한다.
•
주간 스토리 포인트 양 차트를 예로 든다. 이는 생산량을 의미하는 것 같은데, 측정 단위가 포인트였다. 이는 이 팀이 어느 속도로 움직이고 있는지 누구나 알 수 있는 데이터를 제공한다.
•
그리고 남은 스토리 포인트의 차트를 하나 더 예로 드는데, 이는 마일스톤을 어느 시점에 달성할 수 있게 되는지 알 수 있게 한다.
◦
만약 중간에 남은 스토리 포인트의 값이 예상대로 감소하지 않고 튄다면 요구사항의 변경이 발생했기 때문일 것이다.
•
이 두 차트를 벽에 거는 것이 애자일의 중요한 목표다. 관리자가 철십자의 네 가지 축의 가중치를 얼마로 할지 결정해야 할 때, 결정에 필요한 데이터를 제공함으로써 관리자가 프로젝트를 최선의 결과로 이끌도록 한다.
•
즉, 관리자에게 제공해야 하는 데이터는 팀이 어느 속도로 움직이고 있는지, 팀이 목표를 달성하기까지 얼마나 남았는지다. 그렇다면 이 데이터들은 왜 중요한 것일까?
가장 먼저 알게 되는 것
•
마감 기한은 변하지 않고 요구 사항은 계속 바뀐다는 점이다. 이런 상황에서 개발팀은 어떻게든 프로젝트를 성공적인 결과로 이끌어야 한다.
•
폭포수 개발 방법에 따르면 분석, 설계에 비해 구현은 결과물이 명확하다. 따라서 분석, 설계는 계획에 명시된 기간이 끝나면 끝난거고 구현은 이해관계자와 고객의 요구사항을 만족시키는 제품이어야 한다.
•
구현을 하는 과정에서 설계에 문제가 있음을 깨닫거나 요구사항이 변경되면서 기존 설계에 변경사항이 발생한다. 그리고 이 변경사항은 또 다른 변경사항을 낳는다.
•
이를 저자는 따라잡을 수 없는 프로세스 인플레이션이라고 부른다.
더 나은 방법
•
폭포수 모델의 발상은 꽤 타당하다. 먼저 문제를 분석하고 해결 방법을 설계하고, 그 설계를 구현한다.
◦
단순하고 직접적이며 명확하다. 그러나 틀렸다.
•
애자일 프로젝트의 접근법은 방금까지 읽은 것과는 완전히 다르다. 딱 와닿는 느낌을 준다.
•
애자일도 분석으로 시작한다. 대신 프로젝트 일정을 일정한 크기로 더 작게 나눈다. 이를 반복 주기 또는 스프린트라고 부른다.
◦
길이는 보통 1주일 혹은 2주일인데, 저자는 1주일을 더 선호한다. 2주일은 감당하기에 너무 많은 변경사항이 발생할 수 있기 때문이다.
반복 주기 0
•
첫 번째 반복 주기는 종종 반복 주기 0이라고도 한다. 반복 주기 0에서는 짧게 기능 목록을 만드는데, 이를 스토리라고 부른다.
◦
뒤에서 더 자세하게 다루며 지금은 개발해야 하는 기능이라고 생각하자.
•
반복 주기 0 동안 개발 환경을 준비하고 스토리의 크기를 추산하고 최초의 계획을 세운다.
•
이때 계획은 단순하게 세운다. 처음 반복 주기 몇 번 동안 처리할 스토리를 대략 할당한다. 마지막으로 개발자와 아키텍트는 잠정적인 스토리 목록을 바탕으로 초기 시스템 설계의 잠정적인 밑그림을 그린다.
•
스티로를 쓰고, 그 크기를 추산하고, 계획을 세우고 설계를 하는 이 과정은 끝없이 계속된다. 그래서 애자일의 프로젝트 표를 보면 탐색이라는 영역이 전체 프로젝트를 관통하며 걸쳐있다.
◦
즉, 맨 처음부터 끝까지 프로젝트의 모든 반복 주기에 분석과 설계, 구현이 각각 조금씩은 들어 있는 것이다.
•
이 설명을 듣고 애자일이 짧은 폭포수를 반복하는 것이라고 받아들이는 사람도 있을 것이다. 하지만 그렇지 않다.
◦
반복 주기는 3단계로 나누어지지 않기 때문이다. 꼭 반복 주기의 앞부분에만 분석을 하는 것도 아니다. 반복 주기가 끝날때쯤 구현을 하는 것도 아니다.
◦
반복 주기 전체에 걸쳐 요구 사항 분석, 아키텍처 수립, 설계, 구현 활동이 끊임없이 일어난다.
•
애자일 프로젝트에서 반복 주기는 가장 작은 단위가 아니다. 애자일에는 여러 계층이 있고, 분석, 설계, 구현은 각각의 계층에서 일어난다.
애자일은 데이터를 만든다
•
반복 주기 1의 시작, 가장 먼저 스토리를 몇 개나 완료할 수 있을지 추산해 본다. 그리고 반복 주기 동안 팀은 이 스토리들은 완료하는데 필요한 일을 한다.
•
물론 끝내기로 계획한 스토리를 모두 끝낼순 없다. 실제로 그 문제에 뛰어들어 해결하기 전까지 정확한 작업기간을 추산할 수 없기 때문이다.
•
반복 주기가 끝나면 우리가 얼마나 스토리를 쳐낼 수 있는지 알게 된다. 이것이 앞서 말한 포인트 지표다.
•
이 데이터에 기반하여 원래의 계획을 조정하고 프로젝트의 새로운 종료 일자를 계산할 수 있다. 물론 계산 결과는 매우 실망스러울 가능성이 높다.
•
오차 범위를 줄이려면 반복 주기를 몇 번 더 해보고 결과를 산정하는 것이 정확하다.
•
이 과정을 통해 기존의 마감기한에 맞춰 프로젝트를 끝낸다는 것이 헛된 희망임이 확실해져 간다.
희망 대신 관리
•
희망을 없애는 것이 애자일의 주요 목표다. 애자일을 실천하면 희망이 프로젝트를 죽이기 전에 희망을 파괴할 수 있다.
•
애자일이 빠르게 나아가는 것이라고 생각하는 사람이 있다. 그렇지 않다. 빠르게 나아가는 것이었던 적은 없다. 애자일은 우리가 얼마나 망했는지를 최대한 빨리 아는 것이다.
•
최대한 빨리 알아야 상황을 관리할 수 있기 때문이다.
철십자 관리하기
•
이제 관리해야할 때다. 프로젝트 관리의 철십자로 돌아가 좋음, 빠름, 저렴함, 완성들을 관리자가 프로젝트에서 얻은 데이터에 기반하여 결정을 내릴 시간이다.
•
이 프로젝트는 얼마나 좋고, 빠르고, 저렴하고, 완성되어야 할까?
•
일정 변경하기
◦
프로젝트 관리자에게 프로젝트를 연기하자고 해보자. 이런 대화는 보통 끝이 좋지 않다.
◦
마감 기한은 타당한 사업성의 이유로 결정된 것으로 잘 변경되지 않는 사항들이다.
•
사람 추가하기
◦
일정을 늘리지 못했다면 사람을 추가해보자. 사람을 두 배 늘리면 일도 두 배 이상 빠르게 할 수 있지 않을까?
◦
사실은 그 반대다. 브룩스의 법칙에 따르면 지연된 프로젝트에 인력을 추가하면 더 늦어진다.
◦
새로운 사람이 기존 사람들의 생산성을 빨아먹기 때문에 몇 주 간의 생산성은 곤두박질친다. 그러다 잘 풀리면 점점 도움이 되기 시작한다.
◦
이것도 불가하다면 다음으로 넘어가 품질에 대한 이야기를 해보자.
•
품질 떨어뜨리기
◦
테스트도 하지 않고, 리뷰도 하지 않는다. 이런 상황에서 코드 리팩토링은 사치품이다.
◦
하지만 이는 소용없는 행동이다. 쓰레기를 만든다고 더 빨리 갈 수는 없다. 더 느려질 뿐이다.
◦
빠르게 가는 유일한 방법은 제대로 가는 것이다.
•
범위 변경하기
◦
이제 바꿀 수 있는 것은 단 하나 남았다. 기능에 우선순위를 두어 몇몇 기능을 제거하는 것이다.
◦
합리적인 조직이라면 이 제안을 받아들일 것이다. 그리고 계획을 면밀히 살펴 급하지 않은 기능을 찾는다.
◦
이렇게 계획이 조정되고 몇 가지 기능은 연기된다.
비즈니스 가치 순서
•
우리는 비즈니스 가치의 순서를 잘 모른다. 따라서 이해관계자들에게 물어 도메인을 이해해야 한다.
•
그리고 기능을 순차적으로 개발해나가야 한다. 그렇지 않으면 중요하지 않은 기능부터 만들고 있을 가능성이 높다.
개요가 끝났다.
•
애자일의 핵심을 가볍게 살펴봤다.
•
애자일은 프로젝트를 더 작은 반복 주기로 나누는 프로세스다.
•
각 반복 주기의 결과물을 측정하여 지속적으로 일정을 평가하는 데 사용한다.
•
기능은 비즈니스 가치 순서대로 구현하므로 가장 중요한 것이 먼저 구현된다. 품질은 가능한 한 노게 유지한다. 일정은 주로 기능의 범위를 조절하여 관리한다.
•
이것이 애자일이다.
삶의 순환
•
이는 XP의 실천 방법을 설명하는 론 제프리즈의 그림으로, 삶의 순환이라는 애칭으로 불리곤 한다.
•
이 책에서 XP의 실천 방법을 소개하는 이유는 모든 애자일 프로세스 중에 XP가 가장 잘 정의되어 있고 가장 완전하며 가장 덜 혼란스럽기 때문이다.
◦
사실상 다른 애자일 프로세스들은 XP의 부분 집합이거나 XP의 변종이다. 이 말은 다른 것들을 얕잡아보는 것이 아니다.
•
XP는 애자일의 프로토타입이자, 최고의 대표주자이며 본질이고 핵심이다.
⇒ 뭔가 XP가 애자일의 대표적인 구현체라는 느낌이 들었다.
•
삶의 순환 그림은 세 개의 고리로 나누어진다.
•
가장 바깥은 비즈니스와 관련된 XP의 실천 방법을 보여준다. 이 고리는 본질적으로 스크럼 프로세스와 동일하다.
◦
이 실천 방법들은 개발팀과 사업 부서가 의사 소통하는 방법과 프로젝트를 관리하면서 지켜야할 원칙에 대한 체계를 제안한다.
◦
계획 게임
▪
가장 중심적인 역할을 하며, 프로젝트를 기능, 스토리, 작업으로 쪼개는 방법을 알려준다.
▪
크기를 추정하거나 우선순위를 결정하거나 기능이나 스토리, 작업의 일정을 정하는 데 필요한 지침을 제공한다.
◦
작은 릴리스
▪
팀이 일을 조그만 크기로 나눠 하도록 이끈다.
◦
인수 테스트
▪
기능이나 스토리, 작업의 완료를 정의할 수 있게 해준다. 완성 조건을 모호하지 않게 규정하는 방법을 보여준다.
◦
전체 팀
▪
소프트웨어 개발팀이 여러 가지 역할로 구성되어 있음을 나타내는 개념이다. 팀을 이루는 프로그래머, 테스터, 관리자 등은 같은 목표를 위해 함께 일한다.
•
가운데 고리는 팀과 관련된 실천 방법을 담고 있다. 이는 개발팀을 관리하고 팀원들이 서로 의사소통하는 체계와 원칙을 제공한다.
◦
지속 가능한 속도
▪
개발팀이 자원을 너무 빠르게 소진해 결승선에 도달하기도 전에 탈진해 버리는 것을 막기 위한 실천 방법이다.
◦
공동 소유
▪
팀이 프로젝트 안에 칸막이를 쳐 지식이 퍼지지 못하게 만드는 것을 막는다.
◦
지속적 통합
▪
피드백 고리가 자주 돌게 만드는데 계속 집중하게 만든다. 이를 통해 언제나 팀의 위치를 인지할 수 있어야 한다.
◦
메타포
▪
시스템에 대해서 팀과 사업 부서가 의사소통할 때 사용할 어휘나 표현을 만들고 널리 공유하는 실천 방법이다.
•
삶의 순환에서 안쪽 고리는 기술 실천 방법을 담고 있다.
◦
짝 프로그래밍
▪
기술팀이 지식을 공유하고 서로 리뷰하고 협력하도록 하여 혁신과 정확성을 끌어내는 방법이다.
◦
단순한 설계
▪
팀이 노력을 낭비하지 않도록 도와주는 실천 방법이다.
◦
리팩토링
▪
모든 작업 산출물의 지속적인 개선과 향상을 장려한다.
◦
테스트 주도 개발
▪
기술팀이 최고의 품질을 유지하면서도 빠르게 움직이기 위해 사용하는 안전망이다.
•
이 실천 방법들은 애자일 선언의 목표와 적어도 다음과 같이 밀접하게 매핑되고 있다.
◦
공정과 도구보다 개인과 상호작용
▪
전체 팀, 메타포, 공동 소유, 짝 프로그래밍, 지속 가능한 속도
◦
포괄적인 문서보다 작동하는 소프트웨어
▪
인수 테스트, 테스트 주도 개발, 단순한 설계, 리팩토링, 지속적 통합
◦
계약 협상보다 고객과의 협력
▪
작은 릴리스, 계획 게임, 인수 테스트, 메타포
◦
계획을 따르기보다 변화에 대응하기
▪
작은 릴리스, 계획 게임, 지속 가능한 속도, 테스트 주도 개발, 리팩토링, 인수 테스트
결론
•
애자일이 무엇인지, 그리고 어떻게 시작되었는지 살펴보았다.
•
애자일은 작은 소프트웨어팀이 작은 프로젝트를 관리할 수 있게 도와주는 작은 규칙이다. 하지만 이런 작고 작은 규칙들이 어마어마한 영향력을 갖고 있다.
◦
모든 큰 프로젝트는 작은 프로젝트들이 모여 만들어지기 때문이다.
