Rule of Extreme Programming(XP)

dykwon·2023년 11월 5일
0

XP의 철학에 대해 더 알고 싶다면

https://velog.io/@dykwon/Second-edition-of-Extreme-ProgrammingXP-2nd-Edition

정말 애자일스럽다 XP

그동안 내가 팀원분들과 꽤나 애자일스럽게 일을 해왔다는 사실을 알게 되었다.
팀을 매니징하면서 Jira의 사용과 이전 팀장님께 받은 영향이 컸던 것 같다.

http://www.extremeprogramming.org/rules.html

Rules of XP

  1. Planning
  • 스토리를 작성하라
    • 유저 스토리는 시스템이 유저 또는 고객을 위해 서비스해야하는 항목
    • 이 내용은 고객이 직접 작성하며, 개발자는 스토리를 통해 요구사항을 파악
    • 해당 요구사항으로부터 개발자는 예상시간을 파악하고, 개발 후 승인 테스트를 진행
  • 릴리스 계획회의를 통해 릴리스 계획을 수립하라
    • 릴리스 계획은 유저 스토리를 추정하는 것으로 수립됨
    • 최종 릴리스 계획이 수립되고 경영진이 불만스러워할 때 사용자 스토리에 대한 추정치를 변경하고 싶은 유혹이 듭니다. 이렇게 해서는 안 됩니다. 추정치는 유효하며 반복 계획 회의 중에 있는 그대로 필요합니다. 지금 과소평가하면 나중에 문제가 발생할 수 있습니다.
    • http://www.extremeprogramming.org/rules/planninggame.html
  • 프로젝트는 여러번의 반복의 집합이다. (ex : 스프린트)
  • 각 반복마다 반복 계획을 수립하라.
    • 프로그래밍 작업을 미리 계획하지 말고, 반복이 시작될때 회의를 열어 계획을 수립하라.
  1. Managing
  • 팀에게 개방향 작업 공간을 제공하라
    • 스탠드업 회의를 위한 넓은 공간과, 화이트보드, 소유권이 없는 공동자리 등
  • 지속 가능하고 측정 가능하며 예측 가능한 속도 설정
    • 너무 빠르게 달려나가거나, 너무 느리게 루즈해지거나하면 안되고, 적당한 속도로 적당한 계획을 가지고 지속가능하게 그리고 우리의 숲이 보이도록 계획하고 속도를 설정
  • 스탠드업 미팅은 매일 시작 전 진행
  • 사람들을 옮겨라
    • 실제로 매일 크롤링 업무만 하는 사람은 다른 업무를 해보지 못한 것에 대한 아쉬움을 겪게됨
    • 특정 코드의 섹션에 대해 모든 것을 아는 한 사람 대신 각 세션의 코드에 대해서 모든 사람들이 알고 있는 편이 좋다. (페어 프로그래밍과 이동을 통해 교차훈련)
    • 팀의 유연성이 생김
  • 업무 프로세스, 개발 프로세스 등 XP에 한정되지 말고 개선이 필요한 부분은 언제든지 개선할 것
  1. Designing
  • 간결하게 디자인하라
  • 시스템 메타포를 사용하라
    • 시스템 메타포란 모든 사람들(고객, 프로그래머, 그리고 관리자)이 시스템의 작동 방법에 대해 이야기할 수 있는 스토리다.
    • 프로젝트의 목표와 복잡성을 이해하고 설명하는 데 도움을 주는 비유나 비유적인 모델을 의미한다.
  • CRC 카드를 사용해라 (객체간 관계 카드, Brain Storming Tool)
  • 스파이크 솔루션을 사용하라
    • 예를 들어 어려운 이슈가 있다고하면, 해당 이슈에 팀원 2명을 투입하여 2주간 해당 이슈에 대해서만 해결하도록 함으로써, 짧은 시간동안 기술적 또는 기타 이슈를 조사하고 해결하기 위한 작업
    • 기능을 빠르게 추가하지 말아라. 기본 기능과 간결함에 집중하라.
      • 미래의 요구 사항과 추가적인 유연성에 대해서는 눈을 감으세요.
    • 리팩토링은 언제든지 어디서든지 할 수 있는 만큼 해라.
  1. Coding
  • 고객은 항상 함께 할 수 있어야한다.
    • 요구사항을 파악할때도(스토리 작성)
    • 배포를 할때도, 기능 테스트 과정중에도
    • 기타 필요한 과정중에 함께 있어야 한다.
  • 코드는 팀원간 합의된 규격에 따라 형식화 되어야한다.
    • 코딩 컨벤션 일치, 네이밍 등
  • 코드는 작성전 단위테스트가 먼저 작성되어야 한다.
  • 모든 Production용 코드는 페어 프로그래밍을 통해 작성되어야 한다.
  • 자주 코드 저장소에 통합하고 커밋하라 (코드를 저장소와 최신으로 유지하라)
  • 개발은 병렬로 진행하더라도, 통합은 순차적으로 한 스레드에 한번만 진행하라
    • 다중 작업에서 통합 시, 문제가 발생하지 않도록 순차적으로 통합을 신중히 하라는 뜻.
  • 집단 소유권은 설계자뿐만 아니라, 모든 개발자가 기능 추가, 버그 수정, 디자인 개선, 리팩터링을 위해 코드를 변경할 수 있음을 의미함. 책임과 함께 권한을 위임할 수 있어야함. 이를 위해 100% 통과가능한 단위테스트를 항상 활용하면 신뢰성을 높일 수 있음
  1. Testing
  • 모든 코드는 단위 테스트를 갖고 있어야한다.
  • 모든 코드는 배포되기전에 모든 단위 테스트를 통과해야한다.
  • 버그가 생기면 단위테스트가 생겨야한다.
  • 승인 테스트는 자주 실행되어야한다. 그리고 점수는 퍼블리쉬 되어야한다.

위에 작성한 Rules of XP를 읽어보고 아래 링크의 맵을 보면 이해가 쏙쏙 !
http://www.extremeprogramming.org/map/project.html

profile
Programmer, who turns ideas into value

0개의 댓글

관련 채용 정보