매일 스크럼을 활용하여 프로젝트를 운영해 나가면서 느끼게 되는 점들이 있습니다.

전반적인 관점에서 보면 스크럼을 제대로 적용하고 있느냐 나아가 스크럼이나 애자일프로세스를 사용하고 있느냐는 크게 문제가 아닐 수 있습니다. 프로젝트의 방향타를 잡고 있는 선장과 그 배를 실제로 움직이는 선원들이 얼마나 하나로 뭉쳐져 있느냐, 일을 통해 얼마나 즐거움을 느끼느냐(일하는 분위기가 즐거운 것일수도 있지만 매일매일 발전하는 스스로를 볼 때 느끼는 자부심측면이 더 강합니다), 옆의 동료들이 얼마나 자신들의 업무에 몰입하고 있으며 진지한가 등이 실제적인 성공요소라고 생각합니다.

문제는 그러한 것들의 요소중에 많은 부분이 프로세스나 방법론으로 만들어지기는 어렵다는 것입니다.(특정 방법론들이 도움을 주기는 하지만 그럴 자세가 되어 있는 사람들이 우선 있어야 한다는 전제가 있습니다) 서로 교감하고 있지 않은 사이의 개발자들 혹은 개발자-관리자 사이에서 Daily Scrum을 한다고 저절로 모든 문제가 해결되지 않습니다. 오히려 개발자들의 시간이 더 낭비되고 더 많이 체크당한다는 피해의식에 사로잡히기 쉽습니다.

사실 현실세계에서는 7~8명의 팀을 만들면 거의 항상 1명 정도는 문제가 되는 인원이 생깁니다. 그 사람이 마침 Project Leader인 경우도 있고(그럼 상대적으로 고통의 시간이 줄어들고 빨리 망하게 됩니다) 모든 팀회의에서 드러내지 않고 패배의식을 전파하는 팀원인 경우도 있습니다. 방법론이나 프로세스가 그러한 1명의 어려움을 쉽게 극복하게 도와주면 좋겠지만 무슨 방법을 쓰던 그 문제가 되는 인원으로 인하여 전체적인 퍼포먼스나 팀 분위기, 팀 비젼에 대한 공유가 어려워지고 목표달성이 어렵게 됩니다.

너무도 당연한 이야기라서 무슨 방법론이나 프로세스, 철학의 근처도 못가지만 제가 지금까지 체험한 바로는 높은 Intelligence를 가진, 서로 신뢰할 수 있고 존경할 수 있을 정도로 믿음이 가는 사람들로만 팀이 구성된다면 심지어 폭포수형 방법론을 채택하더라도 실제로 동작하는 것은 그 방법론을 처한 상황에 최적화하여 사용하고 있을 것입니다. 왜냐하면 그러한 사람들의 집합이라면 본인들이 처한 상황을 그대로 받아들이는 것이 아니라 개선시킬려고 끊임없이 고민하고 노력할 것이며 목표를 달성하는 데 가장 어울리는 방법이라면 굳이 무슨 무슨 방법론에 그다지 구애받지 않을 충분한 집단지성이 발휘될 것이기 때문입니다.

실용주의 프로그래머에서 제시한 많은 팁이나 XP나 스크럼같은 애자일 방법론, 각종 Spring이나 Ruby on Rails같은 개발Framework들은 그러한 집단지성이 성과를 Maximazation할 수 있도록 도와주는 타인들의 공통적인 경험이나 Tool로써 사용될 수 있습니다.

책을 번역하면서 우려되는 바는 혹시 우리가 지금까지 써온 방법으로는 잘 안되었으니 "스크럼"이라는 새 방식을 쓰면 좀더 좋아질까하는 방식으로 접근할까봐 걱정됩니다. 체중을 감량하지 않으면 아무리 다른 색깔의 옷을 입어도 멋있게 보이지 않습니다. 툴이나 방법론 등에 책임을 전가하기 보다는 자신의 팀, 더 나아가 자신을 되돌아보면서 내가, 우리가 이 소프트웨어 개발이라는 업무에 얼마나 진지한지 물어볼 필요가 있습니다. 이런 근본적인 문제가 어느 정도 해결된 후에야 여러 방법론이나 툴이 도움이 될 것입니다.

Agile Process, SCRUM!!! 호기심 탐구 결과.

Apple의 위대함은 기존에 존재하지 않았던 신기술을 발명하는데 있는 것이 아니라 이미 남들이 제안해둔 신기술들을 전혀 새로운 시각에서 해석하여 사용자에게 색다른 경험을 안겨준다는데 있다.

Apple II는 논외로 하더라도 Macintosh라는 이름을 달고 1984년 세상에 나온 것을 보자.

그전에 PC가 존재하지 않았던 것도 아니고 마우스나 키보드가 처음 선보여진 것도 아니건만 조지 오엘의 1984만큼이나충격적인 디자인이었다. 더 충격적이었던 것은 하드웨어의 미니멀리즘뿐만 아니라 OS에도 그러한 사상이 일관되게 적용되어 있다는사실이다.

1984년 Mac OS

 

Mac OS 7

Mac OS X Tiger

 

이러한 점들은 iPod (역시 시장 최초의 MP3 Player는 아니었다)이나 iPhone에도 고스란히 이어지고 있다.

Apple의 모든 Product에 대한 정보에 대해서 일목요연하게 정리한 위키피디아 페이지는 다음과 같다.

http://en.wikipedia.org/wiki/List_of_Apple_Macintosh_models_by_case_type

본 블로그의 성격과는 잘 맞지 않을 수도 있지만 소프트웨어 공학도 미학적인 측면이 많이 강조될 필요가 있습니다. (특히 아키텍처 측면에서) 미적 감각을 개발한다는 취지에서 글을 올리게되었습니다.

제가 볼때는 렉서스는 결함없는 차는 잘 만들지 몰라도 무언가 tasty한 차를 만드는 능력은 닛산의 인피니티에 비해 떨어지는 것은 사실입니다. G37 Coupe와 IS250을 비교해보면 극명하게 드러납니다.

단지 스포츠 "카"라는 것이 아니라 "머쉰"으로써의 존재감을 그동안 렉서스는 보여주지 못하고 있었다고 생각합니다. 하지만 이번 도쿄 모터쇼에서는 인피티니의 곡선에 도전하는 듯한 컨셉트 카들을 선보이고 있습니다.

LF-A는 이전부터 몇몇 렌더링이 유출되었던, 관심을 모으는 모델이며 특히 사이드미러를 거의 없앤 것과 박력있는 뒷모습이 인피니티를 위협할 것 같습니다. 양산형에서도 같은 컨셉이 유지될 지 흥미를 자아내고 있습니다.

개인적으로 SUV는 그다지 흥미를 가지지 못하지만 Interior나 Head Lamp의 디자인이 특이해서 같이 이미지를 올립니다.

LF-A 2인용 스포츠카 타입입니다.
LF-Xh는 SUV타입인데 아마도 하이브리드 엔진인듯합니다.

예전에는 프로젝트가 시작하기 전에 요구사항을 모두 "수집"하고 "분석"하여 "정리"한 후 "확정"하는 것을 당연한 일로 받아들였다. 물론 real world에서는 그렇게 되는 프로젝트는 내가 수행하는 프로젝트는 물론 주위에서도, 아니면 내가 아는 모든 소프트웨어 개발 프로젝트에서도 거의 찾아보기 어렵다는 사실을 깨달게 되었다. CMMI적으로는 일단 "확정"하고 "변경관리"를 하면 되지 않느냐라고 할 수 있으나 고객이나 개발자입장에서 "변경관리"를 수행하는 것은 상당한 고통이 따르기 마련이다(개인적으로 GM과 일년 넘게 변경관리에 목을 매고 수행해본 결과이다)

결국 고객은 완성된 제품을 보고 써본 후에나 이제 제대로된 요구사항을 내놓수 있다는 사실을 인정해야 했다. 만약 그것이 fact라면 우리가 해야 할 행동은 우직하게 계속 요구사항을 프로젝트 시작단계에서 최대한 많이 확정지으려할 것이 아니라 최대한 빠른 주기로 고객에게 보여주면서 요구사항이 자연스럽게 흘러나오고 stable해질 수 있도록 돕는 것이 더 자연스러운 선택이라고 할 수 있을 것이다.

아래는 현재 번역하고 있는 스크럼 책에서 슈와버가 자신의 경험을 들어서 이 부분에 대해 설명하고 있는 부분을 인용해보았다:

내가소프트웨어 개발을 시작했을 당시에는 고객 참여와 협업은 전혀 문제가 되지 않았었다. 60년대에는 컴퓨터가그다지 강력하지 못해서 사용자도 적었고 응용프로그램도 단순했으며 단계별로 마일스톤을 가져간다는 개념도 아직 알려지지 않을 때였다. 나는 하루나 이틀짜리 짧은 반복주기를 사용하고 있었다. 나는 고객과만나서 함께 고객이 원하는 바를 종이에 스케치하곤 했다. 우리는 내가 완전히 이해할 수 있을 때까지의견을 서로 주고받았다. 그리고 난 뒤 나는 내 책상으로 돌아가 솔루션을 설계하고 코딩한 후 펀치카드에천공을 하고 천공한 카드로 컴파일을 했다. 컴파일과 링크가 성공적으로 끝나면 나는 시험용 데이터를 입력해서동작시켜보았다. 그런 다음 나는 고객에게 돌아가 “이것이당신이 원하던 것입니까?”하고 물었다. 우리는 그때 미처이렇게 할 수 있는 것이 천국이라는 사실을 깨닫지 못했다.

 

응용프로그램과기술이 점점 복잡해짐에 따라 프로젝트에 관여하는 이해관계자도 늘어났으며 이렇게 증가된 참여자들간의 의사소통을 조정하기 위해 여러 실천 방법이 도입되었다. 예를 들어, 많은 이해관계자들이 참여하고 있으므로 우리는 개발을시작하기 전에 그들의 요구사항을 모두 수집하기 시작했다. 우리는 시스템은 그들 각각의 요구사항 모두를반영하여 구축되어야 한다고 느꼈다. 문서는 의사소통을 위한 매체로는 적당치 못했으므로 우리는 서로 의사소통하기위해 그림을 사용하기 시작했으며 이 그림들을 글로써 보완했다. 하지만 그림은 부정확했으므로 우리는 그림을형식화시켜 표현할 수 있는 모델링 기술을 개발했다. 각각의 단계는 이해관계자와 개발자 사이에 쐐기를박는 셈이었다. 우리는 얼굴을 맞대고 하는 의사소통에서 문서기반의 의사소통으로 가버렸다. 우리는 신속한 왕복에서 길고 지루한 요구사항 수집 단계로 가버렸다. 우리는단순한 언어에서 애매하면서도 고도로 상세화된 산출물로 가버렸다.

 

되돌아보면, 우리가 소프트웨어 엔지니어링의 실천 방법을 개선시킬수록 우리는 관련자와 개발자간의 거리를 점점 넓히고 있는셈이었다. 이렇게 소원해지고 있던 관계에 마지막으로 종지부를 찍은 것이 바로 순차적 개발의 모든 단점을담고 있었던 폭포수 방법론(waterfallmethodology)의 도입이었다. 폭포수 방법론에서는 모든 요구사항을 모은 뒤설계를 만들어 내며, 그 다음에 코드를 작성한다. 그 뒤테스트를 개발하고 실행한 뒤 마지막으로 시스템을 설치하게 된다. 이러한 각 단계 사이에는 검토 회의가존재한다. 관련자들은 이 검토 회의에 초청받아 그때까지의 진척사항에 대해 검토하게 된다. 이 회의에서 관리자와 개발자들은 고객에게 다음과 같이 물어보게 된다. “우리가수집한 요구사항과 이를 기반으로 구축한 모델이 당신이 원하는 것을 정확하게 모두 나타내고 있습니까? 만약당신이 그렇다고 대답한다면 그 뒤부터는 이에 대해 변경하는 것은 비용이 증가하게 될 것입니다!” 대화에서알 수 있듯이 이것은 고객과 개발자간의 계약을 나타낸다. 이 시점까지 서로간의 협업은 거의 없었는데다짜고짜 계약하는 자리에서 “만약 내가 당신에게 보여준 것이 당신이 원하는 것에 대한 완전한 설명이라면일을 진행하도록 합시다. 하지만 만약 당신이 동의할 수 없다면 당신이 포기할 때까지 요구사항을 개발하는일을 계속할 겁니다!”라고 말하는 셈이었다.

(중략)

"스크럼으로 애자일 프로젝트 관리하기"(가칭, 번역 중)

부록 A: 규칙

스크럼마스터는 프로젝트에 관련된 모두가 스크럼의 규칙을 준수하도록 할 책임이 있다. (“닭”이나 “돼지” 모두에게 적용된다)[1] 이 규칙들은 스크럼에 참여하는 누구라도 게임의 규칙을 알 수 있도록 스크럼 프로세스를 한데 묶는 역할을 한다. 만약 이 규칙들이 강제되지 않는다면 사람들은 도대체 무엇을 해야 되는지 알아내느라고 쓸데없이 시간을 낭비하게 될 것이다. 규칙들에 대해 논쟁이 벌어지게 되면 사람들은 그 논쟁의 해결을 기다리느라고 시간을 낭비하게 된다. 이 규칙들은 지금까지 실제로 수천 개의 프로젝트에서 성공적으로 운영되었다. 만약 여기에서 제시하는 규칙을 바꾸고 싶다면 스프린트 회고 미팅을 논의의 장(場)으로 사용할 수 있을 것이다. 규칙의 변경은 팀이 스스로 필요해서 실시하는 경우에만 허용되며 경영층으로부터의 변경은 허용되어서는 안 된다. 규칙에 대한 변경은 스크럼에 참여하는 모두가 스크럼이 어떻게 동작하는지 깊게 이해하고 있어서 규칙을 변경하기 위해 필요한 숙련도와 세심한 주의가 보장되는 상태에 도달해있음을 스크럼마스터가 확신하기 전까지는 허용되어서는 안 된다. 다시 한번 강조하지만 스크럼마스터가 이러한 상태에 도달했다고 결정하기 전까지는 그 어떠한 규칙도 절대로 변경되어서는 안 된다.

 

스프린트 계획 수립 미팅

스프린트 계획 수립 미팅은 8시간으로 제한되며 각각 4시간으로 구분된 2개의 세션으로 구성된다. 첫 번째 세션에서는 제품 백로그를 선정하고 두 번째 세션에서는 스프린트 백로그를 준비하게 된다.

• 참석자는 스크럼마스터, 제품 책임자, 팀이다. 추가적으로 비즈니스 영역이나 기술 영역에 대해 조언을 해줄 사람들을 초청할 수는 있으나 이러한 조언이 끝나면 떠나야 한다. 이 미팅에 “닭”이 참관자로 참여하는 것은 허용되지 않는다.
• 제품 책임자는 미팅 전까지 제품 백로그를 준비해야 한다. 부득이 제품 책임자가 참여할 수 없거나 제품 백로그가 준비되지 않는 경우에는 스크럼마스터가 제품 책임자의 대리인을 세우거나 제품 백로그를 준비해야 할 책임이 있다.
• 4시간 동안 실시되는 첫 번째 세션의 목표는 제품 백로그 중 팀이 이번 스프린트에서 출시할 기능을 선정하고 이에 대해 약속을 하는 것이다. 팀은 이 기능들에 대하여 스프린트 검토 미팅에서 제품 책임자와 관련자에게 시연을 하게 될 것이다.
• 팀은 이에 대해 여러 제안을 할 수 있으나 제품 백로그 중 어떤 항목으로 스프린트를 구성할 것인지를 결정하는 것은 궁극적으로 제품 책임자의 권한이다.
• 팀은 제품 책임자가 결정한 제품 백로그 중에서 얼마만큼의 일을 스프린트 동안에 해낼 수 있는지 결정할 권한이 있다.
• 미팅의 첫 번째 세션에 대하여 4시간으로 시간제한을 하는 것은 제품 백로그 분석에 사용할 수 있는 시간을 제한하기 위해서이다. 추가적인 분석은 스프린트 내에서 행해져야 한다. 이 첫 번째 세션만으로는 제품 백로그에서 선정된 항목들이 철저하게 이해되기 어려우며 우선순위가 높은 항목들이 단지 큰 덩어리로 부정확한 추정치(estimate)만을 가지게 되므로 팀은 스프린트 내에 선택한 기능들에 대한 개발을 완료할 수 없을지도 모른다.
• 스프린트 계획 수립 미팅의 두 번째 세션은 첫 번째 세션이 완료된 후 연이어 실시하며 역시 4시간으로 제한한다.
• 팀이 제품 백로그에 대해 문의할 경우 답변할 수 있도록 제품 책임자는 두 번째 미팅에도 참여해야 한다.
• 이번 스프린트를 위해 제품 백로그에서 선정된 기능을 어떻게 구현할 것인지에 대한 결정은 전적으로 팀에게 맡겨지며 외부에서의 어떠한 참견이나 지시도 있어서는 안 된다. 그 누구도 팀의 질문에 답변하거나 말없이 관찰하는 것 이외에는 어떠한 행동도 허용되지 않는다.
• 두 번째 세션의 결과물은 스프린트 백로그라고 불리는 작업과 각 작업에 대한 추정치, 작업 할당을 나열한 리스트이며 팀은 이 스프린트 백로그를 기반으로 개발을 시작하게 된다. 작업 리스트는 완벽할 필요는 없으나 팀원들이 서로 자신의 역할과 책임을 명확히 인식할 수 있을 정도는 되어야 하며 스프린트의 앞 부분을 시작할 수 있을 정도로 구체적인 정보는 담고 있어야 한다. 팀은 스프린트를 진행하면서 스프린트 백로그의 항목을 좀더 구체화하게 된다.

 

일일스크럼 미팅

일일스크럼 미팅은 팀원이 몇 명이든 상관없이 15분으로 제한한다.

• 일일스크럼 미팅은 항상 같은 시간 같은 장소에서 실시한다. 일일스크럼 미팅은 팀원들이 어제는 무엇을 했고 오늘은 무엇을 할 것인지 가장 잘 생각할 수 있도록 업무 시작의 첫 번째 활동이 되는 것이 제일 좋다.
• 모든 팀원은 반드시 참석해야 한다. 만약 부득이하게 팀원 중 한 명이 참석할 수 없는 경우가 발생한다면 불참 인원은 전화로 참석하거나 참석한 다른 팀원이 불참 인원의 상태에 대해 대신 보고해야 한다.
• 미팅은 반드시 정시에 시작한다. 스크럼마스터는 팀원들의 출석여부에 상관없이 약속된 시각에 미팅을 시작한다. 지각한 팀원은 스크럼마스터에게 1달러를 벌금으로 즉시 내야 한다.
• 미팅 시작 즉시 스크럼마스터 바로 옆 팀원으로부터 보고를 시작하여 반시계방향으로 모든 사람이 완료할 때까지 이어간다.
• 보고 시 팀원들은 다음의 질문 세 가지에 대해서만 말한다

(이 프로젝트에 국한하여) 지난번 일일스크럼 미팅 이후 무엇을 했나?

(이 프로젝트에 국한하여) 이 미팅 직후 다음 일일스크럼 미팅까지 무엇을 할 것인가?

업무를 효과적으로 수행하는데 장애가 되는 요소는 무엇인가?

• 팀원들은 이 세 가지 질문을 벗어나서 이슈, 설계, 문제에 대한 토론, 잡담을 해서는 안 된다. 스크럼마스터는 보고가 집중력을 가지고 한 사람에서 다음 사람으로 빠르게 넘어갈 수 있도록 할 책임이 있다.
• 일일스크럼 미팅에서는 한번에 한 사람만 말할 수 있다. 즉, 자신의 상태에 대해 보고하는 사람만 말할 수 있다는 것이다. 다른 사람들은 이때 경청한다. 옆 사람과의 잡답은 허용되지 않는다.
• 어떤 팀원의 보고가 다른 팀원의 관심 사항이거나 다른 팀원의 도움이 필요한 경우에는 일일스크럼 미팅 직후에 관련자들이 모일 수 있도록 팀원 중 누구라도 추가 미팅을 준비한다.
• “닭”은 말을 하거나, 감시한다는 느낌을 주거나, 인상을 찌푸리는 등 자신의 존재를 두드러지게 하는 행위를 해서는 안 된다.
• “닭”은 미팅을 방해하지 않도록 팀에서 멀찌감치 떨어져 있어야 한다.
• 너무 많은 “닭”이 미팅에 참석하려고 할 때에는 스크럼마스터는 참석인원을 제한해서 미팅이 정돈되고 집중할 수 있는 환경을 조성해야 한다.
• “닭”들은 미팅 직후라도 팀원들에게 상세한 설명을 요청한다든지 충고나 지시를 해서는 안 된다.
• “돼지”나 “닭” 누구라도 위의 규칙을 준수할 수 없는 사람은 “닭”인 경우 미팅에서 제외되거나 “돼지”인 경우 팀에서 제외된다.

 

이 글은 스프링노트에서 작성되었습니다.