XP란 무엇인가?
자신을 보호하기 위해 뭔가를 유보해두는 오래된 습관은 효과가 없다.
마지막 20%의 노력을 쓰지 않고 남겨두는 것이 나를 지켜주지 않는다.
프로젝트가 실패한다면, 내 모든 것을 다 쏟아 붓지 않았다고 해서 내 기분이 좋아지지 않는다
프로젝트를 성공시킬 수 없었다는 실패감에서 나를 보호해주지는 않는다.
하지만 최선을 다했다면 나는 여전히 자신에 대해 만족감을 느낄 수 있다.
이런 태도를 취한다면 상황이 어떻든 안전함을 느낄 수 있다.
내가 어떻게 느끼는지가 내가 최선을 다했느냐 아니냐에 달려 있다면, 최선을 다하기만 한다면 언제나 자신에 대해 만족감을 느낄 수 있기 때문이다. 1
XP 팀은 성공을 위해 온힘을 쏟아부으며, 나온 결과에 대한 책임을 받아들인다. 자신이라는 인간의 가치를 프로젝트에 매어놓지 않는다면, 어떤 상황에서라도 최고의 작업을 할 수 있다. XP에서는 실패를 준비하지 않는다.
인간관계에서 약간 거리를 두는 것, 일을 너무 적게 하거나 많이 함으로써 노력을 유보해 두는 것, 책임 소재를 한 번 더 흐리기 위해 피드백을 미루는 것, 이런 행동 가운데 어떤 것도 XP 팀에는 있을 자리가 없다.
제약조건에 대해 불평을 늘어놓는 것은 목표로부터 주의를 분산시킬 뿐이다. 여러분의 명료한 자아는 제약조건이 어떻든 최고의 일을 할 수 있다.
어떤 프로젝트를 완수할 시간이 6주로 정해졌다면, 조절할 수 있는 유일한 요소는 자신의 행동뿐이다. 6주어치의 일을 해낼것인가 아닌가? 다른 사람의 기대를 조절할 수는 없다. 그러나 그들의 기대를 현실 상황가 맞추도록 프로젝트에 대해 여러분이 알고 있는 것들을 그들에게 말해 줄 수는 있다.
다른 사람의 기대를 ‘관리’하는 것은 내 일이 아니다.
자기들의 기대를 관리하는 것은 그들 몫이다.
최선을 다하고 의사소통을 명확하게 하는 것이 나의 몫이다.
XP가 위험에 대처하는 방법 2
- 일정 밀림: XP는 아무리 길어도 몇 달인 정도로 릴리즈 주기가 짧아야 한다. 그래야 일정이 밀리는 정도에 한계가 있다.
일주일 단위로 iteration을 통해 고객이 요청한 기능을 구현하고 프로젝트 진정에 대한 피드백을 주고 받는다.
가장 우선순위가 높은 기능부터 구현해야 한다. 따라서 릴리즈때 어떤 기능이 구현되지 못했다 해도 그 기능은 가치가 낮은 기능일 것이다. - 프로젝트 취소: XP는 팀의 비즈니스 구성원들에게 비즈니스에 가장 중요하면서도 가장 작은 릴리즈를 고르라고 요구한다. 따라서 배치전에 잘못될 가능성은 더 적어지고 소프트웨어 가치는 언제나 최고를 유지한다.
- 시스템 이상: XP는 포괄적인 자동화 테스트 suite를 만들고 유지하며, 이 테스트들은 품질 기준을 유지하기 위해 시스템에 변화가 생길 때마다(하루에도 몇 번이나 생긴다) 돈다.
- 결험 비율: XP는 함수 단위로 테스트를 작성하는 프로그래머, 그리고 프로그램 기능 단위로 테스트를 작성하는 고객 둘 다의 관점에서 테스트를 한다.
- 비즈니스에 대한 오해: XP에서는 비즈니스 쪽 사람들도 팀의 당당한 정규(first-class) 구성원이 되어야 한다. 프로젝트의 명세는 개발 과정 중에도 끊임없이 다듬어지기 때문에, 고객과 팀이 배운 것들이 소프트웨어에 그대로 반영될 수 있다.
- 직원 교체: XP에서는 자신의 일을 추정하고 완료하는 책임을 받아들여야만 한다/ 그리고 추정이 더 정화해질 수 있도록 실제 걸린 시간을 피드백해주며, 구성원이 내린 추정을 존중해 준다. XP는 팀 안에서 인간적인 접촉을 장려함으로써, 일에 대한 불만족의 핵심 요인이 되는 직원들의 외로움을 줄여주기도 한다. 직원 교체에 대한 대처법이 명시적인 모델로 포함되어야 한다. 교체하는 과정에서 격려와 기존 구성원들의 도움을 받는다.
XP란 무엇인가?
- XP는 오래되고 효과가 없는 사회적 습관들을 버리고 새로운 습관들로 채택하는 것이다.
- XP는 오늘 내가 기울인 모든 노력에 대해 자신을 인정해 주는 것이다.
- XP는 내일은 좀 더 잘해보려고 애쓰는 것이다.
- XP는 팀 전체가 공유하는 목표에 내가 얼마나 기여했는지를 잣대로 자신을 평가하는 것이다.
- XP는 개발을 하는 중에도 인간적 욕구의 일부를 채우겠다고 요구하는 것이다.
XP 팀에게 중요한 것
의사소통
개발 과정에서 문제가 생겼을때 누군가 이미 그 문제의 해결책을 알고 있는 경우가 정말 많다. 하지만 그런 지식이 문제 해결을 만들 사람에게 전달되지 못하곤 한다.
어떤 문제에 맞닥뜨린 경우, 이 문제가 의사소통의 부재 때문에 생긴 게 아닌지 자신에게 질문해 보라. 이 문제를 해결하려면 어떻게 의사소통해야 할까?
단순성
XP의 가치 가운데 가장 지적인 가치다. 우아하게 해결할 만큼 단순한 시스템을 만드는 것, 어려운 일이다.
제대로 작동할 만한(효과가 있을 법한) 가장 단순한 것은 뭘까? 이 질문의 비판자들은 이 질문의 앞 절반을 놓치는 듯 하다.
“매우 중요한 보안과 안정성 제약 조건을 지켜야 하기 때문에 절대로 우리 시스템을 단순하게 만들 수 없을 것 같군요.” 지나치게 단순해서 일이 제대로 되지 못할 방법을 생각하라고 요구하는 것이 아니다.
생각의 불필요한 복잡성을 제거하는 쪽으로 기울이라는 것이다.
만약 보안 문제 때문에 원래대로라면 프로세서 하나로도 될 시스템을 프로세서 두 개로 분할해야 한다면, 내가 이해하는 한도 안에서는 그 결과가 단순한 방법이다. 이것보다 더 좋은 해결책은 그 보안 문제를 프로세서 하나만 쓰면서도 해결할 방법을 찾을 수 있는 경우에만 존재할 수 있다.
따라서 단순성의 의미는 상황에 따라 결정된다.
만약 내가 파서를 작성하는데 내가 속한 팀이 파서 생성기라는 개념을 이해하고 있다면, 파서 생성기를 사용하는 것이 단순한 것이다.
만약 팀이 파싱에 대해 아무것도 모르고 파싱해야 할 언어가 간단하다면, 재귀적 하향 파서가 더 단순한 것이다.
의사소통을 개선하면 불필요한 요구사항이나 뒤로 미룰 요구사항을 제거할 수 있으므로 단순성에도 도움이 된다.
단순성을 지니면 그만큼 의사소통해야 할 것도 줄일 수 있다.
피드백
소프트웨어의 세부사항, 시스템의 요구사항 혹은 아키텍처든 고정된 것은 없다. 특히 경험해 보기 전에 정해진 방향은 수명이 짧다. 변화는 불가피하지만, 변화는 피드백을 필요하게 만든다.
Footnotes
-
언제나 나는 모든 일에 내 영혼을 실어 최선을 다하고 싶은 마음과 그렇게 했을때에 대한 왠지 모를 두려움이 앞설어 그 주변을 배회하며 스멀스멀 알게 된 것에 스스로를 자위하며 내 안의 불을 소화하는 삶을 살았다. 그러나 결국 마지막에 남는 것은 어떠한 공허감과 자신에 대한 불만족이다. 이 불만족은 나에게 보내는 신호이다. 이 상황이 계속 반복되며 어느 순간 이 불만족만 사라지고 드라마의 배경 인물이 되는 순간 나의 영은 빛을 잃고 이 우주의 한 조각 데이터 쪼가리가 된다. 지금 바로 이 순간부터 내 의지가 향하는 방향대로 삶을 살아야 비로소 내 스스로에게 만족하고, 스스로가 완성에 이르는 길에 첫 시작을 떼는 것이다. ↩
-
이제는 에이전트에 이러한 원칙을 적용하는 것이 좋을 것 같다. ↩