SW 방법론에서의 Agile 정의
- 짧은 주기의 개발 단위를 반복하며 프로젝트를 완성해가는 것
- 스프린트 단위(디자인 -> 개발 -> 테스트)를 반복
고객과 개발자의 지속적인 소통으로 변화하는 요구 사항을 신속하게 반영 가능
개인보다는 팀의 목적을 우선시, 고객의 의견을 가장 높은 가치로 둔다.
팀원들의 주기적인 회의 및 제품 시현을 통해 잠재적인 버그 수정과 미흡한 기능 추가 가능
프로젝트를 진행하면서 고객으로부터 즉각적인 피드백을 통한 수정, 보완 가능
팀원들의 주도적이며 자발적인 개발 문화로 프로그램 전체의 품질 향상에 기여 가능
Agile 개발의 등장 배경
폭포수 개발론 - 가장 오래된 SW 개발론
- 요구 사항이 바뀌거나 수정하려면 다시 맨 처음부터 수정해야 하는 불편함 존재
이러한 단점을 극복하기 위해, agile이 등장하게 됨
Agile 선언문
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다.
이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다.
- 공정과 도구보다 개인과 상호작용을
- 포괄적인 문서보다 작동하는 소프트웨어를
- 계약 협상보다 고객과의 협력을
- 계획을 따르기보다 변화에 대응하기를
이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.
| 워터폴 방법론 | 애자일 방법론 | |
| 요구사항 | 초기 단계에서 명확하게 파악 | 지속적으로 요구사항을 반영 |
| 특징 | - 요구사항 분석 및 문서화에 시간이 오래 소요될 수 있음 - 고객의 요구사항이나 피드백에 대한 대응이 느림 |
- 문제 해결을 위해 팀원들 간 소통과 협업 중요 - (문서화 x) |
| 적합한 경우 | - 요구사항이 매우 디테일하고 명확한 프로젝트 - 변화가 적고 유동성이 낮은 프로젝트 - 큰 규모의 제품 런칭, 메인 기능 개발 등에 적합 - B2B 프로젝트 (은행권 업무, POS 프로그램, 키오스크 등) |
- 사용자의 피드백을 수집하고, 빠르게 개선이 필요한 경우 - 요구사항이 변경되거나 문제 발생이 잦은 프로젝트 - 고객, 시장의 변화에 빠르게 대응해야 하는 기업 - B2C 프로젝트 (게임, 배달 앱 서비스, 대부분의 앱 프로그램) |
애자일 방법론의 장점
- 프로젝트의 계획에 걸리는 시간을 최소화 가능
- 반복적인 테스트로 잠정적인 버그를 쉽고 빠르게 개선 가능
- 계획 변경이나 기능 추가에 유연함
- 고객의 요구 사항에 대한 즉각적인 피드백에 유연하게 프로토타입 모델을 빠르게 출시 가능
- 빠듯한 출시 일정에 비교적 빠르게 제품 출시 가능
애자일 방법론의 단점
- 확정되지 않은 계획 및 잦은 요구사항 변경으로 인한 반복적인 유지 보수 작업이 많음
- 고객의 요구 사항 및 계획이 크게 변경될 경우, 모델 자체가 무너질 수 있음
- 팀 중심의 개발로 인한 공통 작업의 리소스 투입이 많음 (회의, 로그 등)
- 반복적인 업무로 개발 속도는 빠를 수 있으나 번아웃 현상이 쉽게 올 수 있음
- 확정되지 않은 계획으로 인해 개발 진행에 대한 정확한 이해 부족 발생 가능
MVP (최소 기능 제품; Minimum Viable Product)
고객이 원하는 제품의 최소한의 기능을 정의
- 최소 비용으로 빠르게 만드는 "핵심 기능" 만을 담은 제품
- 수익성 판단을 위한 시간과 비용 절감 측면에서 매우 효율적
- 사업 리스크 최소화 : 실패하더라도 괜찮아!
스프린트 (Sprint)
팀이 일정량의 작업을 완료하기 위해 정해진 짧은 기간, 기업에서는 보통 2주 정도의 기간으로 시작
스크럼 (Scrum)
정해진 스프린트 내에 실제 행해져야 하는 개발 업무
- 제품 백로그 작성 : 고객 및 프로젝트 이해관계자들의 의견을 취합하고 업무의 우선순위를 매기는 작업
- 스프린트 백로그 작성 : 스프린트 내에 각 팀원들이 해야 할 업무의 리스트를 만드는 작업
- 데일리 스크럼 미팅 : 만들어진 리스트를 바탕으로 매일 진행한 업무를 보고하고 공유하는 작업
- 개발 및 테스트 : 팀원들이 실제 맡은 영역을 개발, 테스트 하는 작업
- 스프린트 리뷰 및 회고 : 스프린트 내에 만들어진 결과물을 통해 장&단점을 분석하고 더 나은 방향으로 개선하는 작업
테스트 주도적 개발 (Test Driven Development)
- 모든 것을 만들고 예측하기에는 시간이 부족
- 실제 필요한 기능만 만들고, 그 기능이 제대로 동작하는 지 코드 기반으로 테스트
- 잘 동작하는 것이 확인되면 코드 리팩토링 및 모듈화
데브옵스 (Dev + Ops)
개발과 운영을 동시에 하자! (폭포수는 개발 후 운영)
- 새로운 소프트웨어 기능 개선, 버그 수정 시 바로 배포함으로써 빠른 피드백 가능
- 지속적 통합 및 연속 배포 (CI / CD) 구축
요약 및 정리
그래서 애자일 어떻게 하는건데?
1. 데일리 스크럼
팀원들과 "팀 단위 학습"과 "밀도 높은 협업"을 위해 매일 오전 스크럼을 진행
- 매일 오전, 팀원들과 프로젝트(학습) 상황과 계획을 공유한다.
- 오늘 할 일을 포함하여 팀원들에게 공유하거나 도움이 필요한 상황, 논의하고 싶은 주제를 공유
- 팀 별로 12분을 넘기지 않는다 (2분 / 1인)
2. 스프린트 세션 (회고)
한 주간의 우리 팀의 프로젝트 수행 현황을 객관적으로 되돌아보며, 각 관점에서 이야기를 나누어 다음 주 실행 가능하고 측정 가능한 aciton을 도출
KPT 회고 (예시)
Keep
- 현재 만족하고 있는 부분
- 계속 이어갔으면 하는 부분
- 좋았던 점을 기반으로, 앞으로 프로젝트를 진행할 때 계속 유지해야 할 사항
ex) Jira 스프린트 종료 후 구성원들이 돌아가며 피드백했던 것, 컨벤션 상세화해서 가독성 높인 것, 서로 코드 리뷰해줬던 과정, 트러블 슈팅한 것을 노션에 상세히 정리한 것, .. 등
Problem
- 불편하게 느끼는 부분
- 개선이 필요하다고 생각되는 부분
- 아쉬웠던 점을 기반으로 앞으로 프로젝트를 진행할 때 개선해야 할 사항
- 단순히 일어난 사건 뿐 아니라, 해당 결과에 이르기까지의 과정을 정리
ex) 시간의 부족으로 같은 플젝 안에서 자신의 영역 외에는 잘 모르고 지나친 것, 기능구현을 위해 찾은 코드를 복붙만 해서 이해도가 낮아 문제해결능력 부족, 트러블 슈팅 후 기록없이 넘어가서 같은 이슈 발생 시 바로 해결하지 못하고 시간을 낭비, .. 등
Try
- Problem에 대한 해결책 제시
- 다음 회고 때 판별 가능한 것
- 자신의 행동으로 제어 가능한 것
- 회고 직후, 실행 가능한 것
ex) 깃에 리드미나 위키에 프로젝트 진행상황 상세하게 기록 후 팀원과 공유, commit 메시지를 직관적으로 작성, 그날 그날의 트러블 슈팅 기록하기, 무중단 배포 시스템 구축하기, 이슈 세분화해서 할당하고 진행상황 공유하기, .. 등
주의할 점 : 구체적이고 실천 가능해야 한다
- 나쁜 예
- Problem : 이번에 소통이 안 돼서 장애가 났습니다
- Try : 공유를 잘 합시다
- 좋은 예
- Problem : 광고 상품이 추가될 떄 유관 부서에 공유가 누락되어 데이터 정합성이 안 맞았습니다.
- Try : 상품을 추가하는 코드하 호출되면, 유관 담당자에게 자동 발송하는 기능을 추가합시다.
팀 별 회고 진행 후, 회고 기록을 공유
3. 백로그 작성
백로그는 개발 작업의 전체 목록을 의미
- 백로그에는 요구사항에 대한 기능, 작업, 버그 등을 작업의 우선순위를 포함해 상세히 작성
- 칸반보드 혹은 간트차트를 활용해 작업 진행 상황을 관리할 수 있음
칸반 보드 (Kanban Board)
Back Log(목록), To do(할 일), In Progress(진행 중), Done(완료) 열로 나뉘어 태스크를 업무의 진행 상황에 맞게 옮길 수 있도록 시각화한 프로젝트 관리 방법
- 작업 속도와 처리량 향상 : 프로젝트 흐름을 쉽게 파악할 수 있다.
- 과도한 일정으로 인한 병목 현상 방지 : 한 번에 수행할 작업량 조절 가능
간트 차트 (Gantt Chart)
프로젝트 진행 상황과 종속성을 가로막대 그래프로 시각화한 방법
- 프로젝트를 한눈에 쉽게 파악하고 작업 종속성을 파악할 수 있음
- 진행 상태 추적이 편해서 일정 관리가 용이
'IT_Study > Team Project' 카테고리의 다른 글
| [특화 PJT] 게임 통신 방식에 따른 서버 분류 및 WAN 환경에서 유저 연결 시 문제점 (0) | 2023.09.20 |
|---|---|
| [특화 PJT] Data Flow 설계기법 (0) | 2023.08.29 |
| [공통 PJT] 코드 리뷰 방법 정리 (0) | 2023.07.07 |
| [공통 PJT] Jira 및 JQL 활용 / Project Management 방법론 (0) | 2023.07.06 |