2장. 운전하는 법 배우기
소프트웨어는 모든 것이 변한다. 요구사항, 설계, 비즈니스, 기술, 팀 등 모든것이 변한다. 또 한, 고객은 시스템이 해결해야 하는 문제가 어떤 것인지를 대강 알고 있지만, 문제를 해결하기 위해 소프트웨어가 정확히 어떤 일을 해야 하는지는 알지 못한다. 이런 상황에서 변화를 극복하지 못하는 것은 큰 문제가 된다.
XP는 빈번하게 작은 수정을 거친다. 즉, 스프트웨어의 배치(deploy) 간격을 짧게 유지하고 목표를 향해 전진하게 해서 변화에 적을할 수 있게 한다. 혹여 잘못된 길에 들어서도 머지않아 그것을 깨달을 수 있게 해준다.
3장. 가치, 원칙, 실천방법
많은 기술과 뛰어난 솜씨를 가지고 있는 수준에서의 지식과 이해를 실천방법이라 하자. 실천 방법은 첫 발을 내딛는 지점이 되어주기 때문에 유용하다. 이런 실천 방법을 가지고 있는 상태로 고도로 발단된 감각을 가지고 있다면, 이 감각으로 인해 많은 것을 간단하고 명백하게 파악할 수 있다면, 이 수준의 지식과 이해를 가치라 하자. 가치는 우리가 보고, 생각하고, 실행하는 것을 판단하기 위해 사용하는 큰 규모의 척도다.
가치를 명시하지 않는다면, 실천은 목적을 잃어 기계적인 활동이 된다. 가치는 실천방법에 목적을 부여한다.
실천방법은 가치의 증거다. 가치는 추상적인 개념이라 어디에든 갖다 붙일 수 있다. 그에 반해 실천 방법은 명확하다. 누군가가 어떤 가치를 중요시할 때 그 사람이 실천 방법을 계속 실천하는지 여부를 구체적으로 알 수 있다. 따라서 가치는 실천방법에 목적을 부여하고, 실천방법은 가치에 책임을 부여한다.
원칙은 가치와 실천방법 사이를 잇는 다리다. 원칙은 특정한 영역에서 영원한 지침이 된다.
이 책은 xp에 대한 가치, 원칙, 실천방법을 제시한다.
4장. 가치
소프트웨어 개발자는 각자가 중요시하는 관점을 가지고 있다. 하지만, 팀 단위로 작업을 할때는 개인의 행동에 초점을 맞추는 것보다, 팀의 일원이나 조직의 일원으로 어떻게 행동하는지가 중요하다. 그러면 팀에게 중요한 것은 무엇일까? XP에서는 개발을 이끌기 위해 의사소통, 단순성, 피드백, 용기, 존중이라는 가치를 포용한다.
의사소통
개발 과정에서 문제가 생겼을 때 누군가는 그 해결책을 알고 있을 수 있다. 하지만, 의사소통의 부재로 인해 문제를 해결할 힘이 있는 사람에게 의션이 전달되지 못하곤 한다. 또 한, 의사소통 부족이 아닌 지식 부족으로 문제가 발생해도 의사소통은 유용하다. 문제가 발생했을 때, 문제 발생의 이유를 찾은 다음 어떻게 해야 문제의 재발을 방지할지를 이야기해볼 수 있다.
단순성
단순성은 XP의 가치 가운데 가장 강력하게 지적이다. 단순성은 최대한 시스템을 단순하게 만들면서 불필요한 복잡성을 줄이는 것이다. 의사소통을 개선하면 불필요한 요구사항이나 뒤로 미룰 수 있는 요구사항을 제거할 수 있으므로 단순성을 성취하는 데 도움이 된다. 단순성을 성취하면 의사소통해야할 것도 줄인다.
피드백
경험해 보기 전에 결정한 방향은 수명이 짧다. 변화는 불가피하고, 변화는 피드백을 필요하게 만든다.
한번에 완벽한 해결책을 만들면 좋겠지만, 요구사항 등 많은 것들이 시시각각 바뀌기 때문에 완벽한 해결책을 만들기란 쉽지 않다. 따라서 점진적 개선을 하고 피드백을 이용해 목표에 가까워져야 한다. 피드백은 팀원의 의견, 테스트 성공 여부 다방면으로 들어온다.
XP팀은 최대한 빠른 주기로 많은 피드백을 만들기 위해 노력한다. 만약 피드백 양이 너무 많아 제대로 대응할 수 없다면, 피드백 주기 속도를 늦추고, 팀의 피드백 양 초과의 이유를분석하라.
피드백은 의사소통의 핵심이다. 피드백을 통해 놀랍도록 단순한 해결책에 도달할 수 있다. 반대로, 시스템이 단순해야 시스템에 대한 피드백을 빠르게 받을 수 있다.
용기
팀원이 개인의 두려움을 어떻게 다루는지가 개인이 팀원으로의 효율을 결정한다. 하지만, 다른 가치 없이 용기만 존재한다면 위험하다. 결과를 생각하지 않고 일을 진행하는 것은 효과적인 팀워크가 아니다. 용기는 다른 가치들과 조화를 이룰 때 강력해진다. 진실을 말하는 용기는 의사소통과 신뢰를 키운다. 나쁜 관습을 버리고 새로운 해결책을 찾는 용기는 단순함을 북돋운다. 진짜 답변, 구체적인 답변을 추구하는 용기는 피드백을 낳는다.
존중
팀의 구성원들과 프로젝트를 존중하지 않는다면 XP가 아니다. 소프트웨어 개발과 맞닿아 있는 모든 사람은 동등한 가치를 지닌다. 소프트웨어 개발에서 생산성과 인간성을 동시에 개선하려면, 팀에 속한 모든 개인의 기여를 존중해야 한다. 모든 사람이 중요하다.5
다른 가치들
의사소통, 단순성, 피드백, 용기, 존중은 XP를 이끄는 가치다. 팀은 이 가치들 외에 다른 가치들 역시 선택할 수 있다. 그저 팀이 추구하는 가치에 팀의 행동이 어울리기만 하면 된다. 다른 중요한 가치로는 안전성, 보안, 예측가능성, 삶의 질 등이 존재한다.
가치는 소프트웨어를 만들 때 구체적인 지시사항을 알려주지 않는다. 가치와 실천방법 사이의 간극 때문에 이 둘을 이어줄 다리가 필요하다. 원칙이 바로 이 다리이다.
5장. 원칙
가치는 너무나도 추상적이여서 행동의 직접적인 지침이 되지 못한다. 따라서 가치가 아닌 원칙들을 행동의 지침으로 삼아야 한다. XP의 지침이 되는 원칙들은 다음과 같다.
인간성
소프트웨어를 개발할 떄 팀원이 인간으로서 가지는 욕구를 충족시키지 못하는 경우가 존재한다. 이런 현상은 결국 높은 이직률, 많은 비용, 업무 중단 등을 초래한다. 팀원의 인간성을 존중하기 위해서는 그저 팀에서 떨어져 있을 시간을 주면 된다. 이런 시간들은 개인이 더 많은 에너지와 더 넓은 시야를 얻게 하고, 이것들을 팀으로 가져오게 한다. 즉, 업무 시간에 제한을 두면 된다.
팀 단위 개발에서 개인의 욕구와 팀의 욕구의 균형을 맞추는 것이 중요하다. 하지만, 이 균형을 위해 사생활을 업무시간에 노출하는 것은 좋지 않다. 팀을 위해 자신의 욕구를 희생하는 것은 좋지 않지만, 팀에 해를 끼치지 않으면서도 자신의 욕구를 충족시킬 방법을 찾아야 한다.
경제성
팀이 하는 일이 비즈니스 가치를 지니고, 비즈니스 목표에 부합아며, 비즈니스 필요를 충족해야 한다.
돈은 시간적 가치, 시스템과 팀의 선택적 가치가 소프트웨어 개발에 영향을 주는 경제성 두 측면으로 나뉜다. 시간적 가치는 오늘의 천원이 내일의 천원보다 가치있는 것이다. 즉, 돈은 더 일찍 벌어들이고 지불을 나중에 하는 소프트웨어가 더 가치있다. 소프트웨어 개발의 두 번째 경제적 가치는 미래의 선택사항을 늘리는 것이다. 특정 목적으로 설계된 프로그램을 다른 곳에서도 사용할 수 있다면, 훨씬 가치있는 소프트웨어가 된다.
상호 이익
모든 활동은 그 활동에 관련된 모든 사람에게 이익이 되야 한다. 한쪽이 손해를 보는 해결책은 사람간의 감정을 손상시키기 때문에 손해다. 컴퓨터 비즈니스는 사람 장사다, 원활한 인간관계를 유지하는 것은 매우 중요하다. 또 한, 현재의 이익과 미래의 이익을 모두 신경써야 한다. 미래의 누군가를 위해 대량의 문서를 작성하는 것은 개발 속도 저하를 야기하기에 현재의 이익을 희생한다.
XP는 이런 문제를 다음과 같은 방식으로 해결한다.
1. 더 나은 설계를 위해 테스트를 구현하고 미래를 위해 테스트를 남겨둔다.
2. 우발적 복잡성을 제거하기 위해 신중한 리펙터링을 한다. 이는 만족감을 주며, 결함 수를 줄이고 다른사람이 코드를 이해하기 쉽게 한 다.
3. 일관성 있고 명시적인 이름을 쓴다. 그러면 개발 속도가 높아지고, 다른 사람이 코드를 쉽게 읽을 수 있다.
XP의 상호 이익 원칙은 내게 지금 이익이 되고, 나중에도 이익이 되고, 내 고객에게도 이익이 되는 실천방법을 찾는 것이다.
자기 유사성
어떤 해결책의 구조를 다른 맥락에, 심지어 규모의 차이가 있더라고 그대로 적용할 수 있다. 예를 들어, 실패하는 테스트를 작성하고, 그 테스트를 통과하도록 하는 구조는 분기 단위에서 해결하고 싶은 주제들을 목록으로 만들고, 그걸 다시 스토리 여러개로 만드는 식으로 적용할 수 있다.
자기유사성이 소프트웨어 개발에서 언제나 효과적인 원칙은 아니다. 때로는 효과적인 구조가 다른 상황에서는 효과를 발휘하지 못한다. 그럼에도 어떤 일을 시작하기에 좋은 방법임은 확실하다.
개선
소프트웨어 개발에 있어서 완벽은 존재하지 않는다. XP의 주기는 오늘할 수 있는 최선을 다하고, 내일 더 잘하기 위한 깨달음과 이해를 구하기 위해 노력하는 것이다. 예를 들어, ‘분기별 주기’ 실천 방법은 장기 계획은 경험에 비추어 개선될 수 있다는 가능성의 표현이다.
완벽해질 때까지 기다리지 말고 개선을 실천하라. 어떤 것부터 시작하면 좋을지 찾아보고, 일단 시작한 다음 거기서부터 차츰 개선하라.
다양성
개발 팀 구성원이 모두 비슷한 사람이라면, 문젯거리와 해결책을 생각해내기 어렵다. 팀 안에는 다양한 종류의 기술, 사고받식, 시야들이 모여있어야 한다.
다양성이 있으면 갈등이 따라온다. 이 갈등은 하나의 문제에 대해 두 개 이상의 해결책이 나올때 발생한다. 이런 상황에서 XP의 다양성 원칙은 프로그래머가 문제를 해결하기 위해 협동하고 두 의견을 모두 존중할 것을 권한다. 이 권유를 기본으로 하되 갈등을 어떻게 생산적으로 풀 수 있는지를 고려해야 한다. 다른 사람을 존중하면서 자신에게도 충실하다면 스트레스가 쌓이는 상황에서도 원활한 의사소통이 가능하다.
반성
좋은 팀은 일만 하지 않는다. 어떻게, 왜 일을 하는지도 생각한다. 자신들이 성공한 이유화 실패한 이유를 분석하고 들어낸다. XP의 주기에는 팀 반성 시간도 포함되지만, 반성을 꼭 정해진 시간에만 해야 하는 것은 아니다. 모든 시간에 지금 일하는 방식에 대해 의문을 갖고 개인적인 반성을 할 수 있다.
반성은 머리와 감정 두가지를 필요로 한다. 부정적인 감정이 든다면 그 감정에 대해 귀를 기울여라. 지성으로 조율된 감정은 통찰력의 원천이다.
흐름
소프트웨어 개발에서 흐름은, 개발의 모든 단계를 동시에 작업해 가치 있는 소프트웨어를 물흐르듯이 끊임없이 제공하는 것이다. XP의 여러 실천 방법은 분리된 단계보다 끊임없는 행동들의 흐름으로 기울어 있다. 간혹, 이 흐름을 방행하는 문제가 발생할 수 있다, 이때는 흐름에서 잠시 벗어나도 괜찮다. 하지만, 흐름을 방행한 문제가 해결됬다면 되도록 빨리 원래의 흐름대로 돌아와야 한다.
기회
가끔씩은 문제를 기회로 볼 줄도 알아야 한다. 단순히 생존할 정도로만 문제를 해결하는 것은 뛰어난 실력을 갖추는데 도움이 되지 않는다. 문제를 배움의 기회로 전환할 줄 알아야 한다.
XP를 실천하면 여러 문제를 만나게 된다. 이때, 이 문제들을 개인적 성장의 기회, 더 깊은 인간관계를 맺을 기회, 더 개선된 소프트웨어를 만들 기회로 전환하겠다고 결심하는 것이 익스트림(extreme)한 행동의 일부다.
잉여
소프트웨어 개발에서 핵심적이면서도 해결하기 어려운 문제에는 해결방법을 여러 개(잉여를) 마련해 놓아야 한다. 잉여를 만드는 데는 자원이 소모된다. 하지만, 잉여를 만들기 위해 소모되는 자원이 잉여의 부재로 발생한 재앙으로 치루는 자원보다 적다. 예를 들어 소프트웨어의 결함은 핵심적이면서도 해결하기 어려운 문제다. 이를 위해 XP에서는 페어 프로그래밍, 지속적인 통합, 진짜 고객 참여 등을 사용한다. 그리고, 이들 중 일부는 잉여다.
실패
무엇을 해야 할지 모르겠다면, 실패를 감수하고 일단 시도하라. 실패를 감수하는 것이 성공으로 가는 가장 빠른 길이다.
실패는 자원의 허비가 아니다. 실패가 지식을 늘려준다면, 실패는 자원의 허비가 아니다. 지식은 귀중한 것이다.
품질
품질을 희생하는 것을 프로젝트 관리 수단으로 삼지 말라. 품질은 제어할 수 있는 수단이 아니다. 품질의 우수성은 프로젝트 속도와 관련이 없다. 프로젝트를 계획하고, 기록을 남기고, 방향을 잡기 위해 품질 대신에 범위(scope)를 선택하라. 일주일별 주기, 분기별 주기는 기록을 남기고 범위를 선택하기 위한 명시적인 지점을 제공한다.
품질에 대한 걱적으로 무위도식하지 말라. 확실한 방법을 모르겠다면 방법들 중 가장 최선이라 생각되는 것을 적용하라. 만약 확실한 방법이 많은 시간을 요구하고 시간이 충분치 않다면, 적절한 시간을 요구하는 방법들 중 최선의 방법을 선택하라. 그 후, 추후에 그 확실한 방법을 적용시켜라.
아기 발걸음
큰 발걸음으로 큰 변화를 만들지 말라. 단계를 잘게 쪼갤 때(아기 발걸음으로 갔을 때) 생기는 부하(overhead)가, 큰 변화를 시도했다가 실패해서 다시 원상태로 돌아갈 때 드는 낭비보다 훨씬 작다.
아기 발걸음으로 간다는 의미는 굼뜬 변화를 한다는 의미가 아니다. 조건이 갖추어 졌을 때, 사람들과 팀들은 많은 작은 단계를 빠른 속도로 밟아 난가서 마치 도약하는 것처럼 보인다.
받아들일 책임
책임감은 오직 책임질 마음이 있는 사람들만 받아들일 수 있다. 그리고, 책임감을 느낄 지는 자신만이 선택할 수 있다.
책임을 받아들인다면, 그 일에 대해 모든 책임을 지어야 한다. 예를 들어, 스토리를 구현할 책임을 진다면, 그 사람은 스토리의 설계, 구현, 테스트까지 모든 책임을 지어야 한다.
권위와 책임은 바늘과 실이다. 책임과 권위가 잘못 연결된다면, 팀의 의사소통이 외곡된다. 권위가 있다면 책임도 함께 지어야 한다.
결론
원칙을 이용하면 실천방법들을 더 잘 이해할 수 있다. 목적에 맞는 실천방법이 없다면, 원칙을 이용해 새로운 실천방법을 고안할 수 있다. 원칙이 없다면, 실천방법이 아무리 명확하게 쓰여져 있어도 그 문장을 분명히 이해할 수 없다.
6장. 실천 방법
가치를 통해 목적을 불어넣지 않은 실천방법은 기계적으로 따르는 규칙일 뿐이다. 기계적인 실천방법은 아무런 의미를 가지지 않는다. 따라서 가치를 우선적으로 생각하고 원칙을 통해 실천방법을 만들고 사용하라.
실천방법은 상황에 따라 달라진다. 상황이 바뀌면 그에 맞추어 다른 실천방법을 골라야 한다. 하지만, 가치는 변할 필요가 없다. 원칙은 문제 영역(domain)이 달라졌다면 새로운 원칙을 추가해야 할 수도 있다.
XP의 실천 방법들 중 절대적인 것들은 없다. 그저 개선을 할 수 있는 방법들 중 하나일 뿐이다. XP의 실천방법들은 여러 실천 방법이 조합 될 떄 그 효과가 증폭된다.
출처 - 익스트림 프로그래밍