Extreme Programming Development

[ XP 계획 ]

▪ XP에서는, 고객도 개발 팀의 한 사람이며 시스템 요구사항을 구체화 하고 우선순위를 정해줄 의무가 있다.

▪ 요구사항은 시나리오나 유저스토리로 표현된다.

▪ 스토리카드에 기록된 것은 개발팀에서 다시 task 단위로 분리한다. 각 Task 별로 성과와 자원이 평가된다.

▪ 고객은 개발 우선순위를 정하고 다음 배포에 포함할 스토리를 선택한다.

 

[ XP 배포 ]

▪ 새로운 버전은 하루에 몇 번씩 만들어 질지도 모른다. 배포는 약 2주마다 고객들에게 전달된다(milestone)

▪ 배포 마감날짜는 절대 미루지 않는다. 만약 개발에 문제가 발생하면 기능을 제거하고 배포한다.

▪ 모든 새로운 버전은 테스트를 한 이후 승인하며 테스트 또한 성공적으로 기능이 실행되어야 한다. 모든 테스트는 실행 가능 해야 하고 자동적으로 이루어 진다.

 

[ XP 변경 ]

전통적인 소프트웨어 공학	XP
미래의 변동사항을 예상해야 하고 그러한 변화를 위한 설계를 해야 한다. 시간을 효율 적으로 사용하고 나중에 드는 비용을 줄이기 위해 변경사항을 예상한다.	변화에 대처하기 위해 프로그램에 보편성을 추가하기 위한 시간을 투자하지 않는다. 때때로 예상했던 변화는 일어나지 않고 예상했던 것과 완전히 다른 것이 나타난다. -> 그러므로 XP는 개발 할 때 더 쉽게 변화를 줄 수 있도록 끊임없이 코드를 향상 시켜야 한다.

 

[ XP Refactoring ]

▪ 반복적 개발이므로, 소프트웨어 구조를 망가뜨릴 경향이 있다. 따라서 변경하기가 갈수록 어려워진다.

▪ Refactoring 하면서 이러한 문제점을 해결 한다(?)

 - 개발 팀들은 가능한 코드 향상을 바라기 때문에 급하지 않은 상황에서도 코드향상을 시킨다.

▪ Ex) 속성과 함수의 이름 수정, 반복적인 코드 제거, 클래스 상속의 재조직..

▪ 프로그램 개발 도구는 Refactoring을 도와준다.

  - 코드간 연관성을 찾아 주거나, 코드 수정을 도와준다.

▪ Refactoring은 소프트웨어의 이해성을 향상시키고 문서화의 필요성을 줄여준다.

▪ 코드를 깔끔하게 구조적으로 만들었기 때문에 변경하기 쉬워진다.

▪ 가끔 변경을 할 수 없는 경우에는 구조를 바꾸어야 한다.

 

[ XP의 Test ]

▪ XP는 프로그램 테스트의 중요성을 강조한다.

▪ XP에서, 프로그램은 각 변경사항을 적용 한 후 테스트된다.

 

댓글이나 공감 남겨주는 사람 착한사람