애자일 개발 방법 - 익스트림 프로그래밍 XP
2025-02-10 15:35:59 0 보고서
전체 콘텐츠를 보려면 로그인하세요
이 마인드맵은 '애자일 개발 방법 - 익스트림 프로그래밍 XP'에 대한 개요입니다. 익스트림 프로그래밍(XP)은 소프트웨어 개발의 예측 가능성을 강조하는 방법론으로, 켄트 베이커와 워드 커닝햄, 론 제퍼슨에 의해 창시되었습니다. XP는 요구 변경으로 인한 비용을 줄이고, 프로젝트 개발의 초기 단계에서 시스템 요구사항을 확정하여 개발 비용의 급격한 증가를 방지하려는 목표를 가지고 있습니다. 이 방법론은 짧은 배송 시간, 페어 프로그래밍, 지속 가능한 리듬 등 12가지 핵심 실천을 포함하며, 소통, 간단함, 피드백, 용기의 네 가지 가치를 중시합니다.
저자의 다른 작품
개요/내용
익스트림 프로그래밍의 4가지 가치
소통
소프트웨어 시스템의 기본적인 임무 중 하나
개발자와 소통하여 시스템의 구체적인 요구사항을 명확히 한다
목표는 모든 개발자들에게 시스템에 대한 공유된 관점을 제공하는 것입니다.
이는 또한 시스템의 최종 사용자의 관점과 일치하는 것입니다.
이는 또한 시스템의 최종 사용자의 관점과 일치하는 것입니다.
자주적인 구두 교류와 피드백을 장려합니다.
간단해
가장 간단한 해결 방법부터 시작합시다.
계속적인 리팩토링을 통해 더 나은 결과를 얻는다.
현재의 필요성에만 초점을 맞추어 설계와 코딩을 진행하며,
내일, 다음 주 또는 다음 달에 나타날 수 있는 필요성은 고려하지 않습니다.
내일, 다음 주 또는 다음 달에 나타날 수 있는 필요성은 고려하지 않습니다.
미래의 수요는 그들이 아직 제기하기 전에 변할 가능성이 높습니다.
설계와 코드의 간소화는 의사소통의 질을 향상시킬 수 있습니다.
피드백
피드백은 빠를수록 좋습니다.
"피드백"은 시스템 개발의
많은 다양한 측면과 관련이 있습니다.
많은 다양한 측면과 관련이 있습니다.
시스템으로부터의 피드백
단위 테스트
수정된 시스템의 상태를 직관적으로 얻을 수 있습니다.
고객으로부터의 피드백
기능성 테스트
고객과 테스터가 작성합니다.
현재 시스템의 상태를 알게 되었습니다.
2~3주에 한 번씩 계획합니다.
고객은 개발 진행 상황을 매우 쉽게 이해하고 관리할 수 있습니다.
팀으로부터의 피드백
고객이 새로운 요구사항을 가지고 프로젝트 계획 회의에 참석합니다.
팀은 새로운 요구사항을 구현하는데 필요한 시간을 직접 평가한 후 고객에게 피드백할 수 있습니다.
피드백은 "커뮤니케이션"과 "간단함" 이라는 두 가치와 밀접하게 연관되어 있습니다.
소통 시스템의 결함
단위 테스트 작성
간단하게 코드의 특정 부분에 문제가 있음을 입증하다
사용자는 정의된 기능 요구 사항을 기반으로 시스템에 대해 주기적인 테스트를 수행합니다.
"프로그래밍에 대한 낙관주의는 위험하며, 시기적절한 피드백이 이에 대한 해결책입니다."
Kent Beck
용기
오늘의 필요에만 맞춰 디자인하고 코딩하세요,
내일은 생각하지 마세요.
내일은 생각하지 마세요.
디자인의 늪에 빠지지 않도록 하며
다른 문제들에 지나치게 많은 불필요한 노력을 소비하지 않도록 하자
다른 문제들에 지나치게 많은 불필요한 노력을 소비하지 않도록 하자
재구성해야 할 때 코드에 대해 편안함을 느낄 수 있다.
기존 시스템을 검토하고 개선하세요
이후에 발생하는 변화 요구사항이 더 쉽게 실현될 수 있습니다.
기존 코드를 완전히 버려야 할 때를 알기
하루 종일 자신이 설계하고 코드한 복잡한 문제에 빠져
아무런 성과도 얻지 못했습니다.
아무런 성과도 얻지 못했습니다.
다음 날 새로운 그리고 맑은 관점에서 생각해 보세요.
30분 안에 쉽게 해결할 수 있습니다.
익스트림 프로그래밍
익스트림 프로그래밍
Extreme programming
XP로 약어됩니다.
소프트웨어 공학 방법론
다르다
보다 유연성을 강조하기보다 예측 가능성을 강조한다.
창시자
켄트 베이커, 워드 커닝햄
론 제퍼슨
극한 프로그래밍의 목표
요구 변경으로 인한 비용을 줄이세요.
시스템 요구사항은 프로젝트 개발의 시작 단계에서 확정됩니다.
프로젝트 개발이 후반 단계에 접어들 때 발생하는 요구사항 변경은 개발 비용을 급격히 증가시킬 수 있으며, 이러한 요구사항 변경은 일부 매우 빠르게 발전하는 분야에서는 불가피한 것입니다.
기본 가치, 원칙, 방법 등의 개념을 도입함으로써
변경 비용을 낮추는 목적
익스트림 프로그래밍의 12가지 핵심 실천
짧은 배송 시간
스クラ럼처럼 반복적인 전달 방식을 채택합니다.
각 반복마다 1-3주의 시간
반복 종료
팀이 운용 가능한, 테스트를 거친 기능을 전달합니다.
이 기능들은 즉시 사용할 수 있습니다.
플레이 계획
두 가지 문제
납품일까지 얼마나 많은 작업을 완료할 수 있는지 예측하세요
지금과 다음에 무엇을 해야 할까요?
이 두 가지 질문에 끊임없이 답하십시오
두 가지 문제에 대한 두 개의 해당 과정
소프트웨어 출시 계획 (출시 계획)
개발 비용, 위험 및 각 요구 사항의 중요성에 따라 대략적인 프로젝트 계획을 수립합니다.
최초의 프로젝트 계획은 정확할 필요도(또는 가능성도) 없으며, 정확할 수도 없습니다.
주기적 개발 계획 (반복 계획)
개발 과정에서
여러 단계의 계획이 있습니다.
예를 들어, 세 주에 하나씩 계획을 세운다.
어떤 주기 동안 시스템에 내부 재정비와 최적화를 진행합니다(코드와 설계)
어느 기간에 새로운 기능이 추가되었습니다.
한 주기 내에 두 가지 측면의 작업을 동시에 수행할 것입니다.
이로운 점과 불리한 점이 있다
이점
고객은 즉시 알 수 있습니다.
어떤 것들을 완료했나요?
만든 것이 사용하기에 적합한가요?
아직 무엇을 더 만들어야 할지 또는 무엇을 개선해야 할지 등에 대해
해로운 점
생产出한 것을 보고, 매우 불만족스러울 수도 있어 중지 계약을 할 수도 있습니다.
문제를 조기에 발견하고 해결하기 위해
페어 프로그래밍
두 명의 사람이 한 대의 컴퓨터 앞에 앉아 함께 작업을 완료합니다.
프로그래머는 컴퓨터를 제어하며 주로 코딩의 세부 사항에 관심을 둡니다.
다른 한 사람이 주로 전체 구조에 주목합니다.
첫 번째 프로그래머가 작성한 코드를 끊임없이 검토합니다.
짝은 고정되어 있지 않습니다.
지속 가능한 리듬
장기적으로 유지되는 속도로 열심히 일하기
체력을 보존하세요
프로젝트를 마라톤 경주로 생각하세요.
대신에 전속력으로 달리기
코드 집합 소유
모두가 모든 코드에 대해 책임을 집니다.
누구나 코드의 임의 부분을 변경할 수 있습니다.
队伍 프로그래밍은 이 실천에 큰 기여를 했습니다.
다양한 팀에서 일하기
모든 프로그래머는 완전한 코드를 볼 수 있습니다.
코딩 표준
모든 사람들이 통일된 프로그래밍 표준을 따릅니다.
모든 코드가 한 사람이 쓴 것처럼 보입니다.
간단한 디자인
전통적인 개발 방식에서 모든 요구사항을 한 번에 충족시키는 일회성 총괄 설계가 없습니다.
디자인 과정은 거의 전체 프로젝트 개발 내내 지속됩니다.
프로젝트 계획을 수립하는 것에서부터
각 개발 주기(Iteration)의 계획을 수립하다
각 요구 모듈에 대한 간결한 설계
설계의 재검토
그리고 지속적으로 중단되지 않는 디자인 재정비와 최적화
전체 설계 과정은 나선형의, 끊임없이 전진하고 발전하는 과정입니다.
테스트 주도 개발
재구성
시스템 은유
지속적인 통합
XP 개발팀은 시스템이나 기능 모듈이 어떻게 작동하는지를 많은 생생한 비유를 사용하여 설명합니다.
현장 고객
고객
시스템에 대금을 지불하는 사람이 아닙니다.
오히려 그 시스템을 실제로 사용하는 사람들
고객
항상 현장에서 문제를 해결합니다.
스토리 쓰기
수락 테스트
더 자주 교류하고 논의하기
0 댓글
다음 페이지
