[02장] 익스트림 프로그래밍 소개

DAYEON·2022년 3월 2일
0

Clean Software

목록 보기
2/3
post-thumbnail

개발자로서 우리가 기억해야 할 것은 XP가 마을에서 유일한 게임이 아니라는 것이다.


익스트림 프로그래밍 실천방법

  • 애자일 방법 중에서도 가장 유명한 익스트림 프로그래밍 (XP)
  • 단순하면서도 서로 의존적인 실천 방법의 집합으로 구성되어 있음

- 고객 팀 구성원

  • XP 팀의 고객은 기능 요소를 정의하고 우선순위를 매기는 개인 또는 그룹
  • 경우에 따라 고객은 개발자와 동업하는 분석가, 마케팅 전무가의 그룹일 수 있음
  • 고객은 사용자를 대신하는 대리인, 구매자일 수 있으나 XP에서는 누구든 팀의 멤버이며, 팀에서 일할 수 있음
  • → 가까이 있을 수 있을 뿐만 아닌, 실제 고객을 대신할 수 있고, 그럴 의지가 있는 사람을 찾아라

- 사용자 스토리

  • 프로젝트 일정 계획 수립을 위해 요구사항에 대해 알아야하지만 자세히 알 필요는 X
  • 요구사항의 구체적인 세부 내용은 변동적이므로 의미없는 노력일 수 있음
  • XP를 사용할 땐 고객과 대화함으로 요구사항의 세부 내용에 대한 감은 잡지만, 세부 사항을 기록하지는 않음 '색인 카드 키워드'

- 짧은 반복

  • 반복 계획
    • 보통 2주 단위로 진행, 마이너 공개 (최종 제품에 반영 미확)
    • 개발자는 이전 반복의 완성도를 측정하여 반복의 예산 수립, 고객은 예산 이하의 한도로 반복 스토리 선택
    • 반복 시작 후, 고객은 반복 동안 스토리 정의나 우선순위를 바꾸지 않는 것에 동의
  • 릴리즈 계획
    • 릴리즈는 대게 3개월 의미, 메이저 공개 (최종 제품에 반영)
    • XP 팀은 종종 다음 약 6번의 반복 일정을 정밀하게 표현한 릴리즈 계획을 수립
    • 이전 릴리즈의 완성도를 측정하여 릴리즈 예산 수립, 고객은 구현 스토리 순서 결정 가능

- 인수 테스트

  • 사용자 스토리의 세부 사항은 고객이 명시한 인수 테스트의 형태로 기록
  • 인수 테스트는 자동, 반복적으로 실행될 수 있는 스크립트 언어의 한 종류로 작성
  • 시스템이 고객이 명시한 대로 동작하는지 여부를 검증 (EX: QA 부서 운영..)
  • 테스트를 통과하면 통과한 테스트의 본문에 추가되고 다시 실패하는 것이 허용되지 않아 시스템 다운을 방지

- 짝 프로그래밍

  • 모든 운영 코드는 같은 워크스테이션으로 일하는 프로그래머 짝들에 의해 작성
  • 코드 작성 멤버와 입력된 코드를 보며 에러와 개선점을 찾는 멤버의 긴밀한 상호작용
  • 역할은 자주 바뀜, 한 시간 동안 몇번이라도 교대로 작업 가능

- 테스트 주도 개발

  • 모든 운영 코드는 실패하는 단위 테스트를 통과하기 위해 작성됨
  • 테스트 케이스와 코드를 작성하는 사이의 간격은 1분 정도로 매우 빠름, 함께 진화, 테스트 케이스가 코드보다 약간 앞서가는 정도
  • 모듈 별 독립적으로 테스트될 수 있게 코드 분리 필요
  • 리펙토링 용이하게 만듬

- 공동 소유권

  • 개인이 어떤 한 모듈이나 기술에 대해 책임을 지거나 더한 권한을 갖지 않음
  • XP가 전문성을 부정한다? → X. 팀원들의 역량 강화와 넓은 전문성 부여 가능

- 지속적인 통합

  • 프로그래머는 자신의 코드를 체크인하고 하루에 몇 번씩 그것을 통합
  • 첫 번째로 체크인한 사람을 우선으로 나머지 사람의 코드를 병합
  • XP 팀은 비차단 소스 제어 방식 (nonblocking source control, 아무때나 어떤 모듈이라도 체크아웃하도록 허용)
  • 프로그래머가 모듈을 수정하고 난 뒤에 그것을 다시 체크인하려면, 먼저 그 모듈을 체크인한 다른 사람이 수정한 부분과 병합할 준비가 되어있어야 할 것
  • 모듈에 대한 빈번한 체크 필요

- 지속 가능한 속도

  • 빨리 골인하려면 팀이 지속 가능한 속도로 달려 에너지와 경각심을 보존해야 함
  • XP 규칙은 팀이 초과 근무를 하지 않도록 하는 것, 예외는 릴리즈 마지막 주!

- 열린 작업 공간

  • 두서너개의 워크스테이션이 설치된 테이블, 짝이 나란히 앉을 수 있는 의자, 벽엔 상황 차트, 태스크 명세, UML 다이어그램..., 낮은 웅성거림
  • 상황실이라는 환경에서 일하는 것이 두 배 정도 생산성을 향상할 수 있다고 함

- 계획 세우기 게임

  • 업무와 개발의 책임 분리가 계획 세우기 게임의 정수
  • 업무 관련 인력은 기능 요소가 얼마나 중요한지 결정, 개발자는 그 기능 요소를 구현하는 데 얼마나 비용이 들 것인지 결정

- 단순한 설계

  • XP 팀은 그들의 설계를 가능한 한 단순하고 표현적으로 만듦
  • 반복에 대해 작업하기로 계획했던 스토리에만 초점을 맞추어 공략
  • 한 반복에서 다음 반복으로 넘어갈 때 시스템의 설계를 마이그레이션해서 현재 구현 스토리에 가장 적합한 설계가 되도록 함
  • 3가지 XP 지침
    1. 어떻게든 동작하는 가장 단순한 것을 생각
    2. 필요하지 않을 것이라는 가정에서 시작
    3. 중복 코드 사용 X

- 리팩토링

  • 코드는 부패하기 쉬움, 구조는 퇴화함 → 리펙토링으로 반전!!!!
  • 리팩토링 후엔 단위 테스트 실시, 프로그래머는 1시간 혹은 30분마다 리팩토링 실시

- 메타포

  • XP의 모든 방식 중 가장 이해하기 어려운 것에 속함
  • 퍼즐을 하나로 묶는 강력한 요소인 전체 그림, 전체 시스템을 하나로 묶는 큰 그림
  • 종종 메타포는 시스템을 이름으로 요약, 시스템의 요소에 기호를 부여하고 그 관계를 정의하는 것을 도와줌


기억에 남는...

사용자 스토리 (user story)란 현재 진행 중인 요구사항에 관한 대화의 연상 기호다.

반복 계획(iteration plan)은 개발자가 세운 예산에 따라 고객이 선택한 사용자 스토리의 집합이다.

릴리즈는 절대적인 것이 아니다. 고객은 요구 내용을 언제든지 변경할 수 있다. 스토리를 취소하고, 새로운 스토리를 작성하고, 스토리의 우선순위를 변경할 수도 있다.

짝은 어떤 모듈이라도 점검하고 개선할 권리를 갖는다. 프로그래머는 하나의 개별적인 모듈이나 기술에 대해 개인적으로 책임을 지지 않는다.

소프트웨어 프로젝트는 단거리 경주가 아니라 마라톤이다. 출발선에서 가능한 빠르게 레이스를 시작하는 팀은 결승점에 도달하기 한참 전에 탈진하고 말 것이다.


profile
노력하는 초보 개발자

0개의 댓글