익스트림 프로그래밍(Extreme Programming XP)¶

• 짧은 주기의 이터레이션(Iteration)을 통해 요구 변화에 신속하게 대응하여 고품질의 소프트웨어를 빠르게 전달하는 애자일의 방법론 중 하나입니다.

XP의 필요성¶

• 신속한 개발 : RUP의 산출물 부담으로 신속한 개발이 불가능 하기 때문에 필요합니다.
• Time To Market : 빠른 시장 대응 능력이 향상되고 적시에 배포가 가능합니다.
• 유연한 대처 : 프로세스 중심의 전통 방법론으론 빠른 시장 대응이 어렵기 때문에 필요합니다.

XP의 특징¶

• 개발자, 관리자, 고객의 조화로 개발 생산성을 높입니다.
• 고객 요구 사항 변경에 적극적이고 긍정적으로 대응이 가능합니다.

XP의 구성요소¶

1. 사용자 스토리(User Story)¶

• 사용자 요구 사항/UML의 Use Case와 같은 목적
• 릴리즈 게획을 작성하기 위한 단위
• 기능 단위로 필요한 내용을 간단하게 기재, 필요 시 간단한 테스트 사항도 표기 가능
• 시스템을 사용하는 고객이 필요한 것이 무엇인지를 기술

2. 아키텍처 스파이크(Architectural Spike)¶

• 어려운 요구 사항 혹은 잠재적인 솔루션들을 고려하기 위해 작성하는 간단한 프로그램
• 사용자 스토리의 신뢰성을 증대시키거나 기술적인 문제의 위험을 줄이고자 하는데 목적

3. 배포 계획(Release Planning)¶

• 전체 프로젝트에 대한 배포 계획을 생성

4. 반복(Iteration)¶

• 하나의 반복을 1주~3주 정도로 나누고 프로젝트 전반에 균일하게 유지
• XP의 반복은 프로세스의 평가와 계획을 단순하고 신뢰성 있게 만드는 핵심 항목(반복 계획 미팅)
• 사용자 요구 사항 변경, 기술적인 문제 등 상황에 따라 릴리즈 및 반복 계획 수정 가능

5. 승인 테스트(Acceptance Test)¶

• 릴리즈 전의 인수 테스트, 고객이 수행

6. 소규모 배포(Small Release)¶

• XP 주기의 마지막 단계
• 소규모로 빈번하게 배포하면 고객에게 여러 가지 이득을 조기 제공
• 프로그램은 빠른 피드백을 제공 받음

7. 기립 회의(Standup meeting)¶

• 전체 팀원들 사이의 의사소통으로 현재의 문제점 해결책 등을 논의하고 팀이 초점을 잃지 않도록 하기 위해 사용

XP의 가치¶

• 의사소통(Communications) : 개발자, 관리자, 고객 간의 원활한 의사소통
• 단순성(Simplicity) : 부가적 기능, 사용되지 않는 구조와 알고리즘 배제
• 피드백(Feedback) : 지속적인 테스트와 통합, 반복적 결함 수정, 빠른 피드백
• 용기(Courage) : 고객의 요구사항 변화에 능동적인 대처
• 존중(Respect) : Stakeholder는 팀원의 기여를 존중하여 소프트웨어 개발 생산성과 인간성을 동시 개선

XP의 원칙¶

• 인간성(Humanity)
• 경제성(Economics)
• 상호 이익(Mutual Benefit)
• 자기 유사성(Self-similarity)
• 개선(Improvement)
• 다양성(Diversity)
• 반성(Reflection)
• 흐름(Flow)
• 기회(Opportunity)
• 중복(Redundancy
• 실패(Failure)
• 품질(Quality)
• 아기발걸음(Baby Steps)

실천 항목¶

1. Fine Scale Feedback¶

• Test Driven Development

  - 개발자 먼저 단위 테스트, 실제 코드를 작성하기 전에 먼저 작성합니다.

  • 고객은 기능 테스트를 작성하여 요구 사항이 모두 반영되었는지를 확인합니다.

• Planning Game
  • 사용자 스토리를 이용해서 다음 릴리즈의 범위를 빠르게 결정합니다. 비즈니스 우선 순위와 기술적 평가가 결합되어있습니다.

• Whole Team
  • 개발 효율성을 위해 고객을 프로젝트에 상주시킵니다.
  • 고객은 스토리를 명확하게 해주고, 중요한 비즈니스 결정사항에 대해 명확한 답을 제공해주는 역할을 합니다.

• pair Programming
  • 두 사람이 함께 프로그램 작업을 합니다(Driver/Partner)
  • 모든 프로그래밍은 하나의 컴퓨터에 2명의 프로그래머가 같이 공동작업을 합니다.

2. Continuous Process¶

• Continuous Intergration
  • 컴포넌트 단위로 혹은 모듈 단위로 나누어서 개발된 소스코드들은 하나의 작업이 끝날 때 마다 지속적으로 통합되고 동시에 테스트됩니다.

• Design Improvement
  • 프로그램 기능은 변경 없이 중복/복잡성 제거, 커뮤니케이션 향상, 단순화, 유연성 추가 등을 통해 시스템을 재구성 합니다.

• Small Release
  • 필요한 기능들만 갖춘 간단한 시스템을 빠르게 릴리즈, 고객이 소프트웨어가 어떻게 돌아가는지 아주 짧은(2주) 싸이클로 볼 수 있도록 자주 새로운 버전을 배포합니다.

3. Shared Understanding¶

• Simple Design
  • 당장 필요하지 않은 디자인 배제합니다.
  • 항상 가장 간결한 디자인 상태 유지합니다.

• System Metaphor
  • 공통의 name system(의사 소통 및 공통 개념 공유)
  • 전체 개발 프로세스에 걸쳐서 시스템의 동작에 대한 전체 그림을 표현하는 것으로, 이해하기 쉬운 스토리로 이루어집니다.

• Collective Code Ownership
  • 팀의 모든 프로그래머가 소스 코드에 대해서 공동 책임을 지는 것으로, 시스템에 있는 코드는 누구든지 언제라도 수정 가능해야 합니다.

• Coding Standard
  • 팀원들 간 커뮤니케이션을 향상시키기 위해서는 코드가 표준화 된 관례에 따라 작성되어야 합니다.

4. Programmer Welfare¶

• Sustainable Pace
  • 일주일에 40시간 이상을 일하지 말도록 규칙으로 정하고 2주를 연속으로 오버 타임 하지 않도록 합니다.