[마이리뷰] 칸반과 스크럼

칸반과 스크럼
헨릭 크니버그 & 마티아스 스카린 지음, 심우곤.인범진 옮김 / 인사이트 / 2013년 5월

스크럼 팀 운영을 하면서 스프린트가 종종 실패하는 경우가 있었다. 원인을 분석해보니 대부분 유지보수 및 지원 업무가 긴급해지고 일의 양이 많아지는 경우 스프린트 실패로 이어졌다. 책 내용 중 ˝들어가기˝ 에서 당일 기준 시급한 일을 다루는 팀에 대해서 칸반을 추천하는 내용을 보고 이 책을 읽어보게 되는 계기가 되었다. 칸반이나 스크럼을 운영하고 있는 사람이나 운영 계획이 있는 사람이면 꼭 읽어보면 좋다.

전반부에는 칸반과 스크럼의 주요 특징을 시각적인 자료들을 활용하여 쉽게 이해 할 수 있고 핵심을 잘 정리하였다. 나머지 후반부는 칸반 보드를 만드는 것 부터 운영에 대한 경험적인 내용을 담고 있는데 독자가 몸 담고 있는 팀에 칸반을 도입할 수 있게 용기를 주고 현실적인 도움이 될 것이다.

아래는 책에서 스크럼과 칸반을 비교함에 앞서 나온 인상적인 내용이다.
프로세스를 비교하고 도입하는데 있어서 꼭 읽어봐야 하는 내용이 아닐까 생각한다.


스크럼과 칸반은 둘 다 프로세스 도구다.
도구 = 작업이나 목적을 달성하려고 사용하는 모든 것
프로세스 = 일하는 방법 비판이 아닌 이해를 통해 도구를 비교하자.

나이프와 포크, 어떤 것이 나을까? 상당히 의미 없는 질문이다. 처한 상황에 따라 답이 달라지기 때문이다. 고기 완자를 먹을 때는 포크가 최선일 것이고, 버섯을 잘게 썰 때는 나이프가 최선일 것이다. 테이블 위에서 드럼 소리를 내려고 한다면 어떤 것이든 괜찮을 것이다. 도구를 비교 할 때는 주의해야 한다. 비판이 아닌 이해를 통해 도구를 비교하자.


스스로를 한가지 도구에 제한하지 마라. 필요한 만큼 도구를 이것저것 섞어서 사용하라. 예를 들어 XP의 상당 부분을 채택하지 않은 성공적인 스크럼 팀을 상상하기 어렵다. 많은 칸반 팀이 스크럼 실천법인 일일 스탠드업 미팅을 한다. 일부 스크럼 팀은 백로그 항목의 일부를 RUP 실천법인 유스케이스로 작성하거나 칸반 실천법인 대기열 크기를 제한한다.

[마이리뷰] NHN은 이렇게 한다! 소프트웨어 품질관리

NHN은 이렇게 한다! 소프트웨어 품질관리 ㅣ TECH@NAVER 시리즈 1
유석문 외 지음 / 위키북스 / 2010년 8월

처음 요리를 하게 되면 간단한 요리를 하게 되더라도 많이 헤매게 된다. 어떤 재료가 필요한지, 그리고 재료들을 어떻게 손질해야 하는지를 모르기 때문에 좋은 결과를 얻기 어렵다. 이런 경우 충분히 친절한 설명과 가이드가 필요하다.

이 책은 가장 소프트웨어 품질 관리를 시작하려고 할 때 어떤 도구들이 있고 어떻게 사용하는지에 대한 충분히 친절한 가이드 책이다. 개발 조직에서 코드의 품질을 보장하기 위한 도구 사용의 큰 그림을 보고 싶은 사람이 보면 좋은 책이다. 하지만 CI 운용을 해보거나 품질향상을 위해 여러가지 자료를 찾아보고 시도를 해본 사람이라면 내용 깊이에 대해서 아쉬움이 있을수 있다.


어떤 서비스나 재화를 생산하는 과정은 ‘정의된 프로세스(Defined Process)’를 따르는 경우와 ‘경험적 프로세스(Empirical Process)’를 따르는 경우로 나뉜다.
정의된 프로세스는 공장의 생산 라인과 같이 반복할 수 있는 과정을 의미한다. 정의된 프로세스에서는 미리 정의된 절차가 있으며 이 프로세스의 참여자는 절차를 잘 지키고 지시서를 충실하게 이행하여 반복적으로 같은 제품을 생산한다. 반면 경험적 프로세스는 어머니가 음식을 만드는 과정과 유사하다. 음식이 완성될 때까지 양념을 넣고 간을 보고 다시 양념을 넣는 과정을 반복한다. 이렇게 피드백을 자주 받는 방식으로 제품을 생산하는 방식 경험적 프로세스라고 한다.

소프트웨어 개발의 특징과 오해 중에서...


애자일 방법론은 소프트웨어 개발이 제조업에서 사용하는 정의된 프로세스가 아닌 경험적 프로세스에 더 적합하다고 생각하는 소프트웨어 개발 방법론이다. 단 한 번의 설계와 구현, 테스트만을 거쳐 제품을 출시하는 과정을 거치는 기존의 소프트웨어 개발 방법론이 성공하지 못한 원인을 설명한다.

첫 장에서 왜 이런 도구들이 필요한지 개발 프로세스와 함께 풀어나가는 내용이 인상 깊었다. 고객의 요구사항은 시간에 흐름에 따라 변화하기 때문에 소프트웨어 개발은 waterfall 모델과 같이 Defined Process에 맞지 않는다. 이런 배경으로 Iterative and Incremental한 애자일 개발을 하는게 효율적인 것이고 각 도구들은 반복적 활동에 큰 도움이 된다.

코딩 컨벤션, 코드 리뷰, 코드 커버리지, 정적 분석, 사이클로매틱 복잡도

대부분 협업 조직에서 필요로 하는 도구들이지만, 만약 1인 개발을 하거나 협업을 하지 않는다고 하더라도 코드 커버리지, 정적 분석등은 꼭 필요하지 않을까 싶다.

품질을 위해서 어떤 도구들을 했고 어떻게 설정하는가에 대해서 나와있지만, 그 후 어떤 변화가 있었는지 그리고 도입 과정에서 어려움은 없었는지와 같은 경험적인 이야기가 포함되지 않은 점이 아쉽다. 방법과 예시는 독자가 각 도구들의 홈페이지에 찾아가도 찾아볼 수 있기 때문이다.

또한 사이클로매틱 복잡도의 알고리즘이 너무 단순해서 이걸 도입하는게 사실 큰 효과가 있을지 모르겠다. if, if-else, switch와 같은 분기의 개수만으로 코드가 복잡하다고 판단하는게 맞는지 명확하게 이야기 하고 있지 않기 때문이다.

마지막으로 NHN에서는 필요한 도구들을 활용하는 것을 넘어서 만드는 모습까지 종종 볼 수 있다.
필요한 것을 만들고 활용하는 조직 문화를 고려했을 때 앞으로도 훌륭한 품질 관리를 하지 않을까하는 생각을 해보았다.

[마이리뷰] TED 프레젠테이션

TED 프레젠테이션
제레미 도노반 지음, 김지향 옮김, 송상은 해제 / 인사이트앤뷰 / 2012년 11월

대학시절 프리젠테이션을 할 때가 문득 떠올랐다. 긴장을 숨기기 위해 힘차게 자기 소개로 시작하지만 준비한 PPT 대본을 그대로 읽어내려가기 바쁘다. 말 실수를 줄이기 위해 내용들이 가득 차 있는 PPT 구성. 그럼에도 불구하고 흐름이 기억나지 않아 말 실수를 하고 나서 목소리가 점점 작아지는 모습.

지금은 그 때만큼 긴장하지 않고 목소리가 작아지는 일은 없지만 여전히 멋진 발표를 하고 있다는 생각하지는 않는다.

어느날 강남역에 있는 중고서점에서 시간을 잠시 보내고 있었는데 문득 이 책이 눈에 띄어서 바로 구매하게 되었다. 이 책은 어떻게 이야기를 할 것인가에 대한 가이드라인을 만난 기분이 들었고 그 동안 내가 프레젠테이션을 했었던 것을 회상하면서 비교할 수 있었다. 나는 듣는 사람 입장을 고려해서 발표하기 보다는 발표자인 본인 위주로 이야기 및 발표를 하지 않았나 싶다. 또한 내가 겪은 경험을 이야기로 풀어가지 않았고 내가 알고 있는 그리고 학습한 정보를 단순히 나열하고 말하고 있었구나라는 생각이 들었다.

스토리를 만들어 나가는 동안 역할 바꾸기도 끊임없이 시도할 필요가 있다.
비판적인 청중의 입장에서 서서 “그래서 뭐 어쨌다고?”, “이 얘기가 도대체 나에게 무슨 도움이 되지?”라고 질문을 던져보는 것 말이다.
<Rule 01 깊은 자기 성찰에서부터 시작하라>

“당신의 삶을 기록할 수 있다면 어떨까요? 당신이 말한 것, 당한이 한 일, 손가락 하나만 움직이면 모든 것을 저장할 수 있는 완벽한 메모리 창고가 있다면 어떨까요? 과거로 돌아가 기억하고 싶은 순간들을 찾아내 필름처럼 되돌릴 수 있고, 시간의 흔적을 …. 5년반 전, 우리 가족이 시작한 여행이 바로 이것이었습니다.˝

오프닝 코멘트를 준비할 때는 은연 중에 청중이 프레젠테이션을 통해 얻게 될 이점까지도 생각할 수 있도록 해야 한다.
<Rule 04 인상적인 오프닝이 분위기를 결정한다>

이외에도 다양한 Rule과 팁을 만날 수 있다. 하지만 가장 중요한 것은 이 책의 마지막 “에필로그”에서 강조하듯이 연습 및 실제 발표가 필요하는 점이다. 책에서 서술한 모든 Rule이 도움이 된다고는 말할 수 없지만, 프레젠테이션에 관심이 있다면 잘하고 싶은 생각이 있다면 충분히 도움이 될것이라고 생각한다.

[마이리뷰] 조훈현, 고수의 생각법

조훈현, 고수의 생각법 - 생각은 반드시 답을 찾는다 ㅣ 인플루엔셜 대가의 지혜 시리즈
조훈현 지음 / 인플루엔셜(주) / 2015년 6월

조훈현 국수가 그 동안 어떤 길을 걸어왔는지를 알 수 있다. 인상 깊었던 부분은 너무나도 많다. 타고난 자질도 있겠지만 프로가 될 수 밖에 없는 그의 이야기들 모두가 나에게 큰 영향이 되었다. 아마도 프로가 되고픈 모든 이들에게 필요한 이야기 아닐까 싶다.

어렸을 때 일본에서 배우게 되는 스승의 가르침과 최고가 되는 과정 그리고 현재의 고민까지, 바둑을 하는 사람이 아니더라도 읽으면 프로가 되려면 어떻게 해야하는지를 알게 해줄 것이다. 그리고 시간이 지남에 따라 무엇을 고민해야 하는지를 간접적으로 생각하게 해줄 것이다. 

˝창의적인 생각의 과정은 어느 분야나 다르지 않을 것이다. 핵심은 바로 문제의식과 질문이다. 이 문제를 개선할 방법은 없을까? 무엇이 잘못된 걸까? 이렇게 스스로에게 질문을 하고 상식과 지식을 동원하여 추측을 한 후 해결책을 찾아나선다. 그렇게 시행착오를 반복하면서 원하는 결과를 얻어내는 것이 바로 창의성의 과정이다.˝

˝복기를 해야 무엇을 잘했고 무엇을 잘못했는지 정확히 알고 넘어갈 수 있기 때문이다. 복기를 잘해두면 같은 실수를 되풀이하지 않을 수 있고, 또 좋은 수를 더 깊이 연구하여 다음 대국에 활용할 수 있다. 이처럼 승리한 대국의 복기는 이기는 습관을 만들어주고, 패배한 대국의 복기는 이기는 준비를 만들어준다. ˝

˝결국 상대방을 분석하는데 시간을 쏟는 것 보다는 지금까지 해온 바둑 공부를 쭉 이어서 하는 것이 더 나은 준비라는걸 깨달았다. 가장 좋은 방법은 그날의 바둑을 복기하는 것이다. 낮에 둔 바둑을 그대로 기억하여 다시 놓아보는 것은 바둑 공부의 기본이다.˝

˝나는 바둑이 계속 발전할 수 있는 이유가 다른 분야와 달리 지식의 집단적 공유와 공개적 토론의 문화가 활발하기 때문이라고 생각한다.˝

[100자평] 그림으로 공부하는 시스템 성능 구조

그림으로 공부하는 시스템 성능 구조 ㅣ 그림으로 공부하는 시리즈
오다 케이지 외 지음, 김완섭 옮김 / 제이펍 / 2015년 5월

시스템 성능과 구조에 대한 디자인 패턴같은 책이다. 다양한 사례들로 읽기 좋게 설명하나 완전 초보자용은 아니다.
개발 2년 이상 했다면 꼭 한번 읽어보라. 실제 시스템 성능뿐 아니라 모돌 설계를 할 때에도 도움이 될 것이다.