자세히 봐야 잘 된다 스프린트도 그렇다
https://brunch.co.kr/@2902c1f0270046b/39
이전 글에서 애자일과 애자일에서 선정해야 할 유저 스토리에 대해 알아보며 실제로 프로덕트에 적용해봤습니다. 그렇다면 애자일을 실제로 실천하려면 어떤 방법을 써야 할까요?
애자일의 방법론, 스크럼
앞서 언급했듯이 애자일에 대해서 이전 글에서 다뤘다. 하지만 애자일의 방법론을 정확하게 알기 위해서 한 번 더 짚고 가야 할 필요성이 있다.
출처: 파이오니아애자일이란?
'기민한', '민첩한'이라는 뜻을 가진 형용사로 사무환경에서 부서 간 경계를 허물고, 직급 체계를 없애 팀원 개인에게 의사 권한을 부여하는 것을 말한다. 즉, 소규모의 팀을 꾸려 구체적인 계획 없이 실행에 옮겨 외부 피드백을 계속적으로 반영하여 최종 결과를 만드는 조직의 형태를 말한다. 또 다르게 애자일은 간단한 방식, 최소의 방식으로 일을 하는 방법론을 말한다. 간단한 기능을 자주 만들고 바로 배포하여 고객의 반응을 보는 방식인데 이때 4~6개 정도의 유저 스토리를 만들어서 진행한다.
그렇다면 이번 글에서 다룰 스크럼은 무엇일까?
프로젝트를 빠른 시간 내에 효율적으로 개발하고 해결하는 단기간 프로덕트 개발 방법론
스크럼은 특정 개발 언어나 방법론에 의존적이지 않으며 제품 개발뿐만 아니라 일반적인 프로젝트 관리에도 사용 가능한 프로세스 프레임워크이다. 작은 주기로 개발 및 검토를 하며 효율적인 협업 방법을 제공하는 이 스프린트는 다음과 같은 프로세스를 거친다.
출처: KIC Consulting스크럼팀
스크럼 팀은 적은 수의 인원으로 구성이 되는데 이는 한 명의 스크럼 마스터, 한 명의 프로덕트 오너, 그리고 개발자들로 이루어져 있다. 이는 스크럼 팀이 하나의 프로덕트 목표에 동시에 집중하는 전문가들의 모임이기 때문이다.
개발자: 매 스프린트마다 사용 가능한 증가분의 모든 부분을 만드는 것에 전념한다.
스프린트 및 세부 태스크 계획
완료의 정의를 준수하여 품질을 높이고자 함
스프린트 목표를 위해 계획을 매일 조정
전문가로서 서로 책임을 짐
PO/PM: 스크럼 팀의 결과물인 프로덕트의 가치를 극대화하는 책임을 가진다. 비즈니스 목표를 충족시키는 제품을 만들기 위해 제품 백로그를 관리하고 제품 검토한다.
프로덕트 목표를 세우고 프로덕트 백로그 아이템을 생성하여 명쾌하게 소통
제품 백로그 관리 및 설명
프로덕트 백로그 아이템을 우선순위에 따라 정렬
프로덕트 백로그를 반드시 투명하고 가시적이며 이해가 잘 되도록 만드는 것
스크럼 마스터: 스크럼 가이드에 정의된 대로 스크럼을 확립하는 것에 책임을 가지는데 스크럼 팀과 조직의 모든 구성원이 스크럼 이론과 실천법을 이해하도록 돕는다.
팀원들이 자율관리를 하고 교차기능적이 되도록 코칭
스크럼 팀의 진척에 방해가 되는 장애물 제거
일일 스크럼 회의 진행
모니터링 및 Tracking
스크럼 속 스프린트
‘전력 질주’라는 뜻을 가지고 있는 스프린트는 프로젝트를 빠른 시간 내에 효율적으로 개발하고 해결하는 단기간 프로덕트 개발 방법론이다. 스프린트는 꾸준함을 갖기 위해 한 달 또는 그보다 짧은 기간으로 고정된 길이의 이벤트다. 새로운 스프린트는 직전의 스프린트가 끝나는 즉시 시작한다. 그렇다면 이 스프린트는 어떤 프로세스를 거칠까?
출처: KIC Consulting1. PM/PO는 업무를 사용자 스토리를 기반으로 우선순위에 따라서 프로덕트 백로그*에 정렬
2. 프로덕트 백로그에서 결정된 우선순위를 기반으로 스프린트 기간 동안 해야 하는 일에 대해 리스트 작성
3. 매일 정해진 시간에 정해진 장소에 모여 15~20분 동안 간단하고 빠르게 데일리 스크림 미팅 진행
4. 스프린트 기간 동안 개발한 기능을 이해 관계자들에게 보여주고 피드백 진행
*프로덕트 백로그: 이해 관계자로부터 추출된 제품이 제공해야 하는 기능이나 개발 제품에 대한 요구사항 목록
중요하게 생각해야 할 점
필요한 수준까지 프로덕트 백로그를 정제해야 한다.
범위를 명확하게 하고 필요한 경우 PO/PM과 다시 협상을 할 수 있다.
스프린트 계획 회의를 사용하여 완료해야 할 작업에 대한 자세한 내용을 더 한다.
팀 구성원들이 스프린트에 포함되는 모든 스토리, 버그 및 작업에 대한 작업을 구상하도록 유도한다.
하지 말아야 할 점
스프린트 목표 달성을 저해하는 변경을 해서는 안 된다.
품질을 떨어뜨려서는 안 된다.
너무 많은 스토리를 가져오거나 속도를 과대평가하거나 스프린트에서 완료할 수 없는 작업을 가져오면 안 된다. → 자신 또는 팀이 실패할 수밖에 없는 계획을 세우면 안 된다.
품질 또는 기술적 부채를 잊으면 안 된다. 버그 및 엔지니어링 상태와 같은 Qa 및 기능 이외의 작업에 대한 시간을 책정하면 안 된다.
팀에서 스프린트의 작업에 대해 불분명해서는 안된다.
알 수 없는 부분이 많거나 위험도가 높은 작업을 수락하면 안 된다.
속도, 확실성이 낮은 작업 또는 예상보다 큰 것 같은 작업과 같이 팀에 우려 사항이 있으면 무시하면 안 된다. 문제를 해결하고, 필요한 경우 다시 보정한다.
PM/PO의 역할
출처: DT Evangelist 기술 블로그스프린트를 진행하게 되면 적어도 한 달에 한 번은 프로덕트 목표 대비 진척을 점검하고 조정할 수 있기 때문에 프로젝트 진척에 대한 예측 정확도를 높일 수 있다.
진척을 예측하는 데에는 번 다운(Burn-downs) 차트, 번 업(Burn-ups) 차트, 누적 흐름도 등 다양한 방식이 있다. 이러한 방식이 유용하기는 하지만, 경험주의의 중요성을 대체하지는 못한다. 복잡한 환경에서는 어떤 일이 일어날지 알 수가 없다. 단지 지금까지 무엇이 발생했는지를 토대로 앞으로의 결정을 내릴 수 있다. 이때 오직 PM 또는 PO만이 스프린트를 취소할 결정권을 가진다.
PM/PO는 프로덕트 목표를 달성하기 위해서 가장 중요한 아이템들, 그리고 그것들이 프로덕트 목표와 어떻게 연결되는지를 참여자들이 논의할 수 있도록 준비해야 한다. 그렇다면 PM/PO는 어떤 기준을 통해 스프린트를 계획할까?
1. 이 스프린트가 왜 가치가 있는가?
PM/PO는 프로덕트가 어떻게 가치와 효용성을 높일 수 있는지를 제안한다. 전체 스크럼 팀원들이 협력해서 스프린트 목표를 정의하는데 이때 이 스프린트가 이해 관계자들에게 중요한 이유를 담아야 한다. 스프린트 목표는 반드시 스프린트 계획을 마치기 전에 결정되어야 한다.
2. 이 스프린트의 완료(Done)는 무엇인가?
PM/PO와 논의를 하면서 개발자들이 이번 스프린트에 포함할 프로덕트 백로그 아이템을 선정한다. 스크럼팀은 이 과정 중에 프로덕트 백로그 아이템을 정제할 수 있다. 이를 통해 내용을 더 정확하게 이해하고 할 일에 대한 확신을 가질 수 있다.
3. 선정한 일을 어떻게 완료할 것인가?
개발자들이 선정한 모든 프로덕트 백로그 아이템들을 가지고, 완료의 정의를 충족하는 증가분을 만드는 데 필요한 업무들을 계획한다. 대체적으로 이것은 프로덕트 백로그 아이템을 하루 안에 완료할 수 있는 크기로 더 작게 세분화하는 것으로 이루어진다.
이처럼 PM은 중간 관리자로써 변경할 수 없는 스크럼 프레임워크를 운영해야 합니다. 이전 글과 이번 글에서 설명했던 것들을 다 익혔다고 해서 다 알 수 있는 것도 아닙니다. 린, 애자일 같은 방법론을 현명하게 활용할 줄 알아야 하고 무엇보다 중요한 것은 직접 경험하는 것입니다.
우리는 고객에 대해 잘 모릅니다. 그렇기 때문에 빠르게 그리고 자주 고객에게 릴리즈하고 새롭게 발견해야 합니다. 그렇게 여러 번의 가설 검증 단계를 거치고 우리가 진짜 필요한 것이 무엇인지, 피해야 할 것이 무엇인지 알아냅니다. 그렇게 우리는 이해 관계자들에게 더 빠르게 그들이 원하는 것을 전달할 수 있습니다.
출처 및 자료
