📌 애자일(Agile) 방법론
소프트웨어 개발 방식의 하나로 작업 계획을 짧은 단위로 세워 제품을 만들고 고쳐나가는 사이클을 반복함으로써 고객의 요구 변화에 유연하고도 신속하게 대응하는 개발 방법론
애자일의 핵심은 '협력'과 '피드백'
협력
소프트웨어를 개발한 사람들 안에서의 협력
➡️ 협력을 통해 문제가 발생하는 부분을 쉽게 찾을 수 있고 예상치 못한 문제를 막을 수 있음
피드백
어떻게 했는지 확인하면서 학습을 진행해야 함
➡️ 내부적으로는 내가 만든 것이 어떻게 됐는지 확인하고, 외부적으로는 내가 만든 것을 고객이나 다른 부서가 사용해보고 나온 산출물을 통해 또 다른 것을 배워나가는 것
폭포수(Waterfall) 방식
전통적 방법에 속하는 것을 요구분석단계에서 한번에 모든 요구사항을 정확하게 전달하는 것이 원칙
➡️ 변화가 많은 프로젝트에서는 현실적으로 불가능
진행 방법
-
개발자와 고객 사이의 지속적 커뮤니케이션을 통해 변화하는 요구사항을 수용한다.
-
고객이 결정한 사항을 가장 우선으로 시행하고 개발자가 개인의 가치보다 팀의 목표를 우선으로 한다.
-
팀원들과 주기적인 미팅을 통해 프로젝트를 점검한다.
-
주기적으로 제품 시현을 하고 고객으로부터 피드백을 받는다.
-
프로그램 품질 향상에 신경쓰며 간단한 내부 구조 형성을 통한 비용절감을 목표로 한다.
📌 스크럼
➡️ 애자일을 통한 가장 많이 사용하는 개발 방법론
(소프트웨어 측면에서 팀이라는 단어가 주는 의미를 적용시키고 효율적인 성과를 얻기 위한 것)
1. 제품 기능 목록 작성
개발할 제품에 대한 요구사항 목록 작성
(우선순위가 매겨진 사용자의 요구사항 목록)
개발 중 수정이 가능하기는 하지만, 일반적으로 한 주기가 끝날 때까지는 제품 기능 목록을 수정하지 않는 것이 원칙
2. 스프린트 Backlog
스프린트 각각의 목표에 도달하기 위해 필요한 작업 목록
- 세부적으로 어떤 것을 구현해야 하는지
- 작업자
- 예상 작업 시간
최종적으로 개발이 어떻게 진행되고 있는지 상황 파악 가능
3. 스프린트
"작은 단위의 개발 업무를 단기간 내에 전력질주하여 개발한다"
한달 동안의 큰 계획을 3~5일 단위로 반복 주기를 정했다면 이것이 스크럼에서 스프린트에 해당
- 주기가 회의를 통해 결정되면(보통 2~4주) 목표와 내용이 개발 도중에 바뀌지 않아야 하고 팀원들의 동의 없이 바꿀 수 없는 것이 원칙
✔️ 한 주기 = 스프린트(Sprint)
4. 일일 스크럼 회의
규칙
- 모든 팀원이 참석하여 매일, 짧게(15분) 진행 상황 점검
- 한사람씩 어제 한 일, 오늘 할 일, 문제점 및 어려운 점 이야기
- 완료된 세부 작업 항목을 스프린트 현황판에 업데이트
5. 제품 완성 및 스프린트 검토 회의
모든 스프린트 주기가 끝나면 제품 기능 목록에서 작성한 제품 완성
최종 제품이 나오면 고객들 앞에서 시연을 통한 스프린트 검토 회의 진행
- 고객의 요구사항에 얼마나 부합했는가?
- 개선점 및 피드백
6. 스프린트 회고
스프린트에서 수행한 활동과 개발한 것을 되돌아보며 개선점이나 규칙 및 표준을 잘 준수했는지 검토
(단점보다는 강점과 장점을 극대화하는데 초점 두기)
장점
-
스프린트마다 생산되는 실행 가능한 제품을 통해 사용자와 의견을 공유 가능
-
회의를 통해 팀원들간 신속한 협조 및 조율 가능
-
자신의 일정을 직접 발표함으로써 업무 집중 환경 조성
-
프로젝트 진행 현황을 통해 신속하게 목표와 결과 추정이 가능하며 변화 시도가 용이
단점
-
추가 작업 시간 필요(스프린트마다 테스트 제품을 만들기 때문)
-
15분이라는 회의 시간 지키기 힘듦(시간이 초과되면 그만큼 작업 시간 감소)
-
스크럼은 프로젝트 관리에 무게를 두기 때문에 프로세스 품질 평가에는 미약
[참고 자료]
