본문 바로가기

Architect

스크럼 회의

스크럼 이라는 책을 읽어보면 스크럼 회의라는 것이 있다.
Agile을 실천하는 가장 쉬우면서도 효과는 큰 회의인데 다음과 같은 형식으로 이루어 진다.

# 스크럼 회의 하기 #
1. 따로 회의실을 잡지 않는다
2. 일어선 채로 15분을 넘지 않는다.
3. 어제한일, 오늘할일, 일을하면서 방해가 되는 것을 각자 이야기 한다.

스크럼 회의는 매우 간단하다.
어디서인가 Agile 관련 내용을 읽다가 이와 똑같은 방식으로 회의하는 것을 스탠딩 회의, 티타임 회의라고 했던것 같다.

내가 이 회의를 모 화장품 회사 홈페이지 개편때 사용했었다.
사실 이 회의를 처음 시작할때에는 이 회의의 근본 의도를 파악하지 못했기 때문에, 장황하게 설명하는 사람, 할말이 없는 사람, 타인의 작업 항목에 대해서 태클을 거는 사람, 모두 자신의 일인양 해결해 보고자 대안을 내는 사람등 다양했다.

그렇게 처음 몇번을 하고 났을때는 이런 생각이 들었다.
"아! 역시 관리라는 것은 참 힘든거구나.", "여전히 시간만 낭비하는거 같은 느낌인데?" 라고 말이다.

다음 회의때는 일단 회의를 진행해 나갈 스크럼 마스터가 필요하다는것을 알게 되었다.
스크럼 마스터의 역할은 다음과 같다.
1. 간단하게 자신의 어제한일, 오늘한일, 문제점을 유도할수 있도록 분위기를 만들어 주는것
2. 장황하게 설명되는 것이 있을경우 주의 환기
3. 각 개인의 문제점에 대해서 반드시 기억하고, 회의를 마치면 바로 해결할 수 있도록 개별적으로 관리
4. 회의를 통해서 전체 업무 진행도 이해하기

이런 스크럼 마스터의 역할들을 수행하면서 차츰 스크럼 회의가 자리를 잡게되고, 시간 낭비를 줄일수 있게 되었다.

스크럼 회의의 장점은 이런것 같다.
1. 프로젝트 진행 과정에서 자신의 현재 마일스톤을 매일매일 점검할수 잇다는것.
2. 프로젝트 개발 과정에서 발생하는 문제점을 바로 이슈화 할수 있다는 점 (이것은 매우 큰 효과를 발휘한다.)
3. 프로젝트 진행과 성과에 대해서 모두가 파악할 수 있는 시간이 마련된다는것
4. 문제점 발생시 해당 문제가 누구의 것인지 모든 팀원이 알수 있어 쉽게 뭍혀서 프로젝트 끝까지 그 문제가 진행되지 않게 주의를 줄수 잇다는점..
5. 매일 아침 화이팅 할수 있다는점(팀워크 향상)

사실 상단에 기술된 역할이나 장점 이외에도 많은 이점이 있을수 있다.

스크럼은 이렇게 간단하지만 강력한 효과를 발휘 한다.

스크럼 회의를 하면서 한가지 터득한 것은....
1. 매일 스크럼 회의를 할 필요는 없다는것. (주 2회 정도가 적당할때도 있다. 팀과 프로젝트 특성에 맞게 맞추어야 한다.)
2. 회의할 내용을 딱딱한 분위기에서 하기보다는 차한잔 하면서 하는것도 좋다. (사실 대부분의 중요한 회의는 담배피는 10분에서 이루어 진다 - 담배를 피지않는 나에게서는 그닥 좋은 것은 아니지만 말이다.)
3. 진행하고 있는 일이 현재 발표자가 하지 않아야 하는 일을 하고 있는지 파악하고 조정해 주어야 한다. (사실 다른사람이 우선권이 높다고 시켜서 하고 있다면, 프로젝트 팀의 정보전달 체계가 흔들리고 있음을 파악해야한다. - 이는 매우 위험한 현상이다.)
4. 문제점이 잇다면, 암기를 하던지 메모를 하던지해서 회의이후 반드시 그 문제를 해결해 주어야 한다. (사실 발표만 하고, 해결해주지 않을 바에야 회의를 뭣하러 하는가?. 그리고 문제점에 대한 미해결과 변명은 그사람이 다시는 자신의 문제를 공론화 하지 않게하는 가장 나쁜 일이 아닐까? - 주의)

마지막으로 "선택과 집중"이라는 말이 생각난다.
스크럼 회의는 선택과 집중의 회의라 할수 있다. 프로젝트상에서 흘러가는 많은 시간중에 짧은 15분에 집중해서 프로젝트 사항을 모든 팀원이 공유 할 수 있다.

회의라는 명목하에 버려지는 시간.. 그시간에 한줄이라도 더 코딩해서 쩜 쉬자~..

'Architect' 카테고리의 다른 글

스크럼(Scrum)의 스프린트(Sprint), XP의 스토리(Story)  (1) 2009.10.05
Eclipse plugins for Maven  (0) 2008.10.23
Pratical Java 기본정의  (1) 2008.10.15
리스크관리 개요  (0) 2008.07.17
Loosed Coupling 을 잘 모르는 사람.  (0) 2008.07.02