익스트림 프로그래밍

Extreme programming
극한 프로그래밍에서의 계획 및 피드백 루프
시리즈의 일부
소프트웨어 개발
핵심 활동
패러다임 및 모델
방법론 및 프레임워크
지원 분야
프랙티스
도구들
지식의 표준과 본문
용어집
개요

Extreme Programming(XP; 익스트림프로그래밍)은 소프트웨어 품질과 변화하는 고객 요구사항에 대한 응답성을 개선하기 위한 소프트웨어 개발 방법론입니다.신속한 변화를 위한 소프트웨어 [1][2][3]개발의 한 종류로서, 생산성을 향상시키고 새로운 고객 요구사항을 채택할 수 있는 체크포인트를 도입하기 위해 짧은 개발 주기의 빈번한 릴리스를 지지합니다.

극단적인 프로그래밍의 다른 요소로는 쌍으로 프로그래밍하거나 광범위한 코드 리뷰를 실시하는 것, 모든 코드의 유닛 테스트, 실제로 필요할 때까지 프로그래밍 기능이 아닌 플랫한 관리 구조, 코드의 심플함과 명확성, 시간이 지남에 따라 고객의 요구 사항이 변경되어 문제가 보다 잘 이해될 것으로 예상하는 것 등이 있습니다.고객 및 [2][3][4]프로그래머와의 커뮤니케이션을 중단합니다.이 방법론은 기존의 소프트웨어 엔지니어링 관행의 유익한 요소가 "극한" 수준으로 옮겨진다는 생각에서 그 이름을 따왔습니다.예를 들어 코드 검토는 유익한 관행으로 간주되며, 극단적으로 코드는 지속적으로 검토될 수 있다(즉, 쌍 프로그래밍의 관행).

역사

Kent Beck는 크라이슬러 포괄적 보상 시스템([5]C3) 급여 프로젝트에서 극단적인 프로그래밍을 개발했습니다.벡은 1996년 3월에 C3 프로젝트의 리더가 되었습니다.그는 프로젝트에서 사용된 개발 방법론을 다듬기 시작했고 방법론에 관한 책을 썼다(Extreme Programming Description,[5] 1999년 10월 출판).크라이슬러는 7년 만인 2000년 2월 다임러벤츠가 [6]C3를 인수하면서 C3 프로젝트를 취소했다.Ward Cunningham은 XP의 또 다른 주요 영향자였다.

많은 익스트림 프로그래밍 방법이 오랫동안 존재해 왔습니다. 이 방법론은 "베스트 프랙티스"를 극한 수준으로 끌어올립니다.예를 들어, "각 미세 증가 전에 테스트 우선 개발, 계획 및 쓰기 테스트를 수행하는 연습"은 1960년대 [7]초 NASA의 수성 프로젝트 때부터 사용되었습니다.총 개발 시간을 단축하기 위해 일부 정식 테스트 문서(승인 테스트용 등)가 테스트 준비 소프트웨어와 병행(또는 그 직전에) 개발되었습니다.NASA의 독립적인 테스트 그룹은 프로그래머가 소프트웨어를 작성하고 하드웨어와 통합하기 전에 공식 요구사항 및 논리적 한계에 따라 테스트 절차를 작성할 수 있습니다.XP는 이 개념을 극단적으로 발전시켜 대규모 기능 테스트뿐만 아니라 소프트웨어 코딩의 작은 부분에서도 동작을 검증하는 자동 테스트(소프트웨어 모듈 내에서도 가능)를 작성합니다.

오리진스

1990년대 소프트웨어 개발에는 두 가지 주요 영향이 있었습니다.

  • 내부적으로 일부 개발자들이 선호하는 프로그래밍 패러다임으로서 객체 지향 프로그래밍이 절차 프로그래밍을 대체했습니다.
  • 대외적으로는 인터넷의 발달과 닷컴 붐이 시장 투입과 기업의 성장을 경쟁력 있는 비즈니스 요인으로 부각시켰다.

요건이 급속히 변화함에 따라 제품 수명 주기의 단축이 요구되었으며, 기존 소프트웨어 개발 방식과 충돌하는 경우가 종종 있었습니다.

Chrysler Comprehensive Compension System(C3)은 Chrysler의 급여 시스템을 연구 대상으로 하고 Smalltalk를 언어, GemStone을 데이터 액세스 계층으로 하여 객체 기술을 사용하는 최선의 방법을 결정하기 위해 시작되었습니다.크라이슬러는 저명한 Smalltalk 전문가인 Kent [5]Beck를 시스템 성능 튜닝에 참여시켰지만 개발 과정의 몇 가지 문제를 지적하면서 그의 역할이 확대되었습니다.그는 이번 기회에 단골 협력자인 Ward Cunningham과의 작업을 바탕으로 개발 관행의 몇 가지 변화를 제안하고 구현했습니다.Beck는 [8]이 방법의 초기 개념에 대해 설명합니다.

처음 팀을 이끌게 되었을 때, 저는 그들에게 테스트나 리뷰와 같이 제가 생각하기에 합리적이라고 생각하는 것들을 조금 해달라고 부탁했습니다.두 번째에는 더 많은 것이 걸려 있었다."어뢰는 적어도 좋은 기사가 될 거야"라고 생각했습니다.그리고 팀원들에게 제가 필요하다고 생각하는 것은 10개까지 올리고 다른 것은 빼달라고 부탁했습니다.

벡은 Ron Jeffries를 프로젝트에 초대하여 이러한 방법을 개발하고 개선하도록 지원했습니다.그 후 제프리는 코치로 활동하며 연습을 C3팀에 습관처럼 심어주었다.

XP의 이면에 있는 원칙과 관행에 대한 정보는 오리지널 Wiki인 Cunningham의 WikiWikiWeb에 대한 논의를 통해 전 세계에 전파되었습니다.다양한 기여자들이 아이디어를 논의하고 확장했으며, 그 결과 몇 가지 파생 방법론이 도출되었습니다(신속한 소프트웨어 개발 참조).또한 XP의 개념은 1999년경 XP 웹사이트(https://www.extremeprogramming.org)에서 하이퍼텍스트 시스템 맵을 사용하여 몇 년 동안 설명되어[by whom?] 왔습니다.

벡은 자신의 Extreme Programming Description(1999년)을 시작으로 XP에 관한 일련의 책을 편집했습니다. ISBN0-201-61641-6)는 그의 아이디어를 훨씬 더 많은 청중에게 전파했다.이 시리즈의 저자들은 XP와 그 실무에 참여하면서 다양한 측면을 경험했습니다.그 시리즈에는 그 관행에 비판적인 책이 포함되어 있었다.

현재 상태

XP는 1990년대 후반과 2000년대 초반에 소프트웨어 커뮤니티에서 큰 관심을 끌었으며, 그 기원과 근본적으로 다른 많은 환경에서 채택되고 있습니다.

원래 관행에서 요구되는 높은 규율은 종종 무시되었고, 너무 경직되어 있다고 생각되는 관행들 중 일부는 개별 현장에서 폐지되거나 축소되거나 심지어 미완성 상태로 남겨지게 되었습니다.예를 들어, 특정 프로젝트에 대한 일말 통합 테스트 관행을 주말 스케줄로 변경하거나 단순히 상호 합의된 날짜에 테스트하는 것으로 줄일 수 있습니다.이렇게 좀 더 여유로운 스케줄은 사람들이 단지 종말 테스트를 통과하기 위해 인공 스텁을 만드는 것을 서두르는 것을 피할 수 있을 것이다.덜 엄격한 스케줄을 사용하면 며칠 동안 복잡한 기능을 개발할 수 있습니다.

한편, 다른 민첩한 개발 관행은 그대로 유지되지 않고 있으며, 2019년 현재 XP는 계속해서 진화하고 있으며, 현장 경험에서 얻은 더 많은 교훈을 다른 관행을 활용하기 위해 활용하고 있습니다.초판으로부터 5년 후의 「Extreme Programming Description」 제2판(2004년 11월)에서는, Beck는 보다 많은 가치와 프랙티스를 추가해, 프라이머리 프랙티스와 결과 프랙티스를 구별했습니다.

개념.

목표들

Extreme Programming Description은 극한 프로그래밍을 고품질의 소프트웨어를 생산하기 위해 사람들을 조직하는 소프트웨어 개발 분야로 설명합니다.

XP는 긴 개발 사이클이 아닌 여러 번의 짧은 개발 사이클을 통해 요구사항 변경 비용을 절감하려고 합니다.이 원칙에서 변경은 소프트웨어 개발 프로젝트의 자연스럽고 피할 수 없는 바람직한 측면이며, 안정적인 요건을 정의하려고 하는 것이 아니라 이를 위해 계획되어야 한다.

또한 Extreme Programming은 민첩한 방법론 위에 많은 기본 가치, 원칙 및 관행을 도입합니다.

활동.

XP는 소프트웨어 개발 프로세스에서 수행되는 4가지 기본 액티비티(코딩, 테스트, 듣기 및 설계)에 대해 설명합니다.각 활동은 아래에 설명되어 있습니다.

코딩

XP의 지지자들은 시스템 개발 프로세스에서 진정으로 중요한 유일한 산물은 코드, 즉 컴퓨터가 해석할 수 있는 소프트웨어 명령어라고 주장한다.코드가 없으면 작동하는 제품이 없습니다.

코딩은 가장 적합한 해결책을 찾기 위해 사용할 수 있습니다.코딩은 프로그래밍 문제에 대한 생각을 전달하는 데에도 도움이 됩니다.복잡한 프로그래밍 문제를 다루거나 동료 프로그래머에게 해결책을 설명하는 것이 어렵다고 생각하는 프로그래머는 간단한 방법으로 코드를 작성하고 그 코드를 사용하여 그들이 의미하는 바를 나타낼 수 있습니다.이 입장의 지지자들에 따르면, 코드는 항상 명확하고 간결하며 한 가지 방법 이상으로는 해석될 수 없다.다른 프로그래머들도 자신의 생각을 코드화함으로써 이 코드에 대한 피드백을 줄 수 있다.

테스트

주요 기사:테스트 주도의 개발

테스트는 익스트림 [9]프로그래밍의 핵심입니다.익스트림 프로그래밍의 접근방식은 작은 테스트를 통해 몇 가지 결함을 제거할 수 있다면 많은 테스트를 통해 더 많은 결함을 제거할 수 있다는 것입니다.

  • 유닛 테스트는 특정 기능이 의도한 대로 동작하는지 여부를 판별합니다.프로그래머는 가능한 한 많은 자동 테스트를 작성하여 코드를 "해독"할 수 있습니다.모든 테스트가 정상적으로 실행되면 코딩은 완료됩니다.기술된 모든 코드는 다음 기능으로 넘어가기 전에 테스트됩니다.
  • 인수 테스트는 프로그래머가 이해하고 있는 요건이 고객의 실제 요건을 충족하는지 확인합니다.

비호환 인터페이스의 조기 검출을 위해 처음에는 시스템 전체의 통합 테스트가 일일 업무 종료 활동으로 권장되었으며, 개별 섹션이 일관성 있는 기능에서 광범위하게 분리되기 전에 다시 연결되었습니다.다만, 시스템 전체의 통합 테스트는,[citation needed] 시스템 전체의 인터페이스의 안정성에 따라, 매주 또는 그 빈도로 단축되고 있습니다.

들으면서

프로그래머는 고객이 무엇을 해야 하는지, 어떤 "비즈니스 논리"가 필요한지 귀담아 들어야 합니다.이러한 니즈를 충분히 이해하고 문제를 해결할 수 있는 기술적 측면 또는 해결할 수 없는 측면에 대한 피드백을 고객에게 제공해야 합니다.또, 고객과 프로그래머의 커뮤니케이션은, 계획 게임내에서 한층 더 다루어진다.

설계

단순성의 관점에서 보면, 물론 시스템 개발은 코딩, 테스트 및 청취 이상의 것이 필요하지 않다고 말할 수 있습니다.이러한 활동이 잘 수행되면 그 결과는 항상 작동하는 시스템이 될 것입니다.실제로는, 이것은 효과가 없습니다.설계하지 않아도 먼 길을 갈 수 있지만, 정해진 시간에 꼼짝 못하게 될 것이다.시스템이 너무 복잡해지고 시스템 내 의존관계가 명확해지지 않게 됩니다.시스템에 로직을 정리하는 설계 구조를 만들면 이를 피할 수 있다.설계가 좋으면 시스템 내의 많은 의존을 피할 수 있습니다.즉, 시스템의 일부를 변경해도 시스템의 [citation needed]다른 부분에는 영향을 주지 않습니다.

가치

Extreme Programming은 1999년에 커뮤니케이션, 단순성, 피드백, 용기라는 네 가지 가치를 인식했습니다.Extreme Programming Description 제2판에는 존중이라는 새로운 가치가 추가되었습니다.이 5가지 값은 다음과 같습니다.

의사소통

소프트웨어 시스템을 구축하려면 시스템 개발자에게 시스템 요구 사항을 전달해야 합니다.정식 소프트웨어 개발 방법론에서 이 작업은 문서를 통해 수행됩니다.익스트림 프로그래밍 기법은 개발팀 구성원 간에 제도적 지식을 신속하게 구축하고 보급하는 방법으로 볼 수 있습니다.목표는 모든 개발자에게 시스템 사용자가 보유한 뷰와 일치하는 시스템 공유 뷰를 제공하는 것입니다.이를 위해 익스트림 프로그래밍은 단순한 디자인, 일반적인 은유, 사용자와 프로그래머의 협업, 잦은 구두 커뮤니케이션 및 피드백을 선호합니다.

심플함

익스트림 프로그래밍은 가장 간단한 솔루션부터 시작하도록 장려합니다.나중에 추가 기능을 추가할 수 있습니다.이 접근방식과 기존 시스템 개발 방법의 차이는 내일, 다음 주 또는 다음 달이 아닌 현재의 요구에 맞게 설계하고 코딩하는 데 초점을 맞춘다는 것입니다.이것은 「You will not need it」(YAGNI) [10]어프로치로 요약되는 경우가 있습니다.XP를 지지하는 사람들은 이것이 때때로 시스템을 바꾸기 위해 내일 더 많은 노력을 필요로 할 수 있다는 단점을 인정합니다. 그들의 주장은 이것이 관련되기 전에 변경될 수 있는 미래의 가능한 요건에 투자하지 않는다는 장점으로 보완된 것일 뿐이라는 것입니다.불확실한 미래 요건에 대한 코딩과 설계는 아마도 중요한 기능을 지연시키면서 필요하지 않을 수 있는 것에 자원을 소비하는 위험을 내포하고 있다.「커뮤니케이션」의 가치와 관련지어, 설계와 코딩의 단순성은, 커뮤니케이션의 품질을 향상시킵니다.심플한 코드와 심플한 디자인은 팀의 대부분의 프로그래머가 쉽게 이해할 수 있었습니다.

피드백

극단적인 프로그래밍에서 피드백은 시스템 개발의 다양한 차원에 관련됩니다.

  • 시스템으로부터의 피드백: 유닛 [5]테스트를 작성하거나 정기적인 통합 테스트를 실행함으로써 프로그래머는 변경 후 시스템 상태로부터 직접 피드백을 받습니다.
  • 고객으로부터의 피드백:기능 테스트(승인 테스트)는 고객과 테스트 담당자가 작성합니다.고객은 시스템의 현재 상태에 대한 구체적인 피드백을 얻을 수 있습니다.이 리뷰는 2, 3주에 한 번 실시되므로 고객은 쉽게 개발을 진행할 수 있습니다.
  • 팀의 피드백:고객이 계획 게임에서 새로운 요건을 제시하면 팀은 구현에 소요되는 시간을 직접 견적합니다.

피드백은 커뮤니케이션 및 단순성과 밀접하게 관련되어 있습니다.시스템의 결함은 특정 코드 조각이 깨지는 것을 증명하는 단위 테스트를 작성함으로써 쉽게 전달됩니다.시스템으로부터의 직접 피드백은 프로그래머에게 이 부품을 재코딩하도록 지시합니다.고객은, 유저 [5]스토리라고 불리는 기능 요건에 따라서, 시스템을 정기적으로 테스트할 수 있습니다.켄트 벡의 말을 인용하자면, "낙관주의는 프로그래밍의 직업적 위험이다.피드백이 [11]치료법입니다.

용기.

몇 가지 실천이 용기를 상징한다.하나는 내일이 아니라 오늘을 위해 항상 설계하고 코드화하라는 계명이다.이는 설계에 얽매이는 것을 피하고 다른 것을 구현하기 위해 많은 노력을 필요로 하는 것을 피하기 위한 노력입니다.개발자는 용기를 통해 필요할 [5]때 코드를 리팩터링하는 데 편안함을 느낄 수 있습니다.즉, 기존 시스템을 검토하고 향후 변경 사항을 보다 쉽게 구현할 수 있도록 수정해야 합니다.용기의 또 다른 예는 코드를 버리는 타이밍을 아는 것입니다.소스코드를 작성하기 위해 아무리 많은 노력을 해도 쓸모없는 소스코드를 제거하는 용기입니다.또한, 용기는 끈기를 의미합니다. 프로그래머는 하루 종일 복잡한 문제에 갇혀 있다가 다음 날 문제를 빠르게 해결할 수 있습니다. 단, 끈질기게 풀어야 합니다.

존중하다

존중 가치에는 자존심뿐만 아니라 타인에 대한 존경도 포함됩니다.프로그래머는 컴파일을 중단하거나 기존 유닛 테스트에 실패하거나 동료의 작업을 지연시키는 변경을 실행해서는 안 됩니다.회원들은 항상 높은 품질을 위해 노력하고 리팩터링을 통해 수중에 있는 솔루션에 대한 최상의 디자인을 추구함으로써 자신의 작품을 존중합니다.

앞서 말한 네 가지 가치관을 채택하는 것은 팀 내 다른 사람들로부터 얻은 존경으로 이어집니다.팀의 그 누구도 인정받지 못하거나 무시당했다고 느껴서는 안 된다.이를 통해 높은 수준의 동기 부여가 보장되고 팀 및 프로젝트 목표에 대한 충성도가 높아집니다.이 값은 다른 값에 따라 달라지며 팀워크를 지향합니다.

규칙.

XP에 대한 규칙의 첫 번째 버전은 1999년 Don[12] Wells에 의해 XP 웹사이트에 게시되었습니다.29개의 규칙은 계획, 관리, 설계, 코딩 및 테스트의 범주에 부여됩니다.XP가 이러한 활동을 지원하지 않는다는 주장에 대응하기 위해 계획, 관리 및 설계가 명시적으로 요구됩니다.

다른 버전의 XP 규칙은 XP/Agile Universe 2003에서 Ken Auer에[13] 의해 제안되었습니다.그는 XP가 규칙이 아니라 규칙에 의해 정의된다고 생각했습니다(더 많은 변화와 모호성이 수반됩니다).소프트웨어 개발을 효과적으로 실시할 수 있는 환경을 규정하는 「계약의 룰」과 「계약의 룰」의 2개의 카테고리를 정의했습니다.또, 계약 룰의 프레임워크내에서 시시각각의 액티비티와 룰을 정의하는 「플레이의 룰」도 정의했습니다.

다음은 몇 가지 규칙(불완전)입니다.

코딩

  • 고객님은 언제든지 이용 가능합니다.
  • 유닛 테스트를 먼저 코드화합니다.
  • 한 번에 하나의 쌍만 코드를 통합
  • 최적화를 마지막까지 유지하다
  • 잔업 없음

테스트

  • 모든 코드에는 단위 테스트가 있어야 합니다.
  • 모든 코드가 해제되기 전에 모든 장치 테스트를 통과해야 합니다.
  • 버그가 발견되면 버그에 대처하기 전에 테스트가 생성됩니다(버그는 로직상의 오류가 아니라 작성되지 않은 테스트입니다).
  • 승인 테스트가 자주 실행되고 결과가 공개됩니다.

원칙

XP의 기초를 이루는 원칙은 방금 설명한 가치를 기반으로 하며 시스템 개발 프로젝트에서 의사결정을 촉진하기 위한 것입니다.원칙은 값보다 구체적이고 실제 상황에서 지침으로 더 쉽게 변환되도록 의도되었다.

피드백

익스트림 프로그래밍은 피드백을 자주 그리고 신속하게 수행하는 것이 가장 유용하다고 봅니다.또한 행동과 피드백 사이의 최소 지연이 학습과 변경에 매우 중요하다고 강조합니다.기존 시스템 개발 방법과는 달리 고객과의 접촉은 더 자주 반복됩니다.고객은 개발 중인 시스템에 대한 명확한 통찰력을 가지고 있으며 필요에 따라 피드백을 제공하고 개발을 주도할 수 있습니다.고객으로부터의 피드백이 자주 있기 때문에, 개발자가 잘못 설계한 것을 금방 알아차리고 수정할 수 있습니다.개발자는 이 결정을 실장하는 데 많은 시간을 소비합니다.

단위 테스트는 신속한 피드백 원리에 기여합니다.코드를 작성할 때 장치 테스트를 실행하면 시스템이 변경에 어떻게 반응하는지에 대한 직접적인 피드백이 제공됩니다.여기에는 개발자의 코드를 테스트하는 장치 테스트뿐만 아니라 하나의 명령으로 시작할 수 있는 자동화된 프로세스를 사용하여 모든 소프트웨어에 대한 모든 장치 테스트를 실행하는 것도 포함됩니다.이와 같이 개발자의 변경으로 인해 개발자가 거의 알지 못하거나 전혀 모르는 시스템의 다른 부분에서 장애가 발생한 경우, 자동화된 전체 유닛 테스트 스위트는 장애를 즉시 드러내고 시스템의 다른 부분과의 변경에 대한 호환성이 없음을 개발자에게 알립니다.또한 이러한 변경은 삭제 또는 수정의 필요성에 대해서도 경고합니다.변화합니다.종래의 개발 프랙티스에서는, 자동적이고 포괄적인 유닛 테스트 스위트가 존재하지 않는 경우, 이러한 코드 변경은 개발자에 의해서 무해하다고 간주되어, 통합 테스트 중 또는 더 나쁜 것은 실가동 중에만 나타나며, 모든 변경 중에서 문제가 발생한 코드 변경을 특정할 수 있었습니다.통합 테스트 전 몇 주 또는 몇 달 동안 모든 개발자에 의해 개발되는 것은 엄청난 작업이었습니다.

심플함을 전제로 하다

이것은 모든 문제를 마치 해결책이 "극단적으로 단순"한 것처럼 취급하는 것에 관한 것입니다.기존의 시스템 개발 방법에서는 미래를 위해 계획을 세우고 재사용 가능성을 코드화하는 것을 말합니다.극단적인 프로그래밍은 이러한 아이디어를 거부합니다.

극단적인 프로그래밍을 옹호하는 사람들은 한꺼번에 큰 변화를 일으키는 것은 효과가 없다고 말한다.극단적인 프로그래밍에서는 증분 변경이 적용됩니다.예를 들어 시스템에 3주마다 소규모 릴리스가 있을 수 있습니다.많은 작은 단계를 거치면 고객은 개발 프로세스와 개발 중인 시스템을 더 잘 제어할 수 있습니다.

변화를 받아들이다

변화를 수용하는 원칙은 변화에 맞서는 것이 아니라 변화를 수용하는 것입니다.예를 들어, 반복적인 미팅 중 하나에서 고객의 요건이 크게 변경된 것으로 보이는 경우 프로그래머는 이를 수용하고 다음 반복을 위한 새로운 요건을 계획해야 합니다.

프랙티스

상세 정보:극단적인 프로그래밍 관행

익스트림 프로그래밍은 4가지 영역으로 분류된 12개의 프랙티스로 구성되어 있습니다.

세밀한 피드백

연속 프로세스

공통의 이해

프로그래머 복지

논란의 여지가 있는 측면

XP의 관행에 대해서는 많은 [5]논의가 이루어지고 있습니다.극단적인 프로그래밍을 지지하는 사람들은 온사이트 고객이[5] 비공식적으로 변경을 요청하도록 함으로써 프로세스가 유연해지고 정식 오버헤드의 비용이 절감된다고 주장합니다.XP에 대한 비판론자들은 이로 인해 비용이 많이 드는 재작업과 프로젝트 범위가 이전에 합의되거나 자금을 [citation needed]지원받았던 범위를 넘어설 수 있다고 주장합니다.

변경 관리 위원회는 프로젝트 목표와 여러 사용자 간의 제약에 잠재적 충돌이 있음을 나타냅니다.XP의 신속한 방법은 프로그래머가 통일된 클라이언트의 관점을 가정할 수 있는지 여부에 따라 다소 좌우되므로 프로그래머는 타협적인 목적과 [14]제약을 문서화하는 대신 코딩에 집중할 수 있습니다.이는 여러 프로그래밍 조직, 특히 프로젝트 [citation needed]공유를 위해 경쟁하는 조직이 관련된 경우에도 적용됩니다.

극단적 프로그래밍의 다른 잠재적인 논란거리는 다음과 같습니다.

  • 요건은 사양 문서가 아닌 자동화된 승인 테스트로 표현됩니다.
  • 요건은 사전에 파악하지 않고 단계적으로 정의됩니다.
  • 소프트웨어 개발자는 보통 2인 1조로 작업해야 합니다.
  • 전면에는 큰 디자인은 없습니다.설계 작업의 대부분은 "가장 간단한 작업"에서 시작하여 테스트 실패 시에만 복잡성이 가중되는 등 신속하게 증분적으로 이루어집니다.비평가들은 이를 "시스템 외관을 변형"하는 것에 비유하며, 요건이 변경되었을 때 재설계하는 것보다 재설계하는 데 더 많은 노력을 기울일 것이라고 우려합니다.
  • 고객 담당자가 프로젝트에 첨부되어 있습니다.이 역할은 프로젝트의 단일 실패 지점이 될 수 있으며, 일부 사람들은 이것이 스트레스의 원인이라는 것을 알게 되었습니다.또한 기술 소프트웨어 기능 및 아키텍처의 사용을 지시하려는 비기술 담당자에 의한 마이크로 관리의 위험도 있습니다.

비평가들은 불안정한 요건의 문제, 사용자 충돌에 대한 문서화된 타협, 전체적인 설계 사양 또는 문서의 부족 등 몇 가지 잠재적인 [5]결점을 지적했습니다.

확장성

Thinkworks는 최대 60명 [citation needed]규모의 분산 XP 프로젝트에서 상당한 성공을 거두고 있습니다.

2004년에는 XP의 진화로 IXP(Industrial Extreme Programming)[15]가 도입되었습니다.이것은 대규모로 분산된 팀에서 일할 수 있는 능력을 가져오는 것을 목적으로 하고 있습니다.현재는 23개의 프랙티스와 유연한 가치를 가지고 있습니다.

분리성과 응답성

2003년에 Matt Stephens와 Doug Rosenberg는 Extreme Programming Refactored를 발표했습니다. XP에 대항하는 사례 XP 프로세스의 가치에 의문을 제기하고 [6]개선 방법을 제안했습니다.이것은 기사, 인터넷 뉴스 그룹, 그리고 웹사이트 채팅 영역에서 긴 논쟁을 촉발시켰다.이 책의 핵심 논거는 XP의 프랙티스는 상호 의존적이지만 모든 프랙티스를 도입하려는 실제 조직은 거의 없기 때문에 프로세스 전체가 실패한다는 것입니다.이 책은 다른 비판도 하고 XP의 집단 소유 모델을 사회주의에 부정적으로 묘사하고 있다.

XP의 일부 측면은 Extreme Programming Refactored가 발행된 이후 변경되었습니다.특히 XP는 필요한 목표가 충족되는 한 프랙티스의 수정을 수용하고 있습니다.XP는 또한 프로세스에 대해 점점 더 일반적인 용어를 사용하고 있습니다.어떤 사람들은 이러한 변화가 이전의 비판을 무효화한다고 주장하지만, 다른 사람들은 이것이 단순히 과정을 약화시키고 있다고 주장한다.

다른 저자들은 통일된 방법론을 형성하기 위해 XP와 오래된 방법론을 조화시키려고 시도했다.이러한 XP 중 일부는 대체 방법을 모색했습니다. 예: 프로젝트 라이프 사이클:워터폴, 신속한 애플리케이션 개발(RAD) 등 모든 것을 지원합니다.JP모건체이스는 XP를 능력 성숙도 모델 통합(CMMI)과 식스 시그마라는 컴퓨터 프로그래밍 방식과 결합하려고 했습니다.그들은 세 개의 시스템이 서로를 잘 보강하고, 더 나은 발전을 이끌며,[16] 상호 모순되지 않는다는 것을 발견했다.

비판

극단적인 프로그래밍의 초기 유행과 페어 프로그래밍과 연속 설계와 같은 논쟁적인 교의는 McBreen과[17] Boehm, [18]Turner, Matt Stephens와 Doug Rosenberg에서 [19]나온 것과 같은 특별한 비판을 이끌어냈다.그러나 Agile 실무자들은 이러한 비판의 많은 부분을 Agile [20]개발에 대한 오해로 보고 있습니다.

특히 Matt Stephens와 Doug Rosenberg의 Extreme Programming [6]Refactored는 익스트림 프로그래밍에 대해 리뷰 및 비판하고 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ "Human Centreed Technology Workshop 2006", 2006, PDF, Human Centreed Technology Workshop 2006"
  2. ^ a b UPenn-Lectures-design-patterns "디자인 패턴과 리팩터링", 펜실베니아 대학교, 2003.
  3. ^ a b USFCA-edu-601-강의 익스트림프로그래밍
  4. ^ "Manifesto for Agile Software Development". Agilemanifesto.org. 2001. Retrieved March 26, 2019.
  5. ^ a b c d e f g h i j k l m Computer world - appdev - 92 "익스트림 프로그래밍", Computer world (온라인), 2001년 12월
  6. ^ a b c Rosenberg, Doug; Stephens, Matt (2003). Extreme Programming Refactored: The Case Against XP. Apress. ISBN 978-1-59059-096-6.
  7. ^ Larman 2003. 오류:: (도움말
  8. ^ Interview with Kent Beck and Martin Fowler. informit.com. March 23, 2001.
  9. ^ Lisa Crispin; Tip House (2003). Testing Extreme Programming. ISBN 9780321113559.
  10. ^ Clair Tristram의 "Everyone's a Programmer"테크놀로지 리뷰, 2003년 11월, 페이지 39.
  11. ^ Beck, K. (1999). Extreme Programming Explained: Embrace Change. Addison-Wesley. ISBN 978-0-321-27865-4.
  12. ^ "Extreme Programming Rules". extremeprogramming.org.
  13. ^ Ken Auer는 2008년 9월 20일 Wayback Machine에서 아카이브 완료
  14. ^ John Carroll; David Morris (July 29, 2015). Agile Project Management in easy steps, 2nd edition. In Easy Steps. p. 162. ISBN 978-1-84078-703-0.
  15. ^ Cutter Consortium. "Industrial XP: Making XP Work in Large Organizations - Cutter Consortium". cutter.com.
  16. ^ Extreme Programming(XP; 익스트림프로그래밍) 6 시그마 CMMI
  17. ^ McBreen, P. (2003). Questioning Extreme Programming. Boston, MA: Addison-Wesley. ISBN 978-0-201-84457-3.
  18. ^ Boehm, B.; R. Turner (2004). Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison-Wesley. ISBN 978-0-321-18612-6.
  19. ^ Stephens, Matt; Doug Rosenberg (2004). The irony of extreme programming. MA: Dr Dobbs journal.
  20. ^ sdmagazine 2006년 3월 16일 Wayback Machine에서 아카이브 완료

추가 정보

  • 켄 아우어와 로이 밀러.Extreme 프로그래밍 적용: 플레이 투 윈, 애디슨-웨슬리
  • Ken Auer; Ron Jeffries; Jeff Canna; Glen B. Alleman; Lisa Crispin; Janet Gregory (2002). "Are Testers eXtinct? How Can Testers Contribute to XP Teams?". Extreme Programming and Agile Methods — XP/Agile Universe 2002. Lecture Notes in Computer Science. Vol. 2418. Springer-Verlag. p. 287. doi:10.1007/3-540-45672-4_50.
  • Kent Beck: Extreme Programming 설명: 변화를 받아들여라, Addison-Wesley.1999년 초판제2판, 신시아 안드레스, 2004년
  • 켄트 벡과 마틴 파울러: 계획 익스트림 프로그래밍, 애디슨-웨슬리.
  • Alistair Cockburn: 애디슨-웨슬리 애자일 소프트웨어 개발
  • 마틴 파울러:리팩터링: 기존 코드 설계 개선켄트 벡, 존 브랜트, 윌리엄 옵다이크, 돈 로버츠(1999년)와 함께.애디슨 웨슬리.
  • Harvey Herela (2005).도입 사례: 크라이슬러 종합 보상 시스템입니다.U.C. 어바인 갤런 랩
  • 짐 하이스미스.애디슨-웨슬리, 신속한 변화를 위한 소프트웨어 개발 생태계
  • Ron Jeffries, Ann Anderson 및 Chet Hendrickson(2000), Extreme Programming Installed, Addison-Wesley.
  • Craig Larman & V. Basili (2003)."반복 및 증분 발전: 짧은 역사", 컴퓨터 (IEEE 컴퓨터 학회) 36 (6) : 47 ~ 56 。
  • Matt Stephens와 Doug Rosenberg(2003).Extreme 프로그래밍 리팩터링: XP에 대항하는 케이스, APress.
  • 월터, JB (2008년)"나노컴퓨터와 군집 지능"입력: ISE, 225~256.

외부 링크

Wikimedia Commons에는 Extreme 프로그래밍과 관련된 미디어가 있습니다.
위키 인용문에는 Extreme 프로그래밍과 관련된 인용문이 있습니다.