PO가 느낀 스프린트 방식의 장단점
워터폴과 다른 스프린트의 일정관리 방식과 일하는 방식
우리 프로덕트팀의 경우는 스프린트 방식을 활용하기 위해서 몇가지 스텝을 밟고 있다. 운영되는 프로덕트에서 계속해서 개발을 해나가야 하기 때문에 스프린트가 단일 프로젝트용으로 사용되지 않고, 팀에서는 다양한 프로젝트들이 기간내에 이뤄진다.
첫째, 스프린트 기간에 완료하고자 하는 목표를 정한다.
가능하면 이 목표는 에픽의 사이즈를 쪼개서라도 뭔가 확인하거나 선반영이 가능해서 배포까지 완료하고 작업자가 털어낼 수 있는 범주로 설정한다. 목표는 프로젝트가 하나가 아니기 때문에 여러가지의 마일스톤일 수 있다.
둘째, 스프린트 설계 시점 전에 작업 티켓을 명확하게 설계할 수 있도록 이전 스프린트에서 PRD를 리뷰하고 개발설계할 수 있는 시간을 가진다.
셋째, 스프린트 설계 시점에 이미 명확하게 만들어진 작업 티켓을 중심으로 작업자들이 티켓을 자신의 스토리포인트 내에서 소화가능한만큼 나눠 가진다.
이렇게만 들으면, 그냥 작업 잘 정리해서 스프린트내에 소화할만큼 나누는 것처럼 보이지만 사실 기존의 워터폴 프로젝트 방식에 익숙하다면 이 방식에서 오는 낯선 것들이 곳곳에 존재한다.
가장 어려운 점은 작업자별 상세 일정의 관리에 대한 부분이다. 애자일팀은 스프린트 설계시 본인이 자신의 스토리포인트내에서 수용가능한 티켓을 가져가고, 2주단위의 스프린트에 대해서 그 안에 해결하면 된다. 우선순위는 명확히 전달할 수 있겠지만, 스프린트에 설계된 티켓들의 종료일자는 그 2주내에 해결만 되면 된다고 이야기할 수 있다. 즉, 각 티켓의 실제 종료일정은 메이커들이 정한다. 외주팀들과 협의해서 정해진 날짜에 같이 배포일정을 맞춰야 하는 것이 아니라면 각 팀내에서는 서로간의 연관성을 최대한 줄여서 작업자들이 스프린트 목표를 맞추는 것이 제일 중요해진다.
이 부분이 PO에게는 다소 어려운 게, 프로젝트 관리에서 많은 사람들이 여전히 간트차트에 익숙하기 때문이다.
https://ko.wikipedia.org/wiki/%EA%B0%84%ED%8A%B8_%EC%B0%A8%ED%8A%B8
간트차트는 모든 업무를 나열한 뒤, 이를 일자별로 막대블럭으로 표시한 형태의 프로젝트 관리기법이다. 특히나 폭포수 방법에서는 기획, 디자인, 개발, 테스트, 오픈을 이 간트차트 형태로 세분화하여 그야말로 순서대로 표기하는 것에 딱 맞는다. 어디까지 진행되었는지 확인하기가 아주 유용하다는 장점도 있다.
하지만 스프린트내에서 여러 작업자가 스프린트 기간동안 자신의 속도에 맞춰서 만들게 되었을 때, 작업 기간은 날짜별로 약속된 업무를 종료 하느냐가 아니라 2주내에 여러 티켓이 얼마나 처리되었느냐로 치환된다. 이래서 jira의 대시보드나 번다운차트가 간트차트보다 관리에 적합하게 되어 버린다.
결국 타 팀에 뭔가 일정을 공유할 때, 명확한 날짜가 지정될 필요가 없다면 항상 스프린트 끝나는 일정을 이야기하고 그 전에 끝나면 공지하는 방식으로 소통하게 된다. 여기에 디자인 > 서버개발> 클라이언트개발 이라는 순서를 고려하게 되면 스프린트 로드맵상 3개까지 늘어나게 된다. 어쩌면 폭포수 방법론에 비해서 일정이 더 걸리는 방법이 되기도 한다.
물론, 프로젝트의 날짜가 전사적 차원에서 정해져있어서 동시에 오픈해야하는 클라이언트 개발은 일정에 대한 공유도 중요하긴 하다. 하지만 가능하면 스프린트 내의 작업자 속도에 따라서 테스트 후 배포하는 것을 원칙으로 하기 때문에 이 부분도 빠듯하게 개발하기 보다는 스프린트를 선행하고 날짜에 맞게 서비스가 노출되도록 조율하는 방식으로 일정 관리를 하려고 노력하고 있다. 이렇게 생각하면 일정은 buffer를 고려해서 더 길어질 수 있다. (물론 이러한 것이 가능한 것은 내 프로덕트가 안정성이 더 중요한 주문클레임이기 때문이기도 하다)
또 하나의 낯설음은, 심지어 티켓의 처리담당자도 스프린트 설계 시점에 정해지기 때문에 사전에 해당 기능만 이야기할 개발담당자를 미리 잡아둘 수도 없다는 점이다. 다른 팀과 조율해야하거나 미리 요구사항에 대해서 논의해보려고 하면 팀 전체와 소통하는 스크럼 시간을 활용해서 이슈업을 하거나 논의를 해야한다. 담당자하고만 미리 정해진 일정대로 소통하는 폭포수 프로젝트에 비해서 정말이지 소통의 대상과 소통의 양이 월등히 많아지는 것을 느낀다.
사내에서 프로덕트오너들과 소통해 보았을 때 위와 같은 문제로 스프린트 운영을 사실상 포기하게 되는 팀도 있다고 토로했다. 스프린트라고 단어는 쓰지만 프로젝트 관리는 워터폴처럼 한다는 뜻이다. 이런 경우는 특히 메이커들이 스프린트에서 자발적으로 설계하고 손들고, 완료하고 좀 더 자발적으로 내용을 구체화하기 위해서 이슈를 논의하고 하는 스크럼 과정이 돈독하지 않다면 아예 이슈 발생 시 논의가 되지 않아서 병목이 해소되지 않고 남아버리기도 한다고 했다. 그런데 이 문제는 사실 워터폴 프로젝트에서 고질적으로 나타나는 문제다. 스프린트라는 이름을 쓰고 있지만 일정관리와 메이커들이 익숙하지 않다면 스프린트를 적용하기 어렵다는 이야기였다.
여기에는 분명 차이가 있다. 프로덕트팀의 PO는 화면설계서만큼 기획을 구체화시키기 보다는 Userstory를 통해서 메이커들의 자유도를 어느 정도 보장해주고, 실제 구체적인 정책 마련 시 가이드라인과 의사결정을 돕는 역할을 한다. 아예 모든 것을 다 써주고 그대로 지키라고 하는 화면설계서 방식보다 참여자들의 참여도를 높여야 하기 때문에 어려운 점이 있다. 그런데 그만큼 참여도가 높기 때문에 이슈에 대한 해결도 메이커들이 더 적극적으로 개입하기에 이런 문제들이 줄어든다. 게다가 스프린트 설계시보다 조금이라도 일정이 남으면 다른 개발자의 티켓을 끌어와서 작업을 해주기도 하기 때문에 결국 팀은 스프린트의 목표를 달성한다. 이렇게 팀 자체가 스프린트라는 기간내에 스프린트에 부여한 목표를 완수하는 게 중요하기에 워터폴에서 고질적으로 일어나던 문제들이 몇가지 줄어든다.
워터폴프로젝트는 기간이 아주 타이트하게 간트차트로 관리되기 때문에 항상 테스트 후 오픈이 딜레이되는 상황을 많이 볼 수밖에 없었다. 스프린트라는 기간내에서 작업자가 스토리포인트로 조정하기 보다는 내용이야 어찌됐던 3일, 5일 이라고 가정된 시간내에서 작업이 불가능하거나 병목이 발생하거나 기획이 잘못되면 그 만큼 뒤로 딜레이가 되었기 때문이다. 게다가 수동적으로 일하게 되기 쉬워서 병목에 대한 이슈해결도 꼭 서비스기획자가 참여해서 해결해야하는 경우도 많았다. 예를 들어서, 개발 불가능한 디자인을 수정해야할 때 서로 소통하지 않고 화면설계서가 변경되어 올 때 까지 모두가 손을 놓고 있었던 적이 많다.
스프린트 방식을 제대로 활용하려면,
모자이크 된 간트차트 관리 방식을 버리고
스프린트별 로드맵에 익숙해져야 한다
정리해보면, 스프린트 방식으로 이뤄지는 프로덕트팀의 업무 방식에서 간트차트와 같은 방식으로 일정관리를 하는 것이 적합하지 않다고 할 수 있다. 그리고 딱 정해진 담당자 뿐 아니라 팀 전체와 소통해야하기 때문에 메이커와의 의사소통의 양과 횟수가 워터폴에 비해서 압도적으로 많아져야 하기 때문에 데일리 스크럼이 (특히 지금같은 비대면 시대에는) 굉장히 중요하다는 점이다.
하지만 이렇게 일하면서 워터폴 프로젝트에서 고질적으로 있었던 2가지 문제를 해결할 수 있었다. 실제 계획과 다르게 병목이 일어났을 때 기획서와 기획자에 의존하여 수동적으로 진행되는 이슈는 좀 더 높은 참여도로 대치된다. 그리고 앞의 프로젝트의 병목으로 인해서 오픈이 딜레이 되서 뒤의 프로젝트까지 영향을 주는 워터폴의 치명적 문제도 결국 줄어들게 된다.
그나저나,. 나는 우리 팀 덕분에 스프린트의 장단점에 대해서 느낄 정도로 스프린트를 잘 적응해가고 있다는 사실이 자랑스럽다. 이러니 저러니 해도 메이커들이 간트차트를 요구하거나 무조건 PO에게 정해달라고 의지한다면 이런 방식의 적용 자체가 어려워지는 것이니까. 오늘도 참 감사한 하루다.
