Agile 방법론

1. 등장배경
1. SW의 개발환경의 변화
1. 정보시스템의 'Time To Market'과 '적시배포'가 중요해짐.
2. 사용자 요구가 다양해지고 수명주기가 짧아짐.
2. 기존 방법론의 한계
1. 문서 및 절차위주의 방법론은 변화에의 신속한 적응이 어려움.
2. 변화에 바르게 적응하고 효율적으로 개발할 수 있는 방법론이 필요.
2. 정의
1. e-Business,  시장 및 SW개발환경 등 주위변화를 빠르게 수용하고 이에 능동적으로 대응하는 여러 경량 방법론의 통칭.
3. 특징
1. Predictive 하기보다는 Adaptive한 방법론(변화에 반응하는것이 계획을 준수하는 것보다 우선함)
2. 프로세스 중심이 아닌 사람중심의 방법론(개인간 상호의사소통이 프로세스나 도구보다 우선함)
3. 동작하는 소프트웨어가 포괄적인 문서보다 우선함.
4. 고객과의 협력이 계약협상보다 우선함.
4. 종류
1. XP
1. 정의
1. 반복형 모델의 개발주기를 극단적으로 짧게 함으로서 프로그래머가 설계, 구현, 시험 활동을 전체 SW 개발기간에 걸쳐 조금씩 자주 실시하도록 하는 개발 방법.
2. 원칙
1. 의사소통.
2. 단순성.
3. 피드백
4. 용기.
3. 배경
1. 요구사항 분석의 어려움.
2. 사용자도 개발초기에 요구사항을 명확히 전달하지 못함.
3. 불필요한 다량의 문서작업으로 개발자의 개발시간을 단축시키고 의욕을 저하시킴.
4. 특징
1. 짧은 개발주기 반복.
2. Prototype이 일찍 자주 만들어짐.
3. 개발계획이 프로젝트 진행동안 계속 변화됨.
5. 지침
1. 개발계획 수립(The Planning Process,'Planning Game')
1. 고객과 다양한 스토리카드(story card)를 통한 개발계획 작성.
2. 시스템 메타포어(Metaphore)
1. 문장형태로 시스템 아키텍쳐 기술, 공통의 Saming System 개발, 고객과 개발자간 의소소통 언어.
3. 1주일 40시간
4. 단순설계 - 현재의 비즈니스 가치에 집중, 'refactoring'을 통해 개선
5. 코딩표준
6. Pair-programming - communication의 중요성 강조.
7. 공동소유/공동책임 - 시스템에 존재하는 모든 코드는 언제 누구든지 수정 가능함.
8. 사용자 파견 - 프로젝트팀에 사용자가 상주하여 고객 위주의 프로그래밍, 품질향상의 필수 요소.
9. 테스트 - TFD(Test First Development),테스트 수행 후 검증코드로 작성해 나감.
10. 재구성 - 기능 변화 없이 중복제거, 단순화, communication 향상, 유연성 추가를 위해 시스템 재구성.
11. 짧은 배포주기.
12. 지속적 통합.
6. 생명주기 순환요소
1. 가치정의 - 고객의 시스템의 가치를 정의.
2. 비용산정 - 고객이 결정한 부분에 대해 개발자가 비용추산.
3. 가치선택 - 고객이 필요한 범위를 결정.
4. 개발 - 고객이 결정한 범위를 개발자가 개발.
2. SCRUM
1. 작은 개발팀, 짧은 개발주기, 팀의 집중력과 생산성을 유지시켜 점진적으로 소프트웨어를 산출하는것에 초첨.
2. 스프린트는 통상적으로 4~6주 정도의 기간을 가지는 잘 정의된 개발주기를 의미함.
3. 매일 15분 정도의 스크럼 미팅을 통해 프로젝트 진행상황을 확인하기 때문에 효과적인 프로젝트 운영을 유도함.
4. XP는 리팩토링을 통해 언제든지 변화를 수용하겠다는 관점이나, SCRUM은 변화를 최대한 빨리 감지하여 처리하고자 하는 관점.
3. DSDM
1. 기능모델, 설계와 구현, 수행의 3단계 사이클(2~6주)로 구성.
4. FDD
1. 짧은 반복주기(2주), 5단계 프로세스(전체모델, 특성리스트 생성, 계횎, 설계, 구축)로 구성.
2. 설계, 구축 프로세스의 반복.
5. Agile 프로세스 지원 솔루션
1. http://www.rallydev.com/