미국의 고속도로에는 현재 어느정도 까지 와있는지를 나타내는 마일스톤이 박혀있다고 합니다. 한마디로 내가 지금 어느정도 와있고 앞으로 얼마나 더 남았는지에 대한 “이정표” 역할을 하는 돌 인것이죠.
애자일에서 말하는 마일스톤이란 프로젝트가 완성되기 까지의 중간 단계를의미합니다. 예를들어, “우리 1차 마일스톤에서는 고객이 회원가입하고 로그인 할 수 있는 기능을 만들자” 정도가 될 수 있겠죠. 마일스톤을 잘 세우고 프로젝트를 진행하면 중간에 길을 잃지 않고 프로젝트를 완성 시킬 수 있습니다.
목적지 까지 도달하기 위해 여러개의 마일스톤을 거쳐야 할 수 있습니다. 중요한건 이 마일스톤을 너무 상세하게 정의하지 않는것입니다. 마일스톤을 정의하는데 많은 시간을 쏟는것은 애자일의 취지에 맞지 않습니다. 성능이 어떻고 UI/UX는 어떻고 테스트 케이스 80%이상은 통과해야 한다는등의 구체적인것은 완성시키고 나서 고려해도 늦지 않습니다. 마일스톤은 단지 어떤 기능들이 완성되어야 하는지를 기준으로 간단하게 세워야 합니다.
마일스톤을 먼저 만들고 일정을 세웁시다.
마일스톤을 만든다고해서 각 단계의 마일스톤을 언제까지 완성시키겠다고 하는 상세일정을 정할 필요는 없습니다. 애자일은 소프트웨어 개발에 구체적인 일정을 지키는일보다 팀원간 협력을 통해 지속적인 속도를 유지하며 올바른 방향으로 나아가는것을 더 중요시 여깁니다.
예를들어, 1차 마일스톤에 10가지 기능을 완성시키기로 결정했다고 해봅시다. 이 10가지 기능을 구현할 담당자를 정하고 각 기능에 스토리 포인트를 부여한뒤, 그 포인트들을 총합해서 팀의 하루 처리 스토리 포인트로 나누면 1차 마일스톤까지 몇일이 걸리는지 예상해볼 수 있습니다.
만약에 1차 마일스톤 구현에 2달이 걸린다고 계산되었다면 팀 상황에 맞게 스프린트를 1달 단위 2개 혹은 2주 단위 4개로 나눠볼 수 있습니다.
일정은 이런식으로 기능에서 일정을 산출해내는 방식이어야 합니다. 일정에 기능구현을 끼워 맞추는게 아닙니다. 우리가 오픈까지 3달이 남았으니까 1차마일스톤은 1달뒤 2차 마일스톤은 2달뒤 이런식으로 정해선 안됩니다.
마일스톤에서 구현해야하는 모든 기능들을 백로그에 나열하고 그 기능들에 스토리 포인트를 부여하여 일정을 산정하고 스프린트를 나눠 프로젝트를 진행하게 되는 프로세스입니다.
