Posts tagged 스크럼 일기

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

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

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

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

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

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

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

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

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