이 장에 대한 개요를 제공합의 극단적인 프로그래밍입니다.

민첩 무엇입니까?

‘agile’이라는 단어는−

• 빠르고 쉽게 몸을 움직일 수 있음을 의미합니다.

• 신속하고 명확하게 생각할 수 있습니다.,

비즈니스에서는’민첩’을 설명하기 위해 사용되는 방법으로의 계획과 일하고 있는 점에서 그것은 이해는 필요한 변경 사항이 중요한 작업의 일부입니다. 비즈니스’아길 릴티’는 회사가 항상 시장 변화를 고려할 수있는 위치에 있음을 의미합니다.

Ref:캠브리지 사전 온라인.

에서 소프트웨어 개발 용어는’민첩’에 적응하는 것을 의미’의 변화에 반응하는 능력−변경에서 요구 사항,기술과 사람들입니다.,’

민첩 선언

팀의 소프트웨어 개발자는 게시 민첩한 성명서는 2001 년에 중요성을 강조의 개발팀은 수용 요구 사항의 변화와 고객 참여.

Agile Manifesto 국−

우리는 우리 폭로 더 나은 방법을 개발의 소프트웨어에 의해 그것을 하고 다른 사람들을 돕는 않습니다. 이 작업을 통해 우리는 가치−

• 프로세스와 도구를 통한 개인과 상호 작용에 도달했습니다.

• 포괄적 인 문서를 통해 작업 소프트웨어.,

• 계약 협상을 통한 고객 협업.

• 계획을 따르는 것보다 변화에 반응합니다.

즉,오른쪽에있는 항목에 값이 있지만 왼쪽에있는 항목을 더 소중하게 생각합니다.

적 특성의 민첩성

다음과 같은 특성의 민첩성−

• 민첩성에 민첩한 소프트웨어 개발에 초점을 맞추고 문화의 전체 팀과 함께 다양한 분야,다기능 팀이 있는 능력을 주고 selforganizing.

• 그것은 공유 책임과 책임을 육성합니다.,

• 효과적인 의사 소통과 지속적인 협업을 용이하게합니다.

• 전체 팀 접근 방식은 지연과 대기 시간을 피합니다.

• 빈번하고 지속적인 배송은 팀이 요구 사항에 맞출 수 있도록 빠른 피드백을 보장합니다.

• 협업을 용이하게 결합하는 다른 관점의 적시에 구현 결함을 수정하고 수용을 변경합니다.

• 진행은 일정하고 지속 가능하며 예측 가능한 투명성을 강조합니다.,

소프트웨어 엔지니어링 트렌드

다음과 같은 경향은 관찰에서 소프트웨어 엔지니어링−

• 를 수집하기 전에 요구사항 개발을 시작합니다. 그러나,그 요구 사항이 있는 경우는 변경 될 수 있습니다 그럼 나중에,다음과 같은 일반적으로 주의−

  • 저항의 변화 이후 단계에서의 개발이다.

  • 있는 요구 사항의 엄격한 변경을 포함하는 프로세스 변경 관리는 보드도 있습 밀어 변경을 나중에 출시하였습니다.,고객의 기대에 부응하지 않는 구식 요구 사항을 가진 제품의 배송입니다.

  • 예산 내에서 피할 수없는 도메인 변경 및 기술 변경을 수용 할 수 없음.

• 을 제거하고 결함을 조기에는 개발 수명 주기 위해서 잘라 결함을 수정 비용.

  • 시험 시작 후에 코딩은 완전하고 테스트하는 것으로 간주자의 책임도 검사자가 관여하지 않습니다.

  • 프로세스 자체를 측정하고 추적합니다., 이것은 비싸기 때문에−

  • 모니터링 및 추적 작업 수준에와에서 리소스 수준이다.

  • 개발을 안내하기 위해 측정을 정의하고 개발의 모든 활동을 측정합니다.

  • 관리 개입.

• 개발 전에 모델을 정교하고 분석하고 검증하십시오.프레임 워크로 모델을 사용하도록되어 있습니다. 그러나 모델에 초점을 맞추고 개발에 집중하지 않으면 예상되는 결과를 얻지 못할 것입니다.,

코딩,개발의 핵심은 충분한 강조를 부여하지 않습니다. 그 이유는−

• 생산을 담당하는 개발자는 일반적으로 고객과의 지속적인 커뮤니케이션이 아닙니다.

• 코딩은 볼로 번역의 설계 및 효과적인 구현에는 코드는 거의 반복에 다시 디자인이다.

테스트하는 것으로 간주됩 게이트웨이를 확인하기 전에 결함을 배달합니다.,

• 스케줄 초과의 이전 단계의 발달에 의해 보상 전망을 즐길 수 있는 테스트 요구 사항을 보장 적시 배달입니다.

• 이로 인해 배송 후 결함을 수정하는 비용 초과가 발생합니다.

• 테스터는 책임을 만들과에 대한 책임이 제품의 품질이 비록 그들이 관여하지 않는 전체 과정 동안의 개발이다.

제한한 자원(주로 팀)수는 예산에 리드−

• 리소스 할당

• 팀은 소모.,

• 팀 역량의 효과적인 활용에 손실.

• 감손.

극단적인 프로그래밍−을 처리하는 방법이 일반적인 단점

소프트웨어 엔지니어링을 포함−

• 창의력

• 학습 및 개선을 통한 시험과 오류를

• 반복

극단적인 프로그램 빌드에서 이러한 활동을 수 있습니다. 그것은에 대한 자세한(하지만)디자인 활동으로 여러 꽉 피드백 루프를 통해 효과적인 구현,테스트 및 refactoring 습니다.,

극단적인 프로그래밍에 따라 다음과 같은 값

• 통신

• 단순

• 피드백

• 용기

• 존중

는 무엇입 극단적인 프로그래밍이 가능한가요?

XP 는 가볍고 효율적이며 위험도가 낮으며 유연하고 예측 가능하며 과학적이며 재미있는 소프트웨어 개발 방법입니다.

극단적인 프로그래밍(XP)잉태되었다 및 개발을 주의 특정 요구에 소프트웨어 개발에 의해 작은 팀의 얼굴에서 모호하고 변화하는 요구 사항입니다.,

익스트림 프로그래밍은 민첩한 소프트웨어 개발 방법론 중 하나입니다. 팀 행동을 안내하는 가치와 원칙을 제공합니다. 팀은 자체 구성 할 것으로 예상됩니다. 익스트림 프로그래밍은−

• 각 연습은 간단하고 자체 완성 된 특정 핵심 관행을 제공합니다.

• 관행의 조합은보다 복잡하고 응급 행동을 일으킨다.

변화를 받아

주요 가정의 극단적인 프로그래밍의 비용이 변화하는 프로그램을 개최 할 수있는 대부분 시간이 지남에 따라 지속적으.,>이 달성될 수 있으로−

• 에 중점을 지속적으로 피드백에서는 고객

• 짧은 반복

• 디자인 및 재설계

• 코딩 및 테스트를 자주.

• 결함을 제거기, 따라서 비용 절감

• 유지 고객 관련 개발을 통해

• 전달 작동하는 제품 고객

극단적인 프로그래밍 간단히 말해서

극단적인 프로그래밍을 포함−

• 단위 테스트를 작성하기 전에 프로그래밍 및 유지 모두의 테스트에서 실행합니다., 단위 테스트는 자동화되어 결함을 조기에 제거하므로 비용이 절감됩니다.

• 손에있는 기능을 코딩하고 필요할 때 재 설계하기에 충분한 단순한 디자인으로 시작합니다.

• 한 화면에 두 명의 프로그래머가있는 쌍으로 프로그래밍하여 키보드를 사용하기 위해 교대로 프로그래밍합니다. 그 중 하나가 키보드에있는 동안,다른 하나는 지속적으로 검토하고 입력을 제공합니다.

• 하루에 여러 번 전체 시스템을 통합하고 테스트합니다.,

• 최소한의 작업 시스템을 생산에 신속하게 투입하고 필요할 때마다 업그레이드합니다.

• 항상 관련된 고객을 유지하고 지속적인 피드백을 얻습니다.

반복은 소프트웨어가 변화하는 요구 사항에 따라 발전함에 따라 수용적인 변화를 용이하게합니다.

왜”Extreme?”

익스트림 프로그래밍은 효과적인 원칙과 관행을 극단적 인 수준으로 끌어 올립니다.

• 코드 검토는 코드가 항상 검토되므로 효과적입니다.,

• 테스트는 지속적인 회귀와 테스트가 있으므로 효과적입니다.

• 디자인은 모두가 매일 리팩토링을 수행해야하므로 효과적입니다.

• 통합 테스트는 하루에 여러 번 통합 및 테스트로 중요합니다.

• 짧은 반복은 릴리스 계획 및 반복 계획을위한 계획 게임으로 효과적입니다.

익스트림 프로그래밍의 역사

Kent Beck,Ward Cunningham 및 Ron Jeffries 는 1999 년에 익스트림 프로그래밍을 공식화했습니다. 다른 기여자는 로버트 마틴과 마틴 파울러입니다.,

에서 80 년대 중반,켄트 벡과 구 커닝햄 시작된 한 쌍의 프로그래밍 텍트로닉스에서. 80 년대와 90 년대에 스몰 토크 문화는 리팩토링,지속적인 통합,지속적인 테스트 및 긴밀한 고객 참여를 창출했습니다. 이 문화는 나중에 다른 환경으로 일반화되었습니다.

90 년대 초,핵심 가치는 패턴 커뮤니티 인 Hillside Group 내에서 개발되었습니다. 1995 년 Kent 는 Smalltalk 모범 사례에서이를 요약했으며 1996 년 Ward 는 에피소드에서 요약했습니다.

1996 년 Kent 는 hewitt 에서 단위 테스트와 은유를 추가했습니다., 1996 년 Kent 는 Ron Jeffries 가 코치로 추가 된 Chrysler C3 프로젝트를 수행했습니다. 관행은 C3 에서 정제되어 위키에 게시되었습니다.

스크럼 관행이 통합되어 계획 게임으로 적용되었습니다. 1999 년 켄트는 자신의 저서 인’익스트림 프로그래밍 설명’을 출판했습니다. 같은 해 파울러는 자신의 저서 인 리팩토링을 발표했습니다.

익스트림 프로그래밍은 그 이후로 진화 해 왔으며 진화는 오늘날까지 계속됩니다.

성공에서 산업

의 성공은 프로젝트를 수행하는 극단적인 프로그래밍 사례 때문이−

• 신속한 개발이 가능합니다.,

• 고객의 변화하는 요구 사항에 즉각적인 응답.

• 낮은 결함 비율에 중점을 둡니다.

• 고객에게 일정하고 일관된 가치를 반환하는 시스템.

• 높은 고객 만족도.

• 비용 절감.

• 팀 응집력과 직원 만족도.

극단적인 프로그래밍 장점

극단적인 프로그래밍을 해결 다음과 같은 문제는 종종에서 직면하고 소프트웨어 개발 프로젝트−

• 미끄러정하고 달성 가능한 발전 사이클이 시기적절한 배송 합니다.,

• 취소 프로젝트에 초점을 지속적으로 고객 참여 투명성을 보장과 고객을하고 즉시 해결의 어떤 문제입니다.

• 발생하는 비용에 변경−광범위하고 진행하는 테스트를 확인 변화하지 않는 기존의 기능이 있습니다. 실행중인 작업을 시스템을 항상 보장을 위한 충분한 시간을 수용을 변경하는 등 현재 작업에는 적용되지 않습니다.

• 생산 그리고 포스트 배달 결함:중에서 단위 테스트를 감지 및 수정이 결함을 조기.,

• 오해 비즈니스 및/또는 도메인이 만드는 고객의 일부가 팀은 일정한 통신 및 확인.

• 비즈니스 변경-변경은 불가피한 것으로 간주되며 어느 시점에서나 수용됩니다.

• 직원 회전율-집중적 인 팀 협력은 열정과 선의를 보장합니다. 다 분야의 응집력은 팀 정신을 육성합니다.