익스트림 프로그래밍 XP 요소 및 진행방법

■ XP란?

XP는 고객이 원하는 소프트웨어를 고객이 원하는 시기에 제공하는 것을 목표로 하며, 프로젝트 막바지에도 나올 수 있는 요구사항 변경에 더욱 잘 대처할 수 있도록 한다.

이 방법은 10~12개 정도의 구체적인 실천 방법(Practice)을 정의하고 있어, 비교적 적은 규모의 인원의 개발 프로젝트에 적용하기 좋다. 개발 문서 보다는 소스코드를, 조직적인 개발의 움직임 보다는 개개인의 책임과 용기에 중점을 두는 경향이 크다.

켄트 백은 XP를 이끄는 가치와 원칙에 대해서도 강조했다. XP에서 실천 방법에만 집중하고 가치와 원칙을 무시하면 제대로 XP를 실천하고 있다 하기 힘들 것이다. 원칙은 가치와 실천 방법을 잇는 다리 같은 것이다.

XP의 목적은 '고객이 원하는 양질의 소프트웨어를 빠른 시간안에 전달하는 것'이다. 수시로 발생하는 고객의 요구사항에 대처하고, 고객이 원하는 SW를 고객이 원하는 시간에 인도하기 위해서는 고객과 팀원간의 대화를 통해 해결한다.

 

■ 익스트림 프로그래밍 (XP)의 가치 Values

Value(가치)는 좋아하고, 좋아하지 않는 것에 대한 근원이다. 보고, 생각하고, 실행하는 것을 판단하기 위해 사용하는 큰 규모의 척도이다. 가치가 없는 실천은 기계적인 활동이 되기 쉽다.

가치는 개인이 어떻게 행동하느냐가 아닌 개인이 팀의 일원으로서 어떻게 행동하는가가 중요하고 개인의 장를 무엇보다 우선시하는 것은 팀의 성공에 도움이 되지않는다. 개인적인 가치의 추구 보다는 팀에 도움이 되는 가치에 초점을 맞춘다.

가치는 실천방법에 목적을 부여소프트웨어 프로젝트를 개선하기 위해 켄트 백은 몇 가지 요소가 중요하다고 했다.

▶ 의사소통 communication

의사소통은 팀 개발에 있어서 가장 중요한 요소이다. 개발 과정의 문제는 이미 해결책을 알고 있는 경우가 많다. 문제가 발생했을 때, 누군가 해결책을 알고 있지만 그 해결책이 주체에게 전달이 되지 못하는 경우가 많다. 한 팀이라는 느낌을 만들고 효과적으로 협동하기 위해서 중요한 부분이다.

▶ 단순성 simplicity

꼭 필요한 것만 한다. 간단한 설계 부분은 코드로 바로 작성하고 복잡한 설계 부분은 지속적으로 잘못된 부분을 리팩토링 한다. 불필요한 복잡성을 줄이기 위해 노력해야 한다. 또한 단순성은 상황에 따라 결정된다. 의사소통을 개선하면 단순성을 성취할 수 있고, 단순성을 성취하면 그만큼 의사소통을 줄일 수 있다.

▶ 피드백 feedback

피드백의 형식은 다양하다. 팀은 팀이 다룰 수 있는 한도 내, 빠르고 많은 피드백을 만들기 위해 노력해야 한다. 소프트웨어 개발에서는 변화는 불가피하다. 변화는 피드백을 필요로 한다. 피드백은 의사소통의 핵심이며 단순성에도 기여한다.

▶ 용기 courage

두려움에 직면했을 때 가장 효과적인 행동이다. 문제가 무엇인지 안다면, 그것에 대해 무슨 일이든 해보는 것이 좋다. 단, 결과를 생각하지 않고 하는 것은 좋지 않다. 용기는 다른 가치들과 조화를 이룰 때 강력해지는 가치이다. 진실을 말할 수 있는 용기는 의사소통에 도움을 준다. 실패하는 해결책을 버리고 새해결책을 찾아나서는 용기는 단순함에 도움을 준다. 구체적이고 진실한 답변을 추구하는 용기는 피드백을 낳는다.

▶ 존중 respect

존중은 다른 가치들의 뒤에 숨은 가치이다. 팀 구성원을 존중하지 않는 다면, XP는 실패한다. 프로젝트에 대한 존중이 없다면 프로젝트는 실패한다. 모든 사람은 인간으로서 동등한 가치를 지닌다. 팀에 속한 모든 개인의 기여를 존중해야 한다.

 

■ 익스트림 프로그래밍 (XP)의 원칙 Principles

특정 영역에서의 지침이고, XP 방법을 규정짓는 14가지 기본원리이다.

원칙을 이용한다면 실천방법들은 더 잘 이해할 수 있으며 목적에 맞는 실천방법을 찾을 수 없을 때 그 필요를 채워 줄 실천방법을 고안해 낼 수도 있다. 원칙을 이해하고 있다면, 전반적인 목표들과도 조화를 이루면서 이미 존재하는 실천방법들과도 조화롭게 작동하는 실천방법들을 만들 수 있다.

▶ 인간성 Humanity

인간성을 통해 업무에서 효율적인 의사소통뿐만 아니라 삶의 모든 측면에서 귀중한 관계들을 얻게 된다. 소프트웨어는 사람이 개발하고, 사람을 위해 쓰여 알맞은 프로세스를 만들어 문제를 해결한다. 좋은 개발자가 되기 위해 필요한 것들은 안전, 성취감, 소속감, 성장, 친밀감이다. 개인의 욕구와 팀의 욕구간의 균형을 맞추는 것이 필요하다.

▶ 경제성 Economics

기술적 성공에만 집착하지 않고, 비즈니스 목표와 필요를 충족해야 한다. 경제성은 두 가지 측면에 돈의 시간적 가치와 시스템(돈은 일찍 벌어들이고, 나중에 지불하는 것이 더 가치가 있다)과 팀의 기술적 가치(미래의 선택 사항을 늘릴 수 있다)에 영향을 받는다.

▶ 상호이익 Mutual Benefit

관련된 모든 사람에게 이익이 되어야한다. 해결책이 야기하는 문제보다 해결책이 처리하는 문제의 수가 많아야 상호이익이 된다.

▶ 자기유사성 Self Similarity

어떤 해결책이 효과적이라면, 그 해결책을 다른 곳에 적용해 본다. 규모의 차이는 문제가 되지 않는다. 언제나 효과를 볼 수는 없다. 그 해결책이 모든 상황에 효과적이지는 않다.

▶ 개선 Improvement

어떤 것부터 시작하면 좋을지 찾아보고 일단 시작한 다음 개선하는 것이 좋다. 프로세스나 설계, 스토리를 완벽하게 만들려고 노력하는 것은 가능하다. XP란 개선을 통해 탁월한 소프트웨어에 도달하는 것이다. 새로 발견한 기술적 효율성을 이용해 새롭고 더 효과적인 사회관계를 가능케 하는 것이다.

▶ 다양성 Diversity

개발에 있어서 문제와 함정을 발견하려면 팀 안에 다양한 종류의 기술, 사고방식, 시야들이 모여 있어야 한다. 다양성이 있으면 갈등도 있기 마련이다. 중요한 것은 갈등을 생산적으로 풀 수 있느냐이다. 다양성의 원칙은 프로그래머가 문제를 해결하기 위해 협동할 것과 두 의견을 모두 존중할 것을 권한다.

▶ 반성 Reflection

피드백을 최대화하기 위해 XP 팀에서는 실천과 반성을 뒤섞는다. 좋은 팀은 실수를 숨기려하지 않고 오히려 드러내어 거기에서 배운다. 반성은 ‘공식’적 기회에만 하는 것이 아니다. 반성이 지나친 경우, 실제 개발에 문제가 생기지 않아야 한다. 지성으로 조율된 감정은 통찰력의 원천이 된다.

▶ 흐름 Flow

흐름은 개발의 모든 단계를 동시에 작업함으로써 가치 있는 소프트웨어를 흐르듯이 끊임없이 제공하는 것이다. 개선을 위해 가치를 조금씩, 앞으로, 계속해서, 자주 배치하라고 권한다. 흐름에서 떠나게 될 때 마다 반드시 제자리로 돌아오겠다고 결심해야 한다.

▶ 기회 Opportunity

문제를 기회로 삼아 더 개선된 소프트웨어를 만들겠다고 의식적으로 결심하는 것은 익스트림한 행동의 일부다. 생존의 문제가 아닌, 배움과 개선의 기회로 전환할 줄 알아야 한다.

▶ 중복 Redundancy

핵심적이면서 해결하기 어려운 문제에는 해결방법을 여러 개 마련해 놓아야 한다. 중복은 자원을 소모한다. 중복을 만드는 비용보다 해결방법의 실패로 인한 재앙을 면함으로써 얻는 이득이 더 크다. 정당한 목적이 있는 잉여를 제거하지 않도록 조심해야 한다.

▶ 실패 Failure

실패하더라도 실천을 통해 귀중한 교훈을 얻을 수 있다. 실패가 지식을 늘려주는 한, 그것은 허비가 아니다. 무엇을 해야 할지 모를 경우, 실패를 감수하는 것이 성공으로 가는 가장 짧고 확실한 길이다.

▶ 품질 Quality

품질은 높일수록 제품 전달이 빨라 질 수 있거나, 낮출수록전달이늦어질수있는관리가어려운변수이다. 확실한 방법을 모른다면, 가장 최선책이고 생각하는 방법으로 한다. 시간 안에 할 수 있는 방법으로 최대한 진행 후, 마무리를 생각한다. 품질이 주는 이익에는 명확한 한계가 없으며, 어떻게 더 품질을 올릴까에 대한 이해의 한계만이 있다. 품질은 경제적 요인만으로 설명 할 수 없다. 품질에 대한 걱정이 무위도식의 변명이 되어서는 안 된다.

▶ 아기 발걸음 Baby step

중요한 변화를 한 번에 몰아서 시도하는 것은 위험하다. 조건만 제대로 갖추어진다면, 사람들과 팀들은 많은 작은 단계를 엄청나게 빠른 속도로 밟아나가서 마치 도약하는 것처럼 보일 수 있다. 단계를 잘게 쪼갤 때 생기는 부담이 큰 변화를 시도했다가 실패해서 다시 원상태로 돌아갈 때 드는 낭비보다 훨씬 작다는 사실을 인정하는 것이다.

▶ 수용된 책임감 Accepted Responsibility

어떤 일을 하겠다고 서명한 사람이 그 일의 평가도 내려 보는 것이 받아들인 책임의 원칙을 반영한 예시이다. 책임이 있는 곳에는 권한도 따라온다. 책임과 권위가 잘못 연결되면 팀의 의사소통이 왜곡된다. 권위와 책임이 잘못 연결된 상태에서 살아가는 데 드는 감정적인 부담의 비용도 존재한다.

 

■ 익스트림 프로그래밍 (XP)의 실천방법 Practices

XP는 뚜렷한 목표 제공을 통해 목표를 이루기 위한 것으로써 매일 실천하는 것이지만, 절대적인 것은 아니다. 실천 방법 자체만으로는 부족하다. 가치를 통해 목적을 가지지 않은 실천 방법은 기계적인 규칙일 뿐이다. 동기와 목표를 제공해야 한다. 실천 방법은 함께 사용할 때 효과가 증폭되고, 새로운 방법을 빨리 받을수록 팀에는 이득이 된다. 실천방법은 상황에 따라 달라져야한다. 문제영역이 달라졌다면 새로운 원칙이 필요할 수 있다. 그러나 가치는 새로운 상황에 따라 변할 필요 없고 어떤 실천 방법을 적용할 것인지는 팀의 선택에 달려있다.

▶ 함께앉기 Sit Together

기술적인 해결책만으로 충분하지 않는 경우가 있어 얼굴을 맞대는 시간이 길면 프로젝트가 더 인간적이 되고 생산적이 될 수 있다. 개발 작업은 팀 전체가 들어가기 충분할 정도로 크고 열린 공간에서 하는 것이 좋다. 우리의 모든감각을 이용해 의사소통하는 것은 매우 중요하다. 팀이 준비되기도 전에 개인공간을 나누는 파티션을 허물면 생산성이 오히려 낮아진다.

▶ 전체팀 Whole Team.

팀은 일체라는 느낌과 함께 프로젝트 성공에 필요한 자원을 쉽게 이용할 수 있어야한다. 프로젝트가 성공하기 위해 필요한 기술과 시야를 지닌 사람들은 전부 팀에 포함해야 한다. 이상적인 팀 규모는 12와 150 이그 지점 이다. 프로젝트 규모가 클 경우, 문제를 쪼개서 여러 팀으로 구성된 팀이 해결할 수 있도록 하는 방법을 찾는다면 XP를 대규모로 적용할 수 있다. 전체팀은 일반적으로 tester, interaction designers, architects, project managers, product managers, executives, technical writers, programmers and users 로 구성이 된다. 이들 중에서 가장 중요한 팀원 사용자(user) 이다. 왜냐하면 그들이 프로젝트의 키를 가지고 있는(stakeholder)일 뿐만 아니라 그들을 통해 요구사항(requirement)을 파악 할 수 있기 때문이다.

▶ 정보를 제공하는 작업 공간 Informative Workspace

작업공간을 작업에 대한 것들로 채운다. 프로젝트의 진행상황을 쉽게 알 수 있고 현재와 미래의 문제에 대한 정보를 알 수 있어야 한다. 벽에 스토리카드를 붙이는 방법이 있다. 착실하게 진전시켜야 할 일이 있다면, 그것에 대한 차트를 그리는 것이 좋다. 공간은 지금 일어나는 중인, 그리고 중요한 정보를 위해서만 사용해야 한다.

▶ 활기찬 작업 Energized Work

생산적이고 일의 활력을 유지할 수 있는 정도의 시간만 일하는 것이 좋다. 긴시간일한다고해서더많은가치를생산하지는않는다.하루를 혹사하고, 다음 이틀을 망치는 것은 팀과 자신에게 손해다. 같은 양의 시간을 더욱 잘 활용하기 위해 노력해라. 소프트웨어개발은 통찰력 싸움이다. 그리고 통찰력은 준비되고, 잘 쉬고, 긴장이 풀린 마음에서 생겨난다.

▶ 짝 프로그래밍 Pair Programming

프로그램을 두 사람이 컴퓨터 한 대에 앉아 작성하는 것이다. 혼자 생각 할 시간도 필요하고 짝을 자주 바꾸도록 하여 더 많은 사람과 공유하고 프로젝트 전체에 도움이 되도록 한다. 짝 프로그래밍에서는 개인적인 차이를 존중하는 것이 중요하다. 짝 프로그래밍의 효과는 서로 일에 집중하도록 해주고 시스템을 더 좋게 다듬기 위해 무엇을 할 수 있을지 떠오른 생각을 명료하게 다듬어 준다. 한 사람이 막힐 때 주도권을 다른 사람에게 넘김으로써, 짜증을 덜나게 해준다. 팀에서 지키기로 한 실천방법은 서로 책임지고 지키도록 한다.

▶ 스토리 Story

고객이 볼 수 있는 기능 단위로 계획을 세워야 한다. 스토리 실천방법과 다른 요구사항 실천 방법들 사이의 핵심 차이점은 일찍 추정하기이다. 스토리에는 짧은글이나 그림 설명 외에도 추가로 짧은 이름을 달도록 한다. XP식 계획의 특징하나는 계획의 매우 초기단계에서 스토리추정이 이루어진다는 것이다.

▶ 일주일별주기 Weekly Cycle

한 번에 일주일 분량의 일을 계획한다. 한 주를 시작하는 회의는 지금까지의 진행된 상황이 실제 진행정도와 예상 진행정도를 같이 검토한다. 이번 주에 구현할 일주일분의 스토리를 고객이 고르도록 한다. 스토리를 여러 Task로 쪼갠다. 팀 구성원들은 자기가 할 과업에 서명을 하고, 얼마나 걸릴지 추정한다. 팀과 개인 차원의 실험을 편리하고, 빈번하게 예측 가능하게 할 수 있는 환경을 제공한다.

▶ 사분기 주기 Quarterly Cycle

한 번에 한 분기 분량의 일을 계획해야 하는데 분기마다 한 번씩은 팀, 프로젝트, 프로젝트의 진행정도, 더 높은 목표와 지금 프로젝트의 방향일치 여부 등을 놓고 숙고해 보도록 한다. 분기별 계획에서는 병목, 특히 팀의 힘이 미치지 않는 외부에서 생기는 병목을 찾는다. Repair 작업을 시작한다. 이번 분기의 주제를 계획하고 그 주제들을 다룰 한분 기 분량의 스토리 들을 고른다. 프로젝트가 조직에서 차지하는 위치라는 큰 그림에 초점을 맞춘다.

▶ 여유 – 느슨함 Slack

어떤 계획이든, 일정에 뒤쳐질 경우 포기할 수 있는 비교적 급하지 않은 과업들을 포함시켜 봐야한다. 계획된 것을 지키는 것도 중요하다. 분명하고 솔직한 의사소통은 긴장을 완화하고 신뢰를 회복시킨다.

▶ 10분 빌드 Ten-minute Build

10분 만에 자동으로 전체시스템을 빌드하고 모든 테스트를 하는 것이다. 시스템의 어떤 부분을 빌드해야 하고 어떤 부분을 테스트해야 하는지 추측하기 시작한다면 실수를 저지를 위험을 만드는 셈이다. 자동화 된 빌드는 수작업이 필요한 빌드보다 훨씬 가치 있다.

▶ 지속적 통합 Continuous Integration

개발팀은 항상 최신버전의 소프트웨어에 대한 작업을 해야 한다. 즉, 변경한 것은 두세시간만에 통합하고 테스트하는 것이 좋다. 통합과 빌드의 결과는 완제품이어야 한다. 통합을 오래 미룰수록 비용이 더 들며 통합비용을 예측하기도 힘들어진다. 동기적인 방식은 짧은 피드백 주기를 만들 수 있지만 비동기적 방식은 그렇지 못하다.

▶ 테스트 우선 프로그래밍

코드를 한 줄이라도 변경하기 전, 일단 실패하는 자동화 된 테스트를 먼저 작성한다. 테스트 코드를 만든 후 실제 프로그램 코드 작성을 한다. 작성 종료 조건을 미리 정하고, 코딩을 시작한다. 동작하는 깨끗한 코드를 작성하는 것이 목표인데 짧은 개발 사이클을 반복하고 명세에 기반 하여 결과를 확인한다.

▶ 점진적설계

설계 투자를 단기에 최소화 하라는 것이 아닌, 시스템에서 지금까지의 필요에 비례하도록 설계투자를 유지해 가는 것이다. 기존의 개발 방법과 다른 접근이기 때문에 마지막 책임 지점까지 설계를 미뤄야 한다. 시스템의 필요에 비례하도록 설계투자를 유지하여야 한다. 시스템 설계 시 중복으로 제거한다. 경험을 얻기 전 설계를 하면 문제가 된다. 리펙토링을 활용한다.