스크럼 - 팀의 생산성을 극대화시키는 애자일 방법론

읽은 지는 좀 됐지만, 이제 서평을 남깁니다^^ 

 

저자 : 켄 슈와버, 마이크 비들

출판사 : 인사이트

출판일 : 2008.10.03

 

- 프로젝트 관리가 문서와 일정 중심에서 사람과 기능 중심으로 옮겨 가야 한다는 의견으로, 이에 대한 백데이터 수집과 스스로 이를 실천하기 위해 이 책을 읽는다.

- 책의 내용을 부분 발췌한 것으로, 전체적인 그림을 놓칠까 걱정이 되지만, 기억을 새롭게 떠올리는 용도로^^

- 스크럽의 전반적인 설명은 위키피디아의 글이 더 좋다. 영어 두려운 마음 이해한다. 하지만, 별로 어렵지 않은 영어로 쉽게 설명되어 있다.

 

후원자를 찾으세요. 후원지는 당신을 지지하고 방어해주는 사람을 말합니다. 그는 누구나 다 알만한 업적을 가진 임원일 수도 있고, 신뢰할 만한 동료 이거나, 바로 옆에 있는 유능한 부하직원일 수도 있습니다. 중요한 것은, 그가 여러분의 시도가 외압으로 꺾이는 것을 막아주고, 필요한 자원들을 제공해주며, 정신적으로 탈진해 있을때 사기를 북돋워 준다는 점입니다.
- 좋은 동료를 위아래 관계로 더 확장하면 후원자가 되겠네요. 그래도 셋중에 가장 좋은 것은 수평적 관계에서 잘 맞는 동료이다.

 

작게 시작하세요. 할 수 있는 것부터 시작하세요. 완벽하게 하려고 미루다가 하지 않는 것 보다는 작은 거라도 일단 실천하는 게 좋습니다. 이름 없이 시작하세요. 많은 사람이 변화를 싫어합니다.
호의적인 사람들에 집중하세요. 변화에 부정적인 사람을 변화시키려고 하면, 그 사람도 괴롭고 여러분도 많은 에너지가 소모됩니다. 반면에 호의적인 사람에게 집중하면, 그 사람도 즐겁고 훨씬 적은 수고로도 성과를 낼 수 있습니다. 그리고 다른 사람들도 하나 둘씩 호의적으로 변해갈 것입니다.
- 완전 공감!! 작게, 꾸준히, 실천할 수 있는 것부터, 거창하지 않게, 호의적인 동료들과 함께 시작.

 

스크럼을 한마디로 정의하면, "피드백을 좀더 일찍, 좀 더 자주, 좀더 많이, 좀더 지속적으로 주고받자"라고 할 수 있습니다.
- 당연한 말!! 일찍!! 자주!! 많이!! 지속적으로!!

 

제조업 방식의 소프트웨어 개발기법에서는 명시적이고 반복가능한 프로세스나 조직, 개발자의 역할 규정을 통해 예측이 가능하다고 가정한다. 반면 스크럼에서는 프로세스와 조직, 그리고 개발 관련 역할들이 창발적이지만 통계적으로 예측 가능하다고 가정한다. 그리고 그러한 것들은 단순한 실천법과 패턴, 규칙을 적용할 때 생기게 된다고 가정한다.
- 경험적인 과정에서 통계적으로 예측한다.

 

 

나는 러스티에게 어떤 요청이든지 목록에 추가하라고 조언했다. 러스티는 “안 됩니다” 라고 얘기할 필요가 없었다. 대신 우선순위를 정하기만 하면 되었다. '나쁜' 아이디어란 없었다. 단지 도저히 구현될 것 같지 않은 아이디어만 있을 뿐이었다.
- 요청을 개발로 오해하지만 않는다면. 요청은 항상 그에 따른 비용과 효과 분석을 통한 우선순위가 있다는 사실을 제대로 이해할 필요가 있다. 다시 한번, "단지 도저히 구현될 것 같지 않은 아이디어". 사람들을 괴롭히는 아이디어~~

 

스프린트는 겨우 30 일밖에 되지 않기 때문에, 다들 이번 스프린트가 끝날 때까지 기다려 달라는 요구를 받아들일 수 있었다.
- 반복이 보여주는 마술이다. 이해 가능한 상황에선 누구나 합리적인 의사결정을 한다고 믿을 필요가 있다. 통제되느냐, 믿을만하냐의 문제이다.

 

나는 PNP 팀과 변화하는 요구사항 및 끊임없는 압력들 사이의 완충지대가 되었고, 팀이 스프린트의 목표달성에 집중하도록 도왔다. 내가 수행했던 역할은 나중에 스크럼 마스터(Scrum Master)라고 불리게 되었다.

 

1) 지난 일일 스크럼 회의 이후로 무엇을 했고 2) 다음 일일 스크럼 전까지 무엇을 할 계획이며 3) 무엇이 작업을 방해하고 있는가.
- 회의는 집중해서

 

제품에 원하는 기능을 어렵지 않게 추가할 수 있을 시간이 우리에게 있다면, (약간 더 무리해서) 얼마 간의 위험을 감수한다면 더 많은 기능을 추가할 수 있지 않을까? 이런 식으로 프로젝트는 서서히 미쳐 돌아가기 시작하게 된다. 우리는 감당할 수 있는 최대한의 위험을 감수하려는 경향이 있는 것이다. 제임스 배치(James Bach)
- 진지한 이야기지만 농담처럼 들리는 것은 애써 외면하고 싶은 자기보호 본능 때문일까? 개발할때 여유를 부리는 것은 쉬기 위함이 아니라, 제대로 개발하기 위함임으로 어떻게 이해시킬 수 있을까?

여유에 대한 나의 고민이 리스크 관리와 연결된다.

 

최전선의 스크럼에 속한 사람들은 하루에 한 번 만났고, 한 제품군의 각 스크럼 팀 리더들이 포함된 ‘스크럼들의 스크럼 (A Saum of Scrums)’은 한 주에 한 번 회의를 가졌다. 그리고 임원들의 스크럼은 한 달에 한번 모였다.
- 효과적인 미팅은 어느 수준에서든 가능하다.

 

나는 ADM의 개발프로세스를 각각 한달씩 걸리는 두 개의 연속적인 주기로 재구성하였다. 첫째 주기 동안 기능을 추가한다. 그 다음 주기에서는 릴리스를 준비한다. 만약 릴리스 기간 동안 시간이 남는 개발자가 있다면 다음 릴리스 주기에 추가할 다른 기능들을 작업한다.
- 규칙을 정하고 반복함으로써 숙달되게 한다.

 

그들은 내가 왜 올바르지 못한 길로 가고 있는지를 이해시키기 위해서 "프로세스 역학, 모델링과 제어(Process Dynamics, Modeling, and Control)"라는 산업 공정 제어 이론의 필독 서를 권했다.
- 번역된 것은 없는 거... orz...

 

팀은 제품 백로그의 분량을 결정하고, 스프린트 목표를 수립한다. 대부분의 개발 프로세스에서는 관리자가 각 팀원에게 무엇을 언제까지 해야 한다고 지시한다. 이런 방식으로 어떻게 관리자가팀의 헌신을 이끌어낼 수 있을까? 스크럼에서는 어떤 제3자도 팀원이나 팀에게 이래라 저래라 할 수 없다.
- 당연한 책임은 참여와 권한에서 나온다. 책임감 있는 사람을 구할 수도 있겠지만, 책임감을 느끼게 하는 방법도 있다.

 

팀은 스프린트 목표 달성을 위해 필요한 태스크들의 목록을 작성한다. 이 작업들은 제품 백로그를 작동하는 소프트웨어로 변환하는데 필요한 태스크들의 상세한 목록이다. 각 태스크는 대략 4시간에서 16시간안에 완료할 수 있을 만큼 충분히 자세하게 명시되어 있어야 한다. 이 태스크 목록을 스프린트 백로그라고 부른다. 팀은 스프린트 백로그에서 자신이 할 태스크를 스스로 선택하고 결정한다.
- 제품 백로그와 스프린트 백로그

스프린트 검토 회의는 개발 업무의 일환이다. 누구나 질문하고, 관찰하고, 토론하고 제안할 수 있으며, 그렇게 하도록 장려된다. 만약 타협을 많이 해야 한다면 그렇게 하라. 이 회의는 비평을 하거나 어떤 행동을 취하기 위한 것이 아니라 정보 교환을 위한 것이라는 점을 명심해야 한다. 참석한 모든 사람들이 이번 제품 증분을 이해하는 것이 가장 중요하다. 이 정보가 다음 스프린트 계획 회의의 토대가 되기 때문이다.
- 스프린트 검토 회의의 목적

 

나는 관리자와의 토론에서 줄곧 경험주의적인 접근법을 옹호해 왔다. 미리 모델링할지 여부를 선택에 맡겼을 때 팀의 생산성이 올라가는가? 그렇다면 개발자가 생각을 정리하는 용도 정도로만 모델링을 쓰게 하라. 코드의 품질이 모델링을 강제했을 때보다 많이 떨어지는가? 그렇다면 품질이 중요한 부분을 작업할 때에는 모델링을 필수적으로 하게 하라.
- 경험주의적 접근법 사용 예

 

몇 가지 빽로그 그래프. 어떤 경우든 변경하는 타겟을 동적으로 쫓아야 한다.

 

 

팀은 스크럼 회의를 통해 단순한 정보 공유 이상의 것을 얻을 수 있습니다. 사람들은 이 회의에서 단순히 어제 무엇을 했는지에 대해서만 얘기하는 것이 아닙니다. 모든 사람 앞에서 말함으로써 다른 사람이 무엇을 하고 있는지를 모두 알게 되고 나중에 도움을 줄 수도 있습니다. 또한 현재 문제가 무엇인지를 얘기하는 데 그치지 않고 문제를 관리자와 얼굴을 마주보며 얘기할 수 있습니다. 사람들이 정직할 수 있게 용기를 줍니다. 또한 지금 겪고 있는 문제를 관리자가 해결하도록 압박할 수 있습니다. 그리고 무엇보다도, 이 회의는 서로가 서로에게 다음에 무엇을 할 것인지 약속하게 합니다. 이는 사람들의 신용과 믿음을 모두 시험 받도록 합니다. 스크럼은 팀원들 간에 신뢰를 구축하게 해 주는 높은 수준의 사회적 상호작용입니다.
- 믿고 따르는 느낌으로 그대로 한번 해 보고 싶다.

 

무엇보다도 소프트웨어 개발을 제조업으로 생각하고 그쪽에서 비슷한 프로세스를가져온 것이 큰 실수였다.
제조업에서는 라디오, 자동차나 비행기 같은 똑같은 모델을 계속해서 조립한다. 하지만 소프트웨어 개발은 뭔가 새로운 걸 만들어 내는 과정인데, 비록 소프트웨어의 일부분이 재사용 된다곤 하지만, 매번 형태나 설계가 달라지기 때문이다. 예를들어, 어떤 라이브러리나 컴포넌트를 애플리케이션 개발에 사용하는 경우를 생각해 보자. 컴포넌트의 인자 값은 사용할 때마다 달라지고 몇몇 기능은 오버라이딩(ovenide)되기 마련이다.
- 소프트웨어 개발은 매 개발개발이 매번 새로움이다. 단 한번도 반복되는 경우는 없다.

 

아키텍처 팀과 두 번째 애플리케이션 팀을 하나의 팀이라고 생각하라. 그리고 제품의 출시에만 집중하라.
사용될지 안될지도 모르는 '재사용 가능한 일반적인 서비스'는 더이상 신경 쓰지 말고, 두 번째 애플리케이션에서 꼭 필요한 서비스 개발에만 집중하라.
- 항상 전체 그림만 고민하느라 정작 코딩을 하지 못 하는 상황을 피해야겠다. 일단 작업하고 생각은 딱 작업에 필요한만큼만 과하지 않게 해라.