엔터프라이즈 개발을 위한 스크럼 기반의 개발 방법론 - 3

목록

1. 제품 백로그 준비
2. 릴리즈 계획
3. 스프린트 계획
4. 스프린트 관리
5. 스프린트 종료
6. 제품 백로그 업데이트
7. 회고

스프린트 관리

 

스프린트 계획이 끝났으면, 계획에 따라서 프로젝트를 수행하면서 스프린트 관리(Sprint Tracking)를 해야 한다.

 

스프린트의 태스크 진행 상황을 추적하기 위해서 몇 가지 기법을 지원하는데 다음과 같다.

 

일일 스크럼(Daily Scrum)

일일 스크럼은 일일 오전 업무 공유 시간이다. (보고와 회의가 아닌 형태이다.)

스크럼에서 가장 유용하고 중요한 기법의 하나다.

 

스크럼 팀은 매일 오전에 같은 자리에 모여 어제 자신이 한일과 오늘 자신이 해야 할 일, 자신이 진행하는 태스크를 종료하는데 필요한 시간을 같이 이야기한다.

이 과정에서 다른 팀원과 태스크 진행 상황을 공유할 수 있고, 만약 일의 진행에서 문제가 있는 부분이나 도움을 받고 싶은 부분은 이슈로 제기하여 다른 사람에게 도움을 요청하거나 프로젝트 매니저가 일정을 조정할 수 있도록 한다.

 

프로젝트 관리 관점에서는 일일 스크럼을 통해 지정된 태스크의 진행 상황을 매일 추적할 수 있다.

 

프로젝트 매니저는 일일 스크럼에서 공유된 일정을 바탕으로 스프린트 백로그의 상세 태스크를 업데이트 하는데, 중요한 점은 각 태스크의 종료 까지 남은 시간을 반드시 기록한다. 이 데이터는 처음 계획 대비 현재 상황이 어떻게 진행되고 있는지를 판단할 수 있게 해주는 중요한 지표가 된다.

No	Item	Task	Resource	Owner	Status	1	2	3	4
1	AI. 1	plan	3	Hyeok	closed	3	2	1	0
2	AI. 1	point	4	Suk	closed
3	AI. 1	~	9	Hyeok	In Progress

스프린트 백로그 일정 업데이트

이상적인 프로젝트 진행이라면 위의 스프린트 계획 (칠해진 부분)이 끝나는 다음날 남은 잡업이 0이 되어야한다.

만약 연장 작업이 되더라도 칠해진 블록의 범위는 변경하지 않고 남은 날짜만 계속 업데이트 해간다. 그러면 추후 결과가 계획 대비해서 얼마나 초과되어서 끝났는지를 확인할 수 있다.

 

진행 중에 고객 요건 변경이나 구현의 난이도에 의해 스케줄을 바꾸어야 할 경우가 있는데, 전통적인 스크럼 방법론에서는 스프린트가 한번 계획된 후에 될 수 있으면 스프린트 중간에는 바꾸지 못하도록 하는것이 좋다.

 

국내 SI 프로젝트와 같은 상황에서는 이를 매우 통제하기가 어려워서, 융통성 있게 태스크를 추가하거나 일정을 변경하는 것을 반영하는 것을 권장한다.

새로운 태스크가 생겼을 경우 스프린트 백로그에 넣고, 우선순위를 재조정하는 방식을 사용하는 것이 좋은데, 이러한 태스크는 개발성(구현, 설계, 테스트) 태스크인 경우가 많기 때문에, 스크럼 마스터나 프로젝트 리더가 이를 조정하는 것이 좋고, 기능 단위의 변화가 생겼을 경우 제품 오너를 통해서 우선순위를 재조정하고, 스프린트 계획을 재설계 하는 것이 좋다.

단, 새롭게 발생한 태스크가 있을 때 그만큼 다른 태스크에 대한 일정을 미루거나 우선순위 재조정을 전재로 해야한다.

 

번 다운 차트(Burn Down Chart)

스프린트 제품 백로그를 위와 같은 방법으로 업데이트하면 매일 남은 작업 일 수를 계산할 수 있는데, 이를 그래프로 표현한 것을 번 다운 차트라고 한다.

 

태스크 상태

다음으로, 각 태스크에 대해서 상태를 관리해야 한다. 위에서 보여준 스프린트 제품 백로그 상태 부분을 말하는데, 이 부분은 사실 매일 일일 스크럼 미팅을 하고 엑셀로 프로젝트를 관리하는 경우에는 크게 중요하지 않지만, 좀 더 전문화되고 정교한 태스크 관리 절차를 만들거나 시스템으로 구축하고자 할 때는 필수적인 부분이다.

 

시스템으로 구축할 경우, 해당 태스크를 일일 스크럼 때뿐만 아니라, 항상 상태를 업데이트해서 팀원이나 운영 조직간에 자주 의사소통을 할 수 있고, 저장된 상태나 값을 기반으로 여러가지 지표를 뽑아 낼 수 있다.

태스크 상태는 태스크의 상태 흐름에 따라 정의되는데, 이를 태스크 워크플로라고 한다. 태스크 워크플로는 최대한 단순해야 하며, 관리 지향적이기보다 실무 중심적이어야 한다.

또한, 워크플로가 적용되는 업무의 특성별로 잘 정의되어야 한다. ( 개발의 태스크 플로와 버그의 태스크 플로는 분명히 달라야 한다.)