극단적인 프로그래밍 관행

Extreme programming practices

Extreme Programming(XP; 익스트림 프로그래밍)은 소프트웨어 프로젝트를 구현하는 데 사용되는 신속한 변화를 위한 소프트웨어 개발 방법론입니다.이 문서에서는 이 방법론에서 사용되는 프랙티스에 대해 설명합니다.익스트림 프로그래밍에는 소프트웨어 [1]엔지니어링의 베스트 프랙티스에서 파생된 12개의 프랙티스가 있으며, 4개의 영역으로 분류됩니다.

세밀한 피드백

페어 프로그래밍

페어 프로그래밍은 모든 코드가 두 사람이 하나의 워크스테이션에서 하나의 작업을 프로그래밍하는 것을 의미합니다.한 프로그래머가 워크스테이션을 제어하고 있으며, 주로 코딩에 대해 자세히 생각하고 있습니다.다른 프로그래머는 큰 그림에 더 집중하고 있으며, 첫 번째 프로그래머가 만들고 있는 코드를 지속적으로 검토하고 있습니다.프로그래머는 분에서 시간 단위로 역할을 바꿉니다.

이 쌍은 고정되어 있지 않습니다.프로그래머는 파트너를 자주 바꾸므로 모든 사람이 무엇을 하고 있는지 알 수 있습니다.또, 모든 사람이 시스템 전체에 익숙해져 있습니다.스킬 세트 이외의 부분에도 익숙해져 있습니다.이렇게 하면 페어 프로그래밍을 통해 팀 전체의 커뮤니케이션을 강화할 수도 있습니다.(이는 집단 소유의 개념과도 관련이 있습니다).

기획 게임

익스트림 프로그래밍 내의 주요 계획 과정을 계획 게임이라고 합니다.게임은 반복당 1회, 보통 일주일에 1회 개최되는 회의입니다.계획 프로세스는 다음 두 부분으로 나뉩니다.

  • 릴리스 계획:이 작업은 어떤 요건이 어떤 단기 릴리즈에 포함되어 있는지, 언제 제공해야 하는지 결정하는 데 초점이 맞춰져 있습니다.고객과 개발자가 모두 이에 참여하고 있습니다.릴리즈 플래닝은 다음 3단계로 구성됩니다.
    • 탐색 단계:이 단계에서 고객은 시스템의 높은 가치 요건을 간략하게 제시합니다.이것들은 유저 스토리 카드에 써집니다.
    • 이행 단계:계약 단계에서 비즈니스 및 개발자는 포함되는 기능과 다음 출시 날짜에 전념합니다.
    • 스티어링 단계:조향 단계에서 계획을 조정할 수 있으며, 새로운 요건을 추가하거나 기존 요건을 변경하거나 제거할 수 있습니다.
  • 반복 계획:이를 통해 개발자의 활동과 작업을 계획합니다.이 프로세스에서는, 고객은 관여하지 않습니다.반복 계획도 다음 3단계로 구성됩니다.
    • 탐색 단계:이 단계에서는 요건을 다른 태스크로 변환합니다.작업은 작업 카드에 기록됩니다.
    • 이행 단계:작업은 프로그래머에게 할당되어 완료에 걸리는 시간이 추정됩니다.
    • 스티어링 단계:작업이 수행되고 최종 결과가 원래 사용자 사례와 일치합니다.

Planning Game의 목적은 제품의 배송을 안내하는 것입니다.성과물이 언제 필요하고 생산될지 정확한 날짜를 예측하는 것이 아니라, 간단한 [2]접근 방식을 사용하여 프로젝트를 "조종"하여 납품하는 것을 목표로 합니다.또한 비즈니스 [3]민첩성 측면에서 비소프트웨어 프로젝트 및 팀에서도 Planning Game 접근 방식을 채택하고 있습니다.

릴리스 계획

탐색 단계

이는 요구사항을 수집하고 각 요구사항이 작업에 미치는 영향을 추정하는 반복적인 프로세스입니다.

  • 스토리 쓰기: 비즈니스에는 문제가 있습니다.회의 중에 개발자는 이 문제를 정의하고 요건을 얻으려고 합니다.비즈니스상의 문제를 바탕으로 스토리(사용자 스토리)를 작성해야 합니다.이는 비즈니스에서 이루어지며, 고객이 시스템의 일부로 무엇을 하기를 원하는지 지적합니다.발전이 이 이야기에 영향을 미치지 않는 것이 중요하다.그 이야기는 사용자 이야기 카드에 쓰여 있다.
  • 스토리 견적: 개발 부문에서는 스토리 카드에 포함된 작업을 구현하는 데 걸리는 시간을 예측합니다.개발에서는 문제를 분석하거나 해결하기 위한 스파이크 솔루션을 만들 수도 있습니다.이러한 솔루션은 모든 사용자가 문제를 명확하게 파악한 후 평가에 사용되며 폐기됩니다.다시 말씀드리지만, 이는 비즈니스 요건에 영향을 주지 않을 수 있습니다.
  • 스토리 분할: 반복 계획을 시작하기 전에 설계에 중요한 모든 복잡성을 해결해야 합니다.만약 개발에서 그 이야기를 추정할 수 없다면, 다시 나누어 쓸 필요가 있다.

비즈니스가 더 이상 요건을 제시하지 못할 때는 약속 단계로 넘어갑니다.

커밋 단계

이 단계에서는 비용, 이익 및 일정에 미치는 영향을 결정합니다.4개의 컴포넌트가 있습니다.

  • 가치별 정렬: 비즈니스는 비즈니스 가치별로 사용자 사례를 정렬합니다.
  • 리스크별 정렬: 개발은 리스크별로 스토리를 정렬합니다.
  • 속도 설정:개발은 프로젝트를 어느 정도의 속도로 수행할 수 있는지를 결정합니다.
  • 범위 선택:다음 릴리즈에서 완성될 사용자 스토리가 선정됩니다.사용자 스토리에 따라 출시일이 결정됩니다.
값별 정렬

비즈니스 측면에서는 비즈니스 가치별로 사용자 사례를 정렬합니다.그들은 그것들을 3개의 무더기로 배열할 것이다.

  • 중요: 시스템이 작동하지 않거나 의미가 없는 스토리.
  • 중요한 비즈니스 가치: 중요한 비즈니스 가치가 있는 중요하지 않은 사용자 사례.
  • 좋은 점: 비즈니스 가치가 크지 않은 사용자 사례.
리스크에 따른 정렬

개발자는 리스크에 따라 사용자 스토리를 분류합니다.또한 저위험, 중위험, 고위험의 3가지 스토리로 분류됩니다.다음은 이에 대한 접근법의 예입니다.

  • 리스크 지수 결정: 각 사용자 스토리에 다음 각 요소에 대해 0 ~2의 인덱스를 부여합니다.
    • 완전성(스토리의 모든 세부사항을 알고 있습니까?)
      • 완료(0)
      • 미완성 (1)
      • 불명(2)
    • 변동성(변화할 가능성이 있습니까?)
      • 낮음(0)
      • 중형 (1)
      • 하이(2)
    • 복잡성(구축이 얼마나 어렵습니까?)
      • 심플(0)
      • 표준 (1)
      • 콤플렉스 (2)

사용자 스토리의 모든 인덱스가 추가되어 사용자 스토리에 낮은(0-1), 중간(2-4) 또는 높은(5-6) 위험 지수가 할당됩니다.

스티어링 단계

운영 단계에서는 프로그래머와 비즈니스 담당자가 프로세스를 "조종"할 수 있습니다.즉, 그들은 변화를 일으킬 수 있다.개별 사용자 사례 또는 서로 다른 사용자 사례의 상대적 우선순위가 변경될 수 있으며, 예상이 틀릴 수 있습니다.이번 기회에 그에 맞게 계획을 조정할 수 있습니다.

반복 계획

계획된 팀 속도 스토리 포인트를 고려합니다.반복 기간은 1~3주입니다.

탐색 단계

반복 계획의 탐색 단계는 태스크를 생성하고 그 구현 시간을 추정하는 것입니다.

  • 요건을 작업으로 변환: 작업 카드에 배치합니다.
  • 결합/분할 작업:프로그래머가 태스크를 너무 작거나 너무 커서 추정할 수 없는 경우 프로그래머는 태스크를 결합하거나 분할해야 합니다.
  • 견적 작업:작업을 구현하는 데 걸리는 시간을 어림잡습니다.
커밋 단계

반복 계획의 실행 단계에서는 프로그래머에게 다양한 사용자 사례를 참조하는 작업이 할당됩니다.

  • 프로그래머는 다음 작업을 받아들입니다.각 프로그래머는 자신이 책임질 작업을 선택한다.
  • 프로그래머는 작업을 추정합니다.프로그래머는 이제 작업에 대한 책임이 있기 때문에, 그 또는 그녀는 작업의 최종적인 평가를 내려야 합니다.
  • 부하율 설정:부하 계수는 1회 반복 내의 프로그래머 1인당 실제 개발 시간의 이상적인 양을 나타냅니다.예를 들어, 일주일에 40시간, 회의에 5시간을 할애하면 35시간을 넘지 않습니다.
  • 밸런스:팀 내의 모든 프로그래머에게 태스크가 할당되면 태스크의 예상 시간과 부하 계수를 비교합니다.그러면 프로그래머들 사이에 작업이 분산됩니다.프로그래머가 오버 커밋된 경우, 다른 프로그래머가 태스크의 일부를 넘겨받아야 하며 그 반대도 마찬가지입니다.
스티어링 단계

작업의 구현은 반복의 조향 단계에서 수행됩니다.

  • 작업 카드 가져오기:프로그래머는 자신이 커밋한 작업 중 하나에 대한 작업 카드를 받습니다.
  • 파트너 검색:프로그래머는 다른 프로그래머와 함께 이 작업을 수행합니다.이에 대해서는 페어 프로그래밍 연습에서 자세히 설명합니다.
  • 작업 설계:필요에 따라서, 프로그래머는 태스크의 기능을 설계합니다.
  • TDD(Test-Driven Development)를 사용하여 작업을 구현합니다(아래 참조).
  • 기능 테스트 실행:기능 테스트(관련 사용자 사례 및 작업 카드의 요건에 근거)가 실행됩니다.

테스트 주도의 개발

단위 테스트는 코드 조각(예: 클래스, 방법)의 기능을 테스트하는 자동 테스트입니다.XP 에서는 유닛 테스트는 최종 코드가 코드화되기 전에 작성됩니다.이 접근법은 프로그래머가 자신의 코드가 실패할 수 있는 조건을 생각하도록 자극하기 위한 것입니다.XP는 프로그래머가 코드가 실패할 수 있는 더 이상의 조건을 생각해 낼 수 없을 때 특정 코드 조각으로 끝낸다고 말합니다.

테스트 주도의 개발은 다음 단계를 신속하게 수행하여 진행되며, 각 단계는 최대 몇 분, 가급적 훨씬 짧은 시간이 소요됩니다.각 사용자의 스토리에는 보통 1~2일의 작업이 필요하기 때문에 스토리당 매우 많은 사이클이 필요합니다.

  • 쓰기 단위 테스트:프로그래머는 최소한의 테스트를 작성하지만, 이 테스트는 기능성이 실장되어 있지 않기 때문에 실패합니다.
  • 새로운 테스트의 실패를 확인합니다.프로그래머는 테스트가 실제로 실패했음을 확인합니다.시간 낭비처럼 보일 수도 있지만, 이 단계는 프로덕션 코드 상태에 대한 귀하의 믿음이 올바른지 확인하기 때문에 매우 중요합니다.테스트가 실패하지 않을 경우 프로그래머는 테스트 코드에 오류가 있는지, 또는 프로덕션 코드가 새로운 테스트에서 설명된 기능을 지원하는지 확인해야 합니다.
  • 코드 쓰기:프로그래머들은 새로운 테스트를 통과하기 위해 생산 코드를 충분히 작성한다.
  • 테스트 실행:유닛 테스트가 실행되어 새로운 제품 코드가 새로운 테스트에 합격하고 다른 테스트가 실패하지 않았는지 확인합니다.
  • 리팩터:제품 코드와 테스트 코드 모두에서 코드 냄새를 제거합니다.

위의 프로세스의 보다 강도 높은 버전은 밥 아저씨의 TDD [4]3가지 규칙을 참조하십시오.

팀 전체

XP에서는, 「고객」이 요금을 지불하는 것이 아니고, 실제로 시스템을 사용하고 있는 것입니다.XP에서는 고객이 항상 대기하고 질문에 응할 수 있도록 해야 한다고 합니다.예를 들어, 금융 관리 시스템을 개발하는 팀에는 금융 관리자가 포함되어야 합니다.

연속 프로세스

지속적인 통합

개발팀은 항상 최신 버전의 소프트웨어를 작업해야 합니다.팀원마다 다양한 변경과 개선으로 로컬에 저장된 버전이 있을 수 있으므로 몇 시간마다 또는 중대한 장애가 발생했을 때 코드 저장소에 현재 버전을 업로드해야 합니다.지속적인 통합을 통해 프로젝트 사이클의 후반부에서 통합 문제로 인한 지연을 방지할 수 있습니다.

설계 개선

XP의 원칙은 오늘날 필요한 것만 프로그래밍하고 가능한 한 간단하게 구현하는 것을 지지하기 때문에 때로는 시스템이 고착될 수 있습니다.이 증상 중 하나는 이중(또는 여러 개) 유지보수의 필요성입니다.기능을 변경하려면 동일한(또는 유사한) 코드의 여러 복사본을 변경해야 합니다.또 다른 증상은 코드의 일부에 변경이 가해지는 것입니다.XP의 독트린에 따르면 이 경우 시스템은 아키텍처를 변경하여 코드를 리팩터링하여 보다 단순하고 범용적으로 만들도록 지시합니다.

스몰 릴리즈

소프트웨어의 배포는 구체적인 가치를 창출하는 라이브 기능의 빈번한 릴리스를 통해 이루어집니다.소규모 릴리즈를 통해 고객은 프로젝트 진행에 대한 자신감을 얻을 수 있습니다.이를 통해 고객은 실제 경험을 바탕으로 프로젝트에 대한 제안을 할 수 있으므로 팀 전체의 개념을 유지할 수 있습니다.

공통의 이해

부호화 표준

코딩 표준은 프로젝트 전체에 걸쳐 개발 팀 전체가 준수하기로 합의된 일련의 규칙입니다.이 표준은 선택된 프로그래밍 언어 내에서 소스 코드의 일관된 스타일과 형식뿐만 아니라 [5]결함의 확률을 줄이기 위해 피해야 하는 다양한 프로그래밍 구성 및 패턴을 규정한다.코딩 표준은 언어 공급업체가 지정한 표준 표기법일 수 있습니다(예:Sun이 권장하는 Java 프로그래밍 언어에 대한 코드 규칙) 또는 개발 팀이 정의한 사용자 정의입니다.

Extreme Programming backers는 가능한 한 자기 문서화된 코드를 옹호합니다.이것에 의해,[6] 코드 코멘트가 불필요하게 되어, 코드 자체와 동기 할 수 없게 됩니다.

코드 일괄 소유권

집합 코드 소유권('팀 코드 소유권' 및 '공유 코드'라고도 함)은 모든 사람이 모든 코드에 대해 책임을 지므로 모든 사람이 코드의 일부를 변경할 수 있음을 의미합니다.집합적 코드 소유권은 조직 정책일 뿐만 아니라 감정이기도 합니다."개발자 더욱 그들은 시스템 문맥 이해할 수록, 코드로 질문하는데 기여하 팀 코드의 소유권이 코드 품질 높은 인지는 제품과 높은 팀 응집력 지각은 사용자 필요를 만족시킬 것이라고 믿는다."[7]짝은 프로그래밍, 특히 중복되는 한쌍 회전, 이렇게 하는 것은 다른에서 일하면서 기여하게 된다.쌍, 프로그래머는 시스템 컨텍스트를 더 잘 이해하고 코드 베이스의 더 많은 영역에 기여합니다.

오류를 발견한 개발자가 오류를 즉시 수정할 수 있기 때문에 코드 일괄 소유는 개발을 가속화할 수 있으며, 이로 인해 전체적으로 버그를 줄일 수 있습니다.그러나 프로그래머는 코드를 변경할 때 잘 이해하지 못하는 버그가 발생할 수도 있습니다.충분히 정의된 장치 테스트는 이 문제를 완화해야 합니다.예기치 못한 의존관계에 의해 오류가 발생할 경우 장치 테스트를 실행하면 장애가 나타납니다.

코드를 일괄적으로 소유함으로써 멤버 백업의 향상, 지식 및 학습의 확대, 코드의 책임 공유, 코드 품질 향상, 재작업의 삭감으로 이어질 수 있습니다.그러나 이는 구성원 갈등의 증가, 버그의 증가, 개발자의 정신 흐름의 변화 및 논리의 파괴, 개발 시간의 증가 또는 [8]코드의 이해 저하로 이어질 수 있습니다.

심플한 디자인

프로그래머는 소프트웨어 설계에 대해 "심플한 것이 최선"이라는 접근방식을 취해야 합니다.새로운 코드 조각이 작성될 때마다, 저자는 스스로에게 '같은 기능을 도입할 수 있는 더 간단한 방법은 없을까?'라고 자문해야 한다.대답이 '그렇다'인 경우 보다 간단한 코스를 선택해야 합니다.복잡한 코드를 단순화하기 위해 리팩터링을 사용해야 합니다.

시스템 메타포

시스템 은유는 고객, 프로그래머, 관리자 등 모든 사람이 시스템 작동 방식에 대해 말할 수 있는 이야기입니다.이것은 팀원이 이름만으로 특정 클래스/메서드의 기능을 쉽게 추측할 수 있도록 하는 클래스 및 메서드에 대한 명명 개념입니다.예를 들어, 라이브러리 시스템은loan_records(class)위해서borrowers(class)아이템이 기한이 지났을 경우 make_displaces 조작을 실행할 수 있습니다.catalogue(class)각 클래스 또는 조작에 대해서, 그 기능은 팀 전체에 명백합니다.

프로그래머 복지

지속 가능한 속도

프로그래머나 소프트웨어 개발자는 주당 40시간을 초과해서는 안 되며, 1주일의 초과근무가 있는 경우 다음 주에 초과근무를 포함해서는 안 된다는 개념입니다.개발 사이클은 지속적인 통합의 짧은 사이클이며 완전한 개발(릴리스) 사이클이 더 빈번하기 때문에 XP의 프로젝트는 다른 프로젝트에 요구되는 일반적인 크런치 타임(야근 필요)을 따르지 않습니다.

또한, 이 개념에 포함된 것은 사람들이 잘 쉬면 가장 잘 하고 가장 창의적으로 일을 한다는 것이다.

지속 가능한 속도를 실현하기 위한 열쇠가 되는 것은 빈번한 코드 머지이며, 항상 실행 가능 및 테스트 가능한 고품질 코드입니다.지속적인 리팩터링 작업 방식은 팀원들이 신선하고 경각심을 갖도록 합니다.팀 내에서의 강력한 협업 방식은 주말 동안 재충전의 필요성을 야기합니다.

또한 테스트되고 지속적으로 통합되며 자주 배포되는 코드와 환경은 예기치 않은 운영 문제 및 운영 중단의 빈도를 최소화하고 야간 및 주말 업무와 관련된 작업을 최소화합니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Beck, K. Extreme Programming 설명: 변화를 수용하라 두 번째ed. 애디슨-웨슬리, 2000, 54페이지
  2. ^ Melnik, Grigori; Maurer, Frank (2004). "Introducing Agile Methods: Three Years of Experience". Proceedings. 30th Euromicro Conference, 2004. Proceedings of the 30th Euromicro Conference. IEEE. pp. 334–341. CiteSeerX 10.1.1.296.4732. doi:10.1109/EURMIC.2004.1333388. ISBN 0-7695-2199-1.
  3. ^ 레이번, E. (2013년)신속한 변화를 위한 조직:비즈니스 관리에 대한 린 어프로치.런던:IT 거버넌스 퍼블리싱: 146 ~150
  4. ^ Martin, Robert. "Three Rules of TDD".
  5. ^ Kolawa, Adam; Huizinga, Dorota (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. p. 75. ISBN 978-0-470-04212-0.
  6. ^ http://guzdial.cc.gatech.edu/squeakbook/new-lecture-slides/xp.ppt
  7. ^ Sedano, Todd; Ralph, Paul; Péraire, Cécile (2016). "Practice and Perception of Team Code Ownership". Proceedings of the 20th International Conference on Evaluation and Assessment in Software Engineering. ACM. pp. 1–6. doi:10.1145/2915970.2916002. ISBN 9781450336918. S2CID 10016345.
  8. ^ Ribeiro, Danilo & Silva, Fabio & Valenca, Diana & Freitas, Elyda & Franca, César. (2016년)개발자의 관점에서 본 공유 코드 사용의 장점과 단점: 질적 연구.

외부 링크