[소공 목차]
1. Agile 방법론 개요
1) Agile 정의
- 프로세스보다는 변화에 대응을 위한 사람이 중심이 되어 요구사항 변경에 대해 유연하고 신속하게 적응하면서 시스템을 개발할 수 있는 반복적 방법론
- 효율적인 제품, SW 개발을 위해 절차보다는 사람과 제품에 집중하여 낭비를 제거하고 고객의 요구사항을 보다 유연하고 신속하게 반영하기 위한 방법론
- 특정 개발 방법론을 가리키는 말은 아니고, '애자일(=기민한, 좋은 것을 빠르고 낭비없게 만드는 것)' 개발을 가능하게 해주는 다양한 방법론 전체를 말함
2) Agile 방법론 특징
특징 | 설명 |
애자일에 적합한 환경 | 고객 요구사항이 자주 변경되는 경우 애자일 방법론이 적합 |
고객 참여도 | 고객 프로세스에 협력하기 때문에 고객과 신속한 피드백이 가능 |
업무 효율화 | 프로젝트를 여러 부분으로 나누어 점진적으로 개발하여 신속하고 반복된 주기로 수행 |
소규모에 적합 | 요규사항이 명확하지 않을 경우 또는 소규모 개발에 적합한 소프트웨어 방법론 |
2. Agile 방법론 등장 배경 및 시기
1) Agile 방법론 등장배경
SW 개발 환경 변화
|
- 정보시스템에 대한 사용자 요구 다양해지고, 정보시스템 수명주기 짧아짐
- 정보시스템의 적시성(time-to-market)과 Product의 적시 배포(Release)가 중요해짐 |
개발 방법론 한계
|
- 문서위주, 절차중심의 방법론은 변화에 신속한 적응이 어려움
- 변화에 빠르게 적용하고 효율적으로 개발할 수 있는 방법론이 필요 - 소규모 및 중간규모 시스템에 무거운 계획 기반 기법 적용 시 오버헤드가 너무 커짐 |
2) Agile 방법론 등장 시기
3. Agile 선언문 및 원칙
1) Agile 선언문
The Manifesto for Agile Software Development
· Individuals and interactions over processes and tools
· Working software over comprehensive documentation
· Customer collaboration over contract negotiation
· Responding to change over following a plan
가치
|
지향
|
설명
|
개인과 상호작용
|
소통중시 | 공정과 도구보다 개인과 상호작용을 강조 |
작동하는 소프트웨어
|
실무적 관점 | 포괄적인 문서보다 작동하는 소프트웨어에 가치를 둠 |
고객과의 협력
|
협동 중시 | 계약 협상보다 고객과의 협력에 가치를 둠 |
변화에 대응
|
유연성 | 계획을 따르기 보다 변화에 대응하는 것에 가치를 둠 |
2) Agile 12 원칙
구분 | 12가지 원칙 | 설명 |
고객가치 | 고객만족 추구 | - 빠른 배포와 피드백 반영, 고객의 만족도 향상 |
요구사항 변경 수용 | - 고객 요구 변경 인정 및 대응을 위한 유연성 | |
짧은 배포 간격 | - 도구 등을 통해 빠른 배포, 고객 피드백 반영 | |
소통 | 현업-개발자간 일일 의사소통 | - 담당자와 개발자 간의 소통을 통한 업무 효율화 |
동기부여된 사람들 중용/지원 | - 동기 부여된 팀원을 중용 및 환경 지원 | |
면대면 대화 | - Daily Meeting등을 통한 면대면 대화 | |
개발 | 작동하는 소프트웨어로 진도 측정 | - 직접 SW의 기능/비기능적 요소 및 진행관리 |
지속 가능한 개발 장려 | - 지속 가능한 개발 및 프로젝트 진행 장려 | |
좋은 기술, 설계 관심 | - 우수한 기술, 아키텍처 중시 및 공유 | |
추구 | 단순성 추구 | - 목표 업무와 연관 없는 일들을 최소화 |
자기 조직화 팀 | - 책임감 부여, 생산성 행샹를 위한 자기조직적 팀 | |
정기적 효율성 제고 | - 스프린트 리뷰를 통해 다음 스프린트에 반영 할 수 있는 요소 적용 |
4. Agile 조직 및 회의 체계
1) Agile 조직
조직 | 구성 | 역할 |
TEAM | PO(Project Owner) | 업무의 우선순위를 정하고 백로그 관리 |
SM(Scrum Manager) | 팀의 사람 관리를 하며 실제 팀의 실행을 리딩 | |
Developer | 개발자 | |
Designer | 디자이너 | |
COP | PO COP | 비즈니스 목표와 의존성에 대해 논의 |
SM COP | 실행시 팀 간 의존성이 있는 업무에 대해 확인 및 개선 | |
Design COP | 디자인 가이드, 시안 리뷰 및 피드백 | |
Tech COP | 기술적 Practice 공유 |
2) Agile 회의 체계
모임 | 구분 | 설명 |
Agile COP (Community of Practice) Meeting | COP 구성 원칙 | - 같은 스킬을 가지고 있는 유사 직군의 멤버들의 가상 조직으로 주기적으로 모임 진행 |
구성원의 역할 및 특징 | - 각 직군의 팀 리더들이 기술적인 스킬, 문제점, 표준/가이드화 논의 - 각 팀의 Best Practice를 공유 - Tech COP, PO COP, SM COP, Design COP 등이 운영 |
|
Agile Circle | Circle 구성 원칙 | - 팀 업무 이외에 별도의 이슈/목적을 가지고 업무수행이 필요한 경우 임시적으로 구성되는 조직 |
구성원의 역할 및 특징 | - Cross-function한 이슈 중심의 팀으로 팀 구성시 목적을 분명히 하고, 정기적/부정기적으로 모임을 가지다. 단, 목적이 달성되면 해당 Circle은 해체 | |
Agile 조직 | 특징 | - Cross Function 팀: 목적을 달성하기 위해 조직되고 목적 달성하면 해체 - 팀장이 없음: 보고하는 대상이 없고 팀이 Daily Scrum을 통해 업무 공유 - 제한 인원(9명): 구성원 많아지면 Comm.이 어렵고 관료화 가능성 높음 - QA조직없음: 제품의 품질은 Agile 팀 내에서 책임을 지고 준수 |
5. Agile 방법론 유형
유형 | 내용 |
SCRUM | - 사용자의 요구사항을 만족시키기 위해 프로토타입을 반복, 점진적으로 개발하는 Agile 방법론 - 프로젝트 관리를 위한 애자일 방법론으로서 스프린트(Sprint)라는 통상 4~6주 정도의 잘 정의된 개발주기를 가지며 개발 효율성을 극대화할 수 있는 환경제공 - 투명성(Transparency), 타임박싱, 커뮤니케이션 중심, 경험주의 모델 |
Kanban | - 적시개발(just-in-time)을 지원하는 방법론으로 매우 적은 규칙을 가지고 있는 Agile 방법론 - 칸반보드를 통해 개발공정을 시각화 하고 개발제안(WIP) 이용해 Workflow 상의 공정을 관리하고 최적화하여 적시개발(Just in Time Development)를 지원하는 Agile 방법론 - Workflow 시각화, WIP제한, 소요시간 측정 및 최적화 |
XP (eXtreme Programing) | - 의사소통 개선, 즉각적인 피드백에 의해 단순 코딩하여 소프트웨어의 품질을 높이기 위한 방법 - 개발조직이 기반이 되는 중소규모 팀에 적합한 경량화된 개발방식 - 협업, 빠른 소프트웨어 구현, 매우 기술적인 개발 방식을 강조하는 방법론 |
Lean | - TPS(Toyota Production System)를 벤치마킹하여 재정립한 경영방법론을 소프트웨어 개발에 적용한 개발 방법론 - 80년 도요타 시스템의 린 생산방식을 소프트웨어 개발에 적용 - 파레토법칙에 의거하여 개발에 정말 중요한 20%에 집중하고 낭비되는 요소(가외기능, 혼란, 경계 넘어가기)를 제거 |
6. Agile 방법론 장단점
1) Agile 방법론 장점
장점 | 설명 |
ROI 증대 | - 고객들에게 가치 있는 기능들을 빠르고 안정적으로 전달 |
Delivery Time 감소 | - 요구사항의 변화를 유연하게 수용함으로써 Time to Market 실현 |
창의성 향상 | - 팀 자율성 강화를 통한 업무만족도와 창의성 향상 |
생산성 향상 | - 불필요한 산출물 제거 및 팀 협업 강화 |
제품 품질 향상 | - 고객의 주기적 피드백 및 빈번한 테스트 |
2) Agile 방법론 단점
단점 | 내용 |
체계적인 문서화 및 지침 부족 |
- Agile 프로세스 적용을 지원하는 문서화나 구체적인 지침 부족 - 전체 제품에 대한 통합과 테스팅에 대한 가이드가 부족 |
요구사항 변경에 의한 오버헤드 |
- 비기능적인 요구사항에 대한 고려가 부족 - 요구사항의 잦은 변경에 따른 테스트 수행노력 증가 |
사업 관리 부분 미흡 | - 측정지표가 개발자 위주로 상위관리자의 요구를 충족하기 충족하기 어려움 - 프로젝트 리스크 관리 (Risk management)에 대한 고려 부족 |
감리 대응 문제 | - 기존 방법론에 비해 적은 문서량, 감리 기준에 부합되지 않는 산출물로 이슈 발생 |
7. Agile 과 전통적 개발 방법론 비교
구분 | 애자일 개발 방법론 | 전통적인 개발 방법론 |
계획 수립 | - 유동적인 범위 및 상세 요구사항 조정 - 주기적인 상세계획 |
- 확정된 범위, 초기에 상세 요구사항 확정, 초기 일정계획 수립 |
개발 및 테스트 | - 이터레이션 단위로 실행 소프트웨어를 전달(적시설계/개발) | - 분석/설계/구현/테스트를 순차적으로 수행 |
프로세스 View | - 유연하고 간소함 - 프로젝트 상황에 따라 주기적 조정 |
- 정형화되고 상세화됨 |
업무 수행 형태 | - Self-Organizing 팀 - 팀 중심 업무 수행(Collective Ownership) |
- 관리자 주도적 명령과 통제 - 개인단위로 업무 수행 |
조직 | - Cross-Functional Team - 전문가가 다기능을 수행 |
- Functional Team - 분업화되고 역할이 한정 |
팀관리 | - 업무몰입 및 코칭, 팀평가 | - 지시 및 감시, 경쟁, 개별 평가 |
문서화 | - 경량 프로세스 및 문서화보다 코드 강조 | - 중량 프로세스, 상세한 문서화 강조 |
성공요소 | - 고객 가치 전달 | - 계획 준수 |
8. 현대 Agile 방법론
1) Agile 원칙 비교(2001 vs. 2015)
2) 현대 Agile 원칙과 프랙티스
'메가노트 > 토픽과제(정리)' 카테고리의 다른 글
사업타당성 평가(이재용 부장님) (0) | 2022.10.08 |
---|---|
공공소프트웨어 사업영향평가제도(안혜진 선임님) (0) | 2022.10.08 |
반복적 개발모델(문경숙 수석님) (0) | 2022.10.08 |
소프트웨어공학 (0) | 2022.10.08 |
무선랜 보안(배준호) (1) | 2022.10.04 |