익스트림 프로그래밍(XP)은 애자일 개발 방법론 중 하나입니다. 소프트웨어. 방법론의 저자는 Kent Beck, Ward Cunningham, Martin Fowler 등입니다.
기획 게임
우리의 세계는 상황의 불변성에 의존하기에는 너무 변하고 예측할 수 없습니다. 소프트웨어 개발에서도 같은 일이 일어납니다. 개발 초기에 그 최종 형태가 미리 자세히 알려진 희귀한 시스템이라고 할 수 있습니다. 일반적으로 고객의 식욕은 먹는 것과 함께 발생합니다. 그는 끊임없이 무언가를 바꾸고, 개선하고, 시스템에서 무언가를 완전히 버리고 싶어합니다. 이것은 모든 사람이 두려워하는 요구 사항의 가변성입니다. 다행히도 인간은 예측할 수 있는 능력이 주어졌습니다. 가능한 옵션따라서 상황을 통제할 수 있습니다.익스트림 프로그래밍에서 계획은 개발의 필수적인 부분이며 계획이 변경될 수 있다는 사실은 처음부터 고려됩니다. 상황을 예측하고 고통 없이 변화를 수용할 수 있는 기술인 그 지점이 바로 계획의 게임입니다. 이러한 게임을 진행하는 동안 알려진 시스템 요구 사항을 신속하게 수집, 평가 및 우선 순위에 따라 개발 계획을 세울 수 있습니다.
다른 게임과 마찬가지로 계획에는 참가자와 목적이 있습니다. 핵심 인물은 물론 고객입니다. 특정 기능의 필요성에 대해 알려주는 사람입니다. 프로그래머는 또한 각 기능에 대한 대략적인 평가를 제공합니다. 계획 게임의 아름다움은 목적의 통일성과 개발자와 고객 간의 연대에 있습니다. 승리하면 모두가 이기고, 패배하면 모두가 집니다. 그러나 동시에 각 참가자는 자신의 방식으로 승리합니다. 고객은 예산에 따라 가장 중요한 작업을 선택하고 프로그래머는 구현 능력에 따라 작업을 평가합니다.
익스트림 프로그래밍은 개발자가 자신의 작업에 얼마나 오래 대처할 수 있는지, 그리고 그들 중 누가 한 문제를 더 기꺼이 해결하고 누가 그렇지 않을지 결정할 수 있다고 가정합니다.
이상적인 상황에서 고객과 프로그래머가 참여하는 계획 게임은 다음 개발 반복이 시작되기 전에 3-6주마다 플레이해야 합니다. 이렇게 하면 이전 반복의 성공 및 실패에 따라 조정하기가 상당히 쉽습니다.
출시 계획
릴리스 계획은 릴리스 날짜와 각 릴리스에서 구현될 사용자 언어를 정의합니다. 이를 기반으로 다음 반복에 대한 문구를 선택할 수 있습니다. 반복 중에 승인 테스트가 생성되고 해당 반복 및 모든 후속 반복 내에서 실행되어 프로그램이 올바르게 작동하는지 확인합니다. 계획은 반복 중 하나의 결과에 따라 상당한 지연 또는 진전이 있는 경우 수정될 수 있습니다.반복. 반복은 개발 프로세스를 동적으로 만듭니다. 프로그래밍 작업을 미리 계획할 필요가 없습니다. 대신 각 반복의 시작 부분에 계획 회의를 갖는 것이 좋습니다. 계획하지 않은 것을 구현하려고 하는 것은 가치가 없습니다. 릴리스 계획에 따라 이러한 아이디어가 차례에 도달하면 이러한 아이디어를 구현할 시간이 있습니다.
미리 기능을 추가하지 않고 직접 계획을 사용하는 데 익숙해지면 변화하는 고객 요구 사항에 쉽게 적응할 수 있습니다.
반복 계획
반복 계획은 프로그램 목표를 달성하기 위한 단계 계획을 개발하기 위해 각 반복이 시작될 때 회의로 시작됩니다. 각 반복은 1주에서 3주 사이에 지속되어야 합니다. 반복 내의 명령문은 고객에게 중요한 순서대로 정렬됩니다. 또한 승인 테스트에 실패하여 개선해야 할 작업이 추가됩니다. 명령문 및 테스트 결과는 프로그램 작업으로 변환됩니다. 작업은 상세한 반복 계획을 형성하는 카드에 기록됩니다. 각 작업을 해결하는 데 1~3일이 걸립니다. 하루 미만이 필요한 작업은 함께 그룹화할 수 있으며 큰 작업은 여러 개의 작은 작업으로 나눌 수 있습니다. 개발자는 작업과 마감일을 평가하여 완료합니다. 개발자가 작업을 실행할 정확한 시간을 설정하는 것은 매우 중요합니다. 3~5번의 반복마다 일부 언어를 재평가하고 릴리스 계획을 수정해야 할 수도 있습니다. 이는 충분히 수용 가능한 일입니다. 가장 중요한 작업 영역을 먼저 구현하면 항상 고객을 위해 최대한의 시간을 할애할 수 있습니다. 일련의 반복을 기반으로 하는 개발 스타일은 개발 프로세스를 개선합니다.상임 회의
매일 아침 문제와 해결책을 논의하고 팀의 집중력을 높이기 위한 회의가 있습니다. 회의는 모든 팀원에게 흥미롭지 않은 긴 토론을 피하기 위해 서서 진행됩니다.일반적인 회의에서 대부분의 참가자는 아무 것도 기여하지 않고 다른 사람의 말을 듣기 위해 참석합니다. 적은 양의 커뮤니케이션을 받기 위해 많은 사람들의 시간이 낭비됩니다. 따라서 모든 사람이 회의에 참여하면 프로젝트에서 자원을 빼앗아 계획에 혼란을 야기합니다.
이러한 소통을 위해서는 상설 회의가 필요합니다. 어쨌든 대부분의 개발자가 참석해야 하는 긴 회의보다 짧은 필수 회의를 한 번 갖는 것이 훨씬 낫습니다.
매일 상설 회의가 있는 경우 다른 모든 회의에는 필요한 사람과 무언가를 가져올 사람들만 참석해야 합니다. 또한 일부 회의를 피하는 것도 가능합니다. 제한된 참가자로 인해 대부분의 회의는 아이디어 교환이 훨씬 더 격렬한 모니터 앞에서 자발적으로 열릴 수 있습니다.
매일 아침 회의는 또 다른 시간 낭비가 아닙니다. 다른 많은 회의를 피할 수 있고 낭비되는 시간보다 더 많은 시간을 절약할 수 있습니다.
간단
단순한 디자인은 항상 복잡한 디자인보다 시간이 덜 걸립니다. 따라서 항상 작동할 수 있는 가장 간단한 일을 하십시오. 작업에 많은 시간을 할애하기 전에 복잡한 코드를 즉시 교체하는 것이 항상 더 빠르고 저렴합니다. 계획되기 전에 기능을 추가하지 않고 가능한 한 단순하게 유지하십시오. 명심하세요: 디자인을 단순하게 유지하는 것은 힘든 일입니다.은유 시스템
클래스와 메서드의 이름을 지정할 때 팀을 동일한 프레임워크로 유지하려면 메타포 시스템의 선택이 필요합니다. 개체의 이름을 지정하는 방법은 시스템의 전체 디자인과 코드 재사용을 이해하는 데 매우 중요합니다. 개발자가 기존 개체의 이름을 어떻게 지정할 수 있는지 정확하게 추측할 수 있으면 시간이 절약됩니다. 시스템에 대한 특정 지식 없이 모든 사람이 이해할 수 있는 개체에 이름 지정 시스템을 사용합니다.작업 현장의 고객
소프트웨어 개발의 주요 문제는 개발된 주제 영역에 대한 프로그래머의 지식 부족입니다. 익스트림 프로그래밍도 이 상황에서 벗어날 수 있는 방법을 찾았습니다. 아니요, 이것은 고객 기업에서의 개발자 인턴십이 아닙니다. 그러면 그는 프로그래밍을 원하지 않을 것입니다. 오히려 개발 과정에 고객이 참여하는 것입니다.문제의 본질을 완전히 이해하지 못하고 텔레파시가 아닌 프로그래머가 어떻게 고객이 원하는 것을 추측할 수 있겠습니까? 답은 분명합니다. 가장 간단한 방법으로그런 불편함을 극복하고 익스트림 프로그래밍은 간단한 솔루션- 고객에게 직접적인 질문을 할 것입니다. 보다 엄격한 접근 방식을 사용하려면 개발 중인 영역에 대한 포괄적인 예비 분석이 필요합니다. 어떤 경우에는 비용이 더 많이 들지만 이것이 정당화됩니다. 일상적인 프로젝트를 수행한 실제 경험은 모든 요구 사항을 사전에 수집하는 것이 불가능하다는 것을 보여줍니다. 또한 현재 모든 요구 사항이 수집되었다고 가정하더라도 여전히 한 가지 병목 현상이 있습니다. 자연의 모든 것과 마찬가지로 프로그램은 즉시 생성되지 않으며 그 동안 비즈니스 프로세스가 변경될 수 있습니다. 이 점을 고려해야 합니다.
많은 사람들이 개발 프로세스에 고객을 참여시킬 가능성을 의심합니다. 실제로 고객은 다릅니다. 고객이나 그 대리인을 유치할 수 없는 경우 개발 중인 분야의 전문가를 임시로 고용하는 것이 합리적입니다. 이러한 단계는 작업의 모호성을 줄이고 개발 속도를 높이며 프로젝트를 고객이 받고자 하는 것에 더 가깝게 만들 것입니다. 이것은 재정적 측면에서도 유익할 수 있습니다. 결국 프로그래머의 급여는 때때로 다른 산업의 전문가 급여를 훨씬 초과합니다.
사용자 이야기. 사용자 스토리(사용자 스토리와 같은 것)는 시스템 작동 방식에 대한 설명입니다. 각 사용자 스토리는 카드에 기록되며 고객의 관점에서 논리적으로 타당한 시스템 기능의 일부를 나타냅니다. 양식은 사용자가 이해할 수 있는 한두 단락의 텍스트입니다(매우 기술적인 것은 아님).
사용자 스토리는 고객이 작성합니다. 시스템 사용 시나리오와 유사하지만 이에 국한되지 않습니다. 사용자 인터페이스. 각 스토리에 대해 이 스토리가 올바르게 구현되었는지 확인하기 위해 기능 테스트가 작성됩니다. 이를 수락 테스트라고도 합니다.
개발 전 테스트
테스트는 고전적인 의미에서 다소 지루한 절차입니다. 일반적으로 정기적으로 동일한 작업을 수행하는 테스터를 고용하고 최종적으로 다른 직책으로 이동하거나 이직 기회가 있는 날을 기다립니다.익스트림 프로그래밍에서 테스트의 역할은 더 흥미롭습니다. 이제 테스트가 먼저 오고 코드가 그 다음에 옵니다. 아직 존재하지 않는 것을 어떻게 테스트할 수 있습니까? 대답은 간단하고 진부합니다. 생각을 테스트하십시오. 미래의 소프트웨어 또는 기능에서 기대할 수 있는 것입니다. 이렇게 하면 프로그래머가 수행해야 하는 작업을 더 잘 이해하고 코드가 작성되는 즉시 기능을 확인할 수 있습니다.
그러나 테스트도 작동하지 않을 수 있습니다. 테스트를 위해 테스트를 작성하는 것은 어떻습니까? 그런 다음 테스트 등을 무한정 테스트합니까? 전혀. 테스트를 위한 테스트가 코드를 대체합니다. 어때요? 그러나보십시오 : 회전하지 않도록 볼트 중간에 너트를 고정해야한다고 상상해보십시오. 그들은 이것을 위해 무엇을합니까? 두 번째 너트를 첫 번째 너트에 가깝게 조여 각 너트가 다음 너트가 돌아가지 않도록 합니다. 프로그래밍에서도 동일합니다. 테스트는 코드를 테스트하고 코드는 테스트를 테스트합니다.
경험에 따르면 이 접근 방식은 속도를 늦출 뿐만 아니라 개발 속도를 높입니다. 결국, 수행해야 할 작업과 필요한 작업량을 알고 있으면 청구되지 않은 구현을 거부하여 시간을 절약할 수 있습니다. 이 순간세부.
페어 프로그래밍
프로덕션 시스템의 모든 코드는 쌍으로 작성됩니다. 두 명의 개발자가 나란히 앉아 있습니다. 하나는 다이얼을 돌리고 다른 하나는 시계를 봅니다. 그들은 수시로 바뀝니다. 혼자 작업하는 것은 허용되지 않습니다. 어떤 이유로 쌍의 두 번째 사람이 무언가를 놓친 경우(그는 아프거나 떠났다 등) 첫 번째 사람이 만든 모든 변경 사항을 검토해야 합니다.이상하게 들리지만 짧은 적응 기간 후에 대부분의 사람들은 짝을 이루어 훌륭하게 일합니다. 작업이 눈에 띄게 빨라지기 때문에 그들은 그것을 좋아합니다. "머리 하나는 좋지만 둘은 더 좋다"는 원칙이 적용됩니다. 커플은 일반적으로 더 최적의 솔루션을 찾습니다. 또한 코드의 품질이 크게 향상되고 오류가 감소하며 개발자 간의 지식 교환이 가속화됩니다. 한 사람이 대상의 전략적 관점에 집중하는 동안 두 번째 사람은 그 속성과 방법을 구현합니다.
직위 변경
다음 반복 동안 모든 작업자는 새로운 작업 영역으로 이동해야 합니다. 이러한 움직임은 지식의 고립을 피하고 병목 현상을 제거하는 데 필요합니다. 특히 페어 프로그래밍에서 개발자 중 한 명을 교체하는 것이 효과적입니다.공동 코드 소유권
공동 코드 소유권은 개발자가 자신의 모듈뿐만 아니라 프로젝트의 모든 부분에 대한 아이디어를 제출하도록 권장합니다. 모든 개발자는 기능을 추가하고 버그를 수정하기 위해 코드를 변경할 수 있습니다.언뜻보기에는 혼돈처럼 보입니다. 그러나 적어도 몇 명의 개발자가 만든 코드가 있다는 점을 고려하면 해당 테스트를 통해 변경 사항의 정확성을 확인할 수 있으며 실제 생활에서는 여전히 다른 사람의 코드를 어떤 식으로든 이해해야 한다는 점을 고려하면 명확해집니다. 공동 코드 소유권은 변경 도입을 크게 단순화하고 팀 구성원의 높은 전문화와 관련된 위험을 줄입니다.
코딩 규칙
당신은 이 프로젝트를 오랫동안 진행해 온 팀에 속해 있습니다. 사람들이 왔다가 갑니다. 아무도 혼자 코드를 작성하지 않으며 코드는 모두의 것입니다. 다른 사람의 코드를 이해하고 수정해야 하는 순간은 항상 있을 것입니다. 개발자는 중복 코드를 제거 또는 변경하고 다른 사람의 클래스를 분석 및 개선하는 등의 작업을 수행합니다. 시간이 지나면 특정 클래스의 작성자가 누구인지 알 수 없습니다.따라서 모든 사람은 공통 코딩 표준(코드 형식, 클래스, 변수, 상수 이름 지정, 주석 스타일)을 준수해야 합니다. 이런 식으로 우리는 다른 사람의 코드를 변경함으로써(앞으로의 공격적이고 극단적인 발전을 위해 필요함) 그것을 바빌론의 판데모니엄으로 바꾸지 않을 것이라고 확신할 것입니다.
위의 내용은 모든 팀 구성원이 공통 코딩 표준에 동의해야 함을 의미합니다. 그것은 중요하지 않습니다. 규칙은 모든 사람이 준수한다는 것입니다. 준수하기를 원하지 않는 사람들은 팀을 떠납니다.
빈번한 통합
개발자는 가능하다면 몇 시간마다 코드를 통합하고 릴리스해야 합니다. 어떤 경우에도 변경 사항을 하루 이상 유지해서는 안 됩니다. 빈번한 통합은 개발자가 아이디어를 교환하거나 코드를 재사용한다는 의미에서 의사 소통할 수 없는 개발 과정에서 소외와 단편화를 방지합니다. 모두가 함께 일해야 합니다. 최신 버전.각 개발자 쌍은 합당한 기회가 있는 즉시 코드를 제공해야 합니다. 이것은 모든 UnitTest가 100%를 통과했을 때일 수 있습니다. 하루에 여러 번 변경 사항을 제출하면 통합 문제가 거의 발생하지 않습니다. 통합은 "지금 지불하거나 나중에 지불하는" 활동입니다. 따라서 매일 조금씩 변경 사항을 통합하면 프로젝트가 전달되기 직전에 시스템을 연결하는 데 일주일을 보낼 필요가 없습니다. 항상 최신 버전의 시스템에서 작업하십시오.
주 40시간 근무
사람, 특히 프로그래머인 경우 비즈니스를 위해 많은 일을 할 수 있습니다. 직장에 머물고, 주말에 일하고, 휴가를 거부하고, 며칠 동안 깨어 있고, 키보드에 앉아 있습니다. .. 일반적으로 좋아하는 오락을 위해 아무것도 할 수 없습니다. 그러나 극단적인 프로그래밍은 그러한 자기 희생과 노동법 규범 위반에 대해 단호하게 반대합니다.이것은 합법성과 인간성에 대한 고려뿐만 아니라 무엇보다도 작업의 효율성과 엄격한 조직을 높일 필요성에 의해 결정됩니다. 결국 익스트림 프로그래밍은 개인이 아닌 전체 그룹을 위해 설계된 집단 게임입니다. 예를 들어 페어 프로그래밍과 같은 것은 참가자의 생체 리듬이 동기화된 경우에만 가능합니다. 그리고 한 사람이 9시에 출근하고 두 번째 사람이 12시에 출근하거나 한 사람이 토요일과 일요일에 일하는 것이 더 낫다고 결정하고 다른 사람이 불편하면 불가능합니다.
그러나 가장 중요한 것은 건강과 성과를 유지하기 위해 사람이 좋은 휴식을 취해야 한다는 것입니다. 하루 8시간 근무와 주 5일 근무는 생산성 극대화를 위해 정확하게 설정됩니다. 많은 서양 기업에서 늦게 퇴근하는 것은 학업 성취도가 낮거나 근무 시간을 적절하게 관리할 수 없는 것으로 간주됩니다. 대부분의 경우 이것이 사실입니다. 네, 그리고 의학적 관점에서 직장에서의 지연은 지속적인 피로, 과민성 및 뇌 활동 감소로 이어집니다. 효율적인가? 그러나 그러한 팀에서 개발자 간의 지속적인 열린 의사 소통을 구성하는 방법은 무엇이며 짝 프로그래밍이 가능합니까? 대답은 부정적입니다. 규칙은 규칙이며 따라야 합니다.
결론
이러한 기술은 우연히 결합되지 않습니다. 이들의 일관된 조합은 개발 프로세스를 지적 공명으로 끌어들여 제품의 품질을 크게 향상시키고 출시 시기를 앞당길 수 있습니다. 모든 익스트림 프로그래밍의 주요 장점은 예측 가능성과 개발 비용 최소화입니다. 출시 시점에 고객이 받고자 하는 제품을 고객에게 제공하는 단계; 물론 직장에서 개발자의 의사 소통 및 교육.서지:
익스트림 프로그래밍(XP)은 진화하는 상향식 소프트웨어 개발 방법으로 시작되었습니다. 이 접근 방식은 소위 Agile Development Method의 한 예입니다. "라이브" 방법 그룹에는 익스트림 프로그래밍 외에도 SCRUM 방법, DSDM(동적 시스템 개발 방법), 기능 중심 개발(시스템 기능에 의해 주도되는 개발) 등이 포함됩니다.
"라이브" 소프트웨어 개발의 기본 원칙은 2000년에 나온 "라이브" 개발 선언문에 고정되어 있습니다.
- · 프로젝트에 참여하는 사람들과 그들의 커뮤니케이션이 프로세스와 도구보다 더 중요합니다.
- · 포괄적인 문서보다 작업 프로그램이 더 중요합니다.
- · 계약 내용을 협의하는 것보다 고객과의 협력이 더 중요합니다.
- · 계획을 따르는 것보다 변화를 실천하는 것이 더 중요합니다.
"라이브" 방식은 대부분의 "무거운" 프로세스에 따라 프로젝트 중에 작성해야 하는 소프트웨어 개발의 과도한 관료화, 최종 결과를 얻는 데 필요하지 않은 부가 문서의 풍부에 대한 항의로 나타났습니다. , 추가 작업예를 들어 CMM에서 요구하는 조직의 고정 프로세스를 지원합니다. 이러한 작업 및 문서의 대부분은 소프트웨어 개발 및 품질 보증과 직접적인 관련이 없지만 개발 계약의 공식 조항을 준수하고 다양한 표준에 대한 준수 인증서를 획득 및 확인하기 위한 것입니다.
"라이브" 방법을 사용하면 개발자의 대부분의 노력이 개발 및 만족의 실제 작업에 집중할 수 있습니다. 진짜 필요사용자. 문서 더미가 없고 일관된 상태로 유지해야 하므로 요구 사항 및 향후 프로그램이 작동해야 하는 환경의 변화에 보다 빠르고 효율적으로 대응할 수 있습니다.
그럼에도 불구하고 XP에는 그림 1과 같이 자체 개발 프로세스 체계가 있습니다(일반적으로 말해서 "개발 프로세스"에 대해 상당히 엄격한 행동 체계로 널리 사용되는 이해는 개발 "활력"이라는 개념과 모순됩니다).
XP의 저자에 따르면 이 기술은 다음 기술의 조합을 사용하는 것만큼 일반적인 행동 패턴을 따르지 않습니다. 그러나 각 기술은 중요하며 Ward Cunningham(Ward Cunningham) 및 Ron Jeffries(Ron Jeffries)와 함께 이 접근 방식의 저자 중 한 명인 Kent Beck에 따르면 기술이 없으면 개발이 XP가 아닌 것으로 간주됩니다.
· 생활 계획 게임)
그 임무는 소프트웨어의 다음 버전 전에 수행해야 하는 작업의 양을 가능한 한 빨리 결정하는 것입니다. 결정은 우선 고객의 우선 순위(즉, 고객의 요구 사항, 비즈니스를 보다 성공적으로 운영하기 위해 시스템에서 필요한 것)를 기반으로 하고, 두 번째로 다음을 기반으로 합니다. 기술 평가(즉, 개발 복잡성, 시스템의 다른 요소와의 호환성 추정 등). 계획은 현실이나 고객의 바람에서 벗어나는 즉시 변경됩니다.
그림 1
· 잦은 변화 버전(작은 릴리스)
가장 먼저 작동하는 버전이 가능한 한 빨리 나타나야 하며 즉시 사용해야 합니다. 다음 버전상당히 짧은 간격으로 준비됩니다(몇 시간에서 작은 프로그램, 대규모 시스템의 심각한 처리로 최대 1~2개월). 제품의 버전(릴리스)은 가능한 한 자주 프로덕션에 들어가야 합니다. 각 버전에 대한 작업은 가능한 한 적은 시간이 소요됩니다. 동시에 각 버전은 비즈니스에 대한 유용성 측면에서 충분히 의미가 있어야 합니다.
· 시스템의 은유
팀에 대해 상당히 간단하고 이해할 수 있는 형태의 은유는 시스템의 주요 메커니즘을 설명해야 합니다. 이 개념은 건축을 연상케 하지만, 수용된 것의 주요 본질을 설명하기 위해서는 한두 구절로 훨씬 더 간단해야 합니다. 기술 솔루션.
아키텍처는 시스템 구성 요소와 구성 요소가 상호 연결되는 방식에 대한 아이디어입니다. 개발자는 아키텍처를 사용하여 시스템에서 일부 새로운 기능이 추가되고 일부 새로운 구성 요소가 상호 작용할 위치를 이해합니다.
시스템 은유는 대부분의 기술이 아키텍처라고 부르는 것과 유사합니다. 시스템 은유는 팀에게 현재 시스템이 어떻게 작동하는지, 어디에 새로운 구성 요소가 추가되는지, 어떤 형태를 취해야 하는지에 대한 아이디어를 제공합니다.
· 단순한 설계 솔루션(단순 설계)
주어진 시간에 시스템은 가능한 한 간단하게 설계되어야 합니다. 기능을 미리 추가할 필요가 없습니다. 명시적으로 요청한 후에만 가능합니다. 모든 초과 복잡성은 발견되는 즉시 제거됩니다.
XP는 작업 과정에서 문제의 조건이 반복적으로 변경될 수 있다는 사실에서 출발합니다. 작업 초기에 시스템을 처음부터 끝까지 세부적으로 설계하려고 하면 시간을 낭비하는 것입니다. XP는 디자인이 프로젝트의 수명 동안 지속적으로 수행되어야 하는 매우 중요한 프로세스라고 제안합니다. 디자인은 끊임없이 변화하는 요구 사항을 고려하여 작은 단계로 수행되어야 합니다. 매 순간, 우리는 현재 작업에 적합한 가장 단순한 디자인을 사용하려고 노력합니다. 동시에 문제의 조건이 변경됨에 따라 변경합니다.
· 개발 에 기초 테스트(테스트 주도 개발)
개발자는 먼저 테스트를 작성한 다음 테스트가 작동하도록 모듈을 구현하려고 합니다. 고객은 시스템의 주요 기능을 시연하는 테스트를 미리 작성하여 시스템이 실제로 작동하는지 확인할 수 있습니다.
XP는 두 가지 유형의 테스트에 중점을 둡니다.
ь 단위 테스트(단위 테스트);
ь 승인 테스트(승인 테스트).
익스트림 프로그래밍 소프트웨어
개발자는 자신이 개발하는 시스템의 모든 단위 테스트가 작동할 때까지 자신이 작성한 코드의 정확성을 확신할 수 없습니다. 단위 테스트를 통해 개발자는 코드가 올바르게 작동하는지 확인할 수 있습니다. 또한 다른 개발자가 특정 코드 조각이 필요한 이유와 작동 방식을 이해하는 데 도움이 됩니다. 또한 단위 테스트를 통해 개발자는 두려움 없이 리팩토링할 수 있습니다.
승인 테스트를 통해 시스템에 실제로 선언된 기능이 있는지 확인할 수 있습니다. 또한 승인 테스트를 통해 개발된 제품의 올바른 기능을 확인할 수 있습니다.
XP의 경우 TDD(Test Driven Development)라는 접근 방식이 더 우선시되며 먼저 통과하지 못한 테스트를 작성한 다음 테스트를 통과하도록 코드를 작성한 다음 코드를 리팩토링합니다.
· 끊임없는 리팩토링
모든 새로운 기능이 추가되고 코드가 늘어남에 따라 개발, 버그 포착 및 후속 변경이 더 어려워진다는 것은 비밀이 아닙니다. 익스트림 프로그래밍의 트릭 중 하나는 코드를 개선하여 추가된 기능을 보완하는 것입니다. 이것이 코드 리팩토링 또는 리팩토링입니다.
프로그래머는 불필요한 복잡성을 제거하고 코드의 이해도를 높이며 유연성을 높이기 위해 시스템을 지속적으로 재작업하고 있습니다. 동시에 단순히 원하는 결과를 제공하는 솔루션과 비교하여 더 우아하고 유연한 솔루션을 선호합니다. 테스트를 실행할 때 성공적으로 리팩토링되지 않은 구성 요소를 감지하고 마지막 일관된 상태로 롤백해야 합니다(이에 종속된 구성 요소와 함께).
리팩토링은 기능을 변경하지 않고 코드를 개선하는 기술입니다. XP는 코드가 일단 작성되면 프로젝트 과정에서 거의 확실히 여러 번 다시 작성될 것임을 의미합니다. XP 개발자들은 개선하기 위해 이전에 작성된 코드를 무자비하게 재작업하고 있습니다. 이 프로세스를 리팩토링이라고 합니다. 테스트 커버리지의 부족은 리팩토링의 거부를 유발하는데, 이는 시스템을 깨는 것에 대한 두려움으로 인해 코드의 점진적인 저하로 이어집니다.
· 프로그램 작성 쌍으로 (쌍 프로그램 작성)
숙련된 개발자는 다른 사람의 코드를 주기적으로 검토하는 것이 품질에 긍정적인 영향을 미친다는 사실을 알게 되었습니다. 익스트림 프로그래머는 이 접근 방식을 개발했습니다. 개발 중에 코드는 쌍 프로그래밍이라는 기술을 통해 지속적으로 수정됩니다.
코딩은 한 대의 컴퓨터에서 두 명의 프로그래머가 수행합니다. 페어링은 임의적이며 문제마다 다릅니다. 키보드가 손에 든 사람 최선의 방법으로현재 문제를 해결합니다. 두 번째 프로그래머는 첫 번째 작업을 분석하고 조언을 제공하고 특정 결정, 새로운 테스트, 덜 직접적이지만 보다 유연한 솔루션의 결과를 고려합니다. 필요한 경우 키보드가 서로 자유롭게 전송됩니다. 프로젝트에서 작업하는 동안 쌍은 고정되지 않습니다. 팀의 각 프로그래머가 전체 시스템에 대해 잘 알 수 있도록 혼합하는 것이 좋습니다. 따라서 페어 프로그래밍은 팀 내 상호 작용을 향상시킵니다.
· 집단 소유 코드(집합 소유권)
집단 소유각 팀 구성원이 전체 원천. 따라서 모든 사람은 프로그램의 모든 부분을 변경할 권리가 있습니다. 페어 프로그래밍은 이 방법을 지원합니다. 서로 다른 페어로 작업하면 모든 프로그래머가 시스템 코드의 모든 부분에 익숙해집니다. 공동 코드 소유권의 중요한 이점은 버그가 발생하면 모든 프로그래머가 수정할 수 있기 때문에 개발 프로세스의 속도가 빨라진다는 것입니다.
모든 프로그래머에게 코드를 변경할 수 있는 권한을 부여함으로써 우리는 자신이 하는 일을 알고 있다고 생각하지만 일부 종속성을 고려하지 않는 프로그래머로부터 버그를 도입할 위험이 있습니다. 잘 정의된 UNIT 테스트는 이 문제를 해결합니다. 검토되지 않은 종속성이 오류를 생성하면 다음 UNIT 테스트 실행이 실패합니다.
· 끊임없는 통합(연속 완성)
시스템은 몇 명의 프로그래머가 기능 구현을 마칠 때마다 하루에 여러 번 가능한 자주 조립 및 통합 테스트를 거칩니다.
시스템을 충분히 자주 통합하면 시스템과 관련된 대부분의 문제를 피할 수 있습니다. 전통적인 방법에서는 일반적으로 개발 중인 시스템의 모든 구성 요소가 완전히 준비된 것으로 간주되는 제품 작업의 맨 마지막에 통합이 수행됩니다. XP에서 전체 시스템의 코드 통합은 개발자가 모든 단위 테스트가 올바르게 작동하는지 확인한 후 하루에 여러 번 수행됩니다.
단순함에도 불구하고 이 기술은 통합 기능에 대한 기존 단위 테스트의 성공, 기능 또는 승인 테스트의 존재, 그리고 물론 이전 상태로 롤백하는 기능과 같은 고유한 사용 규칙이 있습니다. 일반적으로 수반되는 어려움의 통합 및 해결은 다음에서 수행됩니다. 별도의 컴퓨터몇 명의 프로그래머. 이를 통해 통합으로 인한 바람직하지 않은 결과의 위험을 최소화할 수 있습니다.
· 40시간 일하고 있는 일주일
초과 근무는 프로젝트에 큰 문제가 있다는 신호로 간주됩니다. 연속 2주 동안 초과 근무를 할 수 없습니다. 이는 프로그래머를 지치게 하고 작업의 생산성을 크게 떨어뜨립니다.
사람은 특히 프로그래머 인 경우 비즈니스를 위해 많은 일을 할 수 있습니다. 직장에 머물고, 주말에 일하고, 휴가를 거부하고, 며칠 동안 깨어 있고, 키보드에 앉아 있습니다. 일반적으로 좋아하는 오락을 위해 아무것도 할 수 없습니다. 그러나 극단적인 프로그래밍은 그러한 자기 희생과 노동법 규범 위반에 대해 단호하게 반대합니다.
이것은 합법성과 인간성에 대한 고려뿐만 아니라 무엇보다도 작업의 효율성과 엄격한 조직을 높일 필요성에 의해 결정됩니다. 결국 익스트림 프로그래밍은 개인이 아닌 전체 그룹을 위해 설계된 집단 게임입니다. 예를 들어 페어 프로그래밍과 같은 것은 참가자의 생체 리듬이 동기화된 경우에만 가능합니다. 그리고 한 사람이 9시에 출근하고 두 번째 사람이 12시에 출근하거나 한 사람이 토요일과 일요일에 일하는 것이 더 낫다고 결정하고 다른 사람이 불편하면 불가능합니다.
그러나 가장 중요한 것은 건강과 성과를 유지하기 위해 사람이 좋은 휴식을 취해야 한다는 것입니다. 하루 8시간 근무와 주 5일 근무는 생산성 극대화를 위해 정확하게 설정됩니다. 많은 서양 기업에서 늦게 퇴근하는 것은 학업 성취도가 낮거나 근무 시간을 적절하게 관리할 수 없는 것으로 간주됩니다. 대부분의 경우 이것이 사실입니다. 네, 그리고 의학적 관점에서 직장에서의 지연은 지속적인 피로, 과민성 및 뇌 활동 감소로 이어집니다. 효율적인가? 그러나 그러한 팀에서 개발자 간의 지속적인 열린 의사 소통을 구성하는 방법은 무엇이며 짝 프로그래밍이 가능합니까? 대답은 부정적입니다. 규칙은 규칙이며 따라야 합니다.
· 포함 고객 안에 명령(현장 고객)
소프트웨어 개발의 주요 문제는 개발된 주제 영역에 대한 프로그래머의 지식 부족입니다. 익스트림 프로그래밍도 이 상황에서 벗어날 수 있는 방법을 찾았습니다. 아니요, 이것은 고객 기업에서의 개발자 인턴십이 아닙니다. 그러면 그는 프로그래밍을 원하지 않을 것입니다. 오히려 개발 과정에 고객이 참여하는 것입니다.
개발 팀의 일원으로서 항상 근무일 내내 이용 가능하고 시스템에 대한 모든 질문에 답변할 수 있는 고객 담당자가 있습니다. 시스템의 기능, 인터페이스, 필요한 성능, 올바른 작동어려운 상황의 시스템, 다른 응용 프로그램과의 통신 필요성 등
많은 사람들이 개발 프로세스에 고객을 참여시킬 가능성을 의심합니다. 실제로 고객은 다릅니다. 고객이나 그 대리인을 유치할 수 없는 경우 개발 중인 분야의 전문가를 임시로 고용하는 것이 합리적입니다. 이러한 단계는 작업의 모호성을 줄이고 개발 속도를 높이며 프로젝트를 고객이 받고자 하는 것에 더 가깝게 만들 것입니다. 이것은 재정적 측면에서도 유익할 수 있습니다. 결국 프로그래머의 급여는 때때로 다른 산업의 전문가 급여를 훨씬 초과합니다.
· 용법 암호 어떻게 자금 연락
코드는 팀 내에서 가장 중요한 커뮤니케이션 수단으로 간주됩니다. 코드 명확성은 최우선 순위 중 하나입니다. 이러한 명확성을 제공하는 코딩 표준을 따르는 것이 필수적입니다. 이러한 표준은 코드의 명확성과 더불어 최소한의 표현(코드 및 정보의 복제 금지)을 보장해야 하며 모든 팀 구성원이 수용해야 합니다.
· 열려 있는 일하고 있는 공간(열린 작업 공간)
팀은 중요한 기술적 결정을 계획하고 결정할 때 의사 소통과 집단 토론의 가능성을 촉진하기에 충분히 넓은 한 방에 보관됩니다.
· 변화 규칙 ~에 필요한(그냥 규칙)
팀의 각 구성원은 나열된 규칙을 수락해야 하지만 필요한 경우 모든 구성원이 이 변경에 동의하면 팀에서 변경할 수 있습니다.
사용된 기술에서 알 수 있듯이 XP는 소규모 팀(프로그래머 10명 이하) 내에서 사용하도록 설계되었으며, 이는 이 기술의 작성자도 강조합니다. 더 큰 팀 규모는 성공에 필요한 의사 소통의 용이성을 파괴하고 나열된 많은 기술을 불가능하게 만듭니다.
익스트림 프로그래밍은 프로그램을 생성하는 전통적인 프로세스에서 출발합니다. 장기적인 관점에서 시스템을 일회성으로 계획, 분석 및 설계하는 대신 이제 프로그래머는 개발 중에 이러한 모든 작업을 점진적으로 구현합니다.
처음에는 "폭포" 모델이 있었습니다(그림 1a). 우리는 사용자에게 요구 사항을 명확하게 공식화하도록 요청합니다. 우리는 사용자가 원하는 것은 무엇이든 할 수 있는 시스템을 설계하고 있습니다. 우리는 코드를 작성합니다. 우리는 프로그램이 해야 할 일을 하는지 확인하기 위해 프로그램을 테스트합니다. 모든 것이 훌륭합니다.
사실, 상황은 장밋빛과는 거리가 멀었습니다. 개발이 시작되기 전에 사용자는 아직 요구 사항을 명확하게 공식화할 수 없습니다. 그들은 항상 자신이 원하는 것이 무엇인지 몰랐고 때로는 모순되고 문제에 대한 견해를 바꿨습니다. 하지만 사용자만 있는 것은 아닙니다. 우리 프로그래머는 4분의 3을 진행하고 실제로 작업의 3분의 1만 수행한 것을 발견하고 엄청난 성공으로 기뻐했습니다.
따라서 개발 주기가 길면 변화에 적응하지 못하기 때문에 좋지 않습니다. 그러면 주기를 단축해야 하고 모든 문제가 해결되는 것은 아닐까? 무화과에. 도 1b는 폭포수 모델을 반복 모델로 변환하는 것을 예시한다.
폭포수 모델이 갑자기 나타난 것은 아니라는 점을 기억하십시오. 시간이 지남에 따라 프로그램을 변경하는 비용이 매우 많이 증가한다는 충격적인 추정치에 대한 자연스러운 반응이었습니다. 이것이 사실이라면 프로그램 수명 주기의 초기 단계에서 가장 중요하고 광범위한 결정을 내려 나중에 많은 비용을 지불할 필요가 없도록 해야 합니다.
소프트웨어 개발자의 학계는 높은 변경 비용 문제를 해결하고 관계형 데이터베이스, 모듈식 프로그래밍, 정보 은닉과 같은 새로운 기술을 만들었습니다. 그러나 이 모든 작업이 이미 잠재력을 소진했다면 어떻게 될까요? 그리고 우리는 찾을 수 있습니다 새로운 방법"폭포"를 조각으로 자르지 않고 단순히 모든 구성 요소를 혼합하여 변경 비용을 줄이겠습니까? 결과는 그림 1c에 나와 있습니다. 우리는 그것을 "익스트림 프로그래밍"(XP)이라고 불렀습니다.
XP의 해부학
XP는 기존의 생성 프로세스에서 탈피합니다. 소프트웨어 시스템그리고 장기적으로 일회성 계획, 분석 및 설계 대신 XP를 사용하여 이러한 모든 활동을 개발 중에 점진적으로 구현함으로써 프로그램 변경 비용을 크게 절감할 수 있습니다. XP 방법은 누적 사용을 염두에 두고 설계되었으므로 둘 중 하나를 이해하면 필연적으로 다른 것도 이해할 수 있습니다(사이드바 참조). 사이드바는 이 접근 방식의 역사적 배경을 추적합니다.)
XP 개발 주기
무화과에. 2 프로세스 XP는 년, 월, 주 및 일이 측정 단위로 사용되는 다른 시간 축과 관련됩니다. 고객은 가능한 모든 것 중에서 가장 가치 있는 기능(XP에서는 스토리라고 함)을 선택하여 시스템의 다음 버전(릴리스)을 결정합니다. 기능의 가치는 개발팀이 구현하기 위한 재료 및 시간 비용에 의해 결정됩니다.
고객은 해당 버전에 남아 있는 스토리 중에서 가장 중요한 스토리를 선택하여 다음 반복에 대한 스토리를 결정하고, 다시 추정한 개발 비용과 속도를 기반으로 합니다. 프로그래머는 스토리를 로컬 작업으로 나누고 모두가 그 중 하나에 대해 책임을 집니다. 그런 다음 프로그래머는 자신의 문제를 일련의 테스트 케이스로 변환하고 성공적인 실행은 문제가 완전히 해결되었음을 보여줍니다. 파트너와 협력하여 프로그래머는 테스트의 정상적인 작동을 달성하는 동시에 공통 프로젝트를 개발합니다. 따라서 전체 시스템의 가장 간단한 아키텍처를 구현할 수 있습니다.
이야기
XP의 관점에서 시스템이 실제 작동하기까지의 첫 번째 출시까지의 기간은 위험한 예외입니다. 라이프 사이클프로젝트이며 가능한 한 빨리 극복해야 합니다. 그러나 모든 프로젝트에 대한 작업은 어떻게든 시작되어야 합니다.
우선, 시스템이 일반적으로 무엇을 의도하고 무엇을 할 수 있어야 하는지를 먼저 결정하는 것이 필요합니다. 일반적으로 그러한 결정을 내리기 위해서는 몇 가지 분석이 필요합니다. 그것은 그림 1에서 좁은 파란색 직사각형으로 상징됩니다. 1초. 실제로 프로그래밍해야 하는 것이 무엇인지 이해할 때까지 프로그래밍을 시작할 수 없습니다.
일반적인 분석의 결과는 시스템의 가능한 응용 프로그램을 나열하는 색인인 스토리로 표시됩니다. 각 스토리는 특정 비즈니스 목표에 초점을 맞춰 테스트하고 평가할 수 있어야 합니다. 정량적 지표. 한 달이면 충분하다 수용 가능한 시간 10인 프로젝트에 대한 이야기를 공식화합니다. 이 시간이 모든 것에 대한 상세한 연구에 충분하지 않다는 것이 분명합니다. 가능한 문제. 그러나 시스템 구현으로 넘어갈 생각이라면 모든 문제를 분석할 충분한 시간이 없을 것입니다.
버전
그림에서 알 수 있듯이. 2, 우리는 모든 이야기를 한 번에 구현하지 않습니다. 고객은 먼저 논리적으로 서로 관련이 있는 가장 중요한 이야기의 작은 집합을 선택합니다. 그리고 우리는 그것들을 무엇보다도 먼저 프로그래밍하고 작동시킵니다. 그 후에 다른 모든 것이 구현됩니다.
시스템 버전에 대한 이야기를 선택하는 것은 슈퍼마켓에서 쇼핑하는 것과 비교할 수 있습니다. 당신은 주머니에 백 달러를 가지고 가게로 향합니다. 먼저 필요한 것을 고려하십시오. 가격표를 보세요. 그리고 무엇을 살지 결정하십시오. 계획 게임에서 제품은 스토리이고 가격표는 스토리 추정치입니다. 예산은 주어진 시간 단위에 개발 팀이 전달한 예상 스토리 수에 따라 결정됩니다.
구매자(고객)는 바구니를 채울 수 있습니다(일련의 이야기 선택). 그 후 프로그래머가 구현의 최종 날짜를 계산하거나 프로그래머가 예산을 계산하고 고객이 수집하는 날짜를 설정할 수 있습니다. 받은 금액에 필요한 이야기 수.
반복
각 반복의 목표는 몇 가지 새로운 테스트를 거쳐 바로 실행할 수 있는 스토리를 프로덕션에 출시하는 것입니다. 이 프로세스는 구현될 스토리와 개발 팀이 이 작업을 수행하는 방법을 정의하는 계획으로 시작됩니다. 개발이 진행되는 동안 고객은 기능 테스트를 수행합니다. 반복이 끝나면 테스트가 실행되고 개발자는 다음 반복을 위해 준비해야 합니다.
반복을 계획하기 시작하면서 개발자는 고객에게 이번에는 이 버전에서 구현하기 위해 남은 이야기 중에서 가장 가치 있는 이야기를 선택하도록 다시 요청합니다. 개발자는 한 사람이 며칠 안에 완료할 수 있는 모듈인 작업으로 스토리를 나눕니다. 이전과 같은 여러 기술적인 문제가 있는 경우 새로운 버전데이터베이스의 경우 일반 목록에도 포함됩니다.
그런 다음 프로그래머는 특정 작업을 구현하는 책임을 집니다. 모든 작업이 배포된 후 작업을 담당하는 프로그래머가 이번에는 이상적인 프로그래밍 날짜 수로 작업을 평가합니다. 그런 다음 팀의 모든 프로그래머의 작업에 대한 추정치가 수집되고, 일부는 구현에 더 많은 시간을 할애하고 다른 일부는 덜 할 계획이라면 그에 따라 팀의 작업량이 재분배됩니다.
반복하는 동안 프로그래머는 작업을 구현합니다. 작업이 완료되면 해당 코드가 전체 시스템에 통합되고 함께 테스트됩니다. 모든 테스트가 성공적으로 통과하거나 코드를 시스템에 통합할 수 없습니다. 반복하는 동안 고객이 제공한 기능 테스트가 전체 테스트 시리즈에 추가됩니다. 반복이 끝나면 모든 테스트는 개별 모듈및 모든 기능 테스트.
작업
작업을 구현하기 위해 최종 코드는 항상 동일한 시스템에서 두 사람이 작성하기 때문에 작업을 담당하는 프로그래머는 먼저 파트너를 찾습니다. 주제 또는 구현 방법에 대한 질문이 있는 경우 파트너는 이 작업의 코드와 관련될 가능성이 가장 높은 코딩 문제에 대해 잘 알고 있는 고객 및/또는 프로그래머와 짧은(15분) 회의를 개최합니다. 구현.
이 회의의 결과를 바탕으로 프로그래머는 작업이 완료되기 전에 실행해야 하는 테스트 케이스 목록을 만듭니다. 목록에서 프로그래머가 완전히 확신하고 문제의 본질을 더 잘 이해할 수 있는 구현에서 그러한 테스트가 선택됩니다. 테스트 프로그램을 작성 중입니다. 즉시 잘 작동하면 계속 진행할 수 있습니다. 그러나 원칙적으로 문제가 없는 것은 아닙니다. 테스트가 작동하지 않으면 다음 상황 중 하나가 가능합니다.
- 우리는 그것을 작동시키는 간단한 방법을 알고 있으며 이러한 방식으로 행동합니다.
- 우리는 그것을 작동시키는 복잡하고 매우 실망스러운 방법을 알고 있지만 시스템을 다시 설계하고 너무 많은 노력 없이 테스트 케이스가 제대로 작동하도록 하는 방법을 알고 있습니다. 그런 다음 시스템을 재작업하기로 결정합니다.
- 우리는 그것을 작동시키는 어렵고 불쾌한 방법을 알고 있으며 시스템을 정밀 검사할 방법이 없기 때문에 어려운 길을 갑니다.
테스트가 작동한 후 시스템을 개선하는 방법을 다시 이해할 수 있습니다.
테스트 케이스를 구현하는 동안 작동해야 하는 다른 테스트 케이스를 찾을 가능성이 높습니다. 우리는 가져 새로운 테스트목록에 추가하고 개발을 계속하십시오. 아마도 우리는 시스템 재구성의 규모가 현재 테스트의 요구 사항을 초과한다는 것을 알게 될 것이며, 이 사실을 수정하고 계속 진행할 것입니다. 결국 우리의 목표는 세부 사항에 집중하고 특정 문제를 성공적으로 해결하는 동시에 코드에 대한 집중적인 작업 중에 형성되는 시스템의 일반적인 아이디어를 잃지 않는 것입니다.
테스트
XP의 핵심 방법에 대해 이야기하면 이것은 물론 단위 테스트입니다. 지금까지 알 수 있듯이 단위 테스트는 모든 프로그래머의 일상 작업에서 필수적인 부분입니다. 두 가지 기능으로 인해 XP의 테스트 프로세스가 기존 방법보다 훨씬 더 효율적입니다. 프로그래머가 직접 테스트를 작성하고 코딩하기 전에 수행합니다. 물론 프로그래밍을 문제에 대한 점진적인 연구로 접근하고 문제에 대한 연구를 가장 효과적인 수단으로 생각한다면 피드백고객과 함께라면 코딩이 완료된 후 며칠 또는 몇 주 후에 제3자가 작성한 테스트를 통해 가장 많은 이점을 얻을 수 있습니다. XP는 프로그래머가 자신의 코드를 적절하게 테스트할 수 없으므로 쌍으로 작업해야 한다는 기존의 통념을 고려합니다.
일부 방법론, 특히 Cleanroom은 프로그래머가 테스트를 수행하고 어떤 경우에는 프로그램을 컴파일하는 것을 금지합니다. 일반적으로 프로그래머는 코드를 작성하고 컴파일하고 작동하는지 확인한 다음 일부 테스트 조직에 제출합니다. 기존의 벤치마킹 방법은 코드와 변수를 단계별로 살펴보고 인쇄 명령문의 결과를 해석하고 메뉴 버튼을 테스트하는 것입니다.
XP는 기존 방법에 대한 새로운 테스트 기술을 도입하지 않습니다. 그냥 다른 형태로 테스트를 하고, 테스트가 끝난 후 흔적을 남기지 않는 일을 하는 대신 장기적으로 테스트를 생성하는 것입니다. 이 테스트는 오늘 작동하고 시스템 통합이 완료된 날과 다음 날, 그리고 일주일 뒤에, 그리고 내년에 작동합니다. 각 개별 테스트의 정상 작동에 대한 신뢰는 개발자들 사이에서 시스템 전체의 정상 작동에 대한 신뢰를 점차적으로 구축합니다.
이미 언급했듯이 고객도 테스트를 수행합니다. 반복을 시작할 때 고객은 이 반복에 대한 스토리가 완전히 구현되었음을 확신할 수 있는 요소를 찾아야 합니다. 그는 시스템 전체에 대한 테스트에서 이에 대한 자신의 생각을 공식화합니다. 고객은 텍스트 또는 그래픽 스크립팅 언어를 사용하여 테스트를 독립적으로 작성하거나 자신의 테스트 도구를 사용할 프로그래머에게 맡길 수 있습니다. 이러한 테스트는 또한 이번에는 시스템의 올바른 작동에 대한 고객의 신뢰를 구축합니다.
문제가 있습니까?
완벽하게 작동하는 조건에서 하나 또는 다른 프로그래밍 방법을 논의하는 것은 어렵지 않습니다. 예상치 못한 상황이나 바람직하지 않은 상황에 처했을 때 어떻게 할 것인지 아는 것이 훨씬 더 흥미진진합니다.
자신의 능력에 대한 재평가.때때로 당신은 당신이 처리할 수 있는 것보다 더 많은 것을 맡습니다. 가능한 한 자주 작업에 대한 정량적 평가에 의존하여 이러한 상황의 수를 최소화하는 것이 필요합니다. 마음이 답답하다면 먼저 자신에게서 원인을 찾으십시오. 분석: 아마도 당신은 실제 문제를 해결하는 데 너무 산만해 있을 것입니다. 테스트, 파트너와 협력, 시스템 재작업 및 통합에 전념하고 있습니까? 현재 고객이 필요로 하는 것보다 더 많은 일을 하고 있습니까?
개발 속도를 높이기 위해 내부 준비금을 찾을 수 없는 경우 고객에게 도움을 요청해야 합니다. 보장할 수 없는 작업 부하에 대한 책임을 유지하면 계획이 좌절되고 시스템 품질이 손상되어 결국 완전히 사용할 수 없게 됩니다. 자신에게 이것을 허용하지 마십시오. 얻은 경험을 바탕으로 능력을 재평가한 다음 고객에게 요구 사항을 재고하도록 요청하십시오. 세 가지 이야기 중 두 가지만 구현할 수 있다면 어떤 이야기를 먼저 처리하고 다음 반복이나 버전을 위해 유지할 이야기를 결정하게 하십시오. 어떤 부분이 다른 부분보다 더 중요한 그런 이야기가 있습니까? 그런 다음 구현을 여러 단계로 나누고 지연 없이 더 관련성이 높은 구성 요소를 프로그래밍하고 덜 중요한 구성 요소는 조금 나중에 프로그래밍할 수 있습니다.
고객이 협조하지 않는 경우.고객이 게임 규칙을 받아들이지 않는 상황을 상상해 보십시오. 테스트를 하지 않고, 우선순위를 지정하지 않으며, 이야기를 공식화하지 않습니다. 우선, 설치를 시도 신뢰 관계고객과 함께. 반복에서 반복으로 시스템의 기능을 향상시켜 고객에게 개발 프로세스를 제어할 수 있는 기회를 제공합니다. 상호 신뢰가 제대로 작동하지 않으면 이것이 당신의 잘못인지 분석하십시오. 고객과의 효과적인 상호작용을 위해 최선을 다하고 있습니까?
이 문제를 스스로 해결할 수 없는 경우 고객에게 도움을 요청하십시오. XP 원칙은 프로그래머가 고객의 요구 사항을 추측하여 개발하는 것을 허용하지 않습니다. 고객에게 XP의 작업 순서를 예를 들어 설명하거나 시연합니다. 그가 당신에 대한 태도를 바꾸지 않는다면, 당신의 주장을 좀 더 설명적으로 만드십시오. 본질적으로이 문제를 해결하는 데 관심이없는 사람이없는 것으로 판명되면이 프로젝트는 고객 활동에서 우선 순위가 낮을 수 있으며 계속 진행해야한다고 주장해서는 안됩니다.
직원 회전율.팀원 중 한 명이 탈퇴하기로 결정했다고 가정해 보겠습니다. 필요한 서류나 보고서가 부족하여 난관에 봉착하시겠습니까? 우선, 일부 직원 이직률은 개발 팀과 개별 구성원에게 좋습니다. 나는 물론 떠날 때 사람들이 긍정적 인 동기로 인도되기를 바랍니다. 다음 주 말에 집에 돌아가서 프로그래머가 특정 긍정적인 결과그의 활동, 일에 대한 실망의 가능성 및 떠나고 싶은 욕구의 출현이 크게 줄어 듭니다.
누군가가 XP 프로젝트를 떠난다고 해서 그가 혼자 알고 있는 비밀을 가져갈 것이라는 의미는 아닙니다. 시스템의 각 라인은 항상 두 사람이 제어합니다. 그리고 작업실에서 어떤 정보가 나오든 개발자는 테스트를 실행하고 자신도 모르는 사이에 예기치 않은 일이 발생했는지 확인할 수 있기 때문에 팀 작업에 큰 피해를 주지 않습니다.
처음 두 번의 반복 작업 과정에서 XP 팀의 새로운 구성원은 경험이 많은 파트너를 돕고 테스트를 연구하고 고객과 의사 소통하는 것으로 제한됩니다. 자신의 능력에 대한 자신감이 커지면 특정 작업에 대한 책임을 질 수 있습니다. 다음 몇 번의 반복을 개발하는 동안 새 사용자의 성능이 너무 높아져서 모든 사람에게 특정 작업을 제시간에 구현하는 것을 보여줄 수 있습니다. 몇 개월이 지나면 그들은 더 이상 경험 많은 팀원과 구별되지 않습니다.
어려운 문제는 팀 작업에 익숙하지 않은 프로그래머입니다. XP는 힘들고 협력적인 작업이며 모든 사람이 이러한 종류의 작업에 적응할 수 있는 것은 아닙니다. 오래된 습관을 버리는 것이 필요할 수 있으며, 특히 자신을 높이 평가하는 프로그래머에게는 이것이 전혀 쉬운 일이 아닙니다. 그러나 결국 XP의 다양한 형태의 피드백을 통해 누가 팀에서 일할 수 있고 할 수 없는지 정확히 파악할 수 있습니다. 당신 중 한 명이 지속적으로 작업을 완료하지 못하면 그의 모듈을 통합하면 항상 다른 팀 구성원에게 문제가 발생하고 시스템 재작업을 시도하지 않으며 쌍으로 작업하지 않으며 테스트를 수행하지 않습니다. 팀의 모든 사람들은 무엇이 무엇인지 이해할 것입니다. 그리고 그러한 사람이 그의 기술과 경험에 관계없이 떠나야 전체 팀이 더 나아질 것입니다.
요구 사항 변경.대부분의 개발 시스템에서 문제가 되는 문제는 XP에서는 전혀 그렇지 않습니다. 특정 문제를 해결하기 위해 오늘 만들어진 XP 프로젝트는 미래의 기능 변경에 동일한 효율성으로 대처할 것입니다. XP는 "각 생각을 한 번만 공식화"한다는 원칙을 공언하기 때문에 이미 수행된 것과 유사한 작업을 수행하는 것이 더 쉬울 것입니다. 이러한 처리 과정에서 필요성이 가장 자주 발생합니다. 그러나 시스템에 대한 완전히 새로운 요구 사항이 나타나는 경우에도 작동을 위한 새로운 메커니즘을 성급하게 구축할 필요가 없습니다.
처음에는 XP의 변화 적응력에 대한 명확한 개념이 없었습니다. XP의 첫 번째 버전에서 스토리 선택 프로세스는 버전 계획의 일부였으며 스토리는 버전의 모든 반복에 할당되었습니다. 그런 다음 개발자는 계획 노력을 덜 들이고 달성할 수 있음을 발견했습니다. 최고의 결과. 따라서 이제 고객은 다음 반복에 있어야 하는 스토리만 지정하라는 요청을 받습니다. 나타나는 경우 새로운 이야기, 당신은 그것을 예약하고 나머지 반복을 섞지 않습니다. 새로운 이야기가 아직 관련성을 잃지 않았다면 1~2주 안에 고객이 선택할 것입니다.
매번 한 번의 반복을 계획함으로써 우리는 점진적인 자기 개발과 시스템의 자기 유사성을 달성합니다. 몇 개월과 몇 년이라는 규모로 우리는 주어진 시스템 버전의 기록을 다룬 다음 미래 버전의 기록을 다루고 있습니다. 몇 주와 몇 개월 단위로 우리는 이 반복의 이야기를 다룬 다음 이 버전에 남아 있는 이야기를 다룹니다. 일 단위와 주 단위로 현재 작업 중인 작업을 처리한 다음 반복에 남아 있는 작업을 처리합니다. 마지막으로, 우리는 현재 실행 중인 테스트를 몇 분 또는 며칠 단위로 처리하고 있으며, 그 다음에는 우리가 생각해낼 수 있는 다른 테스트 케이스를 처리합니다.
의심의 여지 없이 XP는 우아하고 논리적으로 완벽한 아이디어입니다. 적용 가능성의 한계는 아직 완전히 명확하지 않습니다. 지금 이 접근 방식을 취함으로써, 당신은 어느 정도 용기와 유연성, 그리고 실패할 경우 프로젝트를 포기할 의지를 보여야 합니다. XP는 이 접근 방식의 이점이 분명한 프로젝트에서 먼저 시도해야 합니다. 요구 사항이 명확하게 정의되지 않고 변경될 수 있는 소규모 시스템의 사용자 지정 또는 사내 개발에서.
XP를 경험하고 싶다면 한 번에 모든 것을 하려고 하지 마십시오. 가장 성가신 문제를 선택하고 XP로 해결해 보십시오. 이 문제가 더 이상 가장 성가시지 않으면 다음 문제를 찾아 프로세스를 반복합니다. 계속 진행하다 보면 이전 방법이 더 이상 작동하지 않는다는 것을 알게 될 것입니다. 그러면 더 이상 연락할 수 없습니다. 이 점진적인 온보딩 프로세스를 통해 자신의 개발 스타일을 개발할 수 있는 기회가 주어집니다. 이는 어떤 상황에서도 도움이 될 것이며 XP 문제의 위험을 줄일 수 있습니다.
XP의 비즈니스 결정과 기술적 결정 간의 강력한 구분은 건축가 Christopher Alexander의 작업으로 거슬러 올라갑니다. 그의 저서 The Timeless Way of Building에서는 건물을 운영하는 사람들이 건물을 짓는 동안 중요한 결정을 내릴 수 있어야 한다고 말합니다.
기술 및 비즈니스 관련 변경 사항에 따라 계획을 빠르게 발전시키는 XP의 원칙은 Ward Cunningham이 개발한 스크럼 방법론과 에피소드 템플릿 언어의 원칙을 반영합니다.
실현 가능한 가능성 측면에서 프로젝트를 지정하고 계획하는 아이디어는 Ivar Jakobson의 작업으로 돌아갑니다.
Tom Gilb는 진화 공학 전문가입니다. 그의 최신 글은 몇 주 안에 소프트웨어를 시작하고 실행한 다음 개발하는 데 중점을 둡니다.
Barry Boehm의 나선형 모델은 폭포 모델의 노후화에 대한 첫 번째 반응이었습니다. 오랫동안강력한 기술을 마스터하는 데 있어서 JIT 방법을 만든 Object Technology International의 Dave Thomas와 그의 동료를 능가하는 사람은 없습니다.
XP에서 사용되는 은유 원리의 뿌리는 George Lakoff와 Mark Johnson의 저서, 특히 그들의 최신 저서 Philoslphy in Flesh에서 찾을 수 있습니다. 이 원칙은 포스트모던 철학의 관점에서 은유와 소프트웨어 개발을 연결한 Richard Coine도 제안했습니다.
마지막으로 사무실 조직에 대한 XP의 강조의 대부분은 프로그래머의 작업에 환경 조건의 영향을 언급한 Jim Coplien, Tom DeMarco 및 Tim Lister의 작업에서 비롯됩니다.
XP를 사용하여 프로젝트를 실행하는 예
공리: 공동의 목표를 달성하는 길
지한눌라
팀:관리자, 비즈니스 분석가, 개발자, 테스터, 기술 작가
신청:캠페인 관리 데이터베이스
시행 기간: 3 년
Acxiom은 Forte 분산 객체 지향 개발 툴킷을 사용하여 데이터 웨어하우스를 기반으로 하는 비즈니스 관리 애플리케이션을 만들었습니다. 단 10명으로 구성된 소규모 개발자 팀은 응용 프로그램을 만들 때 객체 지향 프로그래밍 및 공동 개발 원칙을 확고히 고수했습니다. 개발에 걸린 3년 중 지난 2년 동안 관리자, 비즈니스 분석가, 개발자, 테스터 및 기술 작가로 구성된 팀이 익스트림 프로그래밍 방법을 사용하여 성공했습니다.
최근까지 Acxiom은 프로젝트가 간단하고 이전에 구축된 시스템 중 일부가 새 애플리케이션의 일부로 적합할 수 있다면 성공이라고 생각했습니다. 그러나 좋은 결과는 없었습니다. 시스템 재작업은 개발의 중요한 요소가 되었습니다. 우리는 아직 기능을 알지 못하는 프로그램의 일부를 변경하는 것을 두려워하는 것이 좋은 개발자라고 볼 수 없다는 것을 분명히 깨달았습니다. 우리는 프로그램이 우리를 통제하게 합니다. 우리가 무엇을 몰랐다면 주어진 코드, 우리는 그것에 들어가서 알아내는 것을 두려워하지 않았습니다. 직접 하는 것이 좋다 특정 부분전체 애플리케이션을 별도의 부분에 인질로 삼는 것보다 코드를 작성하는 것이 좋습니다.
Forte는 기본 제공되는 기본 테스트 도구를 제공하지 않기 때문에 단위 테스트에 많은 노력을 기울였습니다. 우리는 우리 자신을 만들고 성공적으로 테스트하는 데 사용해야 했습니다. 우리는 최근에 Java 프로그래밍 언어로 전환했고 이제 JUnit을 테스트 도구로 사용합니다.
우리가 처음 XP의 원리에 대해 작업하기 시작했을 때 그의 방법을 사용하고 싶지 않은 프로그래머가 있었습니다. 그들은 이러한 방법이 그들이 개발한 프로그래밍 스타일에 적합하지 않고 생산성을 방해할 것이라고 생각했습니다. 결과적으로 대부분의 문제는 이 사람들이 작성한 시스템 구성 요소에서 발생했습니다. 이 개발자들은 팀워크를 무시하고 서로에게서 배울 수 있는 기회를 이용하는 다른 팀원들에 비해 기술이 열등했습니다. 서로 긴밀하게 협력하는 두 명의 숙련된 프로그래머와 팀의 나머지 부분은 이마가 7스팬인 경우에도 항상 "개인" 기술을 능가합니다.
우리는 팀의 모든 구성원이 XP의 원칙을 따라야 한다는 것을 깨달았습니다. 그렇지 않으면 이 접근 방식이 작동하지 않습니다. 이제 우리는 잠재적인 개발자에게 우리가 채택한 스타일에 만족하지 않으면 다른 팀에서 일을 찾는 것이 좋을 것이라고 즉시 경고합니다. 선택한 개발 방식에 관심이 없는 한 사람이 전체 팀의 노력을 무효화할 수 있습니다. XP의 본질은 시스템을 만드는 과정에서 새로운 아이디어를 집단적으로 발전시키는 것입니다.
HR에 대한 잘못된 인식이 있습니다. 이 접근법개발자의 창의적인 활동과 개인 능력 개발을 억제합니다. 사실, 모든 것이 정반대입니다. XP는 프로그래머의 창의적 성장을 자극하고 개별 팀 구성원이 빛날 수 있는 기회를 제공합니다. 가장 중요한 것은 선택한 방향을 결정하고 확고하게 고수하는 것입니다.
"Extreme Programming"은 우리 팀을 극한 상황에 처하게 하지 않았습니다. 이 방법은 잘 알려져 있고 대체로 친숙한 개발 접근 방식을 사용합니다. 모두가 긴밀히 협력하고 목표를 향해 함께 나아갑니다.
DaimlerChrysler: 세계 최고의 팀
쳇 헨드릭센
팀:프로그래머 10명 포함 15명
신청:급여 계산의 전면 자동화
시행 기간: 4 년
C3 프로젝트 작업은 1995년 1월에 시작되었습니다. Chrysler Corporation은 파트너 회사와 계약을 체결했으며 두 조직의 공동 개발 팀이 프로젝트를 맡았습니다. 파트너는 사용에 중점을 둔 개발 방법론을 따랐습니다. GUI테스트 자동화를 무시했습니다. 결과는 인상적이지 않은 그래픽으로 가득 차 있고 대부분의 직원의 급여를 잘못 계산하는 시스템이었습니다. 이러한 시스템이 월 급여를 생성하는 데 약 100일이 소요됩니다. 우리는 우리가 작성한 프로그램이 실제로 사용되지 않을 것이라는 것을 깨달았습니다.
시스템 성능을 조정하는 데 도움을 주기 위해 Kent Beck에게 연락했습니다. 그는 성능 조정 작업을 수행할 때 끊임없이 마주치는 것과 같은 현상을 우리에게서 발견했습니다. 잘못 설계된 코드, 다시 실행할 수 없는 테스트, 프로젝트에 대한 신뢰를 잃은 관리입니다. Kent Beck은 작성된 모든 코드를 버리고 완전한 XP 프로젝트를 시작할 것을 권장했습니다.
이전 계약은 종료되었고 Chrysler는 개발 팀의 거의 절반을 업데이트했습니다. 그 순간부터 우리는 XP의 규칙에 따라 행동했습니다. 책임이 할당되고, 반복이 계획되고, 테스트 규칙이 설정되고, 페어 프로그래밍이 테스트되고 표준으로 채택되었습니다. 33주가 끝날 무렵, 이미 성능 디버그를 시작하고 병렬 테스트를 수행할 수 있는 시스템이 있었습니다. 시스템이 잘 고려되고 백업되었으므로 성능 조정을 시작할 수 있습니다. 풀세트단위 테스트. 일련의 기능 테스트를 통해 시스템에 필요한 기능이 있음을 고객에게 명확하게 보여주었기 때문에 병렬 테스트를 할 준비가 되었습니다.
C3 구현의 이 단계는 더 빠른 날짜를 예상했지만 1997년 5월에 시작되었습니다. 우리 계획의 실패는 두 가지 요인 때문이었습니다. 먼저 내부 부품만 교체하기로 했습니다. 지불 시스템. 모든 외부 인터페이스는 그대로 유지되었습니다. 일치 출력 새로운 시스템오래된 것의 구성 요소가 훨씬 더 많은 것으로 판명되었습니다. 어려운 과업우리가 예상했던 것보다. 둘째, 우리는 W-2 처리, 이익 공유 또는 일반 인상과 같은 급여 기간 동안 특별한 요구 사항을 시작하지 않기로 결정했습니다. 임금. 그 결과 11월에 했어야 할 일이 4월로 연기됐다.
월별 지불 계산 시스템 출시 이후 몇 가지 새로운 기능과 자동화된 격주 지불 계산을 추가했습니다. 파일럿 그룹의 급여는 1998년 8월부터 계산되었으며 나머지 직원은 1999년 11월까지 작업 시스템을 갖기를 희망합니다.
오랜 개발 기간 동안 얻은 경험을 바탕으로 XP의 원칙에서 벗어날 때만 경영진과 고객의 기대에 부응하지 못했다고 말할 수 있습니다. 개발 과정에서 테스트 과정이 결정적일 때, 코드를 쌍으로 작성했을 때, 가장 단순하고 작동 가능성이 높은 기능이 구현되었을 때 우리는 최고의 팀으로 변모했습니다.
Ford Motor: 효율성과 품질의 독특한 조합
돈 웰스
팀: 12명의 프로그래머를 포함한 17명
신청:비용 분석 시스템
시행 기간: 6 년
Ford Motor Company의 재무 시스템 부서는 생산 수익, 비용, 순이익 및 이익에 대한 보고서를 생성하는 VCAPS(차량 원가 계산 및 이익 시스템) 분석 시스템을 개발합니다. 시스템에 대한 입력은 엔지니어링 제품 사양, 고정 비용 및 비용, 노동 시간과 같은 변동 비용입니다. VCAPS는 이 모든 데이터를 집계하고 효과적인 예측 및 기업 의사 결정을 가능하게 하는 비용 분석과 함께 상세한 보고서를 준비합니다. VCAPS 프로젝트 작업은 1993년에 시작되었습니다. VisualWorks 및 GemStone Smalltalk를 사용하여 개발되었습니다. VCAPS는 현재 소규모 팀에서 유지 관리하고 있으며 곧 보다 현대적인 애플리케이션으로 대체될 예정입니다.
VCAPS 프로젝트를 구현할 때 두 가지 심각한 문제를 해결해야 했습니다. 첫째, 분석가는 이미 작동하는 새로운 기능을 사용하면서 시스템을 변경하기를 원했습니다. 요구 사항은 지속적으로 변경되었고 우리는 그 요구 사항을 따라갈 수 없었습니다. 둘째, 시스템 운영 시간에 일정한 제한이 있었습니다. 동시에 시스템은 데이터를 처리하는 데 많은 시간을 소비했고 긴 시퀀스를 수동으로 입력해야 했습니다. 실수로 인해 다시 시작해야 하고 소중한 시간이 손실되었습니다.
XP의 도움으로 우리는 고유한 기능 조합을 달성했습니다. 끊임없이 변화하는 요구 사항에 신속하게 대응할 수 있었고 위험한 재시작을 피할 수 있는 시스템 품질을 달성할 수 있었습니다.
XP 방법에 대한 작업은 계획 단계에서 시작되었습니다. 그리고 그것은 실수로 밝혀졌습니다. 고객과 경영진은 함께 작업 일정을 조정하는 데 익숙하지 않습니다. 그 결과 발생한 일은 타당성과 실용성의 부족으로 어려움을 겪었습니다. 우리는 총회를 소집하지 않고도 변경할 수 있는 MS 프로젝트 계획으로 전환해야 했고 그 도움으로 경영진에게 익숙한 형태의 계획을 받았습니다.
그런 다음 몇 가지 단위 테스트를 수행했고 1년 후 시스템의 40%가 테스트되었으며 경영진은 오류 메시지 수가 40% 감소했다고 밝혔습니다. 그 후 XP는 세심한 관심을 받았습니다.
새로운 XP 방식을 모두 구현하여 문제를 해결했습니다. 테스트를 통해 지속적인 통합과 잦은 버전 변경으로 이동할 수 있었습니다. 이것은 차례로 시스템의 집합적 소유권과 재설계를 위한 길을 열었습니다. 우리는 간단한 프로젝트를 만드는 것을 목표로 했습니다. 마침내 우리가 쌍으로 프로그래밍을 시도하기로 결정한 순간이 왔습니다. 그리고 우리는 이 성공을 달성하기 위해 열심히 일해야 했습니다. 처음에 우리 개발자들은 이 방법이 매우 불편하다는 것을 알게 되었습니다. 익숙해지고 꽤 편안해지기까지 시간이 좀 걸렸습니다.
1년 반이 지난 후 시스템 장애 횟수가 많이 감소하여 고객과 경영진이 훨씬 더 높은 시스템 안정성을 말할 수 있게 되었습니다. 우리에게 이것은 XP 원칙의 성공을 상징했습니다.
관세 시스템: 읽을 수 있는 테스트
롭 미
팀:세 명의 개발자
신청:운임계산시스템
시행 기간: 3 개월
관세 시스템은 컨테이너 운송을 전문으로 하는 주요 국제 회사 중 하나에서 SmallTalk/GemStone을 사용하여 구현한 대규모 프로젝트의 일부입니다. XP 접근 방식을 사용하면 3명이 3개월 만에 개념에서 시운전까지 이 하위 시스템 개발의 모든 단계를 수행할 수 있습니다. 그 결과 매우 안정적이고 유지 관리가 쉬웠습니다.
프로젝트 작업을 시작하면서 우리는 즉시 몇 가지 사항을 확고히 준수하기로 결정했습니다. 기본 원리들 XP: 항상 쌍으로 코딩하고, 아키텍처를 가능한 한 단순하게 유지하고, 시스템을 적극적으로 재작업하고, 많은 단위 테스트를 작성합니다. 이 모든 원칙은 효과적인 것으로 입증되었습니다. 한 XP 아이디어는 처음에는 실제 코드가 작성되기 전에 코드에 대한 테스트를 작성하는 것이 다소 생소해 보였습니다. 더욱이 이 원칙을 통해 아키텍처 문제를 식별하고 개발 프로세스의 속도를 높일 수 있다는 사실에 놀랐습니다.
처음부터 우리는 또 다른 XP 방식을 사용했습니다. 스토리 형식으로 사용자 요구 사항을 수집하는 것입니다. 결과는 완전히 명확하지 않았습니다. 우리는 프로그래머이고 주로 코딩에 종사하므로 검색 공용어사용자와 함께 하는 것이 우리의 도전이 되었습니다. 문제를 더욱 복잡하게 만들기 위해 우리는 관련성이 있고 모호하지 않은 사용자의 이야기를 원했으며 그렇게 하려면 적극적으로 지원해야 했습니다. 결국 XP에 특별한 역할이 하나 빠졌다는 결론에 도달했습니다. 우리는 사용자와 상호작용하는 것이 주 업무인 사람이 필요했습니다. 분명히 그는 적절한 능력을 가지고 있어야 합니다.
테스트 사례를 만들고 재작업하는 동안 우리는 기본 도메인 개체를 작성하기 위해 특별히 개발된 작은 언어가 매우 유용하다는 것을 깨달았습니다. 덕분에 테스트 코드가 훨씬 더 간결하고 가독성이 높아졌습니다. 또한 테스트를 작성하는 과정에서 개체 인스턴스를 설정하는 방법을 발명하는 데 시간을 낭비하지 않고 10개의 도메인 클래스에 대한 문법을 정의했습니다. 문법은 도메인 객체를 생성하기 위해 생성자가 사용하는 파서를 자동으로 생성합니다. 표준 생성자를 사용하여 개체를 인스턴스화하는 코드는 매우 길고 거의 읽을 수 없으며 테스트 케이스 자체와 거의 유사하지 않습니다.
익스트림 프로그래밍으로 변화 수용, Kent Beck. 컴퓨터, 1999년 10월, pp. 70-77, 허가를 받아 재인쇄됨, Copyright IEEE, 1999, All rights reserved.
익스트림 프로그래밍(XP)은 요구 사항이 불분명하거나 빠르게 변화하는 소프트웨어 제품을 구축하는 중소 규모 개발 팀을 위한 단순화된 소프트웨어 개발 방법론입니다.
XP의 주요 목표는 고객 신뢰 향상 개발 프로세스 개발의 성공에 대한 실제 증거를 제공하여 소프트웨어 제품에 제품 개발 시간의 급격한 감소 . 동시에 XP는 개발 초기 단계에서 버그를 최소화하는 데 중점을 두고 있습니다. 이를 통해 달성 가능 최고 속도완성된 제품을 출시하고 작업의 예측 가능성에 대해 이야기할 수 있습니다. 거의 모든 XP 기술은 소프트웨어 제품의 품질 향상을 목표로 합니다.
원칙 XP
주요 원칙은 다음과 같습니다.
- 반복.개발은 고객과의 적극적인 관계가 있는 상태에서 짧은 반복으로 수행됩니다. 반복은 짧게 제안되며 권장 기간은 2-3주이며 1개월을 넘지 않습니다. 한 번의 반복으로 프로그래머 그룹은 시스템의 여러 기능을 구현해야 하며 각 기능은 사용자 스토리에 설명되어 있습니다. 이 경우 사용자 스토리(UI)는 모듈이 생성되는 기반이 되는 초기 정보입니다. 사용 사례(UT)와 구별됩니다. PI에 대한 설명은 1-2 단락으로 짧지만 PI는 일반적으로 기본 및 대체 흐름과 함께 충분히 자세히 설명되며 모델로 보완됩니다. UI는 시스템 분석가가 설명하는 UI와 달리 XP에서 팀의 일부인 사용자가 직접 작성합니다. XP에서 프로젝트의 입력 데이터에 대한 설명의 형식화 부족은 팀의 전체 구성원으로 개발 프로세스에 고객을 적극적으로 포함함으로써 보상됩니다.
- 솔루션의 단순성.가장 간단한 작업 솔루션이 첫 번째로 채택됩니다. 방법의 극단적인 특성은 다음과 관련이 있습니다. 높은 학위분석의 피상성과 엄격한 일정으로 인한 결정의 위험. 시스템의 주요 기능의 최소 세트는 첫 번째 및 각 후속 반복에서 구현됩니다. 기능은 각 반복에서 확장됩니다.
- 소규모 팀에 의한 집중 개발(10명 이하) 및 페어 프로그래밍(두 프로그래머가 하나의 공통 작업장에서 함께 코드를 작성할 때), 그룹 내 및 그룹 간의 활발한 의사 소통. 이 모든 것은 가능한 한 빨리 문제를 감지하는 것을 목표로 합니다(오류 및 마감 기한 누락 모두). 페어 프로그래밍은 프로젝트 안정화 문제를 해결하는 것을 목표로 합니다. XP 방법론을 사용할 경우 집중적인 작업 일정을 견디지 못한 프로그래머의 이탈로 인해 코드를 잃을 위험이 높습니다. 이 경우 쌍에서 두 번째 프로그래머가 코드의 "상속자" 역할을 합니다. 작업 공간에서 그룹이 분산되는 방식도 중요합니다. XP는 모든 사람이 빠르고 자유롭게 액세스할 수 있는 개방형 작업 공간을 사용합니다.
- 고객 피드백, 대표가 실제로 개발 프로세스에 참여합니다.
- 충분한 용기그리고 위험을 감수하려는 의지.
XP 트릭(연습)
일반적으로 XP는 달성하기 위해 따라야 하는 12가지 규칙(관행) 세트로 특징지어집니다. 좋은 결과. 어떤 관행도 근본적으로 새로운 것은 아니지만 XP에 통합되었습니다.
- 프로세스 계획.전체 개발 팀이 함께 모여 다음 반복에서 시스템의 어떤 기능을 구현할지에 대한 집단적인 결정이 내려집니다. 각 속성 구현의 복잡성은 프로그래머가 직접 결정합니다.
- 고객과의 긴밀한 상호 작용.고객 담당자는 XP 팀의 구성원이어야 합니다. 그는 UI를 작성하고 특정 반복에서 구현될 스토리를 선택하고 비즈니스 관련 질문에 답변합니다. 고객의 대리인은 반드시 전문가 자동화된 주제 영역에서 고객 담당자의 지속적인 피드백이 필요합니다.
- 일반 시스템 명명 규칙.좋은 시스템 명명 규칙 이름 짓기 쉬움 클래스와 변수. 개발 팀은 균일한 명명 규칙을 가져야 합니다.
- 단순한 아키텍처.시스템의 모든 속성은 가능한 한 간단하게 구현되어야 합니다. XP 팀의 프로그래머는 "Nothing more!"라는 모토 아래 작업합니다. 첫 번째 간단한 작업 솔루션이 채택되었으며 현재 필요한 수준의 기능이 구현되고 있습니다. 이것은 프로그래머의 시간을 절약합니다.
- 리팩토링.이는 기존 코드를 단순화하기 위해 최적화한 것으로, 이러한 작업은 지속적으로 수행되어야 합니다. 코드를 투명하게 유지하고 요소를 한 번만 정의함으로써 프로그래머는 나중에 수정해야 하는 버그의 수를 줄일 수 있습니다. 시스템의 각각의 새 속성을 구현할 때 프로그래머는 기존 코드를 단순화할 수 있는지 여부와 이것이 새 속성을 구현하는 데 어떻게 도움이 되는지 고려해야 합니다. 또한 리팩토링과 디자인을 결합할 수 없습니다. 새 코드, 리팩토링을 연기해야 합니다.
- 페어 프로그래밍.모든 프로그래머는 쌍으로 작업해야 합니다. 하나는 코드를 작성하고 다른 하나는 보는 것입니다. 따라서 프로그래머 그룹을 한 곳에 배치할 필요가 있습니다. XP는 분산되지 않은 프로그래머와 사용자 팀에서 가장 잘 작동합니다.
- 주 40시간 근무.프로그래머는 하루에 8시간 이상 일해서는 안 됩니다. 초과 근무의 필요성은 특정 개발 영역의 문제를 나타내는 분명한 지표입니다. 초과 근무의 원인을 찾아 신속하게 제거하는 것이 기본 규칙 중 하나입니다.
- 집단 코드 소유권.팀의 각 프로그래머는 시스템의 모든 부분의 코드에 액세스할 수 있어야 하며 코드를 변경할 수 있는 권한이 있어야 합니다. 필수 규칙: 프로그래머가 변경한 후 시스템이 올바르게 작동하지 않으면 오류를 수정해야 하는 사람은 이 프로그래머입니다.
- 통일된 코딩 표준.코드 공유, 페어 프로그래밍 및 리팩토링과 같은 다른 관행을 지원하려면 코딩 표준이 필요합니다. 단일 표준이 없으면 이러한 관행을 수행하는 것이 적어도 더 어렵지만 실제로는 일반적으로 불가능합니다. 그룹은 지속적으로 시간이 부족한 방식으로 작업합니다. 팀은 오랫동안 프로젝트를 진행해 왔습니다. 사람들이 왔다가 갑니다. 아무도 혼자 코드를 작성하지 않으며 코드는 모두의 것입니다. 다른 사람의 코드를 이해하고 수정해야 하는 순간은 항상 있을 것입니다. 개발자는 중복 코드를 제거하고 다른 사람의 클래스를 분석 및 개선하는 등의 작업을 수행하며 시간이 지남에 따라 특정 클래스의 작성자가 누구인지 알 수 없게 됩니다. 따라서 모든 사람은 코드 형식, 클래스 이름, 변수, 상수 이름, 주석 스타일과 같은 공통 코딩 표준을 준수해야 합니다. 위의 내용은 모든 팀 구성원이 공통 코딩 표준에 동의해야 함을 의미합니다. 무슨 일이 있어도, 모든 사람은 그것들에 복종할 의무가 있습니다.
- 작은 릴리스.최소 반복은 하루이고 최대 반복은 한 달입니다. 릴리스가 더 자주 만들어질수록 시스템의 더 많은 결함이 드러날 것입니다. 첫 번째 릴리스는 초기 단계에서 결함을 식별하는 데 도움이되며 UI를 기반으로 시스템 기능이 확장됩니다. 사용자는 첫 번째 릴리스부터 개발 프로세스에 포함되기 때문에 시스템을 평가하고 사용자 스토리와 댓글을 발행합니다. 이를 기반으로 다음 반복, 즉 새 릴리스가 무엇인지 결정됩니다. XP의 모든 것은 사용자에게 지속적인 피드백을 제공하는 것입니다.
- 지속적인 통합.시스템의 새로운 부분 통합은 최소한 몇 시간에 한 번 가능한 한 자주 발생해야 합니다. 통합의 기본 규칙은 다음과 같습니다. 모든 테스트가 성공적으로 통과하면 통합을 수행할 수 있습니다. 테스트가 통과하지 못하면 프로그래머는 수정한 다음 시스템의 구성 요소를 통합하거나 전혀 통합하지 않아야 합니다. 이 규칙은 엄격하고 모호하지 않습니다. 시스템의 생성된 부분에 하나 이상의 오류가 있으면 통합을 수행할 수 없습니다. 빈번한 통합을 통해 조립에 일주일을 소비하는 대신 기성 시스템을 더 빨리 얻을 수 있습니다.
- 테스트.대부분의 다른 방법론과 달리 XP에서의 테스트는 가장 중요한 구성 요소 중 하나입니다. 극단적인 접근 방식은 다음과 같이 가정합니다. 테스트는 코드가 작성되기 전에 작성됩니다. . 각 모듈에는 이 모듈에 대한 테스트인 단위 테스트가 있어야 합니다. 따라서 XP는 기능을 추가할 때 "품질이 저하되지 않는" 회귀 테스트를 수행합니다. 대부분의 오류는 코딩 단계에서 수정됩니다. 테스트는 프로그래머가 직접 작성하며 그 중 누구라도 모든 모듈에 대한 테스트를 작성할 권리가 있습니다. 또 다른 중요한 원칙: 테스트는 코드를 결정하고 그 반대는 아닙니다(테스트 주도 개발). 즉, 모든 테스트가 성공적으로 통과한 경우에만 코드 조각이 리포지토리에 배치되고 그렇지 않으면 이 코드 변경이 거부됩니다.
XP 프로세스는 비공식적이지만 높은 수준의 자기 훈련이 필요합니다. 이 규칙을 따르지 않으면 XP는 즉시 혼란스럽고 통제되지 않는 프로세스로 바뀝니다. XP는 프로그래머가 많은 보고서를 작성하고 많은 모델을 구축할 것을 요구하지 않습니다. XP에서 모든 프로그래머는 전문적이고 자신의 의무를 책임지는 숙련된 작업자로 간주됩니다. 팀에 이것이 없으면 XP를 구현하는 것이 절대적으로 무의미합니다. 팀 재건을 시작하는 것이 좋습니다. XP에 이상적으로 적합한 팀에서만 개발 위험이 감소합니다. 다른 모든 경우에는 XP가 가장 높은 수준의 위험을 가진 개발 프로세스입니다. XP.
다른 사람.
방법론의 이름은 유용한 전통적인 방법새로운 "극단적인" 수준으로 끌어올리는 소프트웨어 개발 관행. 예를 들어, "익스트림" 버전에서 한 프로그래머가 다른 프로그래머가 작성한 코드를 확인하는 것으로 구성된 코드 수정을 수행하는 관행은 한 프로그래머가 코딩하고 그의 파트너가 동시에 새로 작성된 코드를 지속적으로 검토합니다.
백과사전 YouTube
1 / 5
익스트림 프로그래밍(XP) - 기본 기술
Hexlet 웨비나 #6: 익스트림 프로그래밍
인생 팁. 프로그래밍 대회에 참가하는 이유는 무엇입니까?
032. 페어 프로그래밍 - Sergey Berezhnoy
익스트림 프로그래밍 채널 v. 2.0
자막
XP 기본 트릭
익스트림 프로그래밍의 12가지 기본 기술(책 초판에 따름) 익스트림 프로그래밍 설명)는 네 그룹으로 그룹화할 수 있습니다.
- 짧은 피드백 주기(미세한 피드백)
- 테스트를 통한 개발(테스트 주도 개발)
- 기획 게임
- 고객은 항상 거기에 있습니다(전체 팀, 현장 고객)
- 페어 프로그래밍
- 일괄 처리가 아닌 연속 처리
- 지속적인 통합
- 리팩토링(디자인 개선, 리팩토링)
- 빈번한 소규모 릴리스
- 모두가 공유하는 이해
- 간단
- 시스템 은유
- 집합적 코드 소유권 또는 선택된 디자인 패턴(집단적 패턴 소유권)
- 코딩 표준 또는 코딩 규칙
- 프로그래머의 사회 보장(프로그래머 복지):
- 주 40시간 근무(지속 가능한 속도, 주 40시간)
테스트
XP는 자동화된 테스트(다른 시스템의 로직을 테스트하기 위해 특별히 작성된 프로그램 코드) 작성을 포함합니다. 프로그램 코드). 두 가지 유형의 테스트에 특히 주의를 기울입니다.
- 모듈의 단위 테스트;
개발자는 자신이 개발하는 시스템의 모든 단위 테스트가 작동할 때까지 자신이 작성한 코드의 정확성을 확신할 수 없습니다. 단위 테스트(단위 테스트)를 통해 개발자는 각 테스트가 개별적으로 올바르게 작동하는지 확인할 수 있습니다. 또한 다른 개발자가 특정 코드 조각이 필요한 이유와 작동 방식을 이해하는 데 도움이 됩니다. 테스트 코드를 연구하는 과정에서 테스트 중인 코드의 논리가 명확해지기 때문에 사용 방법이 명확해집니다. 또한 단위 테스트를 통해 개발자는 두려움 없이 리팩토링할 수 있습니다.
기능 테스트는 여러 부분(종종 꽤 인상적인 크기)의 상호 작용에 의해 형성된 논리의 기능을 테스트하도록 설계되었습니다. 그것들은 단위 테스트보다 덜 상세하지만 훨씬 더 많은 것을 다루고 있습니다. 이러한 이유로 산업 프로그래밍에서는 기능 테스트를 작성하는 것이 단위 테스트를 작성하는 것보다 우선시되는 경우가 많습니다.
XP의 경우 TDD(영어 테스트 주도 개발 - 개발에서 테스트까지)라는 접근 방식이 더 높은 우선 순위입니다. 이 접근 방식에 따르면 처음에 실패한 테스트가 먼저 작성되고(단지 확인해야 하는 로직이 아직 존재하지 않기 때문에) 테스트가 통과하는 데 필요한 로직이 구현됩니다. 어떤 의미에서는 TDD를 사용하면 더 사용하기 편리한 코드를 작성할 수 있습니다. 테스트를 작성할 때 아직 논리가 없을 때 미래 시스템의 편의를 가장 쉽게 처리할 수 있기 때문입니다.
기획 게임
계획 게임의 주요 목표는 대략적인 작업 계획을 신속하게 작성하고 작업 조건이 명확해지면 지속적으로 업데이트하는 것입니다. 계획 게임의 인공물은 고객의 소원(고객 이야기)이 포함된 종이 카드 세트와 제품의 다음 하나 이상의 작은 버전 출시를 위한 대략적인 작업 계획입니다. 이 계획 스타일을 효과적으로 만드는 중요한 요소는 이 경우 고객이 비즈니스 결정을 내리고 개발 팀이 기술 결정을 내릴 책임이 있다는 것입니다. 이 규칙을 따르지 않으면 전체 프로세스가 무너집니다.
고객은 항상 거기에 있습니다
XP에서 "고객"은 요금을 지불하는 사람이 아니라 소프트웨어 제품의 최종 사용자입니다. XP는 고객이 항상 연락하고 질문할 수 있어야 한다고 주장합니다.
페어 프로그래밍
페어 프로그래밍모든 코드는 동일한 컴퓨터에서 작업하는 프로그래머 쌍에 의해 생성된다고 가정합니다. 그들 중 하나는 프로그램의 텍스트와 직접 작업하고, 다른 하나는 그의 작업을 보고 무슨 일이 일어나고 있는지에 대한 전반적인 그림을 따릅니다. 필요한 경우 키보드가 서로 자유롭게 전송됩니다. 프로젝트에서 작업하는 동안 쌍은 고정되지 않습니다. 팀의 각 프로그래머가 전체 시스템에 대해 잘 알 수 있도록 혼합하는 것이 좋습니다. 이러한 방식으로 페어 프로그래밍은 팀 내 상호 작용을 향상시킵니다.
지속적인 통합
개발 중인 시스템을 충분히 자주 통합하면 이와 관련된 대부분의 문제를 피할 수 있습니다. 전통적인 방법에서는 일반적으로 개발 중인 시스템의 모든 구성 요소가 완전히 준비된 것으로 간주되는 제품 작업의 맨 마지막에 통합이 수행됩니다. XP에서 전체 시스템의 코드 통합은 개발자가 모든 단위 테스트가 올바르게 작동하는지 확인한 후 하루에 여러 번 수행됩니다.
리팩토링
리팩토링은 기능을 변경하지 않고 코드를 개선하는 기술입니다. XP는 코드가 일단 작성되면 프로젝트 과정에서 거의 확실히 여러 번 다시 작성될 것임을 의미합니다. XP 개발자들은 개선하기 위해 이전에 작성된 코드를 무자비하게 재작업하고 있습니다. 이 프로세스를 리팩토링이라고 합니다. 테스트 커버리지의 부족은 시스템 파괴에 대한 두려움으로 인해 리팩토링 거부를 유발하며, 이는 코드의 점진적인 저하로 이어집니다.
빈번한 소규모 릴리스
제품의 버전(릴리스)은 가능한 한 자주 프로덕션에 들어가야 합니다. 각 버전에 대한 작업은 가능한 한 적은 시간이 소요됩니다. 동시에 각 버전은 비즈니스에 대한 유용성 측면에서 충분히 의미가 있어야 합니다.
제품의 첫 번째 작업 버전이 일찍 출시될수록 고객은 이로 인해 추가 이익을 받기 시작합니다. 오늘 번 돈이 내일 번 돈보다 더 가치 있음을 기억하십시오. 고객이 제품을 더 빨리 사용하기 시작할수록 개발자는 고객의 요구 사항을 충족하는 것에 대한 정보를 더 빨리 받게 됩니다. 이 정보는 다음 릴리스를 계획할 때 매우 유용할 수 있습니다.
설계 용이성
XP는 작업 과정에서 문제의 조건이 반복적으로 변경될 수 있다는 사실에서 출발합니다. 작업 초기에 시스템을 자세히 설계하려고 하는 것은 시간 낭비입니다. XP는 디자인이 프로젝트의 수명 동안 지속적으로 수행되어야 하는 매우 중요한 프로세스라고 제안합니다. 디자인은 끊임없이 변화하는 요구 사항을 고려하여 작은 단계로 수행되어야 합니다. 각 시점에서 현재 문제에 가장 적합한 가장 단순한 디자인을 사용하고 문제의 조건이 변경됨에 따라 변경해야 합니다.
시스템 은유
아키텍처는 시스템의 구성 요소와 그 상호 관계를 나타냅니다. 개발자는 시스템에서 새 기능을 추가해야 하는 위치와 새 구성 요소가 상호 작용할 대상을 이해하기 위해 소프트웨어 아키텍처를 분석해야 합니다.
시스템 은유는 대부분의 기술이 아키텍처라고 부르는 것과 유사합니다. 시스템 은유는 팀에게 현재 시스템이 어떻게 작동하는지, 어디에 새로운 구성 요소가 추가되는지, 어떤 형태를 취해야 하는지에 대한 아이디어를 제공합니다.
좋은 비유를 선택하면 개발 팀이 시스템 작동 방식을 더 쉽게 이해할 수 있습니다. 때로는 이것이 쉽지 않습니다.
인코딩 표준
모든 팀 구성원은 작업 과정에서 공통 코딩 표준의 요구 사항을 준수해야 합니다. 그것에 의하여:
- 팀 구성원은 실제로 프로젝트의 작업 속도에 영향을 미치지 않는 것들에 대해 논쟁하는 데 시간을 낭비하지 않습니다.
- 다른 관행의 효과적인 구현이 보장됩니다.
팀이 균일한 코딩 표준을 사용하지 않으면 개발자가 리팩토링하기가 더 어려워집니다. 파트너를 쌍으로 변경할 때 더 많은 어려움이 있습니다. 일반적으로 프로젝트의 진행이 어렵습니다. XP의 프레임워크 내에서 이 코드 또는 저 코드의 작성자가 누구인지 이해하기 어려운지 확인하는 것이 필요합니다. 전체 팀이 한 사람처럼 통일된 방식으로 작업합니다. 팀은 일련의 규칙을 형성해야 하며, 각 팀 구성원은 코딩 과정에서 이러한 규칙을 따라야 합니다. 규칙 목록은 완전하거나 너무 방대해서는 안 됩니다. 작업은 각 팀 구성원이 코드를 이해할 수 있도록 일반 지침을 공식화하는 것입니다. 코딩 표준은 처음에는 단순해야 하지만 개발 팀이 경험을 쌓으면서 점차 복잡해질 수 있습니다. 표준을 미리 작성하는 데 너무 많은 시간을 할애할 필요가 없습니다.
집단 소유권
집단 소유권각 팀 구성원이 모든 소스 코드에 대한 책임이 있음을 의미합니다. 따라서 모든 사람은 프로그램의 모든 부분을 변경할 권리가 있습니다. 페어 프로그래밍은 이 방법을 지원합니다. 서로 다른 페어로 작업하면 모든 프로그래머가 시스템 코드의 모든 부분에 익숙해집니다. 공동 코드 소유권의 중요한 이점은 버그가 발생하면 모든 프로그래머가 수정할 수 있기 때문에 개발 프로세스의 속도가 빨라진다는 것입니다.