Dayoung

Dayoung

Be-Developer

© 2024

Dark Mode

XP 익스트림 프로그래밍
Oct 3, 2022
  • XP
  • study

01 XP?

  • 우리를 보호해주지만 생산성을 떨어트리는 방어수단을 포기하는것에 대한 이야기
  • XP가 다른 방법론과 다른 이유
    • 짧은 개발주기 : 개발 초기부터 구체적이고 지속적인 반응을 얻게 해준다.
      • 우선순위가 높은 기능부터 구현해야한다.
    • 점진적 계획 접근법 : 계획을 빨리 만들고 시작한다음, 생애내내 계획이 진화하는것을 기대한다.
    • 기능 구현 일정을 유연하게 세워 자주바뀌는 비즈니싀 요구를 대응할 수 있는 능력
    • 자동화 테스트에 의존
    • 구두 전달, 테스트, 소스코드에 의존하여 시스템 구조와 시스템의 의도를 전달하는 점
    • 시스템이 존재하는 마지막 순간까지 끝나지않는 진화적인 설계절차에 의존하는 점
    • 팀 구성원들 사이의 긴밀한 협력에 의존하는 점
    • 팀 구성원들의 단기적 본능과 프로젝트의 장기적 이해 관계 둘다 적용될 수있는 실천방법에 의존하는 점
  • XP는 팀 규모와 상관없다.
  • 빠른 속도로 변하는 요구사항에 적응하는 방법론이다
  • 다른사람의 기대를 ‘관리’하는것은 내 일이아니고, 그들의 몫, 최선을 다하는 것과 의사소통을 명확하게 하는것이 나의 몫

02 운전하는 법 배우기

  • SW가 어디로 갈지 매주 결정을 내리면서, 장기목표가 어디인지는 항상 생각해야한다.

03 가치,원칙,실천방법

  • 실천방법 : 실제로 하는것들
  • 가치 : 어떤 상황에서 좋아하고 좋아하지않는것들의 근원.
    • 가치가 없이는 실천이 기계적인 활동, 목적이나 방향없이 하라니까 하는 것이 되어버린다.
    • 결함에서 배우기를 주저하는 프로그래머는 배움과 자기개선에 다른것만큼의 가치를 부여하지 않는다는것을 보여준다.
    • 추정치에 대해 의사소통을 거부하는것은 개발 과정에서 사회적 힘들의 작용을 그가 어떻게 보는지에 대해 보여준다.
  • 원칙 : 특정한 영역에서 영원한 지침이 되는것.

04 가치

  • 코딩 스타일에서 팀이 공통된 스타일을 지향하고있는것은 중요하다.
  • 의사소통
    • 어떤 문제에 맞닥뜨릴경우, 이 문제가 의사소통의 부재때문에 생긴게 아닌지 자신에게 질문하라.
  • 단순성 : 오늘의 문제가 우아하게 해결될 만큼 단순한 시스템을 만드는것은 중요하다. (복잡성을 제거하라)
  • 피드백 : 팀이 다룰 수 있는 한도 내에서 빨리,많이 피드백을 만들라. (주/월단위 -> 분/시간단위)
  • 용기
    • 행동을 중시 : 문제가 무엇인지 안다면 무엇이든 해보는것
    • 인내 : 문제가 정확히 무엇인지 뚜렷하게 나타날때까지 기다리는것.
    • 용기만 중요한 가치로 삼고, 결과를 생각해보지도않고 어떤일을 하는것은 효과적인 팀워크가 아니다.
    • 용기는 홀로있을때는 위험하지만, 다른 가치들과 조화를 이룰때 강력해진다.
  • 존중 : 팀원들 모든 개인의 기여를 존중해야한다.
  • 기타 : 팀이 신봉하는 가치에 팀의 행동이 어울리도록 만드는것이 중요.

05 원칙

  • 인간성 : 사생활은 개인이 더 많은 에너지와 시야를 얻은 후 팀으로 돌아올 수 있도록 해준다.
    • 팀의 욕구가 장기 개인 목표와 상통한다면 어느정도의 희생은 감수할만하다.
    • 뛰어난 팀은 구성원들이 서로 신뢰를 쌓은 후, 협업의 결과로 자신에게 더 충실해질 자유가 생긴다는점을 구성원들이 깨닫는다.
  • 경제성 : 하는 일이 비즈니스 가치를 지니고 비즈니스 목표에 부합하고, 비즈니스 필요를 충족하는지 확실히 하라.
  • 상호 이익 : 모든 활동은 그 활동에 관련된 모든 사람에게 이익이 되어야한다.
    • 소프트 웨어 내부에 대한 문서를 대량작성하는것은 상호이익 원칙에 위배되는 실천방법의 한 예이다. > 현재의 이익은 없기때문!
    • 좋은 예 : 자동화된 테스트 작성/ 리팩터링 / 적절한 네이밍
  • 자기유사성 (self-similarity)
    • 어떤 해결책의 구조를 다른 맥락에 적용해보라.
    • 구현 전에 시스템 차원의 테스트를 먼저 가지고 있다면, 설계를 단순화하고 스트레스를 줄이고 피드백을 개선할 수 있다.
  • 개선 : 어떤 것부터 시작하면 좋을지 찾아보고, 시작한다음 개선하라.
  • 다양성 : 팀안의 다양성이 필요하다.
    • 어떤 설계에 대한 생각이 두가지가 나왔다면, 문제가 아니라 기회
  • 반성 : 어떻게 왜 지금 일하는 방식으로 일하는지 생각해보자. 공식적인 반성의 시간이 아닌 시간에도!
    • 반성은 행동 한 다음에 오고, 배움은 행동이 반성을 거친것
  • 흐름 : 개발의 모든 단계를 동시에 작업함으로써 가치있는 소프트웨어를 끊임없이 제공하는것.
  • 기회 : 문제를 기회로 전환!
    • 문제 해결시간이 부족하다고 느끼는 욕구는 결과에 대한 두려움에서 자신을 보호하기위한 가면인 경우가 있다.
  • 잉여 : 해결방법을 여러개 마련해두고, 그중 하나만 채택하게되면 나머지는 잉여, 개발이 종료된 다음 하는 테스트도 잉여.
    • 진짜로 잉여적인것으로 판명나기전까지는 가치있다.
  • 실패 : 무엇을 해야할 지 모를경우, 실패를 감수하는것이 성공으로 가는 가장 짧고 확실한 길이다.
  • 품질 : 결함의 수, 설계 품질, 개발의 경험으로 측정했을때 개발팀이 그것을 얼마나 향상시킬수 있는지.
    • XP는 프로젝트를 계획하고, 기록을 남기고, 방향을 잡기위한 주요 수단으로 범위(scope)를 선택한다.
  • 아기발걸음 : 단계를 잘게 쪼갤때 생기는 부하가 큰 변화를 시도했다가 실패해서 복구하는 낭비보다 작다는 사실을 인정하는것.
  • 받아들인 책임 : 일을 하겠다고 서명한 사람이 그일의 평가도 내리는 것이다.
    • 어떤 프로세스 전문가가 나에게 어떤 방식으로 일할지 지시할 권리는 있찌만, 그 작업이 작업의 결과를 공유하지 않는다면, 권위와 책임이 잘못 연결된 것.

    • 06 실천 방법

  • p.71 이미지 참고
  • 실천방법들은 함께 사용했을때 효과가 좋다.
  • 새로운 실천방법을 최대한 빨리 추가하면 득이된다.

10. 전체 XP팀

  • 흐름 원칙 : 대규모배포보다 소규모배포를 꾸준히할때 더 많은 가치가 창출된다.

    테스터

  • 기능을 구현하기 전에, 무엇이 필요한지 정의하고 명시하는 일을 돕는다.
  • XP에서 사소한 실수를 잡아낼 책임은 프로그래머에게 돌아간다. (TDD)
  • happy path를 보고 에러를 예상하고 찾아내는건 테스터의 역할.

상호작용 설계자

  • 시스템의 실제 사용 양상을 분석하여 다음 할일을 찾아내고, 사용자 인터페이스를 계속 다듬는다.
  • 고객과 함께 일한다.

아키텍트 (=개발자?)

  • 대규모 리팩터링을 찾아내고 실행하는 일, 아키텍처를 집중 테스트하는 시스템 차원의 테스트를 작성하는 일, 스토리를 구현하는 일.
  • 아키텍처를 개선하고싶다면, 스트레스테스트를 강화하고 간신히 통과할만큼만 개선한다.
  • 테스트를 의사소통의 수단으로 사용하는 전략
    • 명세서와 설명대신 테스트를 사용해보자. (cuccumber?)

프로젝트 관리자

  • 조직의 다른 부분과의 의사소통 조정
  • 프로젝트 관련 정보를 임원과 동료들에게 프레젠테이션 하기위해 창조적으로 잘 포장할 필요가 있다.
  • 필요할때마다 팀 내부의 가장 적절한 사람과 팀 바깥의 가장 적절한 사람을 연결해주는 역할을 해야지, 의사소통의 병목이 되어서는 안된다.

제품 관리자 (?)

  • 팀이 하기로 한 일이 너무 많다면, 진짜 요구사항과 추측된 요구사항을 분석해서 가려냄으로써 팀이 우선순위를 결정하는 것을 돕는다.
  • 고객과 프로그래머 사이의 의사소통을 장려한다.

임원

  • XP 팀에게 용기,자신감,책임감을 불어넣는다.
  • 규모가 큰 목표를 뚜렷하게 표현하고 유지하는 일.
  • 어떤 의사 결정과정이든 팀으로부터 정직하고 명료한 설명을 들으리라 기대할 수 있어야 한다.
  • 팀의 건강 측정 수치
    • 개발 후 발견된 결함의 갯수
    • 투자를 시작하는 시점, 수익을 발생시키는 시점간의 시차. (보통1년이상)
  • XP팀에서 대화와 작업은 언제나 함께이다. 웅성거림은 팀이 건강하다는 징표이고, 침묵은 위험이 쌓이는 소리다.

테크티컬 라이터

  • 완벽한 문서화란?
  • 기능이 막 구현된 시점에 문서작성도 완료되고, 문서 개선이 쉬운것
  • 기본 개발 주기에 추가시간을 더하지 않고, 사용자와 팀에게 모두 가치있는것.

사용자

  • 스토리를 작성하고 고르는 일을 돕고, 개발중 문제영역에 관련된 결정을 내린다.

프로그래머

  • 스토리와 task추정, 스토리를 task로 나누고, 테스트작성, 기능구현, 개발 프로세스 자동화, 설계의 점진적 개선..

인적자원부

  • 평가와 채용
  • 후보자가 팀에서 하루 일해보는게 가장 좋은 면접. 짝프로그래밍은 기술,사회적 능력을 시험하는 훌륭한 방법.

역할

  • 각 역할들은 고정된것이 아니다.
  • 팀이 성숙해갈때 권위와 책임의 연결을 염두에 두어야한다.
  • 팀원가운데 누구라도 변화를 제안할 수 있지만, 제안자는 자신의 관여를 행동으로 뒷받침할 준비가 되어있어야한다.

11. 제약이론

  • 전체 시스템의 처리능력을 키우려면 먼저 제약지점(병목)을 찾은다음, 최대 속도로 가동하도록 한 다음에, 성능을 향상시키거나, 다른 지점으로 덜거나, 완전히 제거하자.
  • push 모델 (폭포수?) : 명세화 -> 설계 -> 코드 -> 테스트 각 단계가 마무리되면 순차적으로 진행됨
    • 리더가 멤버들에게 일을 할당한다.
  • pull 모델 : 설계는 코드를 작성하는 동안 수정되고, 테스트는 명세에서 끌어져나온다. -> 각 단계가 동시에 진행될수있음
    • 스토리를 우선순위 큐에 넣고, 개인이 큐에서 일을 할당해간다.
  • push and pull

12. 계획짜기 : 범위를 관리하기

  • 공유된 계획의 상태를 보면, 그것에서 영향받는 사람들 사이의 관계가 어떤 상태인지 짐작할 수 있다.
    • 현실과 동떨어진 계획 : 사람들 사이가 불명확하고 균형잡히지 않았다.
    • 상호 동의되고, 필요에 의해 조정되는 계획 : 서로 존중하며 가치있는 인간관계를 의미.
  • XP의 계획짜기는 현재 있는 목표, 가정, 사실을 분명히 드러내는 일부터 시작된다.
  • 계획을 짜는 단계
    1. 해야할 일을 목록으로 작성한다. (스토리에서 task 뽑기)
    2. 각 항목의 작업 시간을 추정한다. (이게어렵..)
    3. 계획중인 주기를 위한 예산을 세운다.
    4. 해야할 일들을 예산내 범위안에서 합의한다. 협상할때 추정치나 예산을 변경하면 안된다.

      2번을 할때, 주로 변경될 코드범위 파악해서 하는데, 이게 하다보면 늘어나서 어려운듯.

  • 계획짜기는 팀원 모두가 참여해야한다.
  • 추정을 개선하려면 빨리 피드백받는것이 중요하다.

    계획단계인데 경험을 얻으라는건 일단 실천하라는건가

  • 필자의 경험에 따르면, 짝프로그래밍은 오히려 시간이 생산적이게 된다. (?)
  • 어떤 주에 할 일의 양을 정확히 지난주에 성취한 일의 양만큼 하기로 계획을 짜자.
  • 빗나간 추정은 정보때문에 생긴 실패지 가치나 원칙때문에 생긴 실패가 아니다.
  • planning poker

13. 테스트 : 일찍,자주, 자동화

  • XP는 테스트의 비용 효율을 높이기 위해 두가지 원칙을 적용한다.
    1. 재확인 : = 테스트
    2. 결함비용증가 (DCI) : 결함은 일찍찾을수록 고치는 비용이 적게 든다.
  • 자동화된 테스트 (테스트 즉각성 immediacy)
    • 빈번한 테스트 = 코드 작성자가 테스트도 작성
    • 부하테스트같은 개발 후 테스트도 개발주기안으로 끌어들여 자동화하자.
  • 테스트 결과는 손으로 계산하는것이 좋다. (계산결과를 복사해서 예상치로 삼지말자.)
  • XP의 테스트 집합
    • 프로그래머 시각에서 작성 (unittest)
    • 사용자 시각에서 작성 (QA?)
  • 구현보다 테스트를 먼저 작성하라 : 인터페이스가 구현에 영향받는것을 줄일 수 있다.
  • 테스트는 진전의 척도를 제공한다 : ex) 테스트 10개중 1개성공 = 척도 10%

14. 설계하기 : 시간의 가치

  • 점진적 설계: 기능을 빨리 제공하고, 프로젝트 생애 내내 매주 기능을 제공하기 위한 방법.
  • 설계 품질이 성공을 보장하지는 않지만, 설계 실패는 실패를 보장한다.
    1. 직관으로 설계
    2. 정말 열심히 생각해서 설계
    3. 경험을 반영해서 설계
  • 세가지 설계 시점중 구현시기를 정할때 고려할것
    • 각 전략이 얼마나 가치를 창출하는가 : ex) 경험이 대부분의 가치를 창출한다면, (1)시작하기 충분한정도만 설계 후, 대부분의 설계는 (3)경험에 비추어하자.
    • 비용 : 설게에 투자한 + 기능추가시 앞으로 투자할 시간
  • 설계를 개선할때(리팩토링) 오늘 영향을 미치는 설계만 개선하는 습관을 길러라. 큰 개선은 목록을 만들고 팀에 공개하라.
  • XP방식 설계 : 경험을 바탕으로 설계할 수 있을때까지, 결정 내용을 즉각 사용할 수 있을때까지 설계를 미룬다.
    • 빨리 배포할수있다.
    • 확신을 가지고 결정할 수 있고, 잘못된 결정을 피할 수 있다.
    • 처음 설계를 수정하더라도 개발 속도를 유지할 수 있다.

      개인적인 경험으로 볼때, 구현중에 설계가 중간에 수정되면 비용이 배로 들었던것같다..? (서비스설계는 특히나)

단순성

  • 설계의 단순성을 평가하는 기준
    1. 작업자들이 이해하기에 적당하다.
    2. 정보전달력 : 의사소통이 필요한 모든 생각은 시스템에 표현되어있다.
    3. 리팩터링되어있다. : 중복코드제거
    4. 최소성 : 위 세가지중 시스템 요소의 수를 최소한으로 줄이자.

15. XP의 확장

사람 숫자

  • 대규모 팀이 꼭 필요하다고 생각하더라도, 먼저 작은 팀만으로 문제를 풀수있지 않은지 생각해보라.
  • 큰문제의 해결 방법
    1. 작은문제로 쪼갠다
    2. 단순한 해결방법을 적용한다
    3. 문제가 히결되지않으면 복잡한 해결방법을 적용한다.
  • 정복 후 분할 : 큰문제를 작은문제로 분할하고, 작은팀에 할당한다. 자연스레 갈라지는 틈을따라 시스템을 분할하고 각팀에게 할당해 진행하며, 분할한것들은 자주 통합한다.

투자

조직의 크기

  • 조직의 일부분에 XP를 적용하려할때, 적용되지않는 팀을 존중하라.
  • 새로 발견한 지식과 힘을 다른 사람에게 강요하지마라.

시간

  • 프로젝트 기간이 길때 XP의 장점. 테스트들이 유지보수에서 자주 생기는 문제를 방지하고 개발 프로세스에 대한 이야기를 들려주기때문.
  • 로제타석문서?

문제의 복잡도

  • XP는 전문가들의 긴밀한 협력이 필요한 프로젝트에서 가장 이상적으로 잘 맞는다.

해결방안의 복잡도

  • 복잡성을 다루는 XP전략은, 지속적으로 배포하면서 복잡성을 깎는 방법이다.
  • 어떤 영역에서 결함을 고치고있다면, 그 영역을 깔끔하게 정리하는 일도 같이 하라.

실패의 결과

  • 안전,또는 보안이 중요한 프로젝트라면, 위험관리 피드백 프로세스를 생명주기 모델안에 포함하라.

16. 인터뷰

  • 의욕넘치는 팀이 완전히 새로 시작하는 자바 프로젝트가 완벽한 XP용 프로젝트이다.
  • XP 프로젝트에서 결함률이 매우 낮다.
  • 기능단위로 계획을짜라
  • 고객이 관심을 가지는 기능들을 계획의 항목으로 삼으라.
  • 릴리즈는 분기에 한번 계획하고 iteration은 더 자주 계획하라.
  • 고객을 팀과 한자리에 앉도록 하라
  • 팀을 개방된 공간에 두라.

XP의 철학

19. 도요타 생산 시스템 TPS

  • 모든 작업자가 전체 생산라인에 책임을 진다.
  • 누구든지 결함이 발견되면 전체 라인을 중단시킬 수 있다.
  • 문제의 근원을 찾고 고치는데에 생산라인의 모든 자원이 투입된다.
  • TPS의 목표는 라인에서 품질을 충분히 만족스러울 정도로 유지해서 그 다음에 품질 검사를 할 필요가 없도록 만드는 것이다.
  • 과잉생산은 가장 큰 낭비다. 작업중 부품의 재고가 많으면 개별 기계들은 더 원활하게 돌아갈지 몰라도, 전체 공장이 그만큼 잘 돌아가는 것은 아니다.
  • SW개발에서, 요구사항 수집은 세부내용을 만들고 개발에 들어가기까지의 경로가 짧을때 과잉생산을 막을 수 있다.

20. XP 적용하기

  • XP를 적용하면 문제를 해결해주기보다는, 해결하기위한 새로운 환경을 얻게될것이다.
  • XP팀은 조직 전체의 목표를 달성하기 위한 자신들의 헌신을 강조하고, 이 작업 방식이 그 목표를 이루는데 어떻게 기여하는지 보여줄 필요가있다.ㅣ
  • 먼저 자신을 변화시킨 다음, 변화를 다른사람들에게 제공하라.
    • ex) 먼저 TDD를 익힌 다음, 팀에게 공유하라.
    • ex) 팀이 스토리 단위로 추정하고 개발하는 법을 먼저 익힌 다음, 내부 고객을 초대해서 스토리를 고르라고 하라.
  • 조직의 실제 가치가 비밀,고립, 복잡성,소심함, 무례함 등 XP와 반대된다면, 새로운 실천방법을 들이대다가 더 문제를 일으킬 수 있다.

21. 순수성

  • extream 한가요? = 팀원들이 스스로 이치에 맞다고 느끼는 모든 일을 지속가능한 방법으로 하는가? 이 질문에 대한 답은 자신뿐이다.