사내 품질 관련 포럼에서 우리 파트 동료가 스크럼 사례발표를 했다. 어쨌거나 지금 우리 파트가 속한 그룹이 ‘품질’ 그룹이기 때문에 발표하게 되었는데, 포럼에 참석하신 분들이 보기에는 처음 들어보는 스크럼이란 개발 프로세스 같은 활동이 품질과 무슨 관계이길래 발표하나 싶었나보다.
발표가 끝나고 나온 첫 질문 “방금 발표하신 스크럼이 품질하고 무슨 상관이죠?” 였다. 어쨌거나 스크럼이 품질을 직접적으로 언급하고 있는 것은 아니니 충분히 이해가는 질문이다.
“스크럼을 도입하면 품질이 좋아지나요?”
그러고 보면 스크럼이 보장해주는 것은 거의 없는 것이나 다름없다. “스크럼과 XP”에서처럼 대개의 성공적인 스크럼 팀은 XP에서 강조하는 프랙티스들을 접목하고 있거나 자신들만의 방법들을 가지고 있다지만 어디까지나 권고 사항이지 스크럼이 명시적으로 언급하는 활동은 3가지 미팅 밖에는 없다. 그 밖의 것들은 팀이 결정할 사항이다.
스크럼이 잘 굴러가지 않는 경우를 살펴보면 원인이 여러가지 있겠지만 엉망인 코드베이스도 주요 원인 중 하나이다. 계획 세운 것이 틀어지는 첫번째 이유가 바로 ‘디버깅’이기 때문이다. 일단 디버깅이 시작되면 해당 태스크 항목(스프린트 백로그 아이템)은 언제 끝날지 알 수 없다.
현재 진행 중인 스크럼 팀만 보더라도 디버깅 등으로 인해 스프린트 목표 달성에 실패한 첫번째 스프린트를 회고하는 자리에서 ’1일 1시간 짝프로그래밍’을 하자는 의견이 도출되었다. 두번째 스프린트에서는 Unit test 환경을 설정하고 Test case 를 추가하는 것이 백로그 아이템에 포함되어 있다.
스크럼 실패의 주요 원인은 낮은 품질이고, 성공적인 스크럼 팀들을 보면 고품질의 제품/코드를 위한 프랙티스들을 병행하고 있다는 점을 보면, 스크럼을 도입이 품질 향상을 가져올 것으로 기대할 수 있다.
정리하자면, 스크럼은 팀 자발적인 품질 활동을 촉발하여 내적품질 향상을 꾀하고 결과적으로 제품 품질의 향상을 가져온다.
우리 그룹에서는 Unit Test를 개발 단계로 넣었습니다. 전혀 애먼 개념으로 사용되고 있죠. 단계를 통과해야지 QA에 넣을 수 있다나… 그러더군요..ㅎㅎ