팀파운데션을 이용하여 스크럼 방법론을 적용하여 프로젝트를 진행하는 시뮬레이션을 해볼까 합니다.
저도 팀파운데션과 스크럼 둘 다 낯선 데요 ㅡ.-;;
그냥 가볍게 팀파운데이션을 스크럼으로 진행하는 연습을 해보겠습니다.
그전에 스크럼(Scrum)이 무엇인지 알아봅시다.
프로그램을 개발하는 것을 건물을 짓는 것에 비유하곤 합니다.
이 두 가지의 가장 큰 차이는 진행사항이 눈으로 보이느냐 보이지 않느냐의 차이죠.
일반적인 프로그램의 개발주기에서는 프로그램이 70% 이상 완료되었을 때쯤이 되어야 고객이 처음으로 그럴싸한 상태의 프로그램을 보게 됩니다.(케바케긴 하죠;;)
그러다 보니 고객의 요구사항 반영이나 프로젝트가 제대로 가고 있는지 등의 많은 문제가 일어납니다.
이런 리스크를 관리하기 위해 방법론을 '소프트웨어 개발 방법론'이라고 합니다.
팀파운데이션에서는 내장되어있는 몇 가지 방법론이 있는데 그중 하나가 스크럼입니다.
이 포스팅에서는 개발 방법론 중에 하나인 스크럼(Scrum)을 알아보겠습니다.
1.스크럼이란?
개발 방법론에서 스크럼 방식은 스프린트(Sprint)라는 주기를 일정시간(30일)으로 잡아 반복하며 주기가 끝날때 마다 직접 테스트가 가능한 프로그램을 제공하는 방식입니다.
(참고 : 위키백과 - 스크럼 (애자일 개발 프로세스))
위키에는 한주기가 30일이라고 나와 있지만 프로젝트성격이나 인력등을 생각해서 더 짧게잡거나 더길게 잡을수도 있습니다.
사용자의 요구사항을 제품 백로그(Product Backlog)라고 합니다.
이 백로그를 스프린트 백로그(Sprint Backlog)단위로 잘라서 스프린트(Sprint)를 진행하여 프로젝트를 완성합니다.
스크럼방식의 가장큰 장점은 주기마다 '실행 가능한 제품(shippable product)'이 나오기 때문에 클라이언트와 말싸움(?)하기 좋다는 점입니다.
일단 눈에 보이는 것이 있으니 클라이언트와 의사소통이 쉽습니다.
(필드에서는 클라이언트와 의사소통만큼 중요한게 없음 ㅡ.-;;)
단점으로는 주기가 끝나는 시점에서 고객이나 프로젝트 매니저가 테스트 가능한 상태로 만들어야 하기 때문에 추가작업이 필요할 수 있습니다.
상황에 따라서 '일일 스크럼 회의(Daily Scrum Meeting)' 때문에 오전을 날려먹을 수도 있죠-_-;
회의시간 문제는 각 팀이 알아서 줄여야 할 문제이긴 하지만 쓸데없이 길어지는 일이 다반사라 좀 훈련이 필요합니다. ㅎㅎㅎ
설명만 보면 '나선 모형(Spiral Model) 개발 방법론'과 비슷한데 나선모형과는 달리 주기가 끝나는 시점에서 중단하지 않고 다음주기로 넘어갑니다.
(나선 모형에서는 버그를 다음 주기로 넘기지 않습니다.)
2.스크럼 구조
스크럼을 한장의 그림으로 표현하자면 다음과 같습니다.
스프린트가 핵심이죠.
3. 스크럼의 진행단계
스크럼의 각각의 단계를 살펴 보겠습니다.
3-1. 제품 백로그(Product Backlog)
제품백로그는 사용자가 요구하는 제품의 기능을 의미합니다.
사용자와의 미팅을 통해 제품백로그를 완성해야 하죠.
개발이 시작되어도 백로그가 수정될 수 있습니다.(보통은 한주기가 끝날때까지 백로그를 수정하지 않습니다.)
3-2. 스프린트 계획 회의(Sprint Planning Meeting)
스프린트 목표와 스프린트 백로그를 계획하는 회의입니다.
제품 백로그를 분석하여 스프린트 주기에 맞게 계발계획을 세우는 회의입니다.
3-3. 스프린트(Sprint)
스프린트는 계발 계획의 1주기를 말합니다.
스프린트 계획 회의에서 1주기의 기간과 목표등을 정합니다.
테스트로만 1주기를 채워도 상관없죠.
3-3-1. 스프린트 백로그(Sprint Backlog)
각각의 스프린트 주기에 해야 할 목표를 위한 작업목록입니다.
스프린트 계획 회의에서 작성하게 됩니다.
스프린트 주기가 완료될 때쯤이면 작업목록에 있는 내용이 완료되어야 하죠.
3-3-2. 일일 스크럼 회의(Daily Scrum Meeting)
스프린트 백로그를 잘 완수하고 있는지 확인하는 회의입니다.
짧게 진행상황 체크만 하는 회의입니다.
3-3-3. 실행 가능 제품(Shiooable Product)
스크럼이 완료되면 요번 주기의 스프린트 목표가 완료됩니다.
'실행 가능 제품'은 목표가 완료됐는지 확인하기 위한 결과물을 말합니다.
이 제품의 수준을 어느 정도를 기준을 잡을지는 회의를 통해서 미리 결정해야 합니다.
단순히 기능구현만 있을 수 있고 폭포수 모형처럼 버그 하나 없이 완벽해야 할 수도 있죠.
3-4. 완료된 제품
모든 주기가 끝나면 제품 백로그와 가장 유사한 제품이 완성 됩니다.
마무리
개발 방법론이라는건 진리가 아닙니다.
방법론이라는것은 이러한 방법도 있다는 이론이죠.
이것을 자신이나 프로젝트의 상황에 맞게 수정하거나 재창조 할 필요가 있습니다.
가끔 프로젝트의 상황이나 규모는 생각하지 않고 무리하게 방법론을 적용하여 효과를 못보거나 오이려 악영향을 받는 경우도 있습니다.
프로잭트에 맞고 다루기 쉬운 방법론을 적용하는것이 모두에게 좋은 것이죠 ㅎㅎㅎ
이렇게 간단하게 스크럼에 대해서 알아 봤습니다.
깊게 들어가면 한도 끝도 없는 게 개발 방법론이라 간단하게 썼습니다;;
다음부터는 이 스크럼을 가지고 팀파운데이션을 연습해 봅시다.
같이 읽으면 좋은 글
