Altruistic Programmer's Blog (KR)

스크럼과 XP를 쓴 아저씨가 블로그에 공개한 버전과 그 후에 내용이 추가되어 InfoQ에 올라간 버전이 있음.

 

블로그 버전을 오늘 읽어봤는데 스크럼에 익숙한 상태에서 간판에 대한 이미지를 얻는데 큰 도움이 되었다.

 

자격증을 가진 스크럼 마스터가 있는 것도 아니고 기존의 조직 체계도 있다보니 한 사람이 여러 역할을 맡을 수 밖에 없다. 우리 팀장님은 실장님, 팀장님, 프로덕트 오우너, 경력많은 개발자(조언자) 역할을 해야하고, 노예형 스크럼 마스터는 개발자 역할을 병행해야 한다.

그러다보니 지금 “경력많은 개발자”의 모자를 쓰고 조언을 해주는 것인지, “프로덕트 오우너”의 모자를 쓰고 요청을 하는 것인지 오해가 생기기 쉽다. 이렇게 설계하는게 좋았다라는 경험을 말해주는 것 뿐인데, 명령으로 받아들여 프로덕트 백로그에도 없는 일을 열심히 하고 있는 불상사가 생길 수도 있다.

지금 어떤 모자를 쓰고서 말하는 것인지 오해하지 않도록 서로 신경 쓸 필요가 있다.

개발팀에게 전달되는 요구사항이나 스펙이 완벽하지 않다고 불만을 가질 일이 아니다. 좋은 설계를 반복없이 한 번에 만들어 낼 수 없는 것처럼 좋은 프로덕트 로그도 한 번에 만들어 낼 수 없다.

보통 고객이란 불특정 다수이므로 완벽한 요구사항을 건네줄 사람이 있는 것도 아니고, 개발 도중에도 시장환경이나 조직의 상황이 계속 변하므로 스펙이나 우선순위 조정이 불가피하고, 기술적인 한계나 복잡성에도 영향을 받는데 이는 개발팀이 연구, 조사, 스파이크 같은 것을 해봐야 알 수 있는 것이라 초기에는 예상하기 힘들다. 이런 이유들로 처음부터 완벽한 프로덕트 로그를 만드는 것은 어렵다.

지난 글에서는 오우너와 개발팀의 역할을 명확히 나눠야 한다고 했지만, 기술적인 한계, 기술의 장단점과 같이 오우너가 프로덕트 로그를 개선하는 것을 돕기 위해서 개발팀이 오우너에게 제공해야 하는 정보도 있다. 다시 말해 개발팀도 좋은 프로덕트 로그를 만드는 일에 일정 부분 공헌할 필요가 있다는 얘기. (스프린트 준비회의에서 많은 대화가 필요하다.)

프로덕트 로그가 완벽하지 않다거나, 자주 변한다고 투덜대지 말자.

새해가 되어 스크럼마스터와 새 스크럼을 구상하면서 그동안 잘못해오던 것들이 몇 가지 드러났다. 작년에도 많은 교훈을 얻었는데 적어두지 못한게 아쉽던 터라, 올 해는 같은 실수를 반복하지 않도록 잘 적어두기로 했다.

좀 당연한 얘기라서 쑥스럽지만 ^^;;  일단 프로덕트 오우너(이하 오우너)란 우리말로는 “제품 책임자”. 제품의 스펙을 결정하고, 스펙 중에 우선순위를 결정해주는 사람이다. 개발팀은 당연히 제품 책임자에게 요청받은 스펙을 구현하는 사람들.

다른 말로는 “책임”과 “권한”을 명확하게 하는 것. 예를 들면 아래와 같이,

“오우너가 스펙을, 개발팀이 구현을”. 설명을 쉽게하려고 이렇게 말했지만 좀 더 원칙적으로 얘기하면 “오우너가 더 추상적인 스펙을, 개발팀이 더 구체적인 스펙을”이 되어서 현실에서는 구분이 어려울 수 있다.

스펙이 “폰트를 바꾸는 기능 추가”와 같이 유저 관점의 기술(記述 description)인 경우에는 구분이 명확하지만, 스펙이 “3가지 DB 지원”과 같이 기술(技術 technology)적인 경우에는 헷갈리기 쉽다. 그래서 라이브러리나 미들웨어 같이 제품을 쓰는 사람도 개발자고, 만드는 사람도 개발자인 경우에는 스펙과 구현의 선을 명확히 긋고 역할을 합의하는 일이 중요한 것 같다.

오우너가 자꾸 이상한 일을 시킨다거나, 개발팀이 원하는 일을 해오지 않는다거나 하는 문제가 생겼을때는 각자의 자질을 의심하기 보다는 역할을 명확히 합의했는지 확인해 볼 일이다.

올해 하반기 6개월동안 스크럼으로 프로젝트를 진행했습니다. 온라인 게임을 위한 라이브러리를 만드는 프로젝트였고, 개발자는 한국인이 4분, 일본인이 1분 참가했네요.

회사에서는 개인별 성과평가를 원하는데, 스크럼에서는 평가와 관련된 가이드가 적어서 고민이었습니다. 개인별 성과를 평가한다는 것의 의미, 목표, 효과는 스크럼의 철학과는 반대되는 것이었지요. (이 부분은 아래 부록에서 설명) 그래도 왠만한 회사에서는 개인별 성과평가를 원할테니 선배님들의 노하우가 있지 않을까하고 Xper 뉴스 그룹에도 질문을 드렸습니다.

어쨌든 반기가 시작하기 전에는 평가방식을 공유, 합의할 필요가 있었으니, 아래와 같이 정해봤습니다.

모두가 같은 평가를 받는 것은 너무나 아름다운 시나리오라는 생각이 들었습니다. 개발자분들이 싫어하지 않을까 걱정했지만 모두들 아무런 이견없이 잘 받아들여 주셨습니다. 착하고 능력있고 잘생긴 분들을 만난 제 복이라고 생각해야겠지요. ㅎㅎ

MVP를 뽑는 것은 혹시나 있을지 모르는 어뷰징, 혹은 사기저하를 방지하기 위한 장치였습니다. 평가방식의 허점을 노려서 놀고먹는 개발자가 생기거나, 엄청난 공헌을 한 개발자에게 실망을 안겨주는 상황을 막아보자는 의도였습니다.

2009년이 저물고 평가의 시간이 돌아왔습니다. 이제와서 돌이켜보니 모두 동일한 평가를 받기로 한 것은 참 잘한 일이었습니다. 내 일, 네 일 가리지 않고 모두가 다같이 열심히 해왔기 때문이지요. 누가 더 잘했고, 누가 더 못했고를 따지기에는 사람과 사람의 역학관계가 너무나 복잡하다는 생각이 들었습니다.

설사 어뷰징이 일어나서 누군가 팀에 폐를 끼쳤다고 해도, 이런 평가 방식 때문은 아니라는 걸 깨달았습니다. 기존의 평가방식이 반년을 돌이켜보며 누구는 잘했으니까 칭찬해주고 누구는 못했으니까 야단치는 식이었다면, 스크럼의 방식은 잘못한 그 시점에 피드백을 주고 잘 할 수 있도록 격려해주는 식입니다. 다시 말해, 잘못하는 것 지켜보다가 나중에 혼내는게 아니라, 바로 지적해주고 올바른 방향으로 이끌어 주는 식입니다. 반년 후에 모두가 칭찬받도록 만드는 방법입니다.

그래서인지 MVP를 뽑는 것은 괜히했다는 생각이 들었습니다. 다들 열심히 했으니 MVP라고 부를만큼 눈에 띄게 공헌한 개발자도 없을뿐더러, 이런 상황에서 도토리 키재기로 1등을 뽑는게 팀웍을 훼손할 수도 있겠다 싶었습니다.

MVP 선출방식을 미리 정해두지 않았다는 점도 큰 실수였습니다. 평가 시즌이 되어서 평가 기준을 바꾸는 건 말이 안되는 일이니까요. 그래도 어찌어찌 논의를 통해서 선출방식을 정하고 투표를 진행했는데, 신기하게도 5명 모두 동률로 1등이 되어서 모두가 MVP가 되는 사상초유(처음 했으니까요-_-;;)의 사태가 발생했습니다. 다행이 큰 출혈없이 MVP 투표를 마감할 수 있었습니다.

역량레벨은 회사에서 각 개인별 역량을 정의해 놓은 레벨입니다. 회사마다 이름은 달라도 이와 비슷한 시스템이 있어서 연봉 테이블에 영향을 준다던지 하고 있지요.

똑같은 일을 해내더라도 역량레벨이 낮은 사람은 더 높은 평가를 받아야 한다던가, 성과평가가 역량레벨 재조정의 근거자료로 쓰인다던가, 실제 역량에 맞지않는 역량레벨을 가지고 있다던가 하는 복합적인 문제가 있습니다.

스크럼 마스터를 대상으로 작성된 글이지만 스크럼의 철학과 기존의 평가 시스템의 충돌을 이해하는데 많은 도움이 되었습니다. 여기서 간단히 내용을 소개하고, 제 견해를 살짝 붙여보겠습니다.

스크럼 책을 처음 읽고 팀에 소개하기 위해서 만들었던 초간단 PT입니다. 조금 꾸질꾸질하지만 참조해주세요~