클린 애자일(Clean Agile - Back to Basics) - 1장 애자일 소개

애자일의 역사

1970년, 소프트웨어 세계가 두 가지 충돌하는 기법의 갈림길 앞에 서 있었다.

• 선-애자일(pre-Agile)
  • 조금씩 걸어보고 측정을 한 후 그에 맞추어 개선하기를 반복하는 방식으로 걷는 것
  • 변경 비용이 작은 프로젝트에서 잘 작동
  • 목표가 명확하게 세워지지 않은 불완전하게 정의된 문제를 잘 풀었다.
• 과학적 관리법
  • 철저하게 분석하고 그에 따라 상세한 계획을 만들기 전까지는 행동을 미루는 방법
  • 변경 비용이 많이 드는 프로젝트에서 잘 동작
  • 목표가 극도로 명확한 매우 상세하게 정의된 문제를 잘 풀었다.

갈림길에서 던져야 했을 질문: “소프트웨어 프로젝트라는 것은 어떤 종류의 프로젝트인가?”

1970년대 우리가 향했던 길은 우연히 향하게 된 것으로 보인다.

1970년, 윈스턴 로이스(Winston Royce)가 대규모 소프트웨어 프로젝트를 관리하는 방법에 대한 그의 아이디어를 설명하는 논문을 썼는데, 여기에 그의 계획을 묘사한 그림(그림 1.1)이 들어 있었다. 로이스가 이 그림을 처음으로 그린 것도 아니고, 그가 추천하는 계획 방법도 아니었다. 사실 이 그림은 이후에 더 좋은 방법을 제시하기 위해 비교 대상으로 내세운 허수아비에 불과했다.

그럼에도 불구하고 이 그림의 절묘한 위치, 그리고 논문의 맨 한두 페이지에 있는 그림으로 전체 논문 내용을 넘겨짚는 사람들의 습관 때문에 소프트웨어 산업은 극적인 변화를 맞았다.

이 방법은 ‘폭포수(Waterfall)’라고 불리게 되었고, 폭포수는 과학적 관리법의 이론적인 후예였다.

로이스가 추천하는 것이 아니었음에도, 사람들은 그의 논문에서 폭포수만 기억했다. 그리고 폭포수 모델은 그 후 30년 동안 산업을 지배했다.

초기 애자일 개혁은 1980년대 후반 혹은 1990년대 초반에 시작되었다.

마틴과 나는 2000년 가을에 만나, 경쟁하고 있는 여러 경향 프로세스 지지자들을 모두 함께 모아 통합 선언문을 만들어 보자는 내 아이디어를 설명했다. 그냥 늦게 초대장을 보냈다. 제목은 ‘경량 프로세스 회담’이었다.

스노버드

2001년 2월 스노버드에서 “경량 프로세스 회담(Lightweight Processes Summit)”이 열렸다.

완성된 네 가지 문장은 아래와 같습니다.

• Individuals and interactions over processes and tools
  • 공정과 도구보다 개인과 상호작용
• Working software over comprehensive documentation
  • 포괄적인 문서보다 작동하는 소프트웨어
• Customer collaboration over contract negotiation
  • 계약 협상보다 고객과의 협력
• Responding to change over following a plan
  • 계획을 따르기보다 변화에 대응하기

그리고 애자일(Agile)이라는 이름이 정해졌습니다.

애자일 개요

모든 소프트웨어 프로젝트는 일종의 트레이드오프(프로젝트 관리의 철십자(Iron Cross))를 벗어날 수 없다.

좋은, 빠름, 저렴함, 완성 - 이 중 세 가지만 선택할 수 있다.

좋은 관리자는 네 가지 속성의 가중치를 관리하지, 모든 속성이 100%가 되기를 요구하지 않는다. 애자일은 이런 관리를 추구한다.

애자일은 개발자와 관리자 프로젝트를 실용적으로 관리할 수 있도록 돕는 체계다.

애자일이 어떻게 이런 관리를 도울까? 애자일 개발팀은 관리자가 좋은 결정을 내리는 데 필요한 딱 맞는 데이터를 생산한다.

이 두 차트를 벽에 거는 것이 애자일의 중요한 목표다. 정확하게 말하자면, 진짜로 필요한 것은 차트가 아닌 데이터다.

데이터가 왜 그렇게 중요할까?

가장 먼저 알게 되는 것

마감 기한

회의 단계

분석 단계

설계 단계

구현 단계

죽음의 행진(Death March) 단계

더 나은 방법

애자일 프로젝트도 분석으로 시작한다. 하지만 이 분석은 끝나지 않고 계속 이어진다. 프로젝트 일정을 일정한 크기로 더 작게 나눈다. 이것을 반복 주기(iteration) 또는 스프린트(sprint)라고 부른다.

반복 주기 0

반복 주기 0에서는 짧게 기능 목록을 만드는데, 이를 스토리라고 부른다. 반복 주기 0 동안 개발 환경을 준비하고, 스토리의 크기를 추산하고 최초의 계획을 세운다. 처음 반복 주기 몇 번 동안 처리할 스토리를 대략 할당한다. 마지막으로 스토리 목록을 바탕으로 초기 시스템 설계의 잠정적인 밑그림을 그린다.

애자일 프로젝트에서는 끊임없이 분석과 설계를 한다.

반복 주기 전체에 걸쳐 요구 사항 분석, 아키텍처 수립, 설계, 구현 활동이 끊임없이 일어난다.

애자일은 데이터를 만든다

반복 주기 1의 시작이다. 가장 먼저 스토리를 몇 개나 완료할 수 있을지 추산해 본다. 그리고 반복 주기 동안 팀은 이 스토리를 완료하는 데 필요한 일을 한다.

반복 주기 1이 끝나면 우리가 계획했던 스토리 중 일부만 완료했을 것이다. 이를 통해 반복 주기 하나 동안 스토리를 몇 개나 완료할 수 있는지 특정한 수치를 처음으로 얻는다.

반복 주기가 진행될수록 오차 범위는 더 줄어들고, 원래 종료 일자에 프로젝트를 끝낸다는 것은 헛된 희망임이 명확해질 것이다.

희망 대신 관리

애자일이 빠르게 나아가는 것이라고 생각하는 사람도 있다. 그렇지 않다. 빠르게 나아가는 것이었던 적은 없다. 애자일은 우리가 얼마나 망했는지를 최대한 빨리 아는 것이다.

철십자 관리하기

좋음, 빠름, 저렴함, 완성. 관리자가 프로젝트에서 얻은 데이터에 기반하여 결정을 내릴 시간이다.

일정 변경하기

마감 기한은 타당한 사업상의 이유로 정해진 것이다. 따라서 프로젝트 연기가 사업에 심각한 타격을 가할 수도 있다.

사람 추가하기

브록스의 법칙에 따르면 지연된 프로젝트에 인력을 추가하면 더 늦어진다.

또 다른 요소는 사람을 추가하는 데 돈이 많이 든다.

품질 떨어뜨리기

쓰레기 같이 만들면 훨씬 더 빨리 진행할 수 있다.

쓰레기를 만든다고 더 빨리 갈 수는 없다. 더 느려질 뿐이다. 빠르게 가는 유일한 방법은 제대로 가는 것이다.

범위 변경하기

하나하나 살펴보며 마감까지 절대적으로 필요하지 않은 기능

비즈니스 가치 순서

반복 주기를 시작할 때마다 다음으로 어느 기능을 구형할지 물어보자. 어떻게 해서든 이해관계자가 원하는 순서대로 기능을 구현할 것이다.

개요가 끝났다

애자일은 프로젝트를 더 작은 반복 주기로 나누는 프로세스다. 각 반복 주기의 결과물을 측정하여 지속적으로 일정을 평가하는 데 사용한다. 기능은 비즈니스 가치 순서대로 구현하므로 가장 중요한 것이 먼저 구현된다. 품질은 가능한 높게 유지한다. 일정은 주로 범위를 조정하여 관리한다.

삶의 순환

그림 1.8은 XP의 실천 방법(practice)을 설명하는 론 제프리스의 그림으로, 삶의 순환(Circle of Life)이라는 애칭으로 불린다.

사실상 다른 모든 애자일 프로세스는 XP의 부분 집합이거나 XP의 변종이다.

가장 바깥은 비즈니스와 관련된 실천 방법을 보여준다.

가운데 고리는 팀과 관련된 실천 방법을 담고 있다.

안쪽 고리는 기술 실천 방법을 담고 있다.

결론

애자일은 작은 소프트웨어팀이 작은 프로젝트를 관리할 수 있게 도와주는 작은 규칙이다. 모든 큰 프로젝트는 여러 작은 프로젝트로 구성된다.