Second edition of Extreme Programming(XP 2nd Edition)

Agile Alliance, extremeprogramming.org 내용을 참고하여 작성되었습니다.

• https://www.agilealliance.org/glossary/xp/
• http://www.extremeprogramming.org/
• https://wiki.c2.com/?WhenIsXpNotAppropriate

Extreme Programming(XP)

XP는 무엇인가 ?

애자일하게 프로그래밍을 하기 위한 방법론 중 하나

• 익스트림 프로그래밍은 더 높은 품질의 소프트웨어와 개발조직의 높은 삶의질을 위해 만들어진 애자일 프레임워크입니다.
• XP는 소프트웨어 개발에 적합한 엔지니어링 관행에 관하여 구체적인 지침을 제공합니다. (아래 실천 사례가 있음)

XP를 만든 사람 => Kent Beck

• XP 방법론을 만들었고, 애자일 선언문의 주요 인물이다.
• 1961년 미국 소프트 웨어 엔지니어이고, 페이스북에서 일했다고 한다.

언제 사용하면 좋은가 ?

작은 규모의 스타트업이나 프로젝트를 이제 막 만들기 시작할때 적용하면 좋다

• 동적으로 소프트웨어 요구사항이 계속 변화할때
• 제한된 시간안에 신기술을 사용해서 프로젝트를 완성해야하는 리스크가 있을때
• 대규모 조직보다는 함께 있는 소규모 조직에 적합
• 사용중인 기술이 자동화 단위 테스트나, 기능 테스트를 지원하는 경우

언제 사용하지 않아야 하는가 ?

10년전에 만들어진 프로그램인데 수정을 해야하는데 이게 기업의 정산과 관련된 시스템이면 ?

• (https://wiki.c2.com/?WhenIsXpNotAppropriate)
• 동시성 미들웨어 개발 : 막대한 양의 기존 시나리오와 결합된 올바른 동시성 동작을 위한 단위테스트가 불가능함
• OS 커널 및 장치 드라이버
• 안전성이 중요한 시스템 : 테스트는 오류의 존재만을 나타낼 뿐, 부재를 나타내지는 않는다. (테스트를 했다고 해서 오류를 모두 발견한 것은 아님)
• 레거시 시스템 : 코드의 양이 너무 방대해서, 유지관리하기 위해 시간적으로 너무 부족할때는 때때로 땜빵(실제로 번역에 납땜질로 되어있음) 임시 조치가 필요하다. 불쾌하겠지만 이것이 최선일 때가 있다.
• 프로젝트 전체가 소프트웨어에 기반한 비용이 많이 드는 결정을 내릴 때

XP의 5개 가치

한줄요약 : 서로 존중하면서 대화를 통해 좋은 방향으로 나아가자.

• http://www.extremeprogramming.org/values.html

• Communication
  서로를 존중하며 의사소통 잘하고

  • 소프트웨어 개발은 팀스포츠와 같아서, 커뮤니케이션을 통해 팀원간 의사소통을 통해 지식을 알리는 것이 필요하다. XP에서는 의사소통을 첫번째 원칙으로 강조한다. (미팅, 화이트보드에 그리기 등)

• Simplicity
  쉽고 빠른 방법으로 간결하게 진행해보고, 너무 복잡하게 생각하지 말기

  • 간결성의 의미는 우리가 이 일을 이루기 위해 가장 간결한 방법을 찾는 것이다. 간결성을 유지하면 우리가 유지보수하거나, 수정하거나, 지원하기에 좋은 시스템 디자인을 가질 수 있고, 시간을 낭비하는 것을 피할 수 있다.
  • 또한 간결성이란 미래를 예측하는 것이 아니라, 현재 있는 요구사항에만 가장 집중 하는 것이다.

• Feedback
  지속적으로 서로 피드백 주면서 팀, 문화, 제품을 계속 발전시키고

  • 지속적인 피드백을 통해, 팀은 개선이 필요한 영역을 확인하고, 그들의 관행이나 실천을 지속적으로 수정하고 향상시킬 수 있다.
  • 그리고 피드백은 서비스나 제품을 만드는데 있어서, 지속적으로 수정할 수 있는 역할을 하여 서비스나 제품 개발이 나아갈 수 있게 한다.

• Courage
  팀이나 제품의 좋은 방향을 위해서 가끔은 쓴소리도 할 수 있어야하고

  • “effective action in the face of fear”
  • 팀원간 받아들이기 어려운 상황에서도 이를 수용하려면 용기가 필요하다.
  • 팀에서 잘못된 방향이나 잘못된 관행에 대해 문제를 제기하기 위해서도 용기가 필요하다.
  • 무엇인가 잘못되고 있을 때 새로운 시도를 하는 것에 있어서도 용기가 필요하다.

• Respect
  대신 이걸 감정적으로 받아드리는게 아니라 어른의 자세로 수용하거나 다른 의견을 제시할 수 있어야하고

  • 팀원간 커뮤니케이션을 하기 위해서는 존중이 필요하다.
  • 그리고 팀원간 존중하며 피드백을 제공하거나 수용해야 한다.

XP의 핵심 방법

• XP의 핵심 방법은 아래 열거된 소프트웨어 개발 방식의 연결고리와 같다.
• XP의 방법은 최초에 만들어진 내용과는 조금 변경이 되었다.
  • 초기버전 : https://ronjeffries.com/xprog/what-is-extreme-programming/
• 아래 내용은 Version 2와 같다. 이 내용은 많은 사람들의 경험으로부터 시행착오를 거쳐서 개선된 내용이 반영되었다.

1. Sit Together
   따로 앉지말고 같이 앉자
   • 커뮤니케이션이 XP의 5대 가치다. 함께 앉아서 대화를 하는 것은 커뮤니케이션에 있어서 효과적이다. 벽이나 파티션 같은 걸 치우고 함께 앉아서 대화하기 좋은 환경을 구성해라.
2. Whole Team
   모두가 하나되어, 위아더 팀으로 일하자
   • 마치 스포츠 팀과 같이, 하나의 목표를 위해 단일팀을 형성해야한다.
   • 예를 들어 축구경기에는 축구 선수 뿐만아니라, 감독과 코치 심지어 관객까지도 하나의 팀이 되어 승리라는 목표를 두고 행동한다.
   • Whole Team은 필요한 역할을 가진 사람뿐아니라 그 필요를 충족하는 일부 역할을 가진(부기능)을 하는 모든 사람들이 협력하여 결과를 달성해야한다는 것을 의미한다.
3. Informative Workspace
   정보공유를 잘하자. 그런 환경을 조성하자.
   • 팀의 공간을 대면이 가능한 개방형 공간으로 만들어라, 그러나 만일 팀원이 원한다면 프라이버시가 필요한 시간에는 팀원이 그런 시간을 가질 수 있도록 해라.
   • 팀의 작업을 팀원과 외부 이해관계자에게도 투명하게 공개해라.
   • 정보공유가 가능한 채널을 만들어라.
4. Energized Work
   건강 지키면서, 할일은 열심히 빡 하고 퇴근은 칼퇴 딱 하고 ! 취미도 열심히하면서 건강 잘관리하고 ! 또 잘 출근해서 또 빡 ! 일하고 ! 야근 강요하지 말고 !
   • 에너지 넘치는 업무란 신체적으로와 정신적으로 집중 상태에 들어갈 수 있도록 하는 단계를 취하는 것을 말한다. 이것은 과도한 노동을 하지 않는다는 것을 의미합니다. (또는 다른 사람들이 당신을 과도하게 노동하게 두지 않도록 합니다).
5. Pair Programming
   시간이 두배로 걸리진 않는다.
   • 두개의 뇌와 네개의 눈이 한 사람이 하는 것 보다 낫다.
   • 코드 품질을 향상시키고, 상호 지속적인 코드리뷰와 서로의 지식을 공유하고 커뮤니케이션 할 수 있는 환경
6. Stories
   비즈니스 도메인과 유저 스토리를 알고 개발한다.
   • 제품이 사용자와 고객에게 의미 있는 내용으로 제공해야 하는 것을 설명합니다.
   • 팀은 스토리를 알게됨으로써, 개발을 위한 계획에 도움을 줄 수 있습니다.
   • 그리고 팀이 특정 스토리를 알게될때 더 자세한 대화를 상키시키는 역할을 합니다.
7. Weekly Cycle
   스프린트를 설정하고, 회고하며, 다음 스프린트를 설정하는 활동
   • 팀은 주간 주기의 첫 날에 진행 상황을 평가하고, 고객은 그 주에 전달하려는 이야기(Stories)를 선택하며, 팀은 그 이야기들을 어떻게 접근할 것인지 결정합니다.
   • 주간 주기가 끝날 때까지의 목표는 선택한 이야기를 실현하는 실행 가능한 테스트된 기능을 보유하는 것입니다.
8. Quearterly Cycle
   Roadmap 중 일종의 분기 KPI를 만드는 것.
   Weekly Cycle은 이 Quearterly Cylce의 세부 내용이 됨
   • 고객은 특정 분기 내에서 원하는 기능에 대한 팀의 전체 계획을 제시합니다.
   • 이는 팀에게 숲을 제시하며, 기능이 언제 사용 가능한지 궁금한 이해관계자들(투자자, 영업파트, 운영파트 등)과 소통하는데 도움이 됩니다.
   • 분기주기는 주간주기의 그룹이 될 수 있습니다. 분기주기의 방향이나 내부 이야기가 변경될 수 있는데, 이떄는 주간주기의 내용을 잘 변경하여야 합니다.
9. Slack
   Task나 Sprint와 같은 단위 또는 그룹화된 업무에 우선순위나 Story를 추가한다는 것 (사실 jira에 이 개념이 다 구현되어있음)
   • 슬랙(Slack) 개념은 주간 주기와 분기 주기에 중요한 작업 또는 이야기에 밀린 경우에 포기할 수 있는 낮은 우선순위의 작업 또는 이야기를 추가하는 것입니다. 다시 말해, 추정치의 내재적인 변동성을 고려하여 예측을 충족시킬 좋은 기회를 남기도록 하는 것입니다.
10. Ten-Minute Build
    전체 시스템을 자동으로 빌드하고 모든 테스트를 10분 안에 실행하자
    • 10분의 시간 프레임을 제안한 이유는 팀이 10분보다 더 걸리는 빌드를 가지고 있으면 자주 실행되지 않을 가능성이 높아져 오류 발생까지의 시간이 더 길어질 수 있기 때문
    • 빌드 프로세스를 자동화하도록 장려하여 정기적으로 실행하고, 자동화된 빌드 프로세스를 사용하여 모든 테스트를 실행하도록 하는 데 도움을 준다.
    • 이 실천 방법은 지속적 통합(Continuous Integration) 실천 방법을 지원하며, 테스트 주도 개발(Test First Development) 실천 방법을 지원한다.
11. Continuous Integration
    CI는 아프면 더 자주하세요
    • 코드 변경 사항이 큰 코드 베이스에 추가될 때 즉시 테스트되는 실천 방법
    • 대부분의 팀은 충돌과 문제의 발견이 발생하게되는것을 싫어해서, 통합 단계를 기피하는 경향이 있는데, XP에서는 아프면 더 자주 하세요 라고 함
12. Test First Programming
    TDD 하세요
    • Test-First Programming은 개발자가 문제를 식별하고 해결하기 위한 피드백 주기를 줄여서 생산 환경으로 들어가는 버그의 수를 줄이는 데 기여합니다.
    • XP는 Test를 기반으로 버그를 수정하거나, 기능을 릴리즈 하며 진행된다.
13. Incremental Design
    영업담당자 : A입니다. 개발자 : A 만들었어요. 영업담당자 : B라니까요 ?
    점진적으로 설계하세요.
    • 리팩토링을 통해서, 설계를 간단히 유지하세요. 프로세스의 중복을 제거하세요.
    • 설계의 올바른 범위를 이해하기 위해서, 먼저 조금만 작업을 수행하고, 특정한 긴으을 제공한 후 실제 설계의 세부사항을 결정하세요.
    • 변경 비용을 줄이고 가장 최신정보를 기반으로 필요한때에 설계를 할 수 있습니다.

XP의 라이프사이클

• 사실 jira를 통해 스프린트와, 태스크, 우선순위, 회고, 스크럼등을 경험해본분이라면 같은 내용이다.
• https://www.agilealliance.org/glossary/xp/ 의 Life Cycle을 읽어보시면 도움이 될 것 같다. PDCA(Plan Do Action Check !)
• http://www.extremeprogramming.org/map/project.html 이곳의 프로젝트 맵도 추천드린다. 클릭하면 XP Map의 구성 요소에 대한 자세한 설명이 있고, 링크되어 이동할 수 있다.