게임 계획
XP 계획의 주소는 다음과 같은 두 가지 주요 질문에서 소프트웨어 개발:예측하는 것입니다 무엇에 의해 달성될 때문에 날짜,그리고 무엇을 결정하여 다음에 수행 할 수 있습니다. 강조는 스티어링 프로젝트는 아주 간단합니다–보다 정확한 예측에 무엇이 필요한 것입니다 얼마나 오래 걸리는 것은 매우 어렵습니다., 두 가지 중요한 계획 단계에서 XP,소 이러한 두 가지 질문:
릴리스 계획은 고객이 제공하여 원하는 기능을 프로그래머,프로그래머 추정들이 어려움이 있다. 비용 견적을 손에 들고 기능의 중요성에 대한 지식을 통해 고객은 프로젝트에 대한 계획을 수립합니다. 초기 출시 계획은 반드시 정확하지 않도의 우선 순위나 추정은 진정으로,고체고 팀을 시작하는 일,우리는 알 수 없는 것이 얼마나 빠르고 그들은 갈 것입니다., 그러나 첫 번째 릴리스 계획조차도 의사 결정에 충분히 정확하며 XP 팀은 정기적으로 릴리스 계획을 수정합니다.
반복 계획은 팀이 몇 주마다 방향을 제시하는 연습입니다. XP 팀은 2 주간의”반복”으로 소프트웨어를 구축하여 각 반복이 끝날 때 유용한 소프트웨어를 실행합니다. 반복 계획 중에 고객은 다음 2 주 동안 원하는 기능을 제공합니다. 프로그래머는이를 작업으로 분해하고 비용을 추정합니다(릴리스 계획보다 세부적인 수준)., 이전 반복에서 수행 한 작업의 양을 기반으로 팀은 현재 반복에서 수행 할 작업에 가입합니다.
이러한 계획 단계는 매우 간단하다,그러나 그들은 아주 좋은 정보와 우수한 스티어링 제어의 손에 있습니다. 몇 주마다 진행량이 완전히 보입니다. XP 에는”90%완료”가 없습니다:장편 이야기가 완료되었거나 그렇지 않았습니다., 이에 초점을 표시한 결과에서 좋은 작은 역설에 하나가 손으로 너무 많은 가시성,고객의 위치에 취소하는 경우에 프로젝트를 진행하는 것으로는 충분하지 않습니다. 다른 한편으로,진행 상황은 그렇게 눈에 보이는,그리고 결정하는 능력을 할 것입니다 다음은 이렇게 완료,XP 프로젝트는 경향이 있는 더 이상의 필요한 것은,적은 압력과 스트레스입니다.
고객험
의 일부로 제시를 원하는 각 기능,XP 에서는 고객이 정의 하나 이상의 자동화된 승인 테스트를 표시하는 기능이 작동하는 것입니다., 팀은 이러한 테스트를 빌드하고이를 사용하여 자신과 고객에게 기능이 올바르게 구현되었음을 증명합니다. 시간의 압박에서 수동 테스트를 건너 뛰기 때문에 자동화가 중요합니다. 그것은 밤이 가장 어두워지면 조명을 끄는 것과 같습니다.
최 XP 팀들이 자신의 고객을 테스트와 동일한 방식으로 프로그래머 테스트:일단 테스트 실행 팀을 유지하는 올바르게 실행되고 있습니다. 이것은 시스템이 향상 될 뿐이며,항상 앞으로 노치되고,백 슬리딩되지 않는다는 것을 의미합니다.,
작은 자료
XP 팀은 작은 연습 릴리스의 두 개의 중요한 방법:
첫째,팀 릴리스행,테스트 소프트웨어,비즈니스 가치를 전달하는 데에 의해 선택,고객마다 반복합니다. 고객이 소프트웨어를 사용할 수 있습니다 어떤 목적을 위해,는지 여부를 평가 또는 출시하여 최종 사용자는(권장). 가장 중요한 측면은 모든 반복이 끝날 때 소프트웨어가 눈에 보이고 고객에게 주어진다는 것입니다. 이것은 모든 것을 개방적이고 가시적으로 유지합니다.
둘째,XP 팀은 최종 사용자에게 자주 출시됩니다., XP 웹 프로젝트는 매월 또는 더 자주 집 프로젝트에서 매일 자주 출시됩니다. 수축 포장 된 제품조차도 분기별로 자주 배송됩니다.
이 자주 좋은 버전을 만드는 것은 불가능한 것처럼 보일 수 있지만 XP 팀은 항상 그것을하고 있습니다. 보 연속 통합에 대해 더 자세히 알고,그리고 이러한 잦은 자료 보관에 의해 신뢰할 수 있는 XP 에서의 강박 관념을 테스트,여기에 설명된 대로 고객에 검사 및 테스트 기반의 개발이다.
심플한 디자인
XP 팀은 간단하지만 항상 적절한 디자인으로 소프트웨어를 구축합니다., 그들은 간단하게 시작하고 프로그래머 테스트와 디자인 개선을 통해 그런 식으로 유지합니다. XP 팀은 시스템의 현재 기능에 정확히 적합한 디자인을 유지합니다. 낭비되는 움직임이 없으며 소프트웨어는 항상 다음에 무엇을 할 준비가되어 있습니다.
XP 의 디자인은 일회성 일이나 앞선 일이 아니라 항상 그렇습니다. 거기 디자인 단계에서의 방출을 계획하고 반복 계획,플러스 팀에 참여 빠른 디자인이션 디자인의 개정을 통해 리팩터링의 과정을 통해 전체 프로젝트입니다., 익스트림 프로그래밍과 같은 증분 반복 프로세스에서는 좋은 디자인이 필수적입니다. 전체 개발 과정에서 디자인에 너무 많은 초점이있는 이유입니다.
쌍 프로그래밍
XP 의 모든 프로덕션 소프트웨어는 동일한 시스템에서 나란히 앉아있는 두 명의 프로그래머가 제작합니다. 이 실습은 모든 생산 코드를 검토하여 적어도 하나의 다른 프로그래머 및 결과에서 더 나은 디자인,더 나은 테스트,그리고 더 나은 코드입니다.
두 명의 프로그래머가”한 프로그래머의 일”을하는 것이 비효율적 인 것처럼 보일 수 있지만 그 반대는 사실입니다., 연구 페어 프로그래밍을 보여줍 페어링이 더 나은 코드에 대해 동일한 시간으로 프로그래머 작업으로 이루어집니다. 맞습니다:두 개의 머리가 실제로 하나보다 낫습니다!
일부 프로그래머는 시도하지 않고 프로그래밍을 페어링하는 것을 반대합니다. 그것은 잘 할 몇 가지 연습을해야합니까,당신은 결과를보기 위해 몇 주 동안 그것을 잘해야합니다. 페어 프로그래밍을 배우는 프로그래머의 90%가 그것을 선호하므로 모든 팀에게 적극 권장합니다.
페어링은 더 나은 코드와 테스트를 제공하는 것 외에도 팀 전체에 지식을 전달하는 역할을합니다., 쌍이 전환됨에 따라 모든 사람이 모든 사람의 전문 지식의 이점을 얻습니다. 프로그래머는 배우고,기술은 향상되며,팀과 회사에 더 가치있게됩니다. XP 밖에서도 자체적으로 페어링은 모든 사람에게 큰 승리입니다.
테스트 기반의 개발
극단적인 프로그래밍 집착하는 의견,그리고 소프트웨어 개발에 좋은 의견을 필요로 테스트합니다. 최고 XP 팀은”테스트 중심 개발”을 연습하여 테스트를 추가 한 다음 작동시키는 매우 짧은 주기로 작업합니다., 거의 손쉽게 팀은 거의 100%의 테스트 커버리지를 가진 코드를 생산하며,이는 대부분의 상점에서 훌륭한 진전입니다. (프로그래머가 이미 더 정교한 테스트를하고 있다면,당신에게 더 많은 힘을 실어줍니다. 그것을 유지,그것은 단지 도움이 될 수 있습니다!테스트를 작성하는 것만으로는 충분하지 않습니다. 여기에서도 극단적 인 프로그래밍이 극단적입니다. 이들은”프로그래머 테스트”또는””단위 테스트는 모두 함께 수집,그리고 모든 시간이 어떤 프로그래머 릴리스 코드를 저장소(과 쌍으로 해제 하루에 두 번 이상),모든 하나 하나의 프로그래머 테스트는 올바르게 실행해야 합니다., 백퍼센트,모든 시간! 이것은 프로그래머가 그들이 어떻게하고 있는지에 대한 즉각적인 피드백을 얻는다는 것을 의미합니다. 또한 이러한 테스트는 소프트웨어 설계가 개선됨에 따라 귀중한 지원을 제공합니다.
디자인 개선(리팩토링)
익스트림 프로그래밍은 모든 반복에서 비즈니스 가치를 제공하는 데 중점을 둡니다. 전체 프로젝트의 과정을 통해이를 수행하려면 소프트웨어가 잘 설계되어야합니다. 대안은 속도를 늦추고 궁극적으로 막히는 것입니다., 그래서 XP 는 Martin Fowler 의 저서”리팩토링:기존 코드의 디자인 개선”의 제목에서 리팩토링이라는 지속적인 디자인 개선 프로세스를 사용합니다.
이터베이스 프로세스에 초점을 맞추고 제거에 복제(의 확실한 표시 가난한 디자인),및에서 증가하는 응집””의 코드,을 줄이는 동시에”연결”. 높은 응집력과 낮은 커플 링은 적어도 30 년 동안 잘 설계된 코드의 특징으로 인식되어 왔습니다. 그 결과 XP 팀은 훌륭하고 단순한 디자인으로 시작하여 항상 소프트웨어에 대해 훌륭하고 단순한 디자인을 갖게됩니다., 이를 통해 개발 속도를 유지할 수 있으며 실제로 프로젝트가 진행됨에 따라 일반적으로 속도를 높일 수 있습니다.물론 리팩토링은 디자인이 발전함에 따라 아무 것도 깨지지 않는다는 것을 확신하기 위해 포괄적 인 테스트를 강력하게 지원합니다. 따라서 고객 테스트 및 프로그래머 테스트는 중요한 활성화 요소입니다. XP 의 관행은 서로를 지원:그들은 별도로보다 함께 강하다.
지속적인 통합
극단적인 프로그래밍 팀을 유지하는 시스템을 완벽하게 통합합니다. 우리는 매일 빌드가 겁쟁이를위한 것이라고 말합니다:XP 팀은 하루에 여러 번 빌드합니다., (40 명으로 구성된 XP 팀 1 명이 하루에 8~10 번 이상 빌드합니다!)
의 혜택이 연습으로 볼 수있는 생각에 프로젝트에 대해 들어 있을 수 있습니다(심지어는 부분)를 빌드 프로세스는 매주이거나 적은 자주,그리고 일반적으로 주도하”통합 지옥”모든 것을 끊었지 아무도 알지 못하는 이유.
드문 통합으로 인해 소프트웨어 프로젝트에 심각한 문제가 발생합니다., 첫째,하지만 통합 중요한 운송 좋은 작동 코드,팀은 실행되지 않기에 그것은,그리고 그것은 종종 위임받은 사람들에 익숙하지 않은 전체 시스템입니다. 둘째,드물게 통합 된 코드는 종종-일반적으로 버그가있는 코드라고 말할 것입니다. 문제는 통합되지 않은 시스템에서 발생하는 테스트 중 하나에 의해 감지되지 않는 통합 시간에 크리프. 셋째,약한 통합 프로세스로 인해 긴 코드가 정지됩니다., 코드 정지 의미 있는 시간이 오래 기간의 프로그래머가 될 수 있는 작업에 중요한 휴대기능지만,그 기능을 갖추고 있어야 합니 다시 개최합니다. 이는 시장에서의 위치 또는 최종 사용자와의 위치를 약화시킵니다.
단체 코드를 소유권
에 극단적인 프로그래밍 프로젝트의 모든 쌍의 프로그래머의 개선할 수 있는 모든 코드에서 어떤 시간입니다. 즉,모든 코드가 많은 사람들의 관심의 이점을 얻으므로 코드 품질이 향상되고 결함이 줄어 듭니다., 거기에 또 다른 중요한 이익뿐만 아니라:이 코드는 개인에 의해 소유,필요 기능은 자주 잘못된 장소 중 하나로 프로그래머는 그가 필요로 하는 기능 코드에서 어딘가에 그가 소유하지 않는. 소유자가 너무 바빠서 프로그래머가 속하지 않는 곳에 기능을 자신의 코드에 넣습니다. 이로 인해 중복으로 가득 차고 낮은(나쁜)응집력으로 추악하고 유지 보수가 어려운 코드가 생깁니다.
집단 소유권은 사람들이 이해하지 못하는 코드에 대해 맹목적으로 작업 한 경우 문제가 될 수 있습니다., XP 을 통해 이러한 문제를 방지 두 가지 주요 기술:프로그래머 테스트를 실수를 잡을,그리고 쌍 프로그래밍을 의미하는 것이 최선의 방법에 익숙하지 않은 코드를 가진 전문가입니다. 필요할 때 좋은 수정을 보장하는 것 외에도,이 연습은 팀 전체에 지식을 전파합니다.
코딩 표준
XP 팀에 따라 일반적인 코딩 표준,그래서 그는 모든 코드 시스템에서처럼 보이는 경우가에 의해 작성된 단일–매우 유능한–개인합니다., 의 구체적인 표준은 중요하지 않다:중요한 것은 모든 코드 보이는 익숙한 지원이 집단의 소유입니다.
유
극단적인 프로그래밍 팀이 개발한 일반적인 시각의 프로그램이 어떻게 작동하는 우리가”유”. 최고의 비유는 간단시켜주는 방법에 대한 설명 프로그램과 같이 작동하는”이 프로그램은 다음과 같 hive,꿀벌의 대한 꽃가루와 그것을 가져 다시 하이브”에 대한 설명으로 에이전트 기반 정보검색 시스템입니다.
때로는 충분히 시적인 은유가 발생하지 않습니다., 어떤 경우에,함께 또는없이 생생한 이미지,XP 팀을 사용하여 공통 시스템의 이름을 확실히 다른 사람에 의해 발생된 문제로 인해 시스템이 어떻게 작동하고 있는 곳을 찾아보세요 당신이 당신을 찾는,또는 적절한 장소를 찾을 넣어 당신이 당신에 대한 추가 할 수 있습니다.
지속 가능한 속도
익스트림 프로그래밍 팀이 장기적으로 그 안에 있습니다. 그들은 열심히,그리고 무한정 지속될 수있는 속도로 일합니다. 이 의미는 그들이 초과 작업을 때 효과적이,그리고 그들은 정상적으로 작동과 같은 방법으로 생산성을 극대화하는 주와 주니다., 요즘 데스 행진 프로젝트가 생산적이거나 양질의 소프트웨어를 생산하지 않는다는 것은 꽤 잘 이해되고 있습니다. XP 팀은 죽지 않고 승리하기 위해 그 안에 있습니다.
결론
극단적인 프로그래밍은 분야 소프트웨어 개발의 값을 기준으로 단순,통신,의견,그리고 용기입니다. 그것은 작품을 가져 팀 전체의 존재에 함께 간단한 방법으로,충분한 피드백을 사용하여 어디에 있는지 그리고 조정하는 실천하는 그들의 독특한 상황이다.피>