『Methods & Tools』의 2010년 봄호에 실린 Daryl Kulak의 “Five Symptoms of Mechanical Agile”을 여기 소개한다.
잘못된 애자일의 다섯 가지 증상(Five Symptoms of Mechanical Agile)
Daryl Kulak
Pillar Technology, http://www.pillartechnology.com
원래 나의 본업은 전문 애자일 코치지만, 오늘은 여러분에게 재미있는 이야기를 들려주는 이야기꾼이 되어야겠다. 나는 이 글에서, 내가 겪었던 사실들에 기반해 애자일이 어떻게 단순한 기계처럼 천편일률적이 되고 구조화되어 가는지를 다루고 있는 5개의 이야기를 하려고 한다. 내가 불순한 의도가 없다는 것을 증명하기 위해, 실화였음에도 불구하고 이야기에 등장하는 실제 이름들은 우화에나 등장할 법한 이름들로 바꾸었다.
증상 1 - 애자일 전문가 신드롬(Agile Expert Syndrome)
옛날 옛날에, 네버랜드 보험사(Neverland Insurance)라는 회사가 있었다. 그 안에 애자일 컨설턴트가 포함된 한 팀이 있었다. 이들은 함께 애플리케이션을 만들기로 했다. 팀은 열 명 정도로 구성되며, 애자일 컨설턴트는 더 할 나위 없이 명민한 사람으로 평판이 좋을 뿐만 아니라 전문적인 애자일리스트(Agilist)기도 했다. 팀원들은 그들의 팀에 그가 속해 있는 것이 정말 행운이라고 느꼈다. 그 애자일 컨설턴트의 이름은 스티키 라그랑주(Sticky LaGrange)였다.
스티키는 팀이 업무를 시작할 수 있도록 도와주었고 또한 그가 알고 있는 모든 애자일 지식을 모두에게 전파했다. 팀은 신중하게 스티키의 조언을 따랐으며, 그들이 뭘 해야 할지 정확하게 알 수 없을 때마다 스티키에게 조언을 구했다. 스티키는 그럴 때마다 팀을 친절히 도왔으며 또한 인내심도 깊었다. 이런 활동들뿐만 아니라, 그는 팀원들을 도와주는 데 많은 시간을 할애했음에도 불구하고 누구보다 많은 코드를 작성했다. 이런 사실에 대해 그 스스로도 자부심을 가지고 있었다. 스티키는 그야말로 놀라운 성과를 보이는 사람이었다.
프로젝트가 끝나갈 무렵, 결국 애플리케이션은 정해진 시간과 예산 안에서 성공적으로 출시되었다. 네버랜드의 모든 사람들이 깊은 감명을 받았다. 그리고 팀은 스스로를 무척이나 자랑스러워했다.
그러자, 네버랜드의 사악한 왕은 팀의 예산을 삭감했고 팀은 어쩔 수 없이 스티키에게 이별을 고할 수 밖에 없었다. 그들 스스로도 스티키에게 모든 걸 배웠기 때문에 이제는 스티키가 없더라도 성공할 수 있을 것이라고 믿었다. 팀은 또 다른 애플리케이션을 만드는 작업을 시작했다. 그들은 스티키가 그들에게 들려준 모든 이야기들을 기억하려고 노력했다. 확신이 서지 않는 상황에서 팀의 누군가는 필연적으로 “스티키라면 어떻게 했을까?”라고 물어볼 수밖에 없었다. 팀은 스티키가 했던 것들을 기억하고 이를 충실히 재현하려고 노력했다. 그러나 일은 예상과 다르게 전개되기 시작했다. 각각의 팀 멤버들은 서로가 다르게 스티키의 충고를 기억하고 있었다. 때로는, 이해할 수 없는 일이지만, 스티키의 조언이 틀린 것처럼 보일 때도 있었다! 이러한 새로운 상황에 스티키의 조언을 적용하는 것은 불가능해 보였다. 어떻게 스티키가 틀릴 수 있지?
팀의 몇몇 사람들은 스티키의 조언을 뛰어넘어 극복해야 한다고 주장했다. 그러나 다른 사람들은 그런 주장들이 끔찍한 것이라고 생각했다. 이런 사람들은 스티키의 조언에 반하는 의견들에 대해 “그건 진정한 애자일이 아니야!”라고 소리지르곤 했다. 스티키의 조언이 처음에는 그렇게 잘 들어맞았는데, 왜 이제 와서 거기에서 벗어나야 한단 말인가?
불행하게도, 네버랜드의 이 팀에는 내가 "애자일 전문가 신드롬(Agile Expert Syndrome)"이라고 부르는 증상이 나타나고 있는 것이다. 이것은 사람들이 컨설턴트의 의견이든, 책이나 기사든, 전문가의 조언을 무조건 따라야 한다고 생각할 때 발생하는 것이다.
이렇게 어떤 것에 의존하고 따라야 한다는 분위기가 팽배해 있을 때는 언제나 그들이 어떤 문제에 직면해 있을 때다. 이럴 때 그들은 애자일을 단순히 기계적으로 수행하게 된다(They are performing Agile mechanically). 기계적인 애자일을 수행하는 팀은 항상 문제에 직면하기 마련인데, 이는 그들이 전문가로부터 받은 충고를 따르는 도중에 뜻밖의 장애에 부딪히기 때문이다. 이런 증상을 겪고 있는 사람들은 일상적인 장애에 부딪힐 때에도 그들이 가지고 있는 지식을 활용하고 할 수 있는 최선의 행동을 하려고 하는 대신, 늘 그들이 추앙하던 전문가들은 이 상황에서 과연 어떻게 할까라고 추측하는 것에만 집중한다.
증상 2 - 의사 결정과 현장의 분리
(Separation of Decision-Making and the Work)
옛날 옛날에 옷을 만들어 파는 ‘싸구려 녹색 셔츠닷컴(Cheap Green Shirts.com)’이라는 회사가 있었다. 이 회사는 훌륭한 성과와 탁월한 생산성을 보여주는 애자일 팀을 여럿 보유하고 있었다. 그들의 업무 진행은 무척 빨랐으며, 팀원들은 행복했고, 사업은 늘 수익을 내고 있었다.
어느 날, 부사장 중의 한 사람이 “생각해보니 잘만하면 우리 팀들을 더 쥐어짜낼 수 있겠어…”라고 생각했다. “A팀이 다른 팀들보다 훨씬 좋은 성과를 내고 있군. A팀의 가장 좋은 사례를 발굴해서 이를 다른 팀에서도 활용하도록 하는 거야. 이런 방식으로, 모든 팀들이 A팀 수준의 성과를 달성하게 되는 거지. 얼마나 훌륭해!”
이에 부사장은 업무와 관련된 제안을 각 팀에게 할 수 있는 소프트웨어 엔지니어링 프로세스 그룹(SEPG)이라고 부르는 애자일 전문가 그룹을 만들었다. “씨페이지(Seepage)”라고 부르는 SEPG의 전문가들은 조심스럽게 각 팀에서 사용된 각각의 사례들을 조사하고, 그 결과를 분석했다. 이후 가장 최고의 사례를 선택해 이를 각 팀들에게 회신해 주었다.
하지만 놀랍게도, 대부분의 팀들은 그 최고 사례의 많은 부분을 제대로 활용하지 못했다. SEPG의 전문가들은 이점에 무척이나 분개했다. “도대체 이 팀들은 뭘 배우려고 들지 않아!” 라면서 SEPG의 전문가들은 불평을 토로했다. 반면, 각 팀에서는 “SEPG 양반들은 도대체 우리 일을 이해하지 못해”라고 말했다.
그러자 부사장은 모든 팀에게 SEPG의 전문가들이 찾아낸 것들을 ‘반드시’ 준수하도록 지시했다. 모든 팀은 부사장의 지시에 따라 충실하게 새로운 사례를 활용하기 시작했다. 바로 이 시점에서, 팀 작업의 속도가 현저하게 느려지기 시작했다. 어떻게 이런 일이 벌어질 수 있을까? SEPG의 전문가들은 “팀들이 우리가 제시한 사례를 잘못 활용하고 있어!”라고 비난했다. 팀에서는 팀 나름대로 “이런 사례들은 우리에게 정말 맞지 않아!”라고 반응했다.
부사장은 우리가 “의사결정과 현장의 분리(Separation of decision-making and the work)”라고 부르는 문제에 봉착한 것이다. 의사결정을 하는 사람이 실제로 작업을 수행하는 것과 관계가 없으면 없을수록, 결과도 그에 따라 더 좋아지지 않을 것이다. SEPG 그룹이 현장으로부터 계속 멀어지고, 팀이 현장에서 매일 매일 수행하는 업무에 익숙해지지 않는다면, 아무리 그들이 전문가라고 하더라도 그들의 조언은 불행하게도 실패할 가능성이 무척 높아지는 것이다. 처음부터 팀은 그들 스스로가 사용하기 가장 적합하다고 생각하는 사례와 방법을 선택할 수 있어야 한다. 의사결정 조직을 실무 조직에서 분리하고 이 권한을 다시 다른 그룹에 할당함으로써, 부사장은 전체 업무의 속도와 팀 만족도를 저하시키고 모든 사람의 불평불만을 사고 만 것이다. 부사장은 팀을 사람이 아니라, 기계라고 생각한 것이다(The vice-president was thinking that the teams were machines, not people).
증상 3 - 시스템이 아니라 사람을 비난함(Blame the Person, Not the System)
같이 협력하는 관계의 두 팀이 있다. 한 팀은 다른 팀에게 코드에서 구현해야 할 일련의 요구사항들을 제공했다. 그 팀을 우리는 “우월한 사람들(Uppities)”이라고 불렀는데, 그들은 프로세스의 상부(Upstream)에서 아래로 지시하는 작업을 수행하기 때문이었다. 다른 팀을 우리는 “우울한 사람들(Downers)”라고 불렀는데 그들은 프로세스의 하부(Downstream)에서 일하기 때문이었다.
두 팀은 약간의 변형을 가하기는 했지만 애자일 방식에 따라 작업을 진행했다. “우월한 사람들” 팀은 6주 보다 더 긴 반복 사이클을 수행한 반면, “우울한 사람들” 팀은 2주간의 반복 사이클을 수행했다. 그러나 어쨌든, 팀의 모든 사람들은 애자일 방식에 대한 어느 정도의 열정을 가지고 있었다.
계속해서 우월한 사람들이 우울한 사람들과 일을 그렇게 잘 맞춰나가지 못하고 있었다. 우월한 사람들의 팀에는 긴급한 위기 상황이 닥치는 적도 여러 번 있었고, 이로 인해 우울한 사람들의 반복 주기가 진행되고 있음에도 불구하고 그들에게 피치 못할 높은 우선순위의 작업을 할당하기도 했었다. 우월한 사람들이 수행하는 작업이 회사에서 가장 중요한 일이었기 때문에, 우울한 사람들은 이를 수용할 수 밖에 없었다.
어느 날, 나는 우울한 사람들이라고 부르는 프로세스의 하부를 맡고 있는 팀의 한 사람과 대화를 나누고 있었다. 그를 도니(Donny)라고 부르자.
나는 도니에게 우월한 사람들과 우울한 사람들 사이에서 발생하고 있는 문제의 근본적인 원인이 뭐라고 생각하느냐고 물었다. “아 물론, 그건 우월한 사람들 때문이죠!”라고 도니가 대답했다. “그들은 다른 팀을 눈곱만큼도 존경하지 않아요! 그들은 이 회사가 자기들 것 인줄 알아요!”
그 대답에 나는 도니에게 당신이 만약 우월한 사람들의 입장이라면 어떻게 대답할 것인지 상상할 수 있겠느냐 라고 물어보았다. “물론이죠. 문제 없어요. 난 한때 거기서 일한 적이 있기 때문에, 그 사람들이 어떻게 이야기할지 잘 알죠.”라고 도니가 대답했다. 나는 그 대답에 놀랄 수 밖에 없었다. “내가 우월한 사람이었을 땐, 정말 명백하게 문제는 우울한 사람들에게 있었어요. 하지만 지금은 내가 정말 이 회사가 어떻게 돌아가는지를 잘 알게 되었고, 그 결과 진짜 문제는 우월한 사람들에게 있지 우울한 사람들에게 있는 것이 아니라는 것을 알게 된 것이죠!”
나는 도니가 “시스템이 아니라 사람을 비난함(Blame the Person, not the System)”이라고 부르는, 또 다른 애자일 신드롬에 빠져있는 것이 아닌지 의심하지 않을 수 없었다. 도니는 자신이 어느 팀에 속하든지 상관없이, 시스템에 문제가 있다고 생각하는 대신 단지 그가 속한 팀이 아닌 다른 팀에 문제가 있다고 생각하고 있는 것이다. 여기서 시스템은 단지 소프트웨어 애플리케이션을 의미하는 것이 아니라, 그 회사의 문화를 포함해 두 팀이 서로 상호작용하는 모든 수단을 의미하고 있는 것이다. 아마도 이 회사에는 이런 갈등을 야기하는 총체적인 시스템의 문제가 있었을 것이며, 이러한 시스템의 문제가 “다른 사람들의 잘못”으로 오해되고 있었을 것이다.
만약 우리가 누구의 잘못인가(힌트: 정답은 항상 ‘다른 사람’이다)를 결정하기 위해 서로 비난하는 행태에 빠지는 것보다 “자, 다같이 시스템 상의 문제를 수정해 봅시다”라는 태도를 견지한다면, 우리는 좀 더 나은 발전을 이루어 낼 수 있을 것이다.
증상 4 - 내가 뭘 해야 하는지 말씀만 해주세요, 보스
(Just Tell Me What to Do, Boss)
내가 다니고 있는 회사인 필라테크놀러지(Pillar Technology)는 개발자를 채용하는 데 아주 엄격한 프로세스를 도입하고 있다. 이 프로세스 중에는 채용 대상인 유망한 개발자가 테스트 주도 개발을 수행할 능력이 있는지 검증하기 위해, 숙련된 전문가 한 명과 짝을 이루도록 하는 과정이 있다.
한 번은 내가 이러한 면접을 관찰할 수 있는 기회가 있었다. 어느 유망한 채용 후보가 면접실로 들어와 우리 회사의 전문가와 함께 앉았다. 그 채용 후보를 에모(Emo)라고 부르도록 하자. 우리가 테스트 하려는 부분이 테스트 주도 개발 프로세스이므로, 우리 회사의 전문가는 에모에게 현존하는 코드와 유닛 테스트를 살펴보고, 어떻게 해야 테스트를 통과할 수 있는지 설명해 보도록 했다.
테스트는 무척 간단한 것이었다. 테스트 코드는 몇 개의 입력값이 주어지더라도, 입력값이 입력된 이후 반환되는 변수가 항상 “12”와 같은 값이어야 한다고 요구했다. 에모가 테스트 코드를 살펴보더니, 코드를 뒤집어 엎어버리기 시작했다. 한 번 슥 코드를 살펴본 다음, 그는 커서를 옮기더니 코드 모두를 지워버렸다! 그리고 그 자리에 반환 변수(The return variable)가 항상 “12” 값을 가지도록 코드를 작성했다. 그리고 에모는 옆 자리의 전문가를 보고 별 것 아니라는 듯 한 번 씩 웃기까지 했다.
이것이 내가 본 가장 짧은 페어링 인터뷰이면서, 또한 가장 오랫동안 사람들의 입에 오르내리고 있는 인터뷰이기도 하다.
에모는 “내가 뭘 해야 하는지 말씀만 해주세요, 보스(Just Tell Me What to Do, Boss)”라고 부르는 애자일 신드롬에 빠져있었던 것이다. 만약 우리 팀의 모든 구성원들이 단지 보스가 가리키는 방향으로만 가려 한다면, 우리는 심각한 문제에 빠지게 될 것이다. 각각의 구성원들이 각각의 문제에 대해 그들이 가진 최대한의 지식과 역량을 반영해야 할 필요가 있다. 보스가 가리키는 방향으로만 가려고 하면, 우리는 에모가 인터뷰에서 한 것과 동일한 행동을 하게 될 것이다.
더구나 사람들은 쉽게 이런 사고 방식에 빠져들고는 한다. 강압적인 매니저일수록 이런 유형의 팀 구성원들을 쉽게 만들어내는데, 이는 사람들이 정확하게 매니저가 원하는 것 외에 다른 것을 하기를 두려워하기 때문이다. 또한, “당신은 무엇을 해야만 한다”라고 너무 자세하게 명세 되어 있는 문서들도 이러한 유형의 구성원들을 만들어내기 십상이다.
팀 구성원들이 이런 수동적인 마음가짐을 가지지 않도록 하기 위해 모든 수단을 강구할 필요가 있다.
증상 5 - 사람과 팀의 경쟁(Competition Between People and Teams)
어느 텔레콤 회사의 부사장은 수하에 항상 훌륭한 성과를 내는 애자일 팀 여섯 팀을 거느리고 있다. 어느 날 그에게 훌륭한 아이디어가 떠올랐다. 매달 상을 내걸고 팀을 경쟁시킴으로써, 그 스스로 “다른 사람들의 콧대를 납작하게 할 만큼 성과를 올릴 수 있겠다(kick it up a notch)”라는 것이었다.
이 부사장을 에머릴(Emeril)이라고 부르자.
에머릴은 가장 빠른 속도로 작업을 마치는 한 팀에게 일주일 동안 공짜 점심을 제공하겠다고 약속했다.
경쟁이 시작됐다. 팀들은 즉시 교묘하게 경쟁에서 이길 수 있는 방법을 찾아보기 시작했다. 그들은 스토리포인트(Storypoint)[1]를 적게 설정하면 할수록, 초과근무 없이도 더 많은 성과를 낼 수 있다는 것을 깨달았다. 부사장이 뭔가가 잘못되어가고 있다는 것을 느낄 때까지, 팀들은 몇 달 동안이나 “스토리포인트 인플레이션(Storypoint inflation)[2]”에 빠져들었다. 결국 그는 모든 스토리포인트가 동일한 값을 가지도록 지시할 수밖에 없었다.
그러자 팀들은 품질과 결함이 성과 측정의 대상이 아님을 깨달았고, 각각의 이터레이션(Iteration)마다 테스팅에 할애하던 시간을 줄이기 시작했다. 아니나 다를까, 포인트는 다시 올라가기 시작했고, 결함의 개수도 마찬가지였다. 이번에도 부사장이 직접 나서서 결함도 성과 측정의 대상에 포함된다고 선포했다. 더 많은 결함이 발견될수록, 팀은 더 낮은 점수를 받게 된 것이다.
이로써 모든 것이 다 해결된 것처럼 보였다. 하지만 부사장은 테스터 역시 팀의 일원이라는 사실을 망각하고 있었다. 그들 역시 공짜 점심을 먹을 수 있는 자격이 있었다. 따라서, 부사장의 세 번째 조치에 의하면, 부사장은 테스터들에게 “너무 많은 결함을 찾지 마세요. 그렇게 되면 공짜 점심을 얻을 수 없습니다”라고 말하는 것과 마찬가지였다.
이런 상황이 계속 이어졌다. 당신은 아마 이런 경쟁이 그리 도움이 되지 않았을 것이라고 쉽게 예측할 수 있을 것이다. 그리고 팀 사이에 자연스럽게 이루어졌던 협력 관계도 사라지게 되었다. 왜 우리가 우리 비용을 들여서 다른 팀을 도와줘야 하는가?
부사장은 “사람과 팀의 경쟁(Competition Between People and Teams)”이라고 부르는 애자일 신드롬에 얽매여 있는 것이다. 사람들, 혹은 팀들을 경쟁에 몰아넣고, 그들이 당신이 바라는 목표를 달성하리라는 기대를 안고 있지만, 그렇게 함으로써 조직은 안에서부터 스스로 파괴될 수도 있는 것이다.
다섯 가지의 증상 – 다섯 가지의 이야기(Five Symptoms – Five Stories)
이런 문제들은 애자일 팀을 확장하거나 유지하는 과정에서 충분히 발생할 수 있는 일들이다. 그리고 이러한 모든 문제들은 근본적으로 애자일의 핵심인 “사람”을 단순한 “기계”로 간주함으로써 발생하는 것들이다.
이렇게 기계적으로 수행되는 애자일을 해결하는 데는 린(Lean) 개발방법, 간판(Kanban) 시스템[3]이나 식스 시그마(Six Sigma), 혹은 그 어떤 새로운 기법들도 도움이 되지 않을 것이다. 아무리 뛰어난 스크럼이라 해도 도움이 되지 않을 것이다. 더 많은 회의를 한다고 해도 시간 낭비일 뿐이다. 오직 사람을 기계로 생각하는 사고를 전환시키는 것만이 이러한 문제를 해결하는데 도움을 줄 수 있을 것이다.
도움이 될만한 몇 가지 아이디어들(Some Ideas That May Help)
여기에 팀의 능력을 향상시키고 이를 유지할 만한 몇 가지 의견을 제시하고자 한다. 여기 제시되는 해결 방법들은 다섯 가지 증상에 대한 각각의 해결책을 의미하는 것은 아니다. 여기 제시된 모든 해결책이 제시된 모든 증상을 해결하는 데 도움은 될 수 있을 것이다.
l 만약 당신이 길가에서 ‘최고의 방법’을 발견한다면 – 그 즉시 못본척 하라[4].
“최고의 방법(Best Practice)”이라는 개념은 모든 것을 맹목적으로 바꾸어놓을 공산이 크다. 이런 개념은 우리가 앞서 논의했던 애자일 전문가 신드롬을 유발할 가능성이 무척 크다.
당신이 다른 곳에서 수행된 사례들을 배우고 이를 당신이 처한 환경에 맞게 시험해 보는 것을 하지 말라는 이야기가 아니다. 나는 단지 그것을 맹목적으로 따르려고 해서는 안 된다는 것을 말하고 싶을 뿐이다(I’m saying that you shouldn’t do it blindly).
“최고의 방법”을 맹목적으로 따르는 것은 항상 문제를 일으키기 마련이다. 다른 곳에서 사용된 사례를 이해하고, 그 다음엔 “그 방법이 여기서는 어떻게 동작하게 되지?(How can that work here?) 여기에 딱 맞게 하려면 어떻게 변경시켜야 되지?(How do we need to change it to fit?)”라는 의문을 반드시 가져야 한다.
l 의사 결정과 실제 작업 사이의 간격을 좁혀라
(Close the Gap Between Decision-Making and the Work)
SEPG 전문가들의 이야기에서 살펴본 바와 같이, 의사 결정 프로세스가 실제로 작업을 하는 사람들로부터 멀어지기 시작하면서 문제가 발생한다. 그 거리가 멀어지면 멀어질수록, 문제는 더욱 커지기 마련이다. 따라서 의사 결정 프로세스를 가능한 한 실제 작업과 가장 가까운 거리에서 수행할 필요가 있다. 만약 어떤 이유로 이것이 분리되어 있다면, 가능한 한 최대한 실무와 가까운 곳에서 의사 결정이 이루어지도록 노력해야 한다(가급적이면 동일한 팀 내에서 이루어지는 것이 좋다).
l 팀 사이의 벽을 허물어라(Break Down the Boundaries Between Teams)
관리자의 가장 큰 의무 중의 하나가 팀 사이의 벽을 허무는 것이다. 팀들끼리 서로 경쟁하게 만드는 것이 바로 그런 벽을 만들어 내는 것이다. 또한 “모든 것은 나를 통해야 해”라고 말하는 관리자들 역시 다른 부서와 의사 소통하는데 장벽을 만든다.
최고의 애자일 관리자라면, 이런 사람들 사이의 경계를 허물고, 팀이 다른 팀이나 그룹, 혹은 다른 부서와 아무런 제한 없이 커뮤니케이션 할 수 있는 방법을 찾으려 노력해야 할 것이다.
l 조직화되지 않은 것들도 소중하게 생각하라(Value the Unstructured)
우리는 아주 자주, 어떤 문제에 직면했을 때 이를 해결하기 위해 뭔가를 조직하려고 한다. 두 애자일 팀이 조금 더 많은 의사소통을 할 필요가 있지 않을까? 그렇다면 “Scrum of Scrums[5]” 회의를 마련해보라.
그러나, 조직화되지 않은 것들에게도 가치를 부여하고 정당한 평가를 수행해야 할 필요가 있다. 때로는 더 많은 조직, 더 많은 회의, 더 많은 역할, 더 많은 문서, 더 많은 조정이 없이도 문제를 해결할 수 있는 방법을 찾으려 노력하는 것, 그것만으로도 가치 있을 때가 있다.
이런 일들을 통해 우리가 처한 상황을 우리 스스로 개선하도록 마음가짐을 바꿀 수 있지 않을까? 만약 그렇다면, 우리는 우리의 마음가짐을 바꾸기 위해서 무엇을 해야 할까? 어떻게 우리 팀 안에서 작업을 진행하는 방식과 조직 문화를 바꿔야 하는 것일까?
l 과도한 엔지니어링을 피하라(Avoid Over-Engineering Your Process)
우리는 종종 어떻게 소프트웨어가 만들어지는지를 설명하기 위해 ‘소프트웨어 엔지니어링’이라는 단어를 사용하고는 한다. 한 번 만들어진 소프트웨어는 당연히 어느 정도 기계적이 될 수밖에 없고, 따라서 우리 스스로 마치 어느 정도 기계 같은 무엇인가를 만든다는 생각을 하게 되는 것도 소프트웨어 개발을 묘사할 때 어느 정도 합리적인 것처럼 보인다.
그러나, 이러한 사고 방식은 우리가 엔지니어 프로세스를 진행하려고 할 때도 문제를 야기할 수 있다. 내가 여러분들에게 들려주었던 이야기에서도 볼 수 있듯이, 프로세스가 단순히 반복적이고 기계적인 것으로 변해서는 안 된다. 프로세스는 살아 움직이며, 숨을 쉬고, 또한 수월하게 받아들일 수 있는 것이어야 한다. 이렇듯 살아있는 프로세스를 만드는 유일한 방법은, 항상 개선의 여지를 만들어놓고 사람들이 하고 싶은 대로 하는 것이 가장 적합한 행동을 하는 것이라고 여기도록 만들어 주는 것이다. 사람들이 정말 사람답게 행동하도록 해주는 것, 그리고 우리가 사람들을 위해 만들었던 기계적인 모델에 그들을 밀어 넣도록 강요하지 않는 것이 무엇보다 가장 중요하다.
[1] 역자 주: 유저 스토리(User story)를 등급별로 분류하고 이에 대해서 점수를 매기는 것. 대체로 간단하고 쉽게 구현할 수 있는 기능일수록 점수가 낮다.
[2] 역자 주: 중요하지 않은 기능을 중요한 기능인 것처럼 부풀려 스토리포인트를 높였다는 이야기로 사료됨
[3] 역자 주: 토요 타의 생산 방식. 한자인 간판의 일본어 발음을 영어로 표기해 “Kanban”이라고 쓴다. 소프트웨어 개발에 있어서는 스크럼에서 사용되는 포스트 잇과 같이, 단일 기능을 표시하는 종이 쪽지 등을 간판으로 간주하기도 한다. 간판 시스템에 대한 참조는 여기에. http://bit.ly/bt9Qmj
[4] 역자 주: 원문은 “Kill it”이라고 되어 있으나 일부러 유연한 표현을 사용했음.
[5] 역자 주: 스크럼을 사용하는 프로젝트 끼리의 동기화를 위한 스크럼 미팅이라고 이해하고 있음
'QA' 카테고리의 다른 글
| 리스크 기반 테스팅 - Part 1 (2) | 2010.06.21 |
|---|---|
| 리스크 기반 테스팅 - Part 2 (2) | 2010.06.21 |
| 효율적인 테스트 케이스 작성법 - 직관적으로 질문하라 (10) | 2010.05.10 |
| 누가 소프트웨어 품질을 책임질 것인가? (2) | 2010.04.28 |
| 생활 속의 QA - Early Testing (4) | 2010.04.20 |
