팀의 생산성을 높이자 - 스크럼

막상 쓰려니 또 멍해지는 기분... 기승전결 이딴거 모른다.. 그냥 쓰는거다...


애자일을 아시나요? 낭비를 줄이고 반복적인 개발과 빠른 피드백을 통해 프로젝트를 성공으로 이끄는 개발방법론입니다. 여기 애자일 방법론 중의 하나인 스크럼이라는 것이 있습니다.

		스크럼 Scrum 켄 슈와버,마이크 비들 공저/박일,김기웅 공역
예스24 | 애드온2

제가 지금까지 해온 프로젝트는 윗분들이 설계해놓은 명세를 갖고 구현,개발을 쭈~욱 한 후 이를 QA 테스트팀에게 넘겨서 그에 따른 피드백을 받아 다시 작업하는 이른바 폭포수라 불리우는 개발방법으로 진행해왔습니다.
여기서 문제가 뭐냐? 윗분들이 문제를 모르는게 문제인거죠. 문제를 해결하는 것도 중요하지만 먼저 문제를 아는게 더 중요한거죠.
이런 폭포수 개발론으로 프로젝트를 진행하게 되면 일단 일을 개발자에게 맡긴 후 꽤 긴 시간동안 개발자는 혼자서 개발을 진행하게 됩니다. 물론 이런저런 얘기를 상급자 한테 할 수 있지만 문제는 마구 감추고 싶어지는 지라 이를 끝까지 안고 가게됩니다. 나중에 보고되서 호되게 욕먹으면 정신차리겠지만 말이죠..
암튼, 이번에 친구놈과 TDD 에 대한 이야기를 하면서 느낀거지만 빠른 피드백만큼 개발을 성공으로 이끄는게 없다는 생각에 이르렀습니다.

자~ 스크럼.
팀을 구성합니다. 이 팀은 프로젝트의 개발외에 어떤 것도 신경쓰지 않고 개발에만 집중하게 됩니다. 불필요한 작업들은 스크럼 마스터라는 리더가 처리하게 됩니다. 리더의 역할이 무엇이냐? 시다바리죠. 영화 친구의 대화같은 상황은 아니지만 '내가 니 시다바리가?' 라고 물으면 '야. 넌 저기 전화나 좀 받아줄래? 나 일에 집중해야하니까' 라고 말할 수 있는 분위기인거죠.
프로젝트는 일일 스크럼 회의를 통해 그날그날 한 일과 해야할 일, 방해요인들을 서로 말하고 스크럼 마스터는 방해요인을 제거합니다. 회의는 길지도 않습니다. 매일 아침 10~15분 정도만 하면 되죠.
그리고 30일 주기로 스프린트라는 기간을 둬서 이 안에 해야할 백로그(작업할 일과 우선순위)를 정해놓고 개발을 시작하죠. 기간이 끝나면 스프린트 기간 동안 만들어진 결과물(제품)을 갖고 고객과 미팅을 하고 피드백을 받고 이를 반복해 나갑니다. 다른 개발론 처럼 프로젝트 끝날때까지 뭐하나 결과물 없이 기다리는게 아니라 스프린트 기간동안 이를 계속 검토해가며 진행해나가는 겁니다.

요구사항과 설계에만 목숨 걸다가 프로젝트 끝날때까지 아무것도 없게 할 것인가? 한달한달 무조건 결과물을 내도록 할것인가?
선택이긴 한데. 일단 해야하는거죠. 뭐라도 나와야 말을 할거아닙니까? 후후

여기서 중요한 것 한가지는 개발자 역시도 할말 안할말 다 해야한다는 겁니다. 문제가 있으면 바로바로 말하고 개발하는데 필요한거 방해되는거 모두 말해야 합니다. 그렇게 해야 서로 의견도 공유가 되고(개발 지식도 공유 오호~) 말이죠. 그리고 스크럼 마스터는 무조건 방해요인을 제거해야합니다. 그게 스크럼 마스터의 역할이니까요. 개발자가 개발에 집중할 수 있도록 해주는거 이게 바로 그의 일입니다.

스크럼 한번 써볼까요? 책에서도 나오지만 물론 이것이 '야~ 우리 스크럼으로 진행하거든?!' 으로 끝나면 안된다는 거죠. 스크럼이라는 개발 방법론이 목표가 되어서는 안됩니다. 최종 목표는 프로젝트의 성공이니까요. 이런저런 개발론을 갖다쓰던간에 프로젝트는 성공해야 합니다.

제 인생에도 이를 적용해야겠어요. 목표를 정하고 스프린트 기간을 둬서 결과물을 내도록 하고.. 그러다보면 제 인생도 성공으로 가고 있지 않을까요?

마지막으로 책에서의 한 구절이 생각나네요...

'이게 코드와 무슨 관련이 있지?

방해요인을 모두 제거하고 목표에 집중해서 성공으로 가 봅시다!

스크럼 Scrum켄 슈와버,마이크 비들 상세보기