[개발 프로세스] 익스트림 프로그래밍 : XP란 무엇인가

이 글은 신시아 안드레스, 켄트 백의 익스트림 프로그래밍을 기반으로 합니다.

XP의 정의

​"모호한 요구사항이나 빠른 속도로 변하는 요구사항에 직면한 중소 규모의 소프트웨어 개발 팀을 위한 가벼운 방법론"

..하지만 이 선언이 XP의 모든 것을 말해주지는 않는다.

XP는 무엇을 버리도록 하는가?

과거에는 잘 통했지만 지금은 일을 최고로 잘 하려고 하는데 방해가 되는 습관과 양식들

우리를 보호해 주긴 하지만 생산성은 떨어뜨리는 방어수단들

XP는 어떤 이야기인가

우리가 할 수 있는게 무엇인지 공개한 다음 그걸 해내는 것

다른 사람도 그렇게 하도록 허용해 주고 기대하는 것

나는 뭐든지 할 수 있다는 사춘깆거 앳된 자신감을 넘어서는 것

비즈니스에서 정말 도움이 되는 훌륭한 코드를 작성하는 것

우리가 될 수 있는 최고의 자신을 향해 나아가면서 그 과정에서 개발자로서 최고가 되는 것

XP는 두가지를 다룬다.

일에서 성공하려면 기술이 있어야 할 뿐 아니라 좋은 인간관계도 있어야 한다.

(코딩, 일, 인간관계) -> 생산성, 자신감에 영향

왜 Extreme(극단) 이라는 이름이 붙었을까?

성공을 준비하라. 성공에서 한 발짝 뒤로 물러나 자신을 보호하지 말라.

최선을 다한 다음 결과에 대처하라.

이것이 바로 극단(Extreme)이다.

...

어떤 프로젝트를 완수할 시간이 6주로 정해졌다면.

당신이 조절할 수 있는 유일한 요소는 시간뿐이다.

6주어치의 일을 해낼 것인가? 아닌가.

XP는 개발 프로세스의 모든 단계에 잠재되어 있는 위험들에 대처하는 소프트웨어 개발 규율이다.

XP가 어떤 방식으로 개발 프로세스의 위험들에 대처할까?

일정 밀림

XP에서는 아무리 길어도 몇 달인 정도로 릴리즈 주기가 짧아야 한다. 그래야 일정이 밀리는 정도에도 한계가 있다.

한 릴리즈 주기 안에서는, 일주일 단위의 반복(iteration)을 사용해서 고객이 요청한 기능들을 구현하고 프로젝트의 진전 상황에 대한 작은 단위의 피드백을 주고받는다. 한 반복 안에서 XP의 계획 단위는 짧은 과업(task, 일, 과제)들이다.

따라서 팀은 주기 안에 문제들을 해결할 수 있다.

마지막으로 XP에서는 가장 우선순위가 높은 기능부터 구현해야 한다. 따라서 릴리즈때 어떤 기능이 미처 구현되지 못했다 해도 그 기능은 가치가 낮은 기능일 것이다.

​프로젝트 취소

​팀의 비즈니스 쪽 구성원들에게 비즈니스에 가장 중요하면서도 가장 작은 릴리즈를 고르라고 요구한다.

따라서 배치전에 잘못될 가능성은 더 적어지고 소프트웨어의 가치는 언제나 최고를 유지한다.

(중요한 기능을 잘못 배치하여 프로젝트가 취소되는 위험에 대비)

​시스템 이상

​자동화된 테스트 스위트(Suite)를 만들고 유지하며, 이 테스트들은 품질 기준을 유지하기 위해 시스템에 변화가 생길 때마다 돌고 또 돈다.

테스트들이 있기 때문에 시스템은 언제나 배치 가능하다.

(테스트 코드로 항상 정상적인 기능을 보장하는 것)

​결함 비율

​XP는 함수 단위로 테스트를 작성하는 프로그래머 (TDD?)

그리고 프로그램 기능 단위로 테스트를 작성하는 고객 (인수 테스트?)

둘 다의 관점에서 테스트를 한다.

​비즈니스에 대한 오해

​XP에서는 비즈니스 쪽 사람들도 팀의 당당한 정규 구성원이 되어야 한다.

프로젝트의 명세는 개발 과정 중에서도 끊임없이 다듬어지기 때문에, 고객과 팀이 배운 것들이 소프트웨어에 그대로 반영될 수 있다.

(비즈니스쪽에서 담당하는 업무도 중요하다고 판단하는 것)

비즈니스의 변화

XP에서는 릴리즈 주기를 짧게 줄이기 때문에, 릴리즈 하나를 개발할 때 반영해야 하는 변화의 양은 줄어든다.

한 릴리즈 동안에는 고객이 자유롭게 아직 완성되지 않은 기능 대신 새로운 기능을 요청할 수 있다.

(이미 완성된 기능을 새로운 기능으로 대체해달라고 하면 개발자들은 곤란하다.)

​이름뿐인 풍부한 기능

​XP는 오직 우선순위가 가장 높은 작업들만 다룰 것을 요구한다.

​직원 교체

​XP에서는 프로그래머들이 자신의 일을 추정하고 완료하는 책임을 받아들여야만 한다.

XP는 추정이 더 정확해질 수 있도록 실제 걸린 시간을 프로그래머들에게 피드백해주며, 프로그래머가 내린 추정을 존중해 준다.

누가 추정을 만들고 변경할 수 있는지에 대한 규칙이 명확하기 때문에, 뻔히 불가능한 것을 해달라는 요청을 받아들여서 프로그래머의 짜증을 돋울 가능성이 줄어든다. (추정을 만들고 변경할 수 있는 사람을 제한해서 임의의 사람이 불가능한 요청을 수락하는 일이 없도록 함)

또한 팀 내에서 인간적인 접촉을 장려함으로써 직원들의 외로움을 줄여준다.

직원 교체에 대한 대처법이 명시적인 모델로 포함되어 있다.

새로운 팀 구성원들은 단계적으로 더 많은 책임을 받아들이도록 격려 받으며, 그러는 과정에서 서로의, 그리고 기존 프로그래머들의 도움을 받는다.

다시 한번 XP란 무엇인가에 대하여 생각해보자.

XP는 오래되고 효과가 없는 사회적 습관들을 버리고 효과 있는 새로운 습관들을 채택하는 것이다.(지속적인 피드백)

XP는 오늘 내가 기울인 모든 노력에 대하여 자신을 인정해 주는 것이다.

XP는 내일은 오늘보다 조금 더 잘해보려고 노력하는 것이다. (

XP는 팀 전체가 공유하는 목표에 내가 얼마나 기여했는지를 잣대로 자신을 평가하는 것이다 (팀 중심)

XP는 소프트웨어 개발을 하는 중에도 여러분의 인간적 욕구 가운데 일부를 채우겠다고 요구하는 것이다(인간관계)

XP는 단순한 개발 방법론의 이론이 아닌, 좋은 프로그램을 만들기 위한 노력과 프로그래머의 자세, 인간관계를 포함한 방법의 집합체인것 같다

​추가,

조대협님의 블로그를 보다가

애자일에는 애자일 사상과 애자일 프로세스로 구분할 수 있다는 것을 알게되었다

내가 위에서 느낀 것은 사상과 개발 프로세스의 차이일 것이다.

> 조대협님의 블로그에서 본 애자일에 관한 글

애자일 및 협업 문화 애자일 과 수평 조직 기반의 개발 문화에 대한 현상은 올해에도 쭈욱 지속될 듯 합니다. 기존의 워터폴이나 경직된 조직 문화와 방법론으로는 현대의 빠른 서비스 개발을 따라갈 수 가 없져 애자일은 워낙 오래전 부터 언급되고 나온거라서 별도로 언급을 하지 않겠습니다만, 왜 이 부분을 2015년의 트랜드로 잡았느냐 하면, 국내 기업의 경우 애자일 프로세스만을 도입하는 것이 아니라, 조직의 구조나 문화 자체를 애자일 사상으로 옮겨가는 경우가 많이 보이기 때문입니다. 기존에 무늬만 애자일이었다면, 작년부터 올해까지는 애자일 문화를 적용하기 위한 직급을 없애고 직책(ROLE) 기반으로 일하기 위한 변화, 수평적 조직 구조, 그리고 스크럼 마스터와 프러덕트 오너등이 조직내에 점점 더 확실하게 자리 잡아 가는 것 같습니다.