샘플 – 38장

38. 정규 대면회의 시간을 가져라

“너는 회의를 열어야 해. 아주 많은 회의 말이야. 사실 우리는 일이 왜 끝나지 않는지 알아낼 때까지 더 많은 회의를 할 거야.”

 

개인적으로 회의를 싫어할지도 모르지만, 의사소통은 프로젝트 성공의 열쇠다. 고객과 이야기를 나누는 것뿐만이 아니라, 반드시 동료 개발자와 의사소통을 잘 해야 한다. 다른 사람이 무슨 일을 하는지 확실히 알고 싶을 것이다. 즉, 여러분이 시달렸던 문제의 해결책이 버니에게 있다면, 가급적 빨리 해결책을 알고 싶을 것이다. 그렇지 않나?

스탠드 업 미팅(스크럼(Scrum)에서 소개했고 XP에서 강조되었다)은 팀을 모으고, 모든 사람에게 정보를 제공하는 효과적인 방법이다. 이름이 암시하듯이, 스탠드 업 미팅에서 참석자는 앉는 게 허용되지 않는다. 이것은 회의를 짧게 유지하도록 해준다. 앉으면 너무나 편안해질 것이기 때문에, 결과적으로 회의는 오랫동안 진행되는 경향이 있다.

앤디에게 고객이 있었는데, 앤디와 데이브 토머스(Dave Thomas)는 스피커 폰을 통해서 원격으로 스탠드 업 미팅에 참석하였다. 어느 날 회의가 갑작스럽게 평소보다 두 배 더 걸리기 전까지는 모든 게 잘 되었다. 여러분이 짐작하듯이, 그들은 회의실로 이동해서 편안한 안락의자에 앉아버렸다.

착석 회의는 보통 더 길어진다. 대부분의 사람은 보통 일어서서 긴 대화를 계속하는 것을 좋아하지 않는다.

회의에 집중도를 높이기 위해서, 모든 사람은 아래 세 가지 질문에 대답하는 방식으로 보고 내용을 간단하게 하자.

 

  • 어제 내가 달성한 일은 무엇인가?
  • 오늘 계획한 일은 무엇인가?
  • 문제나 어려운 점은 무엇인가?

 

참석자마다 말할 수 있는 짧은 시간이 주어진다(약 2분). 장황하게 말하는 경향이 있는 사람을 돕기 위해서 타이머를 사용하면 좋을 것이다. 무언가 더 상세하게 논의하고 싶다면, 스탠드 업 미팅 이후에 적당한 사람과 모이자. (“데이터베이스에 대해서 프레드와 윌마하고 이야기해야 합니다.”라고 회의 동안 말하는 것은 좋다. 단 세부적인 이야기는 시작하지 말자.)

보통 스탠드 업 미팅은 모든 사람이 출근하는 날 일찍 열린다. 스탠드 업 미팅을 첫 번째 일로 계획하지 말자. 출근 지옥을 뚫고 왔는데 커피도 한 잔 하고, 신종 스팸 메일이나 음란 메일을 삭제할 시간도 사람들에게 주어야 한다. 점심 전에 적당한 분량의 일을 처리한 후에 회의를 가져야 하지만, 너무 일러서 모든 사람이 커피 부족 상태로 휘청거리는 모습을 보고 싶지 않을 것이다. 명목상의 출근 시간 이후 삼십 분에서 한 시간 정도가 좋다.

회의에 참석한 사람은 회의의 흐름을 유지하고 집중하기 위해서 다음 몇 가지 규칙을 따라야 한다. 즉 팀원인 개발자, 제품 소유주, 책임자만이 말할 수 있다(side tip에 있는 ‘돼지’와 ‘닭’우화를 살펴보자). 팀원은 질문 세 가지에 답하고 긴 토론에 들어가서는 안 된다(그러나 나중에 이야기 하도록 조정하는 것은 괜찮다). 관리자는 해결할 이슈 목록을 받아 적고, 질문 세 가지에 사람을 집중하게 하는 것 외에 대화를 이끌려고 시도해서는 안 된다.

돼지와 닭

스크럼(Scrum)에서는 팀원과 비 팀원의 역할을 돼지와 닭 이라고 이름 붙였다. 팀원은 돼지(자존심 접었다!)고 비 팀원(관리자, 지원, QA 등)은 닭이다. 이 용어는 농장의 동물이 모여서 식당을 연다는 우화에서 나왔다. 아침 메뉴로 베이컨과 계란 프라이를 내놓으려고 할 때, 닭은 단순히 계란을 하나 내며 참여하는 수준이지만, 돼지는 자기 살을 내어주는 헌신인 것이다.
오직‘돼지’만이 스크럼 스탠드 업 미팅에 참석하는 것이 허용된다.

스탠드 업 미팅은 많은 이익을 제공한다.

 

  • 스탠드 업 미팅은 집중하는 방식으로 하루를 시작하게 한다.
  • 개발자에게 어떤 문제가 있다면, 개발자는 이슈를 공공연하게 만들고 능동적으로 도움을 구할 기회를 얻는다.
  • 스탠드 업 미팅은 추가적인 도움이 필요한 분야를 결정하고 팀 리더나 관리자가 인력을 얻거나 재할당하도록 한다.
  • 스탠드 업 미팅은 프로젝트의 다른 분야에서 무엇이 진행되고 있는지 팀원이 인식하게 한다.
  • 스탠드 업 미팅은 다른 사람이 해결책을 갖고 있는 분야나 중복을 재빨리 파악하도록 해준다.
  • 스탠드 업 미팅은 코드와 아이디어 공유를 촉진해서 개발을 가속시킨다.
  • 스탠드 업 미팅은 앞으로 나아가게 서로 북돋는다. 즉, 다른 사람이 진행 상황을 보고하는 것을 봄으로써 우리 각자가 같은 일을 하도록 동기를 부여한다.

 

스탠드 업 미팅을 수행하는 것은 관리자의 승인(commitment)과 참여가 필요하다. 그렇지만, 팀의 리더 격인 개발자가 스탠드 업 미팅을 시작하는데 도움을 줄 수 있다. 개발자가 관리자를 참석시킬 수 없다면, 비공식적으로 개발자끼리 스탠드 업 미팅을 열 수 있다.

주방 타이머 사용하기

개발자 낸시 데비스(Nancy Davis)는 스탠드 업 미팅에 주방 타이머를 사용한 경험에 대해서 알려줬다.

“작년 크리스마스 때 동생이 제게 준 주방 타이머를 사용했죠. 주방 타이머는 돌아가는 도중엔 소리를 내지 않다가, 마지막에 단 한 번 작게‘딸칵’하고 울렸죠. 타이머가 울리면, 2분을 추가하고 다음 사람으로 넘어갔습니다. 때로는, 타이머를 잊어버리고 필요한 만큼 회의를 하지만, 우리는 대개 타이머에 충실했습니다.”

 

스탠드 업 미팅을 사용하자.

스탠드 업 미팅은 팀을 같은 곳에 둔다. 회의를 열성적이면서 짧고, 집중적으로 유지하자.

 

어떻게 느껴야 하는가?

스탠드 업 미팅이 기다려진다. 다른 사람이 무슨 일을 하고 있는지 잘 알 수 있고, 문제를 가져와 쉽게 열어놓도록 할 수 있다.

 

균형 유지하기
  • 회의는 개발 시간을 뺏기 때문에 시간의 투자에 대한 이익을 최대화해야 한다. 스탠드 업 미팅에 30분 이상을 보내서는 절대 안 되며, 십 분에서 십오 분이 현실적인 목표다.
  • 예약이 필요한 회의실을 사용한다면, 회의실을 한 시간 동안 예약해라. 이렇게 하면 십오 분 스탠드 업 미팅이 끝나고, 더 작은 회의를 위해 이 회의실을 즉시 사용할 기회가 생긴다.
  • 대부분의 팀은 매일 만나야 하지만, 작은 팀의 경우 지나치게 많을 것이다. 이틀에 한 번이나, 일주일에 두 번이면 충분할 것이다.
  • 보고하는 내용의 상세 수준을 주시하자. 회의 동안에 확실한 진척 상황을 보고해야 하지만, 낮은 수준의 상세 내용에 빠져서 꼼짝 못해서는 안된다. 예를 들어서, “로그온 화면을 작업하고 있습니다.”는 충분하지 않다.”로그온은 guest/guest의 사용자 이름과 비밀번호를 받아들이고 내일은 데이터베이스에 접속할 것입니다”가 상세 내용의 적당한 수준이다.
  • 짧은 회의를 유지하기 위한 중요한 요소는 기다리지 않고 바로 시작하는 것이다. 회의를 시작하기 위해서 기다리는데 시간을 낭비하지 말자.
  • 스탠드 업 미팅이 시간 낭비처럼 느껴진다면, 하나의 팀으로서 실제 활동하지 않기 때문이다. 이 점을 인식하는 한 그것이 반드시 나쁜 것은 아니다.