익스트림 프로그래밍(XP)은 결과를 얻지만, 귀하에게 적합한가요?

익스트림 프로그래밍 이라는 용어가 X 게임과 액션 스포츠의 정신적 이미지를 불러 일으킨다면, 그것은 그리 멀지 않습니다. 익스트림 프로그래밍(XP)은 사실 꽤 극단적인 프로그래밍 방식입니다. 다른 애자일 소프트웨어 개발 방법과 마찬가지로 XP는 소프트웨어 엔지니어링을 위해 적응 가능한 테스트 중심 개발을 사용합니다. 그러나 다른 방법과 달리 익스트림 프로그래밍에는 업무 수행 방식을 관리하는 엄격한 규칙과 지침이 있습니다. 

익스트림 프로그래밍(XP)이란?

익스트림 프로그래밍은 짧은 개발 주기와 적은 문서로 속도와 단순성을 목표로 하는 애자일 프로젝트 관리 방법론입니다. 프로세스 구조는 5가지 가이드 가치, 5가지 규칙, 12가지 XP 관행(이 글에서 자세히 설명합니다)에 의해 결정됩니다. 

다른 애자일 방식과 마찬가지로 XP는 업무 스프린트로 세분화된 소프트웨어 개발 방법론입니다. 애자일 프레임워크는 반복 프로세스 를 따릅니다. 즉, 스프린트가 완료된 후에는 프레임워크를 검토하고, 효율을 극대화하기 위해 개선하고, 변화하는 요구 사항에 맞게 조정합니다. 다른 애자일 방식과 마찬가지로 XP의 설계는 개발자가 고객 스토리에 대응하고, 적응하고, 실시간으로 변경할 수 있도록 합니다. 그러나 XP는 훨씬 더 엄격하며, 빈번한 코드 검토와 단위 테스트를 사용하여 신속하게 변경합니다. 또한 모든 개발 단계에서 팀워크를 우선시하여 매우 창의적이고 협업적입니다.

익스트림 프로그래밍 vs. 스크럼

스크럼은 스크럼 마스터가 관리하는 또 다른 일반적인 애자일 방법론입니다. XP와 마찬가지로 스크럼은 사용자 스토리를 기반으로 스프린트를 실행하여 새로운 제품이나 소프트웨어 기능을 개발합니다. 그러나 XP는 Scrum보다 더 엄격하며, 개발자와 고객 간의 지속적인 접촉을 장려하는 엄격한 규칙과 지침을 가지고 있습니다. 또한, XP 프로그래밍만 사용하는 반면, 스크럼은 반복과 고객 입력이 필요한 모든 프로세스에 사용할 수 있습니다.

익스트림 프로그래밍의 창시자는 누구인가요?

XP의 기원은 1990년대 후반으로 거슬러 올라갑니다. Kent Beck이 C3 프로젝트라고 불리는 Chrysler의 급여 소프트웨어 시스템 개발을 관리하기 위해 XP를 만들었습니다. XP의 목표는 개발 프로젝트 내에서 코드 변경에 대한 저항을 제거하는 것이었습니다(여전히 그렇습니다). 보다 전통적인 소프트웨어 개발 방법에서는 코드를 작성한 후에는 (디버깅을 제외하고) 코드를 그대로 두는 경우가 많습니다. XP를 사용하면 코드를 매우 주의 깊게 검토하여 개발자가 단일 반복 후 코드를 완전히 다시 작성하기로 결정할 수 있습니다. 

익스트림 프로그래밍은 언제 사용해야 하나요?

익스트림 프로그래밍은 소프트웨어 개발에 중점을 두기 때문에 일반적으로 엔지니어링 팀에서만 사용합니다. 소프트웨어 팀에서도 특정 설정에서만 작동합니다. 익스트림 프로그래밍을 최대한 활용하려면 다음 경우에 사용하는 것이 좋습니다. 

• 소규모 팀을 관리합니다. 협업성이 뛰어나기 때문에 XP는 10명 미만의 소규모 팀에서 가장 효과적입니다. 

• 고객과 지속적으로 소통하는 경우. XP는 개발 프로세스 전반에 걸쳐 고객의 요구 사항을 통합하며, 테스트 및 승인에도 고객의 요구 사항을 활용합니다.

• 변화를 수용할 수 있는 적응형 팀을 보유하고 있습니다 . 익스트림 프로그래밍은 그 특성상 팀 전체가 열심히 한 일을 버려야 하는 경우가 많습니다. 다른 팀원이 언제든지 변경할 수 있도록 허용하는 규칙도 있지만, 팀원이 이를 개인적으로 받아들이는 경우에는 효과가 없습니다.

• 코딩의 기술적 측면에 정통합니다. XP는 초보자에게 적합하지 않습니다. 빠르게 작업하고 변경할 수 있어야 합니다.

XP의 라이프사이클

XP 라이프사이클은 팀 멤버가 시간당 또는 일일 단위로 거의 지속적으로 연동하는 지속적인 연동을 장려합니다. 그러나 전체 라이프사이클은 다음과 같이 세분화됩니다.

• 사용자 스토리에서 미완료 작업 가져오기 

• 가장 중요한 항목에 우선순위를 부여합니다 

• 반복 계획 시작  

• 솔직한 계획 수립을 통합합니다  

• 모든 이해관계자와 지속적인 커뮤니케이션을 유지하고 팀에 권한을 부여합니다  

• 업무 릴리스  

• 피드백 받기 

• 반복 계획 단계로 돌아가 필요에 따라 반복합니다.

익스트림 프로그래밍의 5가지 가치

익스트림 프로그래밍은 가치에 기반합니다. XP를 사용하면 팀이 외부 동기를 부여받는 대신 이 다섯 가지 가치를 바탕으로 덜 복잡한 방식으로 작업할 수 있습니다(복잡한 디자인보다 단순함과 협업에 집중).

1. 단순성

익스트림 프로그래밍 작업을 시작하기 전에 먼저 스스로에게 물어보세요. 가장 간단하면서도 효과적인 것은 무엇인가요? '작동하는' 부분이 핵심적인 차별화 요소입니다. 가장 간단한 것이 항상 실용적이거나 효과적인 것은 아닙니다. XP에서는 가장 중요한 업무를 먼저 완료하는 데 중점을 둡니다. 이는 달성할 수 있다고 알고 있는 간단한 프로젝트를 찾고 있음을 의미합니다.

2. 커뮤니케이션

XP는 빠른 반응성과 효과적인 커뮤니케이션에 의존합니다. 업무를 수행하려면 팀이 서로에게 개방적이고 솔직해야 합니다. 문제가 발생하면 의견을 제시해야 합니다. 그 이유는 다른 팀 구성원이 이미 해결책을 가지고 있을 가능성이 높기 때문입니다. 만약 그렇지 않다면, 혼자 하는 것보다 그룹으로 더 빨리 해결책을 찾을 수 있을 것입니다.

3. 피드백

다른 애자일 방법론과 마찬가지로 XP는 사용자 스토리와 피드백을 프로세스에 직접 통합합니다. XP의 초점은 빠르고 간단하게 업무를 생산한 다음 이를 공유하여 거의 즉각적인 피드백을 받는 것입니다. 따라서 개발자는 프로세스 전반에 걸쳐 고객과 거의 끊임없이 연락을 주고받습니다. XP에서는 미리 그리고 자주 인사이트를 얻기 위해 릴리스를 자주 출시합니다. 피드백을 받으면 (프로젝트가 아닌) 프로세스를 조정하여 피드백을 통합합니다. 예를 들어, 피드백이 불필요한 지연 시간을 줄이는 경우, 프로젝트 전체를 조정하는 대신 두 명의 개발자가 지연 시간을 개선하도록 프로세스를 조정합니다.

4. 용기

XP에는 일정 수준의 용기가 필요합니다. 항상 진행 상황에 대해 솔직한 업데이트를 제공해야 하며, 이는 상당히 취약해질 수 있습니다. XP에서 마감일을 놓치면 팀 리더는 그 이유에 대해 논의하고 싶어하지 않을 것입니다. 대신, 마감일을 놓쳤다고 말하고, 책임을 지고, 다시 업무에 복귀할 것입니다. 

팀 리더라면 XP 프로세스를 시작할 때 성공에 대한 기대치를 설정하고 '완료'를 정의하는 것이 여러분의 책임입니다. 팀이 성공에 집중하기 때문에 실패에 대한 계획은 거의 없습니다. 그러나 일이 언제나 계획한 대로 진행되는 것은 아니기 때문에 이는 두려울 수 있습니다. 하지만 XP 프로세스 도중 상황이 변경되면 팀은 그에 맞게 적응하고 변경해야 합니다. 

5. 존중

XP가 커뮤니케이션과 정직성을 얼마나 중시하는지 고려할 때, 존중이 중요하다는 것은 당연합니다. 팀이 효과적으로 소통하고 협업하려면 이견을 제시할 수 있어야 합니다. 하지만 친절하게 할 수 있는 방법이 있습니다. 존중은 많은 솔직함이 있더라도 친절과 신뢰로 이어지는 좋은 기반이 됩니다. 익스트림 프로그래밍의 기대치는 다음과 같습니다. 

• 고객과 개발 팀 간의 상호 존중. 

• 팀원 간의 상호 존중. 

• 모든 팀원이 프로젝트에 가치 있는 것을 제공한다는 인식을 갖습니다.

익스트림 프로그래밍 방법론의 5가지 규칙

익스트림 프로그래밍의 가치는 철학적 측면입니다. 반면 규칙은 업무를 수행하는 방법에 대한 실질적인 용도입니다. 효과적인 XP 팀을 운영하려면 둘 다 필요합니다. 

1. 계획

XP의 계획 단계에서는 프로젝트가 실행 가능하고 XP에 가장 적합한지 판단합니다. 이를 위해 다음을 살펴보아야 합니다.

• 사용자 스토리: 단순성 가치와 일치하는지 확인하고 고객이 프로세스를 사용할 수 있는지 확인합니다. 사용자 스토리가 더 복잡하거나 익명의 고객이 만든 경우 XP에 적합하지 않을 수 있습니다.

• 프로젝트의 비즈니스 가치와 우선순위. 이는 '가장 중요한 업무를 먼저 처리하기'라는 원칙에 부합해야 합니다. 

• 현재 어느 개발 단계에 있는지. XP는 초기 단계 개발에 가장 적합하며, 이후 반복에서는 그다지 효과를 발휘하지 못합니다.

프로젝트가 XP에 적합하다는 것을 확인한 후에는 릴리스 일정을 수립하세요. 하지만 피드백을 얻기 위해 일찍 그리고 자주 릴리스해야 한다는 점을 명심하세요. 이를 위해서는 다음을 수행하세요.

• 프로젝트를 반복으로 세분화하고 각 반복에 대한 계획을 수립합니다. 

• 현실적인 마감일과 지속 가능한 속도를 설정하세요. 

• 업데이트가 발생할 때마다 공유하여 팀이 정직하고 투명하게 업무를 수행할 수 있도록 지원하세요. 

• 팀이 더 빠르게 식별하고, 적응하고, 변경할 수 있도록 실시간 업데이트를 공유하세요. 

• 프로젝트 관리 툴 을 사용하여 칸반 보드 또는 타임라인을 생성하여 진행 상태를 실시간으로 추적하세요. 

2. 관리

XP의 핵심 요소 중 하나는 물리적 공간입니다. XP 순수론자들은 모든 팀원이 하나의 개방된 공간에서 일할 수 있는 개방형 작업 공간을 사용할 것을 권장합니다. XP는 협업에 매우 적합하기 때문에 물리적으로 함께 모일 수 있는 공간을 갖는 것이 좋습니다. 하지만 요즘 시대에는 이것이 항상 실용적인 것은 아닙니다. 원격 팀에서 일하는 경우, 원격 협업을 위해 비동기식 업무를 장려하는 플랫폼을 사용하는 것이 좋습니다. 이렇게 하면 모든 구성원이 물리적으로 함께 있지 않더라도 프로젝트를 계속 함께 수행할 수 있습니다.

다른 애자일 방법과 마찬가지로 일일 스탠드업 미팅을 사용하여 체크인하고 지속적이고 개방적인 커뮤니케이션을 장려하세요. 주간 주기와 분기 주기를 모두 사용하는 것이 좋습니다. 분기별 주기 동안 회원님과 팀은 업무를 안내할 스토리를 검토합니다. 또한 XP 프로세스를 연구하여 격차를 찾거나 변경할 수 있는 기회를 찾습니다. 그런 다음 주 단위의 주기로 작업하며, 각 주기는 고객 미팅으로 시작합니다. 고객은 프로그래머가 해당 주에 작업하기를 원하는 사용자 스토리를 선택합니다. 

매니저나 팀 리더는 업무 진행 상태를 유지하고, 진행 속도를 측정하고, 버그나 문제가 발생할 때 이를 해결하도록 팀원들을 전환하거나, 현재 프로젝트와 반복에 맞게 XP 프로세스를 변경하는 데 집중해야 합니다. XP의 목표는 유연성을 유지하고 조치를 취하는 것이므로, 팀의 현재 업무에 집중하고 변화에 대응하는 것이 중요합니다.

3. 디자인

익스트림 프로그래밍을 막 시작할 때는 가능한 가장 간단한 디자인부터 시작하세요. 이후 반복을 통해 더 복잡해질 것이라는 점을 알아두세요. 이 단계에서는 초기 기능을 추가하지 말고 최대한 간단하게 유지하세요.

XP 방법론 팀은 설계에서 각 개체가 상호 작용하는 방식을 보여주기 위해 클래스-책임-협업(CRC) 카드를 사용하는 경우가 많습니다. 카드의 각 필드를 작성하면 모든 기능이 서로 관련되고 상호 작용할 때 시각적 상호 작용을 얻을 수 있습니다. CRC 카드에는 다음이 포함됩니다. 

• 클래스(유사한 개체의 모음)

• 책임(클래스와 관련)

• 협업 참여자(이 클래스와 상호 작용하는 클래스)

CRC는 프로세스를 자극하고 잠재적인 문제를 발견하는 데 유용합니다. 어떤 방식으로 설계하든 잠재적인 병목 현상을 줄이는 시스템을 사용하는 것이 좋습니다. 이를 위해서는 리스크를 적극적으로 찾아야 합니다. 잠재적인 위협이 나타나면 즉시 팀원 한 명에서 두 명에게 위협이 발생할 경우 해결책을 찾도록 배정하세요.

4. 코딩

XP의 더 독특한 측면 중 하나는 코딩 프로세스 전반에 걸쳐 고객과 지속적으로 연락을 주고받는다는 점입니다. 이러한 파트너십을 통해 스프린트가 끝날 때까지 기다리는 대신 각 반복 내에서 피드백을 테스트하고 통합할 수 있습니다. 그러나 XP에서는 코딩 규칙이 상당히 엄격합니다. 이러한 규칙에는 다음이 포함됩니다.

• 모든 코드는 코딩 표준을 충족해야 합니다.

• 단위 테스트를 사용하여 요구 사항을 파악하고 프로젝트의 모든 측면을 개발합니다.

• 페어 프로그래밍: 두 명의 개발자가 동일한 컴퓨터에서 동시에 협업합니다. 이렇게 하면 시간이 추가되는 것이 아니라, 오히려 두 배의 집중력을 사용하여 최고 품질의 결과를 도출할 수 있습니다. 

• 지속적인 연동을 사용하여 새 코드를 추가하고 즉시 테스트합니다.

• 오류를 줄이기 위해 한 번에 한 쌍만 코드를 업데이트할 수 있습니다.

• 공동 코드 소유권 - 팀의 모든 구성원이 언제든지 코드를 변경할 수 있습니다.

5. 테스트

익스트림 프로그래밍 프로세스 전반에 걸쳐 테스트해야 합니다. 모든 코드는 릴리스되기 전에 단위 테스트를 통과해야 합니다. 이러한 테스트 중에 버그를 발견하면 이를 수정하기 위해 새로운 추가 테스트를 생성합니다. 나중에 작업 중인 동일한 사용자 스토리를 승인 테스트로 구성합니다. 이 테스트에서 고객은 결과를 검토하여 사용자 스토리를 제품으로 얼마나 잘 구현했는지 확인합니다.

12가지 익스트림 프로그래밍 관행은 무엇인가요?

프로세스를 더욱 개선하기 위해 XP는 프로세스 전반에 걸쳐 12가지 관행을 사용합니다. 이러한 관행은 애자일 선언문을 기반으로 하지만 XP의 필요에 맞게 조정되었습니다.

1. 계획 게임: XP 계획은 업무를 안내하는 데 사용됩니다. 계획의 결과는 달성하고자 하는 것과 언제까지 달성할 것인지, 다음에 무엇을 할 것인지에 대한 것입니다.

2. 고객 테스트: 새로운 기능을 완료하면 고객은 수락 테스트를 개발하여 원래 사용자 스토리와 얼마나 가까운지 확인합니다.

3. 소규모 릴리스: XP는 프로세스 전반에 걸쳐 인사이트를 얻기 위해 소규모의 정기적인 릴리스를 사용합니다. 종종 릴리스는 사내에서 발생할 수 있지만 고객에게 직접 전달됩니다.

4. 간단한 디자인: XP 시스템은 단순함을 위해 설계되었습니다. 필요한 것만 생산하고 그 이상은 생산하지 않습니다. 

5. 페어 프로그래밍: 모든 프로그래밍은 나란히 앉아 있는 두 명의 개발자가 수행합니다. 익스트림 프로그래밍에는 솔로 작업이 없습니다.

6. 테스트 중심 개발(TDD): XP는 피드백에 의존하므로 많은 테스트가 필요합니다. 짧은 주기를 통해 프로그래머는 자동화된 테스트를 릴리스한 다음 즉시 대응합니다.

7. 리팩터링: 코드베이스의 세부 정보에 주의를 기울이고 중복을 제거하며 코드의 일관성을 유지하는 단계입니다. 그 결과 훌륭하고 간단한 디자인이 탄생합니다.

8. 집단적 소유권: 코드를 개발했는지 여부와 관계없이 모든 코딩 쌍은 언제든지 코드를 변경할 수 있습니다. XP는 팀으로서 코드를 생성하며, 모든 사람의 작업은 더 높은 집단적 기준에 부합합니다.

9. 지속적인 연동: XP 팀은 완료된 반복을 기다리지 않고 지속적으로 연동합니다. XP 팀은 하루에 여러 번 통합하는 경우가 많습니다.

10. 지속 가능한 속도: XP 작업의 강도는 지속 가능한 속도를 설정해야 합니다. 팀은 하루와 일주일에 이 방식으로 생산할 수 있는 작업량을 결정하고 이를 사용하여 작업 마감일을 설정해야 합니다.

11. 비유: 비유는 말 그대로 비유입니다. 이는 팀으로서 결정되며, 팀이 어떻게 기능해야 하는지를 설명하는 언어를 사용합니다. 예를 들어, 우리는 개미집을 만들기 위해 집단으로 일하는 개미입니다. 

12. 코딩 표준: XP 팀은 하나의 표준을 따릅니다. 작가가 항상 같은 사람이 작성하는 것처럼 보이도록 브랜드의 목소리를 취해야 하는 것과 마찬가지로 XP 개발자는 하나의 개발자가 작성한 것처럼 보이도록 동일한 방식으로 코딩합니다.

격렬하지만 효과적입니다

이 시점에서 익스트림 프로그래밍이 극단적이라는 것을 알게 되셨을 것입니다. 이 프로세스는 엄격하고 매우 체계적이지만 그 결과는 그만한 가치가 있을 수 있습니다. 고객 피드백과 강렬한 협업 프로그래밍을 통합한 XP의 고유한 개발 프로세스는 고품질 소프트웨어를 만들어 냅니다. 

업무와 마찬가지로 실시간으로 업데이트되고 조정되는 업무 관리 툴로 XP 계획 및 관리를 간소화하세요.