익스트림 프로그래밍이란? XP 규칙 및 값의 개요
다시 1990 년대에,인터넷의 부상은 소프트웨어 개발의 변화를 필요로했다. 는 경우에 회사의 성공에 의존하는 속도는 회사 성장할 수 있는 시장에 제품을 가지고,기업에 필요한 극적으로 줄여 소프트웨어 개발 라이프 사이클.,
그것은 이러한 환경에서는 켄트 벡 만든 극단적인 프로그래밍(XP),민첩한 프로젝트 관리 방법을 지원하는 자주 출시에는 짧은 개발 주기를 개선하는 소프트웨어 품질 및 개발자에 대응하는 변화하는 고객의 요구 사항입니다.
할 수 있지만 인식하는 몇 가지의 이러한 관행과 값을 다른 프로젝트 관리 방법론,XP 에서는 이러한 모범 사례를”극단적인”수준,방법론으로의 이름을 제안합니다., 와의 인터뷰에서 Informit,Kent 설명합니다:
“처음 요청을 받았는 팀에,나는 그들을 약간의 일을 생각이었다 합리적처럼,테스트 및 리뷰가 없습니다. 두 번째로 라인에 더 많은 것이있었습니다. 전…팀원들에게 필수적이라고 생각했던 것들에 대해 모든 노브를 10 으로 크랭크업하고 그 밖의 모든 것을 버리라고 요청했습니다.”
경우 당신과 당신의 팀에 필요한 빠르게 출시하고 고객의 요청에 응답을 살펴 값과 규칙의 극단적인 프로그래밍—될 수 있습니다.,
값의 극단적인 프로그래밍방법론
XP 는 이상의 시리즈 단계 프로젝트 관리—그것은 다음과 같이 설정된 값의 도움이 될 것입니다 당신의 팀이 작업을 빠르고 효과적으로 더 많은 협력.
단순성
팀은 요구 된 것을 달성하고 그 이상은 없습니다. XP 는 주요 프로세스의 각 단계를 팀 구성원이 달성 할 수있는 더 작고 달성 가능한 목표로 나눕니다.,
간소화된 통신
팀에서 함께 작업의 모든 부분에서 프로젝트 모 요구사항을 구현하는 코드,참여와에서 매일 서 있는 모임을 유지하는 모든 팀 구성원이 업데이트됩니다. 모든 우려 사항이나 문제는 즉시 해결됩니다.
일관되고 건설적인 피드백
XP 에서는 팀이 다른 방법이 아닌 프로젝트 및 고객 요구에 맞게 프로세스를 조정합니다. 팀은 고객으로부터 피드백을 수집하고 필요한 변경을 할 수 있도록 소프트웨어를 일찍 그리고 자주 시연해야합니다.,
존중
극단적인 프로그램을 장려하는”모든 하나 하나에 대한 모든”정신입니다. 계층 구조에 관계없이 팀의 각 사람은 자신의 공헌에 대해 존중받습니다. 팀은 고객의 의견을 존중하며 그 반대도 마찬가지입니다.
용기
팀 구성원이 변화에 적응하고 발생에 대한 책임을 져야 한다. 그들은 진실을 말해에 대해 그들의 진전이”하얀 거짓말”이나 실패를 위해 변명하는 사람들이 기분이 좋습니다. 아무도 혼자 일하지 않기 때문에 두려워 할 이유가 없습니다.,
규칙의 극단적인 프로그래밍방법론
Don Wells 게시 첫 번째 XP 에서는 규칙에서는 1999 년을 카운터는 클레임 극단적인 프로그래밍을 지원하지 않는 활동에 필요한 소프트웨어 개발,기획,관리,및 디자인. 계획에서 소프트웨어 테스트에 이르기까지 각 반복마다 다음 기본 단계를 따르십시오.
기획
이 단계는 UX 마법 발생합니다., 보다 긴 요구 사항을 문서,고객이 기록한 사용자의 이야기,을 정의하는 기능 고객이보고 싶은 함께 기업가치와의 우선 순위는 각각의 특징이다. 사용자 이야기 할 필요가 없 철저 또는 기술 지나치게만 필요를 제공하는 충분한 정보를 팀에 도움이되는 결정하는 방법을 오래 걸리를 구현하는 기능.
Lucidchart 를 사용하면 고객은 기본 순서도를 작성하고 원하는 기능을 쉽게 기록하고 공유 할 수 있습니다.,거기에서 팀은 릴리스 일정을 만들고 프로젝트를 반복(1~3 주 길이)으로 나눕니다. 프로젝트 관리자는 팀과 일정을 공유하기 위해 타임 라인 또는 단순화 된 간트 차트를 만들고 싶을 수 있습니다.
관리하기
이 단계에서 프로젝트 관리자가 설정을 성공에서는 이 방법입니다. 모든 사람이 공동으로 작업하고 효과적으로 모든 슬립 업을 피하기 위해 의사 소통을해야합니다. 이 단계에는 다음이 포함됩니다.
- 팀을위한 열린 작업 공간 만들기
- 지속 가능한 속도 설정(예:, 을 결정하는 올바른 길이에 대한 반복)
- 스케줄링 일간 회의 회의
- 측정 프로젝트 속도(양의 작업을 이루어지고 있는지에서 귀하의 프로젝트)
- 재할당하는 작업을 피해 병목 현상이나 지식 손실
- 규칙을 변경하는 경우 XP 에서 작동하지 않는 완벽하의 팀을 위해
설계
이 규칙을 값의 단순함으로 시작하는 가장 간단한 디자인 때문에 그것은 더 적은 시간이 걸릴 것입을 완료하는 보다 복잡한 솔루션입니다. 기능을 일찍 추가하지 마십시오. 코드를 깨끗하고 간결하게 유지하기 위해 자주 리팩토링하십시오., 그들이 뒤에 팀을 넣어 전에 잠재적 인 문제에 대한 솔루션을 탐구하는 스파이크 솔루션을 만듭니다.
Kent Beck 과 Ward Cunningham 은 또한 XP 방법론의 일부로 사용할 CRC(class-responsibility-collaboration)카드를 만들었습니다. 이 카드를 사용하면 전체 프로젝트 팀이 시스템을 설계하고 객체가 상호 작용하는 방식을 볼 수 있습니다. 당신이 자신을 위해이 브레인 스토밍 도구를 시도하려는 경우,우리의 Lucidchart 템플릿을 시작합니다.,
코딩
그 시간을 마지막으로 온를 구현하는 코드입니다. XP 사례는 단체 코드를 소유권:모든 리뷰 코드 및 개발할 수 있는 기능을 추가,수정,버그 또는 리팩터링. 집단 코드 소유권이 작동하려면 팀이 다음을 수행해야합니다.
- 시스템 은유(표준화 된 명명 체계)를 선택하십시오.
- 연습 쌍 프로그래밍., 팀 구성원은 단일 컴퓨터에서 쌍으로 작업하여 코드를 작성하여 프로덕션으로 보냅니다. 한 번에 한 쌍만 코드를 통합합니다.
- 몇 시간마다 저장소에 코드를 통합하고 커밋합니다.
고객이 사용할 수 있어야한다,가능하면 사이트의 동안,이는 전체 프로세스할 수 있도록 질문에 대답을 설정 요구 사항입니다.
테스트
팀은 단위 테스트를 수행하고 코드를 릴리스하기 전에 버그를 수정합니다. 또한 수락 테스트를 자주 실행합니다.,
익스트림 프로그래밍 사용시기
규칙과 값을 읽은 후에도 XP 가 팀의 요구에 맞는지 아직 확실하지 않습니까? 익스트림 프로그래밍은 다음과 같은 팀을 위해 잘 작동 할 수 있습니다.
- 시스템의 기능이 몇 개월마다 변경 될 것으로 기대합니다.
- 끊임없이 변화하는 요구 사항을 경험하거나 시스템이 무엇을 원하는지 확실하지 않은 고객과 협력하십시오.
- 특히 긴밀한 마감 시간을 중심으로 프로젝트 위험을 완화하고 싶습니다.
- 는 소수의 프로그래머를 포함합니다(2 와 12 사이가 바람직합니다).
- 는 고객과 긴밀히 협력 할 수 있습니다.,
- 는 자동화 된 단위 및 기능 테스트를 만들 수 있습니다.
협업과 지속적인 개발이 팀의 우선 순위라면 익스트림 프로그래밍은 시도해 볼만한 가치가있을 수 있습니다. 이 때문에 고도로 적응할 수 있는 모델의 필요에 대한 지속적인 피드백,고객으로부터 예 오류를 길을 따라,그리고 필요한 개발자가 함께 작업 할,XP 지 않을 보장뿐만 아니라 건강에 제품을 출시하지만 실수로 또한 생산성 향상을 위해 개발 팀이다.,
XP 를 사용하기로 결정한 경우 Lucidchart 에서 사용자 스토리,릴리스 일정,CRC 카드 및 시스템 설명서를 시각적으로 문서화하십시오. 오늘 무료 계정에 가입하십시오.