애자일 개발 방법론과 XP

애자일(Agile) 개발 방법론

 

특정 방법론이 아닌 소프트웨어를 빠르고 낭비 없이 제작하기 위해 고객과의 협업에 초점을 둔 것으로 소프트웨어 개발 중 설계 변경에 신속히 대응하여 요구사항을 수용할 수 있다. 그렇기에 절차와 도구 보다 고객과의 소통 그리고 피드백을 중요시하며, 소트프웨어가 잘 실행되는 가에 가치를 두며, 배포시차를 최소화 할 수 있다.

 

애자일(Agile) 선언문

프로세스나 도구보다 개인과의 소통이 더 중요하다.

완벽한 문서보다 실행되는 소프트웨어가  중요하다.

계약 협상보다 고객과의 협업이 중요하다.

계획을 따르는 것보다 변경에 대한 응답이 더 중요하다.

 

XP(eXtreme Programming)

1999년 Kent Beck이 제안하였으며, 개발 단계 중 요구사항이 시시각각 변동이 심한 경우 적합한 방법론이다.

요구에 맞는 양질의 소프트웨어를 신속하게 제공하는 것을 목표로 한다. 요구사항을 모두 정의해 놓고  작업을 진행하는 것이 아니라, 요구사항이 변경되는 것을 적용하는 방식으로 예측성보다는 정응성에 더  높은 가치를 부여하고, 고객의 참여와 개발 과정의 반복을 극대화해 생산성을 향상시킨  방법이다.

 

XP의 핵심가치

 

소통 : 개발자, 관리자, 고객 간의 원활한 소통을 지향한다.

단순성 : 부가적 기능 또는 미사용 구조와  알고리즘은 배제한다.

피드백 : 소프트웨어 개발에서  변화는 불가피하다. 이러한 변화는 지속적 테스트와 통합, 반복적 결함 수정등 빠르게 피드백 한다.

용기: 고객 요구사항 변화에 능동적으로 대응한다.

존중: 개발 팀원 간의 상호 존중을 기본으로  한다.

 

XP PROCESS

출처 : https://i-bada.blogspot.com/2012/04/agile.html#google_vignette

 

 

XP의 12가지 실천사항

짝 프로그램: 두명이 한 탐이 되어 프로그램 개발

집단 소유권: 개발된 코드는 누구라도 수정 가능.

지속적 통합 : 프로그램 버전이 일치하도록 개발한  코드는 지속적으로 통합

계획 수립 : 유저 스토리 중심으로 개발 활용 및 배포 계획 수립

작은 배포 : 작은 프로그램을 먼저 만들고, 짧은 주기로 배포

메타포 : 은유법을 사용하여 개발자와 설계자의 괴리감 해서

심플  디자인 : 현재 요구사항에 알맞은 가장 단순한 형태로 디자인

테스트 주도 개발: 테스트 한 후에 프로그램 개발

리펙토링: 기능에 변화  없이 프로그램 디자인 패턴 변경 통해 개선

주 40시간 근무: 개발자가 최상의 컨디션을 유지할 수 있도록 야근 금지.

고객 상주: 고객과의 실시간 커뮤니케이션을 통해 의사소통 향상

코딩 표준: 사전에 정의된 코딩 표준을 통해 공동 작업 생산성 향상.

 

효과적인  프로젝트 관리를 위한 3데 요소

사람 - 인적자원

문제 - 문제인식

프로세스 - 작업 계획

 

정형기술 검토 지짐 사항

의제외  그 범위를 유지하라

참가자의 수를 제한하라.

각 체크 리스트를 작성하고, 직원과  시간 일정을 할당하라.

개발자가 아닌 체품의 검토에 집중하라

논쟁과 반박을   제한하라.

검토 과정과 결과를 재검토하라.