[SCRUM] 팁팁 스크럼 선배가 알려주는 팁

스크럼은 복잡한 프로젝트를 관리하기 위한 프레임워크다. 프레임워크는 뼈대, 골격이지 솔루션을 제공해주지는 않는다. 즉, 이 프레임워크를 사용하는 팀의 환경과 성격에 맞추는 과정이 필요함을 의미하는데 그럼 스크럼을 훌륭하게 실행할 수 있는 방법은 뭘까? "스크럼과 XP"의 저자 헨릭 크니버그는 결국 가장 빠른 방법은 누군가의 실패 경험을 딛고 일어서는 베스트 프랙티스 방법이라고 한다. 수많은 시도와 실패 끝에 최적화한 팀의 스크럼 방식을 배워가면서 빠르게 적응할 수 있다. 

스크럼을 하며 겪은 노하우를 묶은 책에서 알려주는 몇 가지 스크럼을 하는데 알아두면 좋을 팁을 정리해보았다. 

스크럼 프레임워크가 무엇인지에 대해서는 이전 글

[SCRUM] 제품의 가치와 생산성을 동시에 생각하는 프로세스 방법론

을 참고하자.

우선 이전에 스크럼을 도입해서 내부적인 조직력, 협동, 관리적 이점 외에 외부적으로 얻을 수 있는 이득은 뭘까?

만약에 외부에서 프로젝트를 따내야 한다거나 투자를 받고자 할 때 팀의 개발 속도를 알면 신뢰할 만한 기간을 지니는 제품 로드맵을 제안할 수 있게 된다. 

스프린트 계획 회의 팁

스크럼 회의중 어떻게 보면 가장 오랜 시간이 걸리는 스프린트 계획 회의에서는 다음 산출물을 예상하고 시작할 수 있다.

스프린트 목표

팀원 목록 (참여 수준을 표기한)

스프린트 백로그

스프린트 데모 날짜

일일 스크럼 시간과 장소

스프린트 계획은 기본적으로 제품 책임자가 백로그와 각 백로그의 추정시간을 준비해 온다.

백로그는 고객 또는 사용자의 요구사항 또는 스토리라고도 하며 비즈니스적으로 가치있는 기능이라고 볼 수 있다. 

이 말은 제품 책임자가 기술적인 베이스를 가지고 있지 않아도 되지만 제품에 대한 이해는 당연히 깊어야 하고 (고객의 요구사항을 대변하는 입장이므로) 회의때 팀과 재조정을 하긴하겠지만 기능 구현에 있어 예상되는 추정시간에 대한 어느 정도의 이해도도 필요하다는 것을 의미한다.

제품 품질에 대해서 사람들이 인식하는 외적인 품질과 유지보수에 큰 영향을 주는 (설계 일관성, 테스트 커버리지, 코드 가독성, 리팩터링 등) 내적 품질을 나눌 수 있는데 외적 품질이 겉보기에 더 중요해 보일 수 있으나 내적 품질은 기회비용으로 둘 수 없는 필수적인 특성을 지닌다.

산출물만 보아도 스프린트 계획 회의는 오랜 시간 미팅이다 못해 타임박스를 초과하기 쉬우므로 시간표를 미리 짜서 리스크를 줄이는 것이 좋다.

기본 순서

1. 스프린트 목표 검토 | 제품 백로그 요약 | 데모 날짜, 장소, 시간 결정

2. 시간 추정 | 중요도 업데이트 | 데모 방법 (실제 테스트할 시나리오식 작성) 기입

3. 스프린트에 포함시킬 스토리 선정 | 실현 가능성 검토

4. 일일스크럼 회의 시간, 장소 결정

스프린트 목표는 생각보다 세우는 것이 쉽지 않을 수 있다. 하지만 억지로 세워도 그만한 가치가 있다.

스토리를 선정할 때 얼마나 많은 스토리를 할 지는 팀이 결정한다. 제품 책임자가 관여를 하는 방식은 스토리의 중요도를 조정하거나 스토리 범위를 줄이거나 또는 스토리를 더 작게 나누는 방법이 있다. 스토리 결정은 직감이 필요하지만 속도를 계산해나가는 것이 중요하다. 

속도 계산은 스프린트 동안의 맨데이 (각 사람당 시간 투입량)에 집중도를 곱해서 계산하는데 집중도는 이전 스프린트에서 추정한 맨데이에서 실제확인한 속도의 비율로 정할 수 있다. 보통은 70%라 한다.

스토리를 벽에 붙일 수 있는 인덱스 카드나 포스트잇을 쓰면 회의 참여도를 높이고 스토리를 여러 개 수정하기도 쉬우며 우선순위 변경을 빠르게 할 수 있다. 

시간 추정같은 경우 스토리를 작업단위로 나누면 더 쉬워진다. 작업단위는 기술적으로 구현에 있어 필요한 세부작업을 의미한다. 

플래닝 포커로 팀원간 시간 추정의 견해차를 좁히는 것도 좋다.

작업이 완료되었다는 것은 기능의 완료인지 테스트의 완료인지 조건을 확인할 수 있는 체크리스트가 있어도 좋다. 하지만 융통성이 필요한 경우는 상식선에서 완료 기준을 다시 정의하는 것이 좋다. 

배포가 된 후 들어오는 버그 이슈들이 제품 백로그와 어떻게 같이 다룰 수 있는지 고민을 해보아야 한다.

일일 스크럼과 데모 팁

벽면에 

할일 | 진행중 | 완료 | 소멸차트 

표를 그려 두면 일일 스크럼시 업데이트 하기도 현재상황을 파악하기도 좋다.

계획에 없던 항목과 다음 할 일도 한 쪽에 기록한다.

데모는 스프린트 목표를 명확히 설명하며 시작하자.

겉치레보단 실제 동작하는 코드 위주에 집중하고 소소한 버그나 사소한 기능은 가능하면 뺀다. 

데모하기 힘든 (예를 들면 성능 개선) 스토리는 대체할 수 있는 또는 증명할 수 있는 (보고서: 테스트 환경, 결과 등) 자료를 준비한다.

스프린트 회고 팁

마지막 스프린트 회고에서는 각자 좋았던 것, 더 잘할 수 있었던 것, 다음 스프린트에서 다르게 해보고 싶은 것을 얘기하고 

추정 속도와 실제속도 차이르 분석해 왜 그런지 토론해서 다음에 반영할 수 있도록 하면 좋다.

추가적인 부분

"스크럼과 XP" 에는 위에서 언급한 '내부 품질'과 관련된 얘기도 많이 나온다. 빌드 자동화라던지 TDD (테스트 주도 개발)에 대한 언급도 많이 있었고, 저자왈 처음 배우기도 익숙해지기도 쉽지 않지만 한 번 알고나면 빠져나올 수 없는 장점을 지닌다고 하는.. 여러 플랫폼을 거쳐 일어나는 자동화가 까다로운 인수 테스트의 경우 어떻게 할지까지도 유지보수뿐 아니라 장기적인 생산성 측면에서 고민을 해보아야 하는 문제이다.

참고 자료

헨릭 크니버그 저, 스크럼 (Scrum) 과 XP, 인사이트, 2009