Agile Method

[ Agile Method의 종류 ]

▪ Extrem Programming(XP),  Scrum

▪ Crystal, Adaptive Software Development, DSDM, Feature Driven Development

▪ The Rational Unified Process ( agile instantiations)

-> incremental 개발, 배포에 기반하지만 다른 프로세스를 사용한다.

 

[ Agile Method의 원리 ]

Principle	Description
Customer involvement	고객들은 개발 과정을 통해 함께 해야 한다. 그들의 역할은 새로운 시스템에 대한 요구조건을 제공하고 시스템을 평가하는 것이다.
Incremental delivery	소프트웨어는 각 단계마다 증가되는 요구조건을 구체화 해주는 고객과 함께 반복적으로 개발된다.
People not process	개발팀의 기술은 인지되어 활용되어야 한다. 팀 멤버들은 정해진 방법이 아니라 그들의 방식대로 개발하기 위해 남겨진다. 프로세스가 줄어들면서 자율성이 높아지지만 감시 또한 높아진다. -> Pair programming 으로 보완할 수 있다.
Embrace change	요구 사항의 변경에 대해 미리 예측하고 있으며 이러한 변화를 받아들일 수 있도록 설계한다.
Maintain simplicity (=refactoring)	소프트웨어 개발과 과정 모두에서 간단함에 집중한다. 가능한 시스템으로부터 복잡성을 제거하도록 한다. 복잡 해 질수록 변화, 발전이 힘들기 때문이다. (코드의 유지 보수성)

 

[ Agile Method 응용 ]

▪ 너무 큰 프로젝트에는 부적합 하므로, 작거나 중간 사이즈의 프로젝트에 적용한다. 너무 많은 팀원은 문서를 필요로 하기 때문

▪ 개발 과정에서 고객이 함께 하여 명백한 승인을 해 줄 의향이 있을 때

▪ 소프트웨어에 영향을 끼칠 외부 규정이나 규칙이 없는 곳. 상무나 비전공자들에게 소프트웨어를 설명하는 것은 대단히 어렵기 때문이다.

 

[ Agile Method 문제점 ]

▪ 프로세스에 함께하는 고객의 흥미를 유지하기 어렵다.

▪ Agile의 특성인 밀접하게 붙어서 일하는 것이 성격에 맞지 않는 팀원이 있을 수 있다.

▪ 많은 중재자가 있는 곳에는 우선순위를 변경하는 것이 어려울 수 있다.

▪ 때때로 간단함은 추가적인 작업을 필요로 한다.

▪ 계약서에 아직 정해지지 않은(반복적으로 계속 추가될) 기능을 기술하는 것이 굉장히 애매하다.

 

[ Agile Method의 유지보수 ]

▪ 시스템은 Agile 방식을 이용하여 유지보수가 가능하며, 공식적인 문서를 최소화 하였는가?

-> 잘 구조화된 코드 작성은 공식적인 문서보다 더욱 가치가 있다.

 

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