Contents

    1. 1장. XP란 무엇인가?
  2. 1부. XP 탐험하기
    1. 2장. 운전하는 법 배우기
    2. 3장. 가치, 원칙, 실천방법
    3. 4장. 가치
    4. 5장. 원칙
    5. 6장. 실천방법
    6. 7장. 기본 실천방법
    7. 8장. 시작하기
    8. 9장. 보조 실천방법
    9. 10장. 전체 XP팀
    10. 11장. 제약이론
    11. 12장. 계획 짜기: 범위를 관리하기
    12. 13장. 테스트: 일찍, 자주, 자동화
    13. 14장. 설계하기: 시간의 가치
    14. 15장. XP 확장
    15. 16장. 인터뷰
  3. 2부. XP의 철학
    1. 17장. 창조 이야기
    2. 18장. 테일러주의와 소프트웨어
    3. 19장. 도요타 생산 시스템
    4. 20장. XP 적용하기
    5. 21장. 순수성
    6. 22장. 해외 개발
    7. 23장. 시간이 지나도 변치 않는 프로그래밍 방식
    8. 24장. 공동체와 XP
    9. 25장. 결론
    10. 주석을 단 참고문헌

1장. XP란 무엇인가?

XP는,

이런 변화를 불러일으키기 위해 무엇을 해야 할까? 그게 경제적으로 효과가 있는 것이기는 할까? 이 책의 나머지 부분에서 그런 것들을 탐구할 것이다.

이 책은 두 부분으로 나뉘어 있다.

  1. 실용적인 부분. 인간적 욕구들을 감안할 뿐 아니라 충족도 시켜주는 소프트웨어 개발 실천 및 사고 방법을 설명한다.
  2. XP의 철학적, 역사적 뿌리를 다루고, XP를 현재의 맥락 속에 위치시킨다.

1부. XP 탐험하기

2장. 운전하는 법 배우기

운전은 그냥 목적지를 맞추어두고 그대로 두는게 아니다. 계속 신경을 쓰면서 이쪽으로 조금, 저쪽으로 조금씩 방향을 고치면서 가는 것이다.

이것이 XP의 패러다임이다. 깨어 있고 적응하며 변하는 것.

소프트웨어의 모든 것은 변한다. 요구사항도, 설계도, 비즈니스도, 기술도, 팀도. 변화는 반드시 일어나기 때문에, 문제가 되는 것은 변화 자체가 아니다. 변화를 극복하지 못하는 우리의 무능력이 문제다.

운전 메타포는 XP에 두 가지 차원으로 적용된다. 고객은 시스템 내용의 방향을 결정한다. 그리고 개발 팀은 개발 프로세스의 방향을 결정한다. XP는 작은 수정을 빈번히 하도록 한다. 그러면 변화에 적응할 수 있고, 잘못된 길에 들어섰을 때 금방 알아차릴 수 있다.

고객이 시스템 내용의 방향키를 잡듯, 전체 개발팀은 개발 프로세스의 방향키를 잡는데, 이것은 현재 쓰는 실천들의 집합에서 시작된다. 개발을 진행하면서 팀은 현재 자기네 프랙티스 중 어떤 것이 팀을 목표 쪽으로 이끄는지, 어떤 것이 멀어지게 하는지 깨닫는다. 프랙티스 하나하나가 효율성, 의사소통, 자신감, 생산성을 개선하는 실험이다.

3장. 가치, 원칙, 실천방법

정원을 가꾸는 기본적인 기술들은 책 한 권만 읽으면 쉽게 익힐 수 있지만, 그것만으로는 정원사가 되지는 못한다. 폴(전문가)과 나(초보자)의 차이는 무엇일까?

폴은 더 많은 기술을 알고 있으며, 심지어 내가 알고 있는 기술일지라도 폴의 솜씨가 더 뛰어나다. 이 수준에서의 지식과 이해를 실천방법(practice)이라고 말할 수 있다. 실천방법은 우리가 매일 하는 그러한 일이다.

그 뿐 아니라, 폴은 정원 일에서 어떤 것이 좋고 나쁜지에 대해 고도로 발달된 감각을 가지고 있다. 그가 이런 것을 느낄 수 있는 까닭은 나보다 가지치기를 잘해서가 아니라, 정원에서 작용하는 여러 힘들에 대한 전반적인 감각이 뛰어나기 때문이다. 내가 생각하고 궁리해야 알 수 있는 것이 그에게는 간단하고 명백한 것이다. 이 수준의 지식과 이해를 가치(value)라고 부를 수 있다.

가치를 명시하는 일이 중요한 까닭은, 가치가 없이는 실천이 기계적인 활동, 아무런 목적이나 방향도 없이 그냥 그렇게 하라니까 하는 것이 되어버리기 쉽기 때문이다.

실천방법은 명확하다. 내가 아침에 스탠드업 미팅을 했는지 안했는지는 누구나 알 수 있다. 그러나 내가 정말 의사소통을 가치 있게 여기는지는 애매하다. 내가 의사소통을 강화하는 실천방법을 계속 실천하는지는 구체적으로 알 수 있다. 가치가 실천방법에 목적을 부여하듯, 실천방법은 가치에 책임을 부여한다.

가치는 보편적이다. 하지만 실천방법은 어떤 상황이냐에 따라 완전히 달라져야 한다.

가치와 실천방법 사이를 잇는 다리가 원칙이다. 원칙은 특정한 영역에서 영원한 지침이 되는 것이다. 폴은 인접한 식물이 서로 약점을 보완해야 한다는 '같이 심기'의 원칙을 이해하고 있다. 금잔화는 딸기를 먹는 해충 가운데 몇몇을 자연스레 쫓아낸다.

책을 읽는다고 XP 프로그래머가 될 수는 없다. 익스트림 스타일로 프로그래밍하고, XP의 가치를 공유하며, 여러분의 실천방법 가운데 일부를 공유하는 사람들의 공동체에 참여하고, 여러분이 아는 것을 다른 사람과 공유해야만 익스트림 프로그래머가 될 수 있다.

4장. 가치

정원 일에 조예가 깊은 폴은 다음에 무슨 일을 해야 할지 직관적으로 안다. 폴은 어떤 것이 중요하며 어떤 것이 중요하지 않은지 본능적으로 안다. 새겨져 있는 것이다.

내가 이랑을 똑바로 파는 것을 중요하게 여겨서, 그것에 심혈을 기울인다. 지나가다 그걸 본 폴이 한 마디 한다. '왜 그렇게 열심히 이랑을 반듯하게 만들려고 들어? 진짜 필요한 일은 퇴비를 더 많이 주는 거야."

내가 가치 있게 생각하는 것과 정말로 가치 있는 것 사이의 차이에서 낭비가 생긴다. 윌 로저스는, '문제는 자네가 모르는 것 때문에 생기는게 아니야. 잘못 아는데서 생기지'라고 말했다.

팀에게 중요한 것이란 무엇일까? XP는 개발을 이끌기 위한 다섯 가지 가치를 포용한다.

의사소통

팀 소프트웨어 개발에서 가장 중요한 것은 의사소통이다. 팀 내에서의 지식의 전파가 안되는 문제, 지식이 부족해서 생기는 문제 등.

물론, 의사소통만으로 되는건 아니다. 그냥 친교모임을 만들자는건 아니니까. 팀이 지키는 다른 가치들이 그렇게 되지 않도록 막아준다. 하지만 의사소통 없는 움직임은 전진이 아니다.

단순성

XP의 5가지 가치 중에서, 가장 지적인 측면의 가치다.

제대로 작동할만한 (효과가 있을 법한) 가장 단순한 것은 뭘까? 여러분의 생각을 불필요한 복잡성을 제거하는 쪽으로 기울여라.

다른 가치들과의 관계:

피드백

고정된 방향이 오랫동안 유효한 경우는 없다. 변화는 불가피하고, 변화는 피드백을 필요하게 만든다.

처음에 아예 제대로 하는게 훨씬 쉽지 않을까?

그렇기 때문에, 한번에 완벽하게 해결하기보다는 점진적 개선에 만족하기 때문에, 우리는 피드백을 이용해 목표에 점점 더 가까이 다가간다.

XP팀은 팀이 다룰 수 있는 한도 내에서 최대한 빨리, 최대한 많은 피드백을 만들기 위해 노력한다. 그 주기를 주 단위나 월 단위가 아니라, 분 단위나 시간 단위로 줄이기 위해 노력한다. 빨리 알수록 빨리 적응할 수 있기 때문이다.

피드백의 양이 너무 많을 때에는, 팀이 중요한 피드백들에 미처 대응하지 못할 수 있고, (속도를 늦추는 것이 아무리 불만스러울지라도) 피드백 주기의 속도를 늦춰야 한다. 그리고 피드백 초과를 불러들인 근본 원인들을 해결할 수 있다.

다른 가치들과의 관계:

용기

용기는 두려움에 직면했을 때 가장 효과적인 행동이다.

다른 가치들과의 관계:

존중

만약 팀의 구성원들이 서로 고려하지 않고 다른 사람이 하는 일들에 신경을 쓰지 않는다면, 제대로 XP를 할 수 없다.

자기 삶이 소프트웨어 개발과 맞닿아 있는 모든 사람은 인간으로서 동등한 가치를 지닌다. 소프트웨어 개발에서 생산성과 인간성을 동시에 개선하려면, 팀에 속한 모든 개인의 기여를 존중해야 한다. 나도 중요한 사람이고 당신도 중요한 사람이다.

다른 가치들

위의 다섯 가지 가치만이 소프트웨어를 효과적으로 개발하게 할 수 있는 가치는 아니다. 이것들은 XP를 이끄는가치다. 여러분의 조직, 팀, 자신은 다른 가치들을 선택할 수도 있다. 제일 중요한 것은 팀이 신봉하는 가치에 팀의 행동이 부합하도록 만드는 것이다. 그렇게 하면 여러 가치 집합을 동시에 유지하려고 노력할 때 생기는 낭비를 최소로 줄일 수 있다.

5장. 원칙

의사소통이 중요한 가치라고 하는 경우에도, 긴 문서를 만드는 목적도 의사소통을 위해서이고, 매일 나누는 대화 역시 의사소통을 위해서이다. 그렇다면 둘 중 어느 것이 가장 효과적인 방법일까? 이는 상황에 따라, 부분적으로는 지적인 원칙에 따라 달라진다.

XP의 지침이 되는 원칙들을 정리했다.

인간성

소프트웨어는 인간이 개발한다. 소프트웨어를 개발할 때, 우리는 흔히 인간으로서 가지는 욕구를 충족시켜 주지 않고, 인간이 약한 존재임을 인정하지 않으며, 인간의 장점을 살리려고 들지 않는다. 그들의 인간성은 인간적 욕구를 인정하지 않는 비인간적인 프로세스 때문에 마모되어 버린다. 이것은 비즈니스 측면에서도 좋지 않다. 높은 이직률은 많은 비용과 업무 중단을 초래하며, 또 사람들이 창조력을 발휘할 기회도 놓치게 만들기 때문이다.

경제성

경제성을 인정하지 않는 소프트웨어 개발은 '기술적 성공'이라는 공허한 승리만 얻을 위험이 있다.

돈의 시간적 가치란, 오늘의 천원이 내일의 천원보다 가치가 있다는 것이다. 돈은 더 일찍 벌어들이고 비용은 더 나중에 지불하는 소프트웨어 개발은 가치가 있다. 점진적 설계 실천 방버에서는 돈 쓰는 일을 뒤로 미루기 위한 노력의 일환으로, 명시적으로 설계에 대한 투자를 끝내 해야만 하는 순간까지 미룬다.

또한, 미래의 선택사항을 늘리는 데서 오는 가치도 있다. 만약 내 미디어 일정관리 프로그램을 다양한 일정 관련 작업용으로 재배치할 수 있다면, 원래 목적 기능으로만 쓰는 것보다 훨씬 가치가 있다.

상호 이익

모든 활동은 그 활동에 관련된 모든 사람에게 이익이 되어야 한다. 이는 가장 중요한 XP의 원칙이지만 가장 고수하기 힘든 원칙이기도 하다. 어떤 문제든, 한쪽에는 이익이 되지만 다른 쪽에는 손해가 되는 해결책이 있게 마련이다. 상황이 급할 때는 이런 해결책들에 끌리기 쉽지만, 결과적으론 손해다. 왜냐면 그런 해결책을 사용했을 때 생겨나는 편치 않은 감정들이, 우리가 소중하게 여겨야 할 관계들을 손상시키기 때문이다.

여러분의 제안을 사람들이 수용하기 원한다면, 그것이 야기하는 문제의 수보다 그것이 해결해 주는 문제의 수가 더 많아야 한다. XP의 상호 이익의 원칙은 내게 지금 이익이 되고, 나중에도 이익이 되고, 내 고객에게도 이익이 되는 실천방법들을 찾는 것이다.

자기유사성

어느날 나는 사르디니아 섬의 해안선을 따라 걷고 있었다. 작은 조수 웅덩이를 하나 보았는데, 직경은 60센티미터쯤 되고 모양은 그리2처럼 생겼다. 고개를 들어보니 내가 걷고 있는, 직경이 1.6킬로미터쯤 되는 만이 그 웅덩이와 대충 비슷한 모양이라는 것이 눈에 들어왔다. '자연의 지리에 프랙탈 성질이 있음을 보여주는 못진 예로군.'하고 속으로 생각했다. 이 모양은 사실 섬 전체 지도의 북서쪽 모서리 부분에서도 찾아볼 수 있다. 자연은 어떤 형태가 효과적이라는 사실을 발견하면, 그 형태를 이용할 수 있는 곳이라면 어디에나 그것을 이용한다.

동일한 원칙이 소프트웨어 개발에도 적용된다. 어떤 해결책의 구조를 다른 맥락에, 심지어 규모에 차이가 있는 다른 맥락일지라도 그대로 적용해 보라. 예를 들어 보자. 개발의 기본 흐름은 일단 실패하는 테스트를 작성하고, 그 다음으로 그 테스트를 통과하도록 만드는 것이다. 이 흐름은 여러 다른 규모에서도 그대로 작용한다. 분기 단위에서는, 해결하고 싶은 주제들을 목록으로 만들고 그걸 다시 스토리 여러 개로 만들어 해결한다. 일주일 단위에서는, 해결하고 싶은 스토리들을 목록으로 만들고, 그 스토리들을 표현하는 테스트들을 작성하고, 그런 다음 그 테스트들을 통과하도록 만든다. 몇 시간 단위에서는, 여러분이 작성해야 할 필요가 있다고 생각하는 테스트들을 목록으로 만들고, 테스트를 하나 작성하고, 그 테스트를 통과하도록 만들고, 다른 테스트를 작성하고, 두 테스트 모두 통과하도록 만들고 하면서 목록이 비워질 때까지 일한다.

자기유사성이 소프트웨어 개발에서 언제나 효과를 발휘하는 원칙은 아니다. 한 맥락에서 효과적인 구조가 다른 상황에서도 반드시 효과적이라는 법은 없다. 그래도 어떤 일을 시작하기에 좋은 방법이긴 하다. 마찬가지로, 어떤 해결책이 유별난 것이라고 반드시 나쁜 것은 아니다. 상황에 따라 정말로 유별난 해결책이 필요한 경우도 있다.

개선

소프트웨어 개발에서는 '완벽하다'는 없고 '완벽해지도록 노력한다'만 있다. 완벽한 프로세스는 없다. 완벽한 설계도, 스토리도 없다. 그러나 완벽하게 만들려고 노력하는 것은 가능하다.

가치를 실천방법으로 옮기는 과정에서, 어떤 행동을 바로 시작하되 결과는 오랜 시간에 걸쳐 다듬는 실천방법들 속에서 개선의 원칙이 드러난다.

발전된 기술은 소모적 노력을 제거하고 있는 반면, 개발 조직에서 끊임없이 심해지는 완고성과 사회적 구조의 분화는 점점 더 소모적이 되어간다. 개선의 열쇠는 이 둘을 화해시키는 것, 곧 새로 발견한 기술적 효용성을 이용해 새롭고 더 효과적인 사회관계를 가능케 하는 것이다.

완벽해질 때까지 기다리지 말고 개선을 실천하라. 어떤 것부터 시작하면 좋을지 찾아보고, 일단 시작한 다음 거기서부터 차츰 개선하도록 한다.

다양성

소프트웨어 개발 팀에서 모든 구성원이 비슷비슷한 종류의 사람이라면 같이 지내기는 편안해도 개발에는 효과적이지 않다. 문젯거리와 함정들을 발견하려면, 문젯거리들을 해결할 방법을 여러 가지 생각해 내려면, 생각해낸 해결책들을 실제로 구현하려면, 팀 안에 다양한 종류의 기술, 사고방식, 시야들이 모여 있어야 한다. 팀에는 다양성이 필요하다.

다양성이 있으면 갈등도 따라오기 마련이다. "우리는 서로 싫어하기 때문에 함께 일할 수 없어" 같은 종류의 갈등이 아니라, "이걸 해결하는 방법은 두 가지야" 같은 종류의 갈등이다. 두 방법 중 무엇을 선택해야 할까?

어떤 설계에 대한 생각이 두 가지 나왔다면, 이것은 문제가 아니라 기회다. '다양성'의 원칙은 프로그래머가 문제를 해결하기 위해 협동할 것과, 두 의견을 모두 존중할 것을 권한다.

갈등이 없는 팀은 없다. 관건은 갈등을 생산적으로 풀 수 있는가이다. 다른 사람을 존중하면서 자신에도 충실하다면 스트레스가 쌓이는 상황에서도 원활한 의사소통을 할 수 있다.

반성 (reflection)

좋은 팀은 그저 일만 하지 않으며, 어떻게 일하는지, 왜 일하는지도 생각한다. 그들은 자신들이 왜 성공했으며 왜 실패했는지 분석한다. 좋은 팀은 실수를 숨기려 하지 않고 오히려 실수를 드러내서 거기에서 배운다. "아무 생각 없이 그저 일하다 보니 잘하게 되었다"라고 말할 수 있는 사람은 존재하지 않는다.

분기별 주기, 일주일별 주기에는 팀 반성(회고)의 시간도 포함된다. 하지만 반성은 '공식' 기회에만 하는 것이라고 선을 그어서는 안된다. 친구와 대화할 때, 일과 상관 없는 독서나 활동을 할 때, 이 모든 시간들이 어떻게 그리고 왜 지금 일하는 방식으로 일하는지 생각해 볼 개인적인 반성의 기회를 제공한다. 함께 식사나 커피를 하는 휴식 시간은 함께 반성을 해볼 수 있는 비공식적인 자리를 마련해 준다.

반성이 이성적인 활동만은 아니다. 본능적 감각에서도 배울 수 있다. 예로부터 두려움, 분노, 걱정 같은 '부정적인' 감정들은 뭔가 안 좋은 일이 생길 것이라는 단서가 되어 왔다. 일에 대해 감정이 해주는 충고에 귀를 기울이게 되려면 노력해야 하지만, 지성으로 조율된 감정은 통찰력의 원천이 된다.

반성은 행동한 다음에 온다. 배움이란 행동이 반성을 거친 것이다. 피드백을 최대화하기 위해, XP 팀에서는 실천과 반성을 뒤섞는다.

흐름

소프트웨어 개발에서 흐름이란, 개발의 모든 단계를 동시에 작업함으로써 가치 있는 소프트웨어를 흐르듯이 끊임없이 제공하는 것이다. XP의 여러 실천방법은 분리된 단계들보다 끊임없는 행동들의 흐름 쪽으로 기울어 있다. 흐름의 원칙은 개선을 위해 가치를 조금씩, 점진적으로, 계속해서, 자주 배치하라고 권한다.

기회

'생존'에만 집착하는 태도는 일을 무사히 넘길 정도까지만 문제를 해결하도록 만든다. 뛰어난 실력을 갖추려면, 문제를 단지 생존의 문제가 아니라 배움과 개선의 기회로 전환할 줄 알아야 한다.

XP를 실천하기 시작하면서 분명 여러 문제를 만나게 될 것이다. 어떤 문제가 오더라도 그것을 기회, 곧 개인적 성장의 기회, 더 깊은 인간관계를 맺을 기회, 더 개선된 소프트웨어를 만들 기회로 전환하겠다고 의식적으로 결심하는 것은 익스트림한 행동의 일부다.

잉여

소프트웨어 개발에서 핵심적이면서도 해결하기 어려운 문제에는 해결방법을 여러 개 마련해 놓아야 한다. 그러면 해결방법 중 하나가 완전히 실패하더라도 다른 것들 덕분에 재앙은 면할 수 있다. 잉여를 만들기 위해 드는 비용보다 재앙을 면할 수 있어 얻는 이득이 더 크다.

잉여를 만들려면 자원이 소모되긴 한다. 그래도 정당한 목적이 있는 잉여를 제거하지 않도록 조심해야 한다. 개발이 종료된 다음에 하는 테스트 단계는 분명 잉여다. 그렇더라도 결함이 하나도 발견되지 않는 성공적인 배치가 실전에서 여러 번 연속되어 이것이 진짜로 잉여적인 것으로 판명나기 전까지는 테스트를 그만두면 안된다.

실패

성공하는데 어려움을 겪는다면, 실패하라. 실패는 자원의 허비가 아닌가? 실패가 지식을 늘려주는 한, 그것은 허비가 아니다. 지식은 귀중한 것이며, 쉽게 얻기 어려운 때도 있다. 실패를 피하지 못할 수도 있다. 무엇을 해야 할지 모를 경우, 실패를 감수하는 것이 성공으로 가는 가장 짧고 확실한 길이다.

품질

품질은 제어할 수 있는 변수가 아니다. 낮은 품질을 감수한다고 프로젝트가 빨라지지 않는다. 높은 품질을 요구한다고 프로젝트가 느려지지도 않는다. 품질이 향상될수록 생산성이나 효율성 같은 다른 바람직한 프로젝트의 속성들도 개선되었다.

품질은 경제적 요인만으로 설명할 수 없다. 사람은 자부심을 느낄 수 있는 일을 해야 한다.

품질이 프로젝트 관리의 수단이 아니라면, 프로젝트를 무엇으로 관리해야 할까? 시간과 비용 역시 대개 바꾸기 힘들다. 따라서 XP는 프로젝트를 계획하고, 기록을 남기고, 방향을 잡기 위한 주요 수단으로 범위를 선택한다. 범위는 미리 정확하게 알 수 없기 때문에, 좋은 관리 수단이 된다.

아기 발걸음

중요한 변화를 한번에 몰아서 시도하는 것은 위험하다. 변화 요구의 대상은 다른 것이 아니라 바로 사람들이다. 변화는 안정을 뒤흔든다. 사람들이 변할 수 있는 속도에는 한계가 있다.

받아들인 책임

책임감은 누구에게 할당할 수 있는 성질의 것이 아니다. 책임감은 오로지 책임질 마음이 있는 사람이 받아들일 수 있을 뿐이다.

책임이 있는 곳에는 권위도 따라온다. 책임과 권위가 잘못 연결되면 팀의 의사소통이 왜곡된다.

6장. 실천방법

실천방법 그 자체만으로는 공허하다. 가치를 통해 목적을 불어넣지 않은 실천방법은 기계적으로 따르는 규칙일 뿐이다.

어떤 실천방법을 적용할지는 여러분의 선택이다. 나는 여기 있는 실천방법들이 더 효율적으로 프로그래밍할 수 있게 해준다고 생각한다.

그렇다고 XP의 실천방법이 무슨 궁극의 것은 아니다. 이것들은 개선으로 향하는 길에 놓인 평범한 정류장들이다. XP의 실천방법들은 함께 사용했을 때 효과가 좋다.

실천방법

7장. 기본 실천방법

이 실천방법 가운데 어떤 것을 먼저 쓸지는 전적으로 여러분의 환경, 그리고 여러분이 어디를 가장 개선하고 싶어하는지에 달려 있다.

함께 앉기

개발 작업은 팀 전체가 들어가기 충분할 정도로 크고 열린 공간에서 하라. 사생활 욕구와 '나만의' 공간 욕구는 가까운 곳에 작은 사적 공간들을 만들어 놓거나 업무 시간에 선을 그어 놓아 다른 곳에서 사생활 욕구를 충족시킬 수 있도록 해서 해결한다.

팀이 사무실의 여기 저기에 흩어져 있게 되면, 팀이 하루에 상호작용하는 시간이 매우 적어질 수 있다.

필요하다면 '함께 앉기'를 조금씩 천천히 진전시켜도 좋다. 개인 공간에 편한 의자를 가져다 놔보고, 하루의 절반을 회의실에서 프로그래밍해보고, 일주일간 회의실을 빌려보기도 하고.

팀이 준비되기도 전에 파티션을 허물면 생산성이 오히려 낮아진다. 팀 구성원의 안정감이 자신만의 공간과 연결되어 있다면, 분노와 저항만 낳게 된다.

'함께 앉기'라는 실천법은, 리모트 팀은 XP를 하지 못한다는걸 뜻하지는 않는다. 실천방법은 이론이고 예측이다.

전체 팀

프로젝트가 성공하기 위해 필요한 기술과 시야를 지닌 사람들을 전부 팀에 포함시킨다. 이 생각은 사실 복합기능팀 (cross-functional team)이라는 옛날 개념을 그대로 빌려온 것이다.

사람들은 '팀'에 속한다는 느낌이 필요하다.

말콤 글래드웰은 팀 규모의 지속성이 끊어지는 두 지점을 제시한다. 12와 150이 그것이다.

12명은 하루에 하루에 모두와 편안하게 의사소통할 수 있는 사람들의 수. 150명이 넘으면 모든 팀원들의 얼굴을 기억할 수 없다. 이 두 한계 지점을 넘으면 신뢰를 유지하기 힘든데, 신뢰는 협력을 하려면 반드시 필요하다. 프로젝트의 규모가 클 경우, 문제를 쪼개서 여러 팀으로 구성된 팀이 해결할 수 있도록 하는 방법을 찾는다면 XP를 대규모로도 적용할 수 있다.

(C3 프로젝트의 규모는 얼마였을까? )

어떤 경우에는 한 사람을 여러 팀에 소속시키기도 한다. 그러나 이렇게 되면 생각이 분산된다. 소속감이 약해지고, 같이 정체성을 둘 다른 프로그래머들이 없어서 '팀'에 속해있다는 느낌이 파괴된다. 그리고 생산성을 떨어뜨린다.

프로그래머들을 제대로 된 팀으로 묶기만 해도 즉각 개선 효과를 볼 수 있다. 이 팀은 저 고객의 요구에만 응답한다. 이렇게 되면 프로그래머는 분산된 생각에서 해방된다. 고객은 전체 팀의 전문성을 필요한 만큼 누릴 수 있다는 이익을 얻는다.

정보를 제공하는 작업 공간

작업 공간을 작업에 대한 것들로 채워라. 프로젝트에 관심이 있는 관찰자라면 누구든지 팀이 사용하는 공간에 들어와서 15초 안에 프로젝트가 어떻게 진행되는지 대략 감을 잡을 수 있어야 한다.

활기찬 작업

생산적으로 일할 수 있는 정도의 시간만, 그리고 일의 활력을 유지할 수 있는 정도의 시간만 일해라. 오늘을 비생산적으로 하루 종일 혹사시키고 다음 이틀 동안 작업을 망치지 말아라.

일하는 시간은 똑같다고 해도 같은 양의 시간을 더욱 잘 활용하라. 날마다 통째로 두 시간을 '코딩 시간'으로 선언하라. 전화기와 이메일 알림 기능을 끄고 두 시간 동안 프로그래밍만 한다. 지금으로써는 이 정도도 만족스러운 개선이 될 수 있으며, 이것은 나중에 일하는 시간을 더 줄이기 위한 발판이 되어줄지도 모른다.

짝 프로그래밍

짝 프로그래밍은 둘이서 동시에 프로그래밍을 (그리고 분석과 설계와 테스팅도) 하면서 프로그램을 더 낫게 만들려고 노력하는 두 사람 사이의 대화다. 짝 프로그래머들은,

스토리

고객이 볼 수 있는 기능을 단위로 해서 계획을 짜라. 어떤 스토리를 작성한 다음에는 그것을 구현하기 위해 필요한 개발 노력을 추정해 본다.

소프트웨어 개발은 '요구사항'이라는 말 때문에 잘못된 길로 빠져 버렸다. 이 말에는 절대적이고 영속적인 어감이 들어 있는데, 이것은 변화를 포용하지 못하게 가로막는다.

스토리 실천방법과 다른 요구사항 실천방법들 사이의 핵심 차이점은 일찍 추정하기다. 추정에서 사업과 기술적 시야가 상호 작용할 기회가 생기는데, 이 기회를 통해 조기에 가치를 만들어 낼 수 있다. 팀이 여러 기능에 들어가는 비용을 알 경우, 팀은 기능들을 쪼개거나, 합치거나, 그 기능들의 가치에 대해 아는 것을 바탕으로 범위를 확장하거나 할 수 있다.

XP식 계획의 특징 하나는 계획의 매우 초기 단계에서 스토리 추정이 이루어진다는 것이다. 이것은 모든 사람이 어떻게 가장 적은 투자로 가장 많은 이익을 볼 수 있을지 생각하도록 만든다.

일주일별 주기

한 번에 일주일 분량의 일을 계획하라. 한 주를 시작하는 회의를 열며, 이 회의에서는 다음과 같은 일을 한다.

  1. 지금까지 진행된 상황을 검토하는데, 지난주의 실제 진행 정도가 예상 진행 정도를 달성했는지 역시 포함해 검토한다.
  2. 이번 주에 구현할 일주일 분의 스토리를 고객이 고르도록 한다.
  3. 스토리를 여러 과업(task)으로 쪼갠다. 팀 구성원들은 자기가 할 과업에 서명을 하고, 얼마나 걸릴지 추정한다.

스토리들이 완성되었을 경우 통과할 자동화 테스트들을 작성하는 것으로 한 주를 시작하라. 그것이 끝난 다음에 남는 시간을 스토리들을 완성하고 테스트를 통과할 수 있또록 만드는데 쓴다.

계획 짜기는 일종의 필요한 낭비다. 계획 짜기 자체만으로는 많은 가치를 창출해내지 못한다. 따라서 계획 짜는 데 들어가는 시간을 조금씩 줄이도록 노력해 본다. 어떤 팀들은 처음에는 일주일에서 하루를 온종일 계획 짜는데 바치는 것으로 시작하지만, 나중에는 주간 계획을 짜는데 한 시간만 써도 될 정도까지 점진적으로 계획 짜는 기술을 발전시킨다.

나는 스토리를 쪼개서 개인이 책임지고, 또 직접 추정하는 과업들로 만들기를 좋아한다. 나는 과업을 개인이 소유하도록 만드는 것이 인간의 소유욕을 충족시키는 데 큰 도움이 된다고 생각한다. 과업으로 쪼갤 필요가 없도록 스토리를 작게 만들어도 되지만, 대신에 고객이 더 많이 일해야 한다. 과업 스택을 사용한다면 서명을 하지 않아도 된다.

일주일 단위로 맥박치는 프로젝트 진행은, 팀과 개인 차원의 실험을 편리하고, 빈번히, 예측가능하게 할 수 있는 환경을 제공하기도 한다. 이번에는 이렇게 해볼까? 저렇게 해볼까?

분기별 주기

분기마다 한 번은, 팀, 프로젝트, 프로젝트의 진행 정도, 더 높은 목표와 지금 프로젝트의 방향 일치 여부 등을 놓고 숙고해 보도록 한다. 한 분기 계획에서는 다음과 같은 일을 한다.

여유

어떤 계획이든, 일정에 뒤쳐질 경우 포기할 수 있는 비교적 급하지 않은 과업들을 포함시켜라. 나중에 더 많은 스토리들을 추가해서 약속한 것보다 더 많은 것을 제공하는 일은 언제든지 가능하다.

여유(slack)의 구조는 여러 방식으로 만들 수 있다. 8주마다 한 주를 '괴짜 주간(geek week)'으로 삼을 수 있다. 한 주 예산의 20퍼센트를 프로그래머들이 고른 과업에 배당해 볼 수도 있다. 자신에게 여유를 주는 것에서 시작해야 할지도 모른다.

10분 빌드

10분만에 자동으로 전체 시스템을 빌드하고 모든 테스트를 돌려라. 빌드가 10분보다 오래 걸린다면 그것을 실행하는 횟수가 현격히 줄어들며, 따라서 피드백을 받을 기회를 놓치게 된다. 그리고 10분보다 짧은 빌드는 커피를 즐길 시간도 주지 않는다.

지속적 통합

변경한 것은 두세 시간 만에 통합하고 테스트해라. 팀 프로그래밍은 분할-정복할 수 있는 성질의 문제가 아니다. 통합 단계는 원래 프로그래밍 시간보다 더 많은 시간이 걸리곤 한다. 통합을 오래 미룰수록 비용이 더 들며 통합 비용을 예측하기도 더 힘들어진다.

비동기적 방식은, 체크인 후 빌드 시스템이 변경을 알아차리고 빌드와 테스트를 하는 방식이다.

나는 동기적 방식을 선호하는데, 2-3시간 정도 규모의 짝 프로그래밍 에피소드가 하나 끝날 때마다 짝과 함께 통합을 한다. 빌드가 완료되고 전체 테스트 스위트가 하나도 깨지지 않고 제대로 돌아갈 때까지 기다린 후에 다음 일을 진행해 나간다.

비동기적 통합은 일일 빌드 실천 방법에서 커다란 개선이지만, 동기적 방식을 쓸 경우에는, 컴파일과 테스트를 수행하는 것을 기다리는 동안에, 우리가 지금 막 함께 끝낸 것을, 그리고 어떻게 했더라면 더 잘할 수 있었을까 함께 이야기할 자연스러운 기회가 생긴다. 또 이 방식에서는, 피드백 주기를 짧고 분명하게 만들어야 한다는 긍정적인 압력도 받을 수 있다. 빌드를 너무 오래 기다리게 되면 빌드 시스템에 개선이 필요하다는 것을 알아챌테니 말이다.

테스트 우선 프로그래밍

코드를 한 줄이라도 변경하기 전에, 일단 실패하는 자동화된 테스트를 먼저 작성하라.

TDD 실천방법은 여러 문제를 동시에 해결해 준다.

점진적 설계

시스템의 설계에 매일 투자하라. 시스템의 설계가 바로 그날 그 시스템이 필요로 하는 것에 훌륭하게 들어맞게 되도록 애써라. 어떤 설계가 현재 최선의 설계인지 더 잘 이해하게 되었다면, 실제가 그것과 일치하도록 점진적으로, 하지만 지속적으로 작업한다.

나는 학교에서 이것과 정반대의 전략을 배웠다. '구현하기 전에 할 수 있는 한 모든 것을 설계해 놓아야 한다. 왜냐하면 구현을 시작한 후에는 설계를 바꿀 기회가 없기 때문이다.' (그러나) XP 팀은 소프트웨어를 변경하는 비용이 속수무책으로 상승하지 않는 조건들을 만들기 위해 열심히 노력한다. 자동화된 테스트, 지속적인 설계 개선의 실천, 명시적인 사회적 절차 등이 모두 변경 비용을 낮게 유지하는 데 기여한다.

설계를 사용하는 시점과 가까운 때에 설계하는 것이 더 효율적이다. 작동중인 시스템에 작고 안전한 보폭으로 변경을 주는 것에 대한 경험이 쌓이면, 설계 노력을 점점 더 뒤로 미룰 수 있게 된다. 그렇게 될수록 시스템은 더 단순해지고, 프로젝트의 진도는 더 일찍부터 나가기 시작하며, 테스트도 더 작성하기 쉬워지며, 쓰템이 더 작아지므로 팀에서 의사소통해야 할 정보의 양도 줄어든다.

-

이 실천방법들은 단순성과 용기를 불러일으키는 존중, 의사소통, 피드백의 기반을 제공한다. 팀원들은 늘어나는 자신감과 능력을 팀 안팎에서 관계들을 구축하는데 사용할 수 있다.

8장. 시작하기

XP를 어디에서 어떻게 시작해야 할까?

지금 서 있는 위치에서 시작해 여러분의 목표와 일치하고 여러분의 가치를 표현하는 실천방법들을 점차 추가하면서 적응해야 한다. 더 많은 실천방법들이 추가될수록 시너지가 생긴다.

한 번에 하나씩 바꾸는 방식으로 시작하는 것이 쉽다. 그러나 반드시 느린 속도로 변해야 하는 것은 아니다. 하지만 변화의 속도가 너무 빠르면 팀이 옛날 실천방법과 가치들로 미끄러져 돌아갈 위험이 높아진다. 새로운 습관들을 익히려면 시간이 걸린다.

제일 먼저 무엇을 바꿀지 어떻게 결정할까? 지금 여러분이 어떤 일을 하는지 그리고 무엇을 이루고 싶은지 살펴보라. 그리고 그 경로에 놓인 첫 번째 실천방법을 선택하라. 변화 계획을 XP 방식으로 짜보는 것 역시 한 가지 방법이다. 소프트웨어 개발 프로세스를 개선하기 위한 스토리들을 작성해보라. '빌드를 자동화한다.' '하루 내내 테스트부터 먼저 한다.' '길동씨와 두 시간 동안 짝 프로그래밍한다.' 그리고 각각 얼마나 걸릴지 추정해보라. 프로세스 개선에 쓸 예산이 얼마나 되는지 파악한다. 최초로 작업할 스토리를 고른다. 어떤 것이 쉽거나 가치 있는지, 어떤 것이 어려운지 발견하면서 적응해간다.

실천방법들의 지도 그리기

여기에 각각의 실천방법이 여러분과 여러분 팀에 어떤 의미를 지니는지 발견하기 위한 연습 문제가 하나 있다.

그림 8은 '활력 넘치는 작업' 실천방법의 지도다. 중앙에는 실천방법이 놓여 있다. 그 바로 아래에는 내가 생각하는 이 실천방법의 목적인, 일과 삶 사이의 균형을 유지하는 것이 그림으로 그려져 있다. 실천방법에 붙어 있는 가지들은 이 실천방법에 영향을 주는 요소들과, 이 그림의 경우 이 실천방법이 잘 되지 않을 때 나타나는 증상들이다. 어떤 실천방법을 생각할 때 마음속에 떠오르는 모든 것을 지도로 그려본다. 글로 쓰든 그림으로 나타내든 여러분 마음대로다.

9장. 보조 실천방법

이 장에 나오는 실천방법들은, 내가 생각하기에 기본 실천방법을 이미 완전히 하기 전에는 실행하기 어렵거나 실행하면 위험한 실천방법들이다. 예를 들면, 결함 비율을 0 가까이로 끌어내리지 않은 상태에서 '매일 배치' 실천방법을 시작한다면, 재앙을 불러들이는 셈이다.

진짜 고객 참여

여러분의 시스템에 따라 인생과 사업이 달라지는 사람들을 팀의 일원이 되게 한다. 통찰력이 있는 고객은 분기별 계획과 일주일별 계획에 참여할 수 있다. 그들은 일부 예산, 즉 가용 개발 능력의 일정 부분을 자신이 원하는 대로 할 수 있다. 만약 이들이 시장의 다른 사람들보다 6개월 먼저 문제점을 예측할 수 있는 사람이라면, 그들이 원하는 대로 시스템을 만드는 것이 여러분을 경쟁자보다 앞서게 만들어 줄 것이다.

내가 보기에는 '전체 팀'이란 생각에 고객 참여의 개념이 이미 들어가 있지만, 진짜 고객을 참여시킬 정도로 끝까지 나아간 팀을 나는 별로 보지 못했다. 진짜 고객과 함께라면 결과도 달라진다.

점진적 배치

최근에 친구에게서, 자체 개발한 시스템을 버리고 기성 패키지 제품으로 전환하려는 계획을 들었다. 그들의 계획은, 패키지 제품을 이용해 현재 기능을 다시 구현한 다음, 어느 일요일 밤을 기점으로 단 한번에 넘어가는 것이었다. 나의 즉각적인 반응은, '그 방식은 절대 먹히지 않아'였다.

그러면 그 대안은 무엇일까? 당장 다룰 수 있는 작은 기능이나 제한된 데이터 집합을 하나 찾는다. 그리고 배치한다. 파일을 두 시스템에서 나누어 처리하고 다시 합치거나, 일부 사용자들이 두 프로그램을 모두 사용하도록 훈련하거나 해서 두 프로그램을 동시에 돌릴 방법을 찾아야 한다.

팀 지속성

효율적인 팀은 계속 함께 하도록 하라. 대규모 조직에서는 사람을 사물로 추상화해서 넣었다 뺐다 할 수 있는 부품으로 보는 경향이 있다. 소프트웨어의 가치는, 사람들이 아는 것과 하는 것 뿐 아니라 인간관계와 사람들이 함께 성취하는 것을 통해서도 만들어진다.

작은 조직에는 이런 문제가 없다. 팀이 하나이기 때문이다. 팀에 엉긴 후에는, 일단 신뢰를 얻고 다른 사람을 신뢰하게 된 후에는, 함께 당하는 재난 외에는 팀을 갈라놓을 수 있는 것이 없다.

그렇다고 해서 팀에 전혀 변화를 주지 말아야 한다는 뜻은 아니다.

팀 크기 줄이기

팀의 능력이 신장되면, 작업량은 일정하게 유지하면서 점차 팀의 크기를 줄여라. 그러면 남은 사람으로 더 많은 팀을 만들 수 있다. 팀원이 너무 적다면, 너무 적은 다른 팀과 합친다. 이것이 도요타 생산 시스템에서 사용하는 실천방법이다.

근본 원인 분석

개발 후에 결함이 발견될 때마다, 결함과 그 원인을 모두 제거하라. 이 실천방법의 목표는 바로 그 결함이 다시 나타나지 않도록 만드는 것이 아니라, 팀이 같은 종류의 실수를 다시는 저지르지 않도록 하는 것이다. XP에서는, 다음 단계가 결함에 대응하는 절차다.

  1. 결함을 드러내는 시스템 차원의 자동화된 테스트를 작성한다. 결함을 드러내는 일에는 우리가 바라는 행동을 보여주는 일도 포함된다. 이 작업은 고객도, 고객 지원팀도, 개발자도 할 수 있다.
  2. 역시 결함을 재생산하는, 가능한 한 범위가 가장 좁은 단위 테스트를 작성한다.
  3. 이 단위 테스트가 통과하도록 시스템을 고친다. 그러면 시스템 테스트 역시 통과되어야 한다. 그렇지 않다면, 2번으로 돌아간다.
  4. 결함을 해결한 후에는, 왜 이 결함이 생겼는지, 왜 결함이 이전에 잡히지 않았는지 알아낸다. 앞으로 이런 종류의 결함이 일어나는 일을 막기 위해 필요한 변화를 시작한다.

오노 다이이치는 마지막 단계를 위한 간단한 절차인 FiveWhys 를 고안해 냈다. 왜 문제가 발생했는지 다섯 번 묻는 것이다. FiveWhys 를 하고 나면, 결함의 중심부에는 사람 문제가 놓여 있다는 것을 알게 된다 (거의 언제나 사람 문제다)

코드 공유

팀 구성원 누구든지 언제라도 시스템의 어떤 부분이든 개선할 수 있다. 시스템에 뭔가 문제가 생겼고 그것을 고치는 일이 지금 내가 하고 있는 일의 범위를 벗어나지 않는다면, 그것을 고쳐야 한다.

코드 공유는 보조 실천방법이다. 팀에 집단 책임감이 발달하기 전에 적용하면 위험할 수 있다. 팀에 집단 책임감이 발달하기 전에는, 아무도 책임지는 사람이 없으면 품질이 떨어지게 된다. 사람들은 팀 전체에 및칠 결과를 생각하지 않고 코드를 변경할 것이다.

그러나 팀워크 모델에는 '각자 자기 일만' 말고도 다른 모델이 있다. 팀 구성원들이 사용자에게 전달할 제품의 품질 뿐 아니라 그것을 만들면서 생기는 자부심에도 집단적인 책임을 느끼는 일은 가능하다.

짝 프로그래밍은 팀 동료들이 서로에게 품질에 대한 자신의 헌신을 보여주고, 좋은 품질을 구성하는 것이 무엇인가에 대한 서로의 기대치를 통일시키는 일에 도움이 된다.

지속적인 통합은 집단 소유를 실시하기 전에 해야 할 또 다른 중요 전제 조건이다.

코드와 테스트

오직 코드와 테스트만 영구 산출물로 유지하라. 다른 문서들은 문서와 테스트에서 생성되도록 한다. 프로젝트 역사의 중요한 부분을 살아있게 하는 일은 사회적 메커니즘에 맡긴다.

단일 코드 기반

코드 흐름은 오직 하나뿐이어야 한다. 잠시 가지를 분기시켜 작업할 수는 있어도, 분기되는 시간은 몇 시간 이내로 한정되어야 한다.

여러 다발의 코드 흐름은 소프트웨어 개발에서 엄청난 낭비를 낳는 근원이다. 소스 코드의 버전을 더 늘리지 말라. 코드 기반의 수를 늘리는 대신, 단일 코드 기반으로 충분하지 못하게 만드는 근본적인 설계 문제를 해결하라.

매일 배치

매일 밤 새로운 소프트웨어를 제품으로 내놓아라.

이 실천방법을 하기 전에 먼저 해야 할 것들이 굉장히 많다. 우선 결함 비율은 많아봤다 한 해에 한 웅큼 정도여야 한다. 또 빌드 환경은 원활하게 자동화되어야 한다. 게다가 배치 도구들도 자동화되어 있어야 하며, 점진적으로 새 버전을 배치하고 실패가 있을 경우 옛 버전으로 돌아갈 수 있어야 한다. 그리고 가장 중요한 것은, 팀 내의 신뢰도와 고객과의 신뢰도가 높은 수준으로 발달해 있어야 한다는 것이다.

범위 협상 계약

소프트웨어 개발 계약을 작성할 때 시간, 비용, 품질은 확정해도, 시스템의 정확한 범위는 계속 협상해 나가자고 요청하라. 긴 계약 하나에 서명하기보다 짧은 계약 여러 개를 여러 번에 걸쳐 서명함으로써 위험도를 낮추어라.

사용별 지불

사용별 지불(Pay-Per-Use) 시스템에서는, 시스템이 사용될 때마다 돈을 청구한다. 돈은 궁극적인 피드백 수단이다. 돈은 구체적이기도 하고 사용가능하다. 돈의 흐름을 소프트웨어 개발에 직접 연결하면, 개선을 이끌어갈 정확하고 시기적절한 정보를 얻을 수 있다.

사용별 지불까지는 아니더라도, 구독 모델로 갈 수도 있다. 구독 모델의 경우, 개발팀은 최소한 유지 비율을 팀이 얼마나 잘 하는지 판단하는 정보의 원천으로 삼을 수 있다.

-

이 실천방법들은 내가 관찰한 결과 훌륭한 소프트웨어 개발팀의 핵심 요소라고 믿게 된 것들이다.

10장. 전체 XP팀

11장. 제약이론

12장. 계획 짜기: 범위를 관리하기

13장. 테스트: 일찍, 자주, 자동화

14장. 설계하기: 시간의 가치

15장. XP 확장

16장. 인터뷰

2부. XP의 철학

17장. 창조 이야기

18장. 테일러주의와 소프트웨어

19장. 도요타 생산 시스템

20장. XP 적용하기

21장. 순수성

22장. 해외 개발

23장. 시간이 지나도 변치 않는 프로그래밍 방식

24장. 공동체와 XP

25장. 결론

주석을 단 참고문헌

CategoryBook CategoryAgile

책/ExtremeProgrammingExplained (last edited 2023-05-09 05:13:04 by 정수)