<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Robert C. Martin on</title><link>https://taetaetae.github.io/tags/robert-c.-martin/</link><description>Recent content in Robert C. Martin on</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sun, 27 Dec 2020 17:06:19 +0900</lastBuildDate><atom:link href="https://taetaetae.github.io/tags/robert-c.-martin/index.xml" rel="self" type="application/rss+xml"/><item><title>애자일 아버지의 고함과 호통 (리뷰：Clean Agile - Back to Basics)</title><link>https://taetaetae.github.io/posts/review-the-book-clean-agile/</link><pubDate>Sun, 27 Dec 2020 17:06:19 +0900</pubDate><guid>https://taetaetae.github.io/posts/review-the-book-clean-agile/</guid><description>&lt;p>﻿　&amp;lsquo;애자일&amp;rsquo; 이라고 하면 무엇이 떠오르는가? 잘은 모르지만 막연하게 생각을 해보면, 매일 오전 스크럼을 하고 진행 현황을 가시화하며 프로젝트를 성공적으로 이끄는 일종의 &amp;lsquo;프로세스&amp;rsquo;로 알고 있다. 좋다는 것도 들었고 도입을 하려 하지만 뭔지 모르게 잘 안되는 그것. 현업에 들어오면서 &amp;lsquo;애자일&amp;rsquo; 도입의 성공/실패에 대한 이야기를 가끔씩 건너건너 들어만 본 수준이다. 이제는 주니어도 시니어도 아닌 &lt;code>중니어&lt;/code>가 되어보니 알고리즘이나 패턴, 신기술도 중요하지만 팀과 프로젝트 전반의 건강하고 성공적인 진행을 위해서는 이러한 활동들이 중요하구나 하며 요즘 &lt;del>(올해)&lt;/del> &lt;strong>뼈!저!리!게!&lt;/strong> 느끼는 중이다.&lt;/p>
&lt;p>﻿　마침 크리스마스 연휴를 앞두고 이 시국에 나가지도 못하는데 뭘 해야 하나 고민하고 있던 찰나 &lt;del>운명처럼&lt;/del> &lt;a href="https://book.naver.com/bookdb/book_detail.nhn?bid=17524418" target="_blank" rel="noopener noreffer ">클린 애자일, 저자 로버트 C. 마틴&lt;/a>이라는 책 추천을 받는다. 보통 필자는 읽고 싶은 책을 고를 때 중요하게 생각하는 두 가지가 있는데 표지와 추천인(혹은 리뷰어)의 대한 신뢰. 둘 다 너무 좋았기에 바로 인터넷 주문을 하였지만 그새를 못 참고 근처 서점에 들러 책을 사 온다.﻿&lt;/p>
&lt;h2 id="갑분돈키호테">갑.분.돈(키호테)&lt;/h2>
&lt;p>　&lt;code>풍차나 폭포를 공격해본 모든 프로그래머에게&lt;/code>&lt;/p>
&lt;figure>&lt;a class="lightgallery" href="https://taetaetae.github.io/images/review-the-book-clean-agile/donkihote.jpg" title="/images/review-the-book-clean-agile/donkihote.jpg" data-thumbnail="/images/review-the-book-clean-agile/donkihote.jpg" data-sub-html="&lt;h2>풍차를 괴물로 보고 달려들었던 돈키호테&lt;/h2>">
 &lt;img
 class="lazyload"
 src="https://taetaetae.github.io/svg/loading.min.svg"
 data-src="https://taetaetae.github.io/images/review-the-book-clean-agile/donkihote.jpg"
 data-srcset="https://taetaetae.github.io/images/review-the-book-clean-agile/donkihote.jpg, https://taetaetae.github.io/images/review-the-book-clean-agile/donkihote.jpg 1.5x, https://taetaetae.github.io/images/review-the-book-clean-agile/donkihote.jpg 2x"
 data-sizes="auto"
 alt="/images/review-the-book-clean-agile/donkihote.jpg" width="80%" />
 &lt;/a>&lt;figcaption class="image-caption">풍차를 괴물로 보고 달려들었던 돈키호테&lt;/figcaption>
 &lt;/figure>
&lt;p>﻿　호기롭게 첫 장을 넘기는데 강렬하게 다가오는 문구. 옮긴이에 따르면 세르벤테스의 소설 &amp;lsquo;돈키호테&amp;rsquo;에서 주인공 돈키호테가 풍차를 공격하는 모습에서 온 표현이라 한다. 대부분 헛되고 무모한 싸움을 하는 사람들을 빗대어 이야기하며 바보 혹은 현실 부적응자로 갈음하는 표현으로 사용된다. 러시아 작가 이반 투르게네프는 햄릿을 사랑하기는 힘들지만 돈키호테는 사랑하지 않기가 힘들다는 &lt;a href="https://m.blog.naver.com/leesr2006/220703629450" target="_blank" rel="noopener noreffer ">이야기&lt;/a>를 했다고 한다. 아마 저자는 고민보다는 행동을 중요하게 생각했던 돈키호테를 빗대어 현실에 안주하지 않고 건강한 개발 문화를 개선하려는 모든 프로그래머에게 조언과 박수를 보내려 했던 건 아닐까 싶다.﻿&lt;/p>
&lt;h2 id="책의-구성">책의 구성&lt;/h2>
&lt;p>﻿　페이지 수(230p)가 많지 않아서 가볍게 읽을 수 있겠다 싶었지만 다소 작은 글씨들로 구성되어 있어서 책을 잘 안읽었던 필자에겐 약간 부담으로 다가왔다. 하지만 내용들이 너~무 공감이 되어 마치 필자의 2020년을 오래전에 예견하고 미리 써둔것 같은 느낌을 받았을 정도라 아침 5시에 일어나 저녁 11시가 되어서야 다 읽을 수 있었다. 처음 들어본 용어나 이해가 잘 안되는 개념들도 있어 다음날 노트북을 옆에 두고 찾아가며 다시 읽기도 하였다. (그만큼 제대로 읽어보고 싶었다.)&lt;/p>
&lt;p>﻿　책 초반부터 저자는 이 책을 &amp;lsquo;선언&amp;rsquo;이나 &amp;lsquo;정의&amp;rsquo; 가 아닌 애자일에 대한 &amp;lsquo;경험&amp;rsquo;을 토대로 오해를 바로잡는다라고 이야기하고 있다. 2001년 2월, 애자일 선언이 &lt;a href="https://agilemanifesto.org/iso/ko/manifesto.html" target="_blank" rel="noopener noreffer ">발표&lt;/a>가 되었고 내년이면 20년이 돼가는 시점에 여러 가지로 변형된 &amp;lsquo;애자일 방법론&amp;rsquo;이 나왔지만 애자일의 기준을 다시 소개하며 본질을 흐려선 안된다고 이야기한다. (책이 부 제목이 Back to Bascis인 것을 보면 &amp;hellip;)﻿&lt;/p>
&lt;p>﻿　흥미진진한 책 내용 중에 아직까지도 머릿속에 남아있던 애자일과 자주 비교되는 &amp;lsquo;폭포수 모델&amp;rsquo;로 프로젝트를 진행한 부분을 필자가 이해한 대로 적어보려 한다. (너무나도 끔찍하게 공감되기에&amp;hellip;)&lt;/p>
&lt;div class="details admonition quote open">
 &lt;div class="details-summary admonition-title">
 &lt;i class="icon fas fa-quote-right fa-fw" aria-hidden="true">&lt;/i>폭포수 모델로 프로젝트를 진행한 사례&lt;i class="details-icon fas fa-angle-right fa-fw" aria-hidden="true">&lt;/i>
 &lt;/div>
 &lt;div class="details-content">
 &lt;div class="admonition-content">&lt;p>﻿프로젝트 관리자가 마감기한을 확인하고 회의를 진행한다. 지금은 1월이고 출시가 10월이니 각 일정은 거꾸로 계산하여 개발은 QA 기간 고려 9월에 종료, 설계는 7월에, 분석은 늦어도 4월까진 하는 걸로 &amp;lsquo;못 박는다.&amp;rsquo; (네&amp;hellip;?)&lt;/p>
&lt;p>그렇게 여유롭게 시간을 보내다 4월이 되어 분석 단계가 끝난다. 왜? 4월이 됐으니까. 또 시간이 흘러 7월이 되자 기적이 발생한다. 설계 종료. 왜? 7월이 됐으니까. 그 후 남은 2개월 동안 개발자들은 엄청난 압박과 급증하는 야근과 함께 하나둘씩 팀을 떠나고 그만두기 시작한다. QA에서 확인한 버그가 셀 수 없이 쏟아져 나온다. (소름 1)&lt;/p>
&lt;p>하지만 10월에 출시하기로 했으니 버그나 에러가 터져 나오지만 출시를 하고. 프로젝트는 실패로 돌아간다. 그리고 회고를 하고. 다음번엔 제대로 해야지! 하며 다짐한다. (소름 2)&lt;/p>
&lt;p>저자는 이것을 따라잡을 수 없는 프로세스 인플레이션(Runaway Process Inflation)이라고 부른다. 우리는 될 리가 없는 일을 계속하려고 한다. 그것도 아주 많이.&lt;/p></description></item></channel></rss>