2013.04.15

폭포수 기법보다 애자일 프로젝트 관리가 좋은 이유

David Taber | CIO
먼저 밝히 두겠다. 필자는 애자일의 '광신도'다. 하지만 제대로 살펴보기로 하자. 애자일의 '성명서'를 냉소적으로 살펴보면 "우리는 예술가다. 새로운 방식으로 예술 프로젝트를 관리해야 좋은 결과를 이끌어낼 수 있다"는 메시지를 전달하고 있음을 알 수 있다.

굳이 냉소적으로 살펴보지 않아도, 기존의 '폭포수' 방법론으로는 애자일 프로젝트를 관리할 수 없는 것이 사실이다. 그러나 관리할 수 없다는 의미는 아니다. 예산과 관리가 필요하다. 그렇지 않으면 '가치'를 구현하지 못한다. 다른 말로 하면 '성숙한' 감독이 필요하다는 의미다.

애자일은 마라톤이 아니라 여러 차례의 단거리 경주다
애자일 프로젝트를 성숙하게 관리하기 위해서는 폭포수 기법과 비교해 더 자주 노력을 기울여야 한다. 또 좀더 세심한 관심이 요구된다. 전형적인 폭포수 프로젝트의 경우, 책임자들이 처음에 예산과 일정을 승인하면, 이후 간헐적으로 이분법적 평가가 이뤄지는 회의가 이뤄진다. 프로젝트 매니저는 사양 요건이 수용할 수 있는 기준을 넘어섰는지 확인만 하면 된다.

사양과 수용 기준을 정하기까지 많은 사전 작업이 필요하기는 하다. 그러나 일단 프로젝트가 시작되면 폭포수 기법에 기반을 둔 감시와 통제는 상당히 쉬워 보인다. 그러나 실제는 그렇지 않다. 기준이 정확하지 않거나 관련이 없는 경우가 너무 많다.

프로젝트 중간에 사양의 일부 세부사항이 잘못됐다는 사실을 발견하기도 한다. 그러나 누구도 사양과 검사 기준을 수정할 시간이 없다. 모든 소프트웨어 프로젝트의 두 가지 문제점인 '범위 추가(Scope Creep)'와 '모호한 수용 기준'이 이런 폭포수 프로젝트의 예산, 일정, 관리 측면에서의 신뢰성을 저해하는 것이다.

대조적으로 애자일 프로젝트에는 선행 업무가 많이 필요 없다. 매일 사양을 정해 관리하기만 하면 된다. 애자일 프로젝트에는 자세한 사양이 없다. 심지어는 완료가 되고 나서도 그런 경우가 있다.

대신 프로젝트 팀이 사업 가치를 기준으로 작업의 우선순위를 정해야 하고, 그럴 권한을 갖는다. 또 각 릴리스마다 '세부 사양과 기준'을 파악해 이행해야 한다. 프로젝트 팀은 정해진 예산과 일정 안에서 단거리 경주를 하는 것이다. 단거리 경주는 짧다. 따라서 오버런(Overrun, 일정을 넘기는 문제)이 많지 않다. 또 프로젝트 팀이 '단거리 경주'를 완주하기 위해 쓸모 없는 것을 없애면서 범위 추가 문제가 발생하지 않는다.

이런 단거리 경주에서 알아야 할 유일한 것은 '정확히 무엇을 전달할 지'가 아닌 '정확히 언제 전달할 지'이다. 애자일 메커니즘을 돕는 많은 도구가 있다. 그러나 가장 기본적인 요소는 팀과 팀 내부의 상호작용이다. 이는 정성적이다. 따라서 정량적 요소를 중시하는 사람들을 미치게 만들 것이다.




2013.04.15

폭포수 기법보다 애자일 프로젝트 관리가 좋은 이유

David Taber | CIO
먼저 밝히 두겠다. 필자는 애자일의 '광신도'다. 하지만 제대로 살펴보기로 하자. 애자일의 '성명서'를 냉소적으로 살펴보면 "우리는 예술가다. 새로운 방식으로 예술 프로젝트를 관리해야 좋은 결과를 이끌어낼 수 있다"는 메시지를 전달하고 있음을 알 수 있다.

굳이 냉소적으로 살펴보지 않아도, 기존의 '폭포수' 방법론으로는 애자일 프로젝트를 관리할 수 없는 것이 사실이다. 그러나 관리할 수 없다는 의미는 아니다. 예산과 관리가 필요하다. 그렇지 않으면 '가치'를 구현하지 못한다. 다른 말로 하면 '성숙한' 감독이 필요하다는 의미다.

애자일은 마라톤이 아니라 여러 차례의 단거리 경주다
애자일 프로젝트를 성숙하게 관리하기 위해서는 폭포수 기법과 비교해 더 자주 노력을 기울여야 한다. 또 좀더 세심한 관심이 요구된다. 전형적인 폭포수 프로젝트의 경우, 책임자들이 처음에 예산과 일정을 승인하면, 이후 간헐적으로 이분법적 평가가 이뤄지는 회의가 이뤄진다. 프로젝트 매니저는 사양 요건이 수용할 수 있는 기준을 넘어섰는지 확인만 하면 된다.

사양과 수용 기준을 정하기까지 많은 사전 작업이 필요하기는 하다. 그러나 일단 프로젝트가 시작되면 폭포수 기법에 기반을 둔 감시와 통제는 상당히 쉬워 보인다. 그러나 실제는 그렇지 않다. 기준이 정확하지 않거나 관련이 없는 경우가 너무 많다.

프로젝트 중간에 사양의 일부 세부사항이 잘못됐다는 사실을 발견하기도 한다. 그러나 누구도 사양과 검사 기준을 수정할 시간이 없다. 모든 소프트웨어 프로젝트의 두 가지 문제점인 '범위 추가(Scope Creep)'와 '모호한 수용 기준'이 이런 폭포수 프로젝트의 예산, 일정, 관리 측면에서의 신뢰성을 저해하는 것이다.

대조적으로 애자일 프로젝트에는 선행 업무가 많이 필요 없다. 매일 사양을 정해 관리하기만 하면 된다. 애자일 프로젝트에는 자세한 사양이 없다. 심지어는 완료가 되고 나서도 그런 경우가 있다.

대신 프로젝트 팀이 사업 가치를 기준으로 작업의 우선순위를 정해야 하고, 그럴 권한을 갖는다. 또 각 릴리스마다 '세부 사양과 기준'을 파악해 이행해야 한다. 프로젝트 팀은 정해진 예산과 일정 안에서 단거리 경주를 하는 것이다. 단거리 경주는 짧다. 따라서 오버런(Overrun, 일정을 넘기는 문제)이 많지 않다. 또 프로젝트 팀이 '단거리 경주'를 완주하기 위해 쓸모 없는 것을 없애면서 범위 추가 문제가 발생하지 않는다.

이런 단거리 경주에서 알아야 할 유일한 것은 '정확히 무엇을 전달할 지'가 아닌 '정확히 언제 전달할 지'이다. 애자일 메커니즘을 돕는 많은 도구가 있다. 그러나 가장 기본적인 요소는 팀과 팀 내부의 상호작용이다. 이는 정성적이다. 따라서 정량적 요소를 중시하는 사람들을 미치게 만들 것이다.


X