출처 : http://www.intelligentbee.com/blog/2015/02/20/should-you-do-scrum/
팀 프로젝트를 진행함에 있어 특정한 프로세스 없이 진행을 했을 때 비생산적이라는 것을 지속적으로 느끼고 있었고, 이번에 소멤 신촌, 강남 친구들의 스크럼 방식의 개발 진행에 느낀바가 있어 책 한권을 읽으며 스크럼에 대해 알고 이를 프로젝트에 적용해보고자 합니다.
일일 스크럼 회의
1. 따로 회의실을 잡지 않고
2. 일어선 채로 최대 15분을 넘기지 않고
3. 1)지난 일일 스크럼 회의 이후로 무엇을 했고, 2)다음 일일 스크럼 전까지 무엇을 할 계획이며, 3)무엇이 작업을 방해하고 있는가
- 리니지2 개발팀의 스크럼 중 -
" 스크럼이나 애자일이 팀의 목표가 되어 가는 건 아닌지를 항상 조심해야한다 "
" Commen sense isn't common 상식은 보편적이지 않다. "
" 스크럼을 한마디로 정의하면, "피드백을 좀더 일찍, 좀더 자주, 좀더 많이, 좀더 지속적으로 주고받자." 라고 할 수 있다 "
책에서는 스크럼이 단순하다고 말한다. 또한 전체 규칙을 설명하는데 10분이 안 걸리는 방법이라고 알려준다. 그러나, 스크럼의 철학과 "왜" 를 이해하는 데에는 10일이 걸릴수도 있고, 스크럼을 제대로 행하는 데에는 10주가 넘게 걸릴 수도 있다고 주의를 준다. 그럼에도 불구하고 스크럼은 간단하다고 얘기한다.
스크럼에 대한 간단한 소개
출처 : http://upload.wikimedia.org/wikipedia/commons/thumb/5/58/Scrum_process.svg/2000px-Scrum_process.svg.png
제품 백로그 ( Product Backlog )
먼저 시스템이 해결해야 하거나, 시스템에 포함되어야 할 모든 것, 즉 기능(Functionality), 특성(features)과 기술을 나열한 목록이 제품 백로그이다. 제품 백로그란, 제품의 모든 요구사항을 우선순위에 따라 나열한 목록을 말한다. 제품 백로그는 결코 확정되지 않는다. 오히려 제품과 함께 성장하고 진화한다. 제품 백로그에서 우선순위가 가장 높은 항목이 가장 필요한 항목이다. 누구나 제품 백로그의 내용들을 제안할 수 있다. 사용자, 고객, 영업 부서, 마케팅 부서, 고객 서비스 부서와 기술부서 모두 이 제품 백로그 항목을 제출할 수 있다.
그러나, 오직 제품 책임자만이 제품 백로그 항목들에 우선순위를 부여할 수 있다. 제품 책임자는 어느 것이 먼저 개발될 것인지를 사실상 결정한다.
스프린트 백로그 ( Sprint Backlog )
스크럼 팀들은 자기 조직적이며 완전히 자율적이다. 스크럼 팀들은 오직 그들이 속한 조직의 표준과 관행 그리고 그들이 선택한 제품 백로그에 의해서만 제약을 받는다. 선택한 제품 백로그를 어떻게 제품 증분 ( 아마도 제품 증분이라는 것이 스프린트 백로그를 의미하는 것 같다)으로 만들것인가는 전적으로 개발팀의 결정에 달려 있다. 팀은 해당 스프린트에서 수행할 태스크의 목록, 즉 스프린트 백로그를 관리한다.
스프린트 ( Sprint )
각 스크럼 팀에서 개발을 진행하는데, 해당 팀들은 30일의 반복주기를 설정하는데. 이를 스프린트라고 일컫는다. 스프린트동안에 개발 가능하다고 생각한 만큼의 제품 백로그를 선택한다. 매 스프린트의 끝에는 새로운 기능이 추가되어 실행 가능한 제품이 인도되어야 한다. 실제, 아키텍처와 설계는 첫 스프린트에서 완료되는 것이 아니라 여러 번의 스프린트를 거쳐야 서서히 드러나게 된다.
스크럼 마스터 ( Scrum Master )
스크럼이 잘 되기 위해서는 팀이 자발적이며 신념이 있어야 한다. 스프린트동안 관리자 즉, 스크럼 마스터는 팀원들이 스크럼의 실천법을 신천하도록 강제하고, 팀이 결정을 내리거나 혹은 필요한 자원을 얻을 수 있도록 돕는다. 스프린트 동안 팀은 팀 외부의 어느 누구에 의해서도 방해를 받거나 지시를 받아서는 안된다.
일일 스크럼 ( Daily Scrum )
스크럼 팀은 매일 일일 스크럼이라고 불리는 짤막한 현황 회의를 갖는다. 일일 스크럼에서 관리자는 진행 상황을 검토하고, 제거해야 하는 장애물을 확인한다. 일일 스크럼은 팀의 진척 정도를 확인할 수 있는 아주 멋진 방법이다.
스프린트를 마치며
팀은 스프린트 검토 회의에 관리자와 함께 모여 이번에 개발한 스프린트 백로그에 대해 검토한다. 각각의 스프린트 백로그( 제품 증분 ) 을 테스트하고 나면, 관리자는 대개 팀의 성과를 활용할 수 있도록 제품 백로그를 정리한다. 제품 백로그는 부분적으로 개발된 제품에 비추어 봤을 때 더 큰 의미를 갖는다. 일단, 제품 백로그가 안정되면 팀은 다음 스프린트에 다시 제품 백로그 중 가장 우선순위가 높은 항목들을 고른다. 이러한 일련의 과정을 반복하고 다시 스프린트를 완수한다. 이 순환 구조는 - 경험주의적인 관리 비용, 시간 그리고 기능과 품질을 바탕으로 평가해서 - 제품이 잠재적으로 릴리즈 가능하다고 판단이 들 때까지 계속된다. 이와 함께 제품의 릴리즈에 대비하여 릴리즈 스프린트를 계획한다.
스크럼은?
스크럼은 직설적이다.
스크럼은 부적절하고 성가신 관리 관행들을 날려버리고 오직 업무 그 자체만을 남겨둔다.
스크럼은 팀을 자유롭게 높아두고 업무에 집중하도록 한다.
스크럼은 개발자들로 하여금 업무에 집중해서 재빨리 고품질의 제품을 만들어 내도록 하는데 필요한 모든 관리 및 통제권을 제공한다.
출처 : http://www.codeproject.com/KB/architecture/scrum/diagram02.png
참고문헌 : 스크럼 : 팀의 생산성을 극대화 시키는 애자일 방법론, 켄 슈와버