스크럼 일기 1 – 역할
새해가 되어 스크럼마스터와 새 스크럼을 구상하면서 그동안 잘못해오던 것들이 몇 가지 드러났다. 작년에도 많은 교훈을 얻었는데 적어두지 못한게 아쉽던 터라, 올 해는 같은 실수를 반복하지 않도록 잘 적어두기로 했다.
프로덕트 오우너와 개발팀의 역할을 명확하게 하고 그에 맞는 정보를 줘야 한다.
좀 당연한 얘기라서 쑥스럽지만 ^^;; 일단 프로덕트 오우너(이하 오우너)란 우리말로는 “제품 책임자”. 제품의 스펙을 결정하고, 스펙 중에 우선순위를 결정해주는 사람이다. 개발팀은 당연히 제품 책임자에게 요청받은 스펙을 구현하는 사람들.
역할을 명확하게 하는 것이란?
다른 말로는 “책임”과 “권한”을 명확하게 하는 것. 예를 들면 아래와 같이,
- 오우너는 개발팀에게 A라는 스펙을 주고 구현할 책임을 준다
- 개발팀은 A라는 스펙을 어떻게 구현할지 결정할 권한을 갖는다
역할이 명확하지 않은 경우에 발생하는 현상
- 개발팀이 책임 이상의 것을 하거나, 요청받는 경우
- 개발팀이 A라는 스펙이 올바른 것인지 고민하고 있다
- 개발팀에게 A라는 스펙을 올바르게 수정하기를 요구한다
- 오우너가 책임 이상의 것을 하거나, 요청받는 경우
- 오우너가 구현 방법에 대해 일일이 관여한다
- 오우너에게 구현방법에 대해서 일일이 물어본다
- 책임이나 권한이 있는 것 같은데, 막상 정보가 부족하다
- 개발팀이 A라는 스펙을 개선하기에는 프로젝트의 비전, 사업 우선순위에 대한 정보가 부족하다.
해결책은?
- 개발팀이 A라는 스펙이 올바른가 고민하지 않기를 바란다면, 그 사실을 명확히 하고 합의한다.
- 개발팀이 일정부분 스펙을 수정해주기를 바란다면, 그 사실을 명확히 하고 필요한 정보를 준다.
- (위 그림의 파란박스에서)개발팀이 어느 높이까지 책임과 권한을 갖는지 명확히 하고 합의한다.
- 개발팀의 역할을 수행하는데 필요한 프로젝트의 목표, 비전, 가치, 우선순위와 같은 정보 제공한다.
- 개발팀이 구현 방법에 대해서 오우너에게 물어본다면
- 역할을 명확하게 해서 개발팀 스스로 판단할 권한이 있음을 주지시킨다.
- 혹은 판단하기에 충분한 정보를 주지 않은 것은 아닌지 확인한다.
현실에서는 알아차리기 힘들 수 있다
“오우너가 스펙을, 개발팀이 구현을”. 설명을 쉽게하려고 이렇게 말했지만 좀 더 원칙적으로 얘기하면 “오우너가 더 추상적인 스펙을, 개발팀이 더 구체적인 스펙을”이 되어서 현실에서는 구분이 어려울 수 있다.
스펙이 “폰트를 바꾸는 기능 추가”와 같이 유저 관점의 기술(記述 description)인 경우에는 구분이 명확하지만, 스펙이 “3가지 DB 지원”과 같이 기술(技術 technology)적인 경우에는 헷갈리기 쉽다. 그래서 라이브러리나 미들웨어 같이 제품을 쓰는 사람도 개발자고, 만드는 사람도 개발자인 경우에는 스펙과 구현의 선을 명확히 긋고 역할을 합의하는 일이 중요한 것 같다.
마무리
오우너가 자꾸 이상한 일을 시킨다거나, 개발팀이 원하는 일을 해오지 않는다거나 하는 문제가 생겼을때는 각자의 자질을 의심하기 보다는 역할을 명확히 합의했는지 확인해 볼 일이다.