Extreme Programming / Kent Beck

Extreme Programming(XP)는 무엇인가

• XP는 Agile 프레임워크 중 하나,
• 소프트웨어 개발의 제약 조건들을 다루는 것에 바탕을 둔 방법론
  • 방법론이란 ‘성공을 보장하려면 따라야 하는 규칙들의 집합’으로 해석되지만, XP는 팀마다 적용 방식이 다를 수 있고 XP를 적용하여도 성공 수준이 모두 다르다
• 양질의 소프트웨어를 만들어내고, 모호하거나 빠른 속도로 변하는 요구사항에 적응할 수 있게 한다

1999년 켄트벡이 좋은 소프트웨어 팀들이 공통으로 지닌 것들 중 가장 효과가 좋았던 것들을 엮어서 가장 순수하고, 가장 Extreme 한 모범 사례를 추출하였다(Extreme Programming Explained, October 1999). 그러나 현재에는 꽤 일반적인 것들이며 XP의 정의는 계속해서 확장되고 있다.

운전하는 법 그리고 XP

운전은 차를 바른 방향으로 가도록 맞춰두고 그대로 있는게 아니다.

계속 신경쓰면서 조금씩 방향을 고치는 것이다.

XP 차원에서의 적용

• 소프트웨어 deploy 간격을 짧게 유지하여 변화하는 고객의 시스템 내용 방향과 개발 팀의 개발 프로세스에 대응한다.
• 고객은 소프트웨어가 어디로 갈지 매주 결정을 내리면서, 어느 지점이 목표 지점인지 늘 생각해야 한다.

XP 배우기 : 가치, 원칙, 실천방법

https://lh4.googleusercontent.com/hmcLOvegici6sMdr9VSDuRBc914cY9QbmPTFPXhNESHAdFbABCPdR1x6NF1JErMs0ZweCrNknBDyedyTLRyA96L0ahC-93dzsn_mCDNhTtaw8RDVJ3OKPK4FHPc_hvmN1xtXVkiqL1P_hVCvbn2ESQY_y0oWES5Zmg5cCe0rTPxZHb4iFROUBM8lxYYXHg

• 가치
  • 자체로는 추상적이고 모호하나
  • 실천방법에 목적을 부여한다
• 실천방법
  • 구체적이고 현실적인 방안
  • 가치에 책임을 부여한다
  • 그러나 어떤 상황이냐에 따라 완전히 달라진다
• 원칙
  • 가치와 실천방법 사이를 잇는 다리
  • 특정 영역에서 영원한 지침

가치

• 의사소통
  • 개발 과정에서 문제가 생겼을 때 누군가는 이미 해결책을 알고 있는 경우가 많다
  • 한 팀이라는 느낌을 주고 효과적으로 협동하려면 의사소통이 중요하다
• 단순성
  • 제대로 동작할만한 가장 단순한 것
  • 불필요한 복잡성을 제거하자
• 피드백
  • 한번에 완벽하게 문제를 해결할 수는 없다
    • 처음 보는 문제에 대해 어떻게 하는 것이 제대로 하는것인지 아직 모를 수 있다
    • 우리의 통제능력과 예측능력을 벗어나는 변화로 이전 결정이 무효가 될 수 있다
    • 해결책을 구현하는 도중 시간이 지나 상황이 바뀌어 그 해결책이 무효가 될 수 있다
  • 피드백을 통해 목표에 나아간다
• 용기
  • 용기만으로는 위험하지만 다른 가치들과 조화를 이룰 때 강력해진다
    • 의사소통 + 신뢰 : 진실을 말할 수 있는 용기
    • 단순성 : 실패할 해결책을 버리고 새로운 해결책을 찾아 나서는 용기
    • 피드백 : 구체적인 답변을 추구하는 용기
• 존중
  • 팀에 속한 모든 개인의 기여를 존중하자

원칙

인간성, 경제성, 상호 이익, 자기 유사성, 개선, 다양성, 반성, 흐름, 기회, 잉여, 실패, 품질, 아기발걸음, 받아들인 책임…

---

• 상호 이익
  • 모든 활동은 그 활동과 관련된 모든 사람에게 이익이 되어야만 한다 (win-win-win)
    • 원활한 인간관계를 유지해야하기 때문
  • 따라서 소프트웨어 내부에 대한 설명 문서를 대량으로 작성하는것은 원칙에 위배된다
    • 미래 프로그래머들이 혹시 코드를 유지보수할 수 있으니 그것을 쉽게 해주기 위해 현재의 내 개발속도를 현저히 떨어뜨리는 것
  • 해결방법 : ‘미래와 의사소통하기’
    • 나는 자동화 테스트를 짜며 더 나은 설계와 구현을 얻을 수 있다. 그리고 그 테스트들은 미래의 프로그래머들도 사용할 수 있게 남겨둔다. 이러한 실천방법은 나와 미래의 유지보수자 모두에게 이익이 된다.
• 아기발걸음
  • 중요한 변화를 한번에 시도하는 것은 위험하다
  • 작은 단계를 빠르게 밟아 도약하자
    • 단계를 쪼갤때 생기는 부하 < 큰 변화를 시도했다가 실패해서 rollback때 드는 낭비
  • 실천방법 : TDD, 지속적 통합

실천방법

함께 앉기, 전체 팀, 정보를 제공하는 작업 공간, 활기찬 작업, 짝 프로그래밍, 스토리, 일주일별 주기, 분기별 주기, 여유, 10분 빌드, 지속적 통합, TDD, 점진적 설계…

---

• 10분 빌드
  • 10분만에 자동으로 전체 시스템을 빌드하고 모든 테스트를 돌려라
    • 10분 이상일 경우 실행하는 횟수가 현격히 줄어들며 피드백을 받을 기회를 놓치게 된다
    • 모든 테스트를 실행시켜 추측으로 인한 위험을 제거한다
    • 스트레스 수준이 높아질 경우의 수동 빌드 빈도가 줄어들 수 있기 때문에 자동화된 빌드가 훨씬 가치있다
• 지속적 통합
  • 변경한 것을 두세 시간만에 통합하고 테스트하라
    • 통합을 오래 미룰수록 비용이 더 들며 통합 비용을 예측하기도 어렵다
  • 저자는 동기적으로 프로그래밍 에피소드가 하나 끝날때마다 페어와 함께 통합
    • 빌드가 완료되고 전체 테스트 스위트가 돌아가는 것을 기다리며 페어 프로그래밍 리뷰
    • 비동기적 방식일 경우 컨텍스트 전환으로 인한 시간 낭비 존재
• TDD
  • 명시적이고 객관적이게 이 프로그램이 무엇을 해야하는지 나타낸다
  • 테스트하기 쉬운 결합도가 낮고 응집도가 높은 코드를 만들어 낸다
  • 작동하는 깨끗한 코드를 작성하고, 테스트로 의도를 드러내면 팀원들의 신뢰를 얻을 수 있다
  • 테스트 작성-코드 작성-리팩토링 과정이 리듬으로 발전해 일의 과정이 자연스럽고 효율적
• 점진적 설계
  • 중요한 결정은 초기에 내리고, 규모가 작은 결정은 나중으로 미룬다
  • 설계를 사용하는 시점과 가까울 때 설계하는 것이 효율적이기 때문
    • 작은 보폭(아기 발걸음)으로 변경을 주는 것에 익숙해지면, 시스템이 더 단순해지고, 테스트도 작성하기 쉬워지며, 시스템이 더 작아져 팀에서 의사소통해야 할 정보도 적어진다.
• 활기찬 작업
  • 생산성은 업무 시간에 비례하지 않는다. 최상의 컨디션을 유지하자.
  • 근무시간 개선을 위해 날마다 통째로 두 시간을 방해받지 않는 코딩 시간으로 선언하는 방법도 있다

XP 적용하기

조직을 변화하는 방법은 자신부터 변화를 시작하는 것이다

• 자기 기술을 발전시킨 다음, 그 기술로 다른 사람을 도우라
  • 스스로 시도하고 싶지 않은 일을 다른 사람이 하기를 기대하는 것은
  • 인간관계에 해를 끼치고 팀의 응집성을 파괴한다
• 지속적 개선
  • 지속적인 깨어있음 -> 피드백 수용하기 -> 개선에 대해 열린 마음

코치 고르기

• XP 적용은 지도력이 필요하다
• 코치는 XP의 가치, 원칙, 실천방법을 예를 통해 전달하여 학습속도를 끌어올릴 수 있다

References

[익스트림 프로그래밍 2판 - 켄트 벡, 신시아 안드레스 공저 / 김창준, 정지호 공역

인사이트(insight)](http://www.yes24.com/Product/Goods/2126201)