9월 초부터 《스크럼》(켄 슈와버, 인사이트)을 읽었다. 그리고 얼마 전에 다 읽었다.
이 책은 상식적인 것들을 말한다. 일은 집중해야 하고, 집중해서 일할 때는 다른 걸 하면 안 된다는 거다. 일하는 사람들은 해당 일 외의 다른 것으로 방해를 받아선 안 되고, 매일매일 진행상황을 실시간으로 점검하고 계획에 반영해야 한다는 말을 한다.
어떤가. 혁신적인가. 언뜻 보기엔 그렇지 않을 것이다. 그런데 혁신적이다. 온갖 장애물을 핑계대며 그렇게 하지 못했던 것에 대해 이 책은 “그렇게 할 수 있다” 하고 말하며, 구체적 방안을 일러 주기 때문이다.
이하는, 후기라기는 뭐하고, 책을 읽으면서 아이폰 어플인 iReadItNow로 메모한 것들을 붙여 넣는다. 이 책을 고르실 분들에게 도움이 되기 바란다.
스크럼을 읽으며 메모한 것들
Author : 켄 슈와버
Format : 223 pages, book
ISBN : 9788991268470
Read : 09.02.2011 ~ 09.17.2011
Rating : 4/5
당시 사람들은 PNP팀에게 직접 가서 제품의 새로운 특징이나 기능을 추가해 달라고 요구하곤 했다. 나는 PNP팀이 작업 요청을 받는 창구를 하나로 만들어, 이런저런 일로 중간에 방해받지 않는다면 생산성이 향상될 거라고 생각했다.
P.6
러스티는 요청을 받으면 그것을 자신의 목록에 추가했다. 그런 후 각 기능의 중요도와 구현에 필요한 기간 그리고 목록에 있는 다른 기능들을 기준으로 해서 우선순위를 정했다. 나는 러스티에게 어떤 요청이든지 목록에 추가하라고 조언했다. 러스티는 “안됩니다”라고 얘기할 필요가 없었다. 대신 우선순위를 정하기만 하면 되었다. ‘나쁜’ 아이디어란 없었다. 단지, 도저히 구현될 것 같지 않은 아이디어만 있을 뿐이었다. 그는 PNP 팀이 오직 자신의 우선순위 목록에 따라 업무를 처리할 거라는 사실을 인디비쥬얼 사의 모든 사람에게 알렸다. 그러고는 자신의 목록을 제품 백로그 목록이라고 부르기 시작했다.
P.6
일일 스크럼 [회의]는 팀의 시간을 낭비하고 있었다. 나는 이 문제를 해결하고 일일 스크럼을 원래대로 돌려놓기 위해서 아주 간단한 몇 가지 대안을 내놓았다. 그것은 첫째, 오직 팀원만 발언할 수 있다. 그 외에 누구도 발언할 수 없다. 만약 팀원이 아닌 사람이 참석을 원한다면 조용히 지켜만 봐야 한다. 둘째, 팀원들은 오직 세 가지 주제에 대해서만 말할 수 있다. 1) 지난 일일 스크럼 회의 이후로 무엇을 했고 2) 다음 일일 스크럼 전까지 무엇을 할 계획이며 3) 무엇이 작업을 방해하고 있는가.
P.11
지금 만들고 있는 제품에 대해 팀원 모두가 전체적인 시야를 가질 수 있는 자율적인(self-enpowered) 팀을 구성해야 한다는 그들의 생각은 더할 나위 없어 보였다.
P.18
브라운 대학의 피터 웨그너는 웨그너의 보조 정리(Wegner’s Lemma)를 통해 외부의 입력에 응답하게 설계된 인터랙티브 시스템을 사전에 완벽하게 명시하거나 테스트하는 것이 불가능하다는 사실을 밝혀내었다. 여기에는 객체지향 시스템을 구축할 때, 폭포수 기법과 같이 알려진 사실만을 투입물로 하는 프로세스는 결과적으로 실패할 수밖에 없다는 수학적인 증거도 있다.
P.18
스크럼의 실천법은 겉으로는 잘 드러나지 않지만 우리 대부분이 잊고 있는 단순하고 보편적인 패턴이라는 것이다. 사실 최근 몇 년 동안에는 스크럼이 조직 패턴의 단순한 집합이라는 생각까지 들 정도였다.
(중략)
그러나 만약 소프트웨어 프로젝트 관리가 이토록 단순하다면, 왜 수없이 많은 프로젝트 관리에서는 이런 정보들이 누락되어 있을까?
… 과거의 어느 시점에서 우리는 소프트웨어 프로젝트를 관리하는 기초적이면서 본능적인 방법을 잊어버렸고 불행히도 그러한 기억상실로 인해 매우 큰 대가를 치렀다.
P.31 ~ 32
우리에게 필요한 것은 빈번하고 직접적인 테스트와 그에 뒤이은 즉각적인 수정임에도 불구하고 우리는 마치 조립라인에서 일하는 것처럼 업무를 처리하는 데 시간을 낭비하고 있었던 것이다.
P.39
스크럼은 경험주의에 바탕을 두고 있기 때문에 이전과 다르게 느껴지고 낯설게 보인다. 계획과 태스크 정의에 소모하는 시간이 줄어들수록 관리 보고서를 작성하고 읽는 데 소요되는 시간이 줄어든다. 그리고 프로젝트 팀이 무슨 일이 벌어지고 있는지를 이해하고 거기에 경험적으로 반응하는 데 더 많은 시간을 쓸 수있게 된다.
P.39
스크럼의 기본 원칙 중 하나는 ‘가능한 것을 하라(the art of possible)’이다. 다시 말해서, 스크럼은 불가능한 것들에 매달리지 말고 가능한 것부터 생각하라고 가르친다. 개발팀에게 최대 허용 시간(box time)을 주고, 그 안에서 제품을 만들어 내라고 요구하는 것이다.
P.42
(옮긴이) 애자일 개발에서는 느낌이 매우 중요하다. 그 이유는 1) 어떤 복잡한 분석도구보다 신속하고 2) 협업에는 공감, 즉 느낌을 나누는 것이 중요하기 때문이다. 일일 스크럼 회의를 끝낼 때나 한 주기를 끝내고 나서 동료들의 느낌을 물어 보고 그 느낌을 공유하기를 권장한다. 단, 주의할 점은 어떤 느낌에 대해서 반박하거나 비판을 해서는 안 된다는 것이다. 그 이유는 그렇게 하면 사람들이 위축되고 자신들의 느낌에 대해서 솔직하게 말하지 않게 되어 프로젝트의 투명성을 떨어뜨리기 때문이다.
P.45
일일 스크럼에서 어떤 결정을 내려야 할 필요가 있다면, 스크럼 마스터는 (심지어 정보가 불충분한 상황이라도) 즉시 결정을 내릴 책임이 있다. 나는 대개의 경우, 아무 결정도 내리지 않는 것보다 어떤 결정이든 내리는 것이 더 유익하다는 사실을 알게 되었다.
P.51
(옮긴이) 지난 수년간의 게임 개발을 통해서 역자 역시 비슷한 결론에 도달했다. 최악의 결정은 틀린 결정이 아니라 느린 결정이다. 그 이유는 틀린 결정은 최소한 교훈을 얻을 기회라도 주기 때문이다. 참고로 이에 대한 좋은 예로 말콤 글래드웰이 쓴 (21세기 북스, 2005년) “제4장 : 생각하기 위해 멈춰 서지 말라”에서 언급된 ‘밀레니엄 챌리지’를 들 수 있다.
P.51
비록 팀이 자신의 업무를 어떻게 처리할지에 대한 결정권을 갖고 있지만 동시에 기존의 계약, 표준, 관습, 아키텍쳐와 기술을 활용하고 준수할 의무도 갖는다. 이런 태도를 견지해야 해당 프로젝트의 제품이 회사의 다른 제품들과 조화를 이루고 스크럼 팀이 다른 사람들로부터 인정을 받을 수 있게 된다.
P.62
각 스크럼 팀은 매일 일일 스크럼 회의라고 불리는 십오 분짜리 현황 파악 회의를 갖는다. 이 회의에서 지난 회의 이후로 무엇이 결정되었고 다음 회의까지 무엇을 할 예정이며 무엇이 진행을 방해하고 있는지 서로 알게 한다.일일 스크럼 회의는 사람들이 팀을 기반으로 신속하고 일사불란하게 그리고 서로 존중하며 협업하는 개발에 적응하도록 해준다. 또한 의사소통을 향상시키고 다른 불필요한 회의를 줄여주며 개발의 장애물을 식별/제거하고 성숙한 의사 결정을 부각/촉진시켜 모든사람이 프로젝트를 충분히 이해하게한다.
P.64
일일 스크럼 회의에 참석하는 것은 보고서를 읽는 것보다 더 쉬울 뿐만 아니라 현황 파악에도 유리하다.
P.65
만약 화이트보드에 적힌 미해결 장애 요소가 계속 늘어나기만 한다면 회사에서 팀을 충분히 지원하지 않고 있다는 것을 의미한다. 이 경우, 스크럼 마스터는 스프린트[스크럼 개발 방법론에서 한 달 정도로 특정 과제들에 매진하는 기간. 스프린트 여러 덩이가 한 프로젝트를 구성한다]를 취소할 수도 있다. … 일단 스프린트 취소를 결정하게 되면, 스크럼 마스터는 프로젝트를 성공시키기 위한 관리자의 지원이나 회사 차원의 노력이 부족했음을 효과적으로 알려야 한다.
P.72
대부분의 경우 재빠른 결정이 누군가가 결정해 주기를 기다리면서 일을 뭉개고 있는 것보다 낫다.
P.73
새로 결성된 팀은 종종 이 회의를 통해서 자신들이 개인으로서가 아니라 하나의 팀으로 살거나 죽을 수 있다는 사실을 처음으로 깨닫는다. 팀이 모든 것이 전적으로 자신들의 독창성, 창조성, 협력과 협업 그리고 해내려는 노력에 달려 있다는 사실을 깨닫는다. 팀이 이 사실들을 깨닫는 순간, 자기 조직화를 통해 진정한 팀의 특성과 행동이 드러나게 된다.
P.78
우리 시스템 개발자들이야 개발하면서 모든 것을 미리 정확하게 파악할 수 없기 때문에 항상 트레이드오프[개발기간을 맞추기 위해 품질을 떨어뜨리거나, 품질을 맞추기 위해 개발 기간을 늘리는 것]가 발생한다는 것을 잘 안다. 그러나 관리자들은 예측하고 싶어 하기 때문에 우리는 종종 관리자 앞에서 그들이 듣고 싶은 것만을 얘기해야 하는 상황에 처하게 된다. 그게 뭐 그리 나쁘냐고? 진짜 재앙이 발생하기 전까지 관리자는아무 것도 모르게 되고 우리가 하는 말을 다 받아들인다. 이렇게 되면 관리자의 참여와 지식, 자원, 지혜를 얻지 못하게 된다. 만약 관리자가 왜 트레이드오프를 하는지 이해하게 되면, 관리자도 참여하고 협력할 것이다. 관리자로서 이것은 대단한 일이 아니다.
P.122 ~ 123
나는 프로젝트 매니저가 고객이 원하는 기한을 맞추려면 기능이 부족해지거나 제품이 불안정해진다는 걸 뻔히 알면서도 그에 대해 약속하는 걸 보아 왔다. …
우리가 알고 있고 믿고 있는 상황을 자기 몫으로 받아 안는 고통스러울 정도의 정직함, 이것이 최선이다.
P.123 ~ 124
신기술로 새 프로세스를 구축하는 개발 프로젝트는 매우 잡음이 심하고 불확실성이 크다고 할 수 있다.
P.133
기술자료는 계획을 짜거나 작업을 진행시키는 데 사용되지 않았다. 대신 어떻게 작업할 수 있는지에 대한 참고문헌으로 사용되었다. 지식 저장소는 새로운 지식이 습득되고 새 기술이 추가될 때마다 진화했다.
이렇게 추상화된 프로세스 지식은 이것이 불완전하고 지침용으로만 적합하다는 걸 잊지 읺는다면 전혀 문제될 것이 없다. 그렇다고 이걸 이용해서 이전과 같은 결과를 얻을 수 있다고 기대해서는 안 된다. 패턴을 통해 특정 문제에 초점을 맞춘 프레임워크 정도를 제공할 수 있는 그런 지식은 표현할 수 있다[ScrumPattern]. 견실한 엔지니어 팀은 문제 해결을 위해 패턴, 기법, 특정 기술에 대한 지식을 끌어다 사용한다. 스크럼은 팀에게 스스로의 지혜와 능력 그리고 옆에 있는 팀원을 의지하라고 가르친다.
P.150
개발팀은 경험적 프로세스인 스크럼을 사용하고 있었으므로 작업을 잠시 멈추고 우선순위를 제고해 보았다. 항상 해오던 식으로 작업하던 걸 잠시 중단하고 지금 상황에서 이제까지의 실천방법이 적절한지를 먼저 자문했다. 간단한 조사 끝에, IBM을 사용하는 곳은 한 곳도 없고 HP 역시 한 곳밖에 없다느 걸 알게 되었다. 현재 작업에서 한 발 물러나 현재 상황을 평가함으로써, 팀은 포팅 작업을 건너뛰고 새 릴리스에만 전념할 수 있게 되었다. 이런 건 단순히 상식을 적용한 예이지 않느냐고 한다면, 그렇긴 하다. 하지만 이것이야말로 경험적 프로세스의 핵심이다.
P.151 ~ 152
제조업에서는 라디오, 자동차나 비행기 같은 똑같은 모델을 계속해서 조립한다. 하지만 소프트웨어 개발은 뭔가 새로운 걸 만들어내는 과정인데, 비록 소프트웨어의 일부분이 재사용된다곤 하지만, 매번 형태나 설계가 달라지기 때문이다. 예를 들어, 어떤 라이브러리나 컴포넌트의 인자값은 사용할 때마다 달라지고 몇몇 기능은 오버라이딩[덮어쓰기]되기 마련이다.
P.156
나는 앞에서 스크럼이 소프트웨어 개발을 연구, 창조가 필요한 신제품 개발 과정이라고 가정했고 그렇기 때문에, 이들 조직 역시 ㅈ기 조직적인 프로젝트 팀이 되어야 하고 중첩적인 개발 단계를 가져야 한다고 제안했다. 즉 이 말은, 스크럼 조직이나 스크럼 프로세스는 통계적으로 규정될 수 없고 반복 가능하지 않다는 것을 의미한다. … 꼭 기억해야 할 것은 ‘인간의 모든 조직은 전부 자기 조직적’ 이라는 점이다.
P.165
절대로 ‘이론상 필요할 것 같은’ 서비스는 만들지 마라. 분명 만드는 것도 힘들거니와 정작 안 쓰게 되는 경우도 많다.
P.185
첫 애플리케이션 개발 때 그랬던 것처럼 두 번째 애플리케이션 개발 스크럼 팀의 최우선 목표 역시 제품의 출시다. 그런 다음 재사용에 대해 생각해야 한다.
P.186
스크럼은 조직 혁신을 통해 생산성을 향상시키는 데 사용된다. 대부분의 조직들은 생산성에 최적화가 되어 있지 않다. 조직이 크고 오래될수록, 비효율이 늘어간다. 마치 지방이 조금씩 쌓여서 심장으로 흘러가는 피의 흐름을 느리게 만드는 것처럼, 비효율도 조금씩 쌓여 조직에 동맥경화를 일으켜 모든 것을 느리게 만든다. 이런 경우 공식 조직 내에 비공식적인 조직이 나타난다. 소위 ‘일을 제대로 할 줄 아는’ 사람들은 이런 비공식 조직이 어떻게 돌아가는지 아는 사람들이다. 이들이 양쪽 조직 내에서 어떻게 역할을 효율적으로 다 할지를 아는 사람들이다 보니, 대부분의 성공한 관리자들은 꼭 이런 직원을 몇 명 두고 있는 실정이다. 하지만, 이런 방법은 생산성을 높이기에는 효율적이지 않다. 이런 식보다는 차라리 잠재되어 있는 문제들을 해결하는 게 훨씬 낫다.
P.205
장애물 제거는 누구의 책임인가? 그에 대한 대답은 ‘전체 조직’이다. 스크럼 마스터는 이 장애물에 대한 책임을 맡아, 장애물 제거를 위해 모두와 함께 작업해야 하는 책임을 진다. 하지만 전체 조직이 이에 대해 헌신해야 한다.
스크럼 마스터는 일일 스크럼 회의를 주관하고 프로젝트의 모든 면을 관장하며 장애물 제거에 책임을 진다. 스크럼 마스터는 관리자의 전폭적인 지지와 연대를 필요로 한다. 무엇보다도 스크럼 마스터가 장애물을 제거할 수 있는 권한을 위임받는 것이 중요하다. 만약 관리자가 스크럼 마스터가 하는 일에 대해 동의하지 않는다면, 제안을 한다든지, 지침을 제시한다든지, 조언을 주는 정도는 할 수 있다. 하지만, 어떤 일이 있더라도 관리자는 스크럼 마스터를 절대 지지해야 한다.
P.208
개발자에게 좋은 장비를 제공하는 것은 업무 효율 외에도 사기 진작에 큰 도움이 된다. 개발자들에게 24인치 모니터 두 대를 세워서 듀얼 모니터로 만들어 쓰게 하다든가, 쿼드 코어에 4g 메모리를 장착한 개발용 컴퓨터를 제공한다든가, 최신 컴파일러와 서드파티(third party) 툴을 정식 구매해서 쓰게 해 주는 것만으로도 의욕을 3-4배 올릴 수 있다.
P.210
하나의 프로젝트를 진행하는 동안, 스크럼 마스터는 개발자들이 지금 하는 일을 논의하기 위해 계속 일어나서 서성대거나 다른 사무실로 몰려다니는 걸 알게 되었다. 이 조직은 열린 작업환경을 받아들이지 못해서 선임 관리자를 제외한 모든 사람을 파티션으로 둘러싸인 개인 공간에 배치했다. 팀은 역동적으로 구성되었지만, 각 팀원들의 위치가 가까운 곳에 모여 있지 않아서 엔지니어가 누군가의 자리로 가려면 꽤 멀리 걸어가야 했다. 이 때마다 집중은 흐트러졌다. 스크럼 마스터는 (전선과 전화선 배치 변경을 도와준) 시스템 관리자와 함께 팀원들의 위치를 이동시켜 모두가 서로 가까이 할 수 있게 했따. 또한 각자의 의자를 칸막이 벽 옆에다 배치해서, 팀원들이 서로 물어볼 게 있을 때마다 일어서서 파티션 너머로 바라보며 디자인 관련 논의를 할 수 있게 했다. 이렇게 하자, 팀의 작업 공간은 마치 프레리 독 타운 같아 보였고 머리를 들어올리기만 하면 되는 작업 환경으 팀원들을 서로 더욱 효과적으로 작업할 수 있게 했다.
작업 공간을 재배치함으로써 얻어낸 생산성은 스크럼 마스터의 세심한 관찰 덕분에 가능한 것이었다. 스크럼 마스터는 주어진 것에 만족하기보다 팀을 좀더 편안하게 하고 더 생산적으로 만들 수 있다면 어떠한 것이라도 해낼 수 있도록 노력해야 한다.
P.212
나는 ‘왕 연구소’가 한창 잘 나가던 시절부터(1980-1984) 쇠락이 시작되던 1985년까지 근무했었따. 이 시기 동안 ‘왕 연구소’의 성장에 따라, 많은 지원 업무가 새로 조직된 지원 조직으로 이양되었다. 곧 상무와 이사, 실장들을 거느린 부사장이 인사과 구매과 같은 지원 조직들을 이끌었다. 그들은 정책, 절차, 양식, 의례 따위를 연구, 개발하는 데 시간을 썼고, 회사 내 다른 팀에 그것을 강요했다. 모두가 그걸 따라야 했는데, 그렇지 않으면 부사장에게 반기를 드는 것으로 보일 수 있었기 때문이었다. 무엇이 적절한지를 생각하기보다 그냥 회사에서 주어진 일을 하는 게 점점 쉬워졌다. 일은 관료정치에 길을 내주었고, 진취적인 기상은 정체에 길을 내주었다. 물론 이것이 ‘왕 연구소’의 몰락을 전부 설명할 수 있는 것은 아니다. 하지만, 이런 것들이 우리 프로젝트에 많은 생산성 저하를 불러 일으켰다.
P.214
기꺼이 목표에 헌신하라. 스크럼은 자신의 공약을 지키려고 헌신하는 사람들에게 그들이 필요로 하는 모든 권한을 부여한다.
P.218
불확실한 요구사항과 불안정한 기술을 이용해서 가치가 있는 제품 개선을 이루긴 어렵다. [원문엔 제품 개선을 이룬다고 돼 있지 않고 제품 증분(increment)을 만든다고 돼 있는데 내맘대로 알아먹기 좋게 수정 – 형우]
P.220 ~ 221
대부분의 사람들은 주의산만에 익숙해져 있다. 업무 도중 해야 할 일들은 참 많다, 우리는 다른 부서의 회의나 사내 교육 등에 꿀려 다니고 그러는 우리 역시 다른 직원들에게 이메일을 보내거나 평가 따위를 쓰게 만들어 하루를 업무 외 다른 일을 하면서 보내게 한다.
P.221
팀은 전체로서 스프린트 목표를 약속하기 때문에 팀 전체가 다 같이 빠져 죽던가, 헤엄쳐 나가던가 둘 중 하나만 할 수 있다. 팀 전체가 영웅이 될 수는 있어도 한 개인이 영웅이 될 순 없다. 어떤 팀원이 능력이 부족하다면, 다른 팀원들이 벌충해 줘야 한다. 팀원이 자신의 단점에도 불구하고 최고의 능력을 발휘할 수 있도록 도와주는 것에 있어 집단 압력(group pressure)과 팀 환경만한 게 없다.
P.226
댓글 남기기