이번에 한이음 프로젝트에 참여하게 되었는데 우리 팀에서 Agile 방법론을 이용해 개발을 하기로 해서 Agile 방법론에 대해 공부해보았다.
💻 Agile 방법론이란?
앞을 예측하며 개발하지 않고, 일정한 주기를 가지고 계속 검토해 나가며 필요할 때마다 요구사항을 더하고 수정하여 커다랗게 살을 붙이면서 개발하는 프로세스 모델 방식이다.
📌 Agile 방법론은 실질적인 코딩을 위한 방법론이다
💡 진행 과정
- 고객의 피드백 or 서비스 요구사항 발생
- Scrum이나 다른 개발 방법론 등을 통해 스프린트 목표 설정 (Scrum 포스트에서 다룰 예정)
- 다음 릴리즈까지 스프린트 진행
- 배포. (다시 1로)
👆 이 과정을 스프린트라고 하는데 주어진 요구사항을 스프린트에 맞춰 작은 단위로 유연하게 개발하는 방식입니다.
💡 애자일 방법론의 특징
✔ 고객과 개발자의 지속적인 소통을 통하여 변화하는 요구사항을 신속하게 수용한다.
✔ 개발자 개인의 가치보다는 팀의 목적을 우선시하며 고객의 의견을 가장 우선시한다.
✔ 팀원들과의 주기적인 회의 및 제품 시현을 통한 방지를 점검한다.
✔ 진행하면서 프로그램을 시행해보고 고객으로부터 피드백을 받는다.
✔ 내부 구조 형성을 통한 비용절감에 힘쓰는 동시에 프로그램 품질 향상을 위해 노력한다.
💡 스크럼(Scrum)
애자일 방법을 실행하는 도구에는 스크럼(scrum), 칸반(kanban), XP(eXtream Progrmming), LSD(Lean SW Development) 등이 있다.
우리는 이중에서 스크럼을 사용할 것이다
스크럼의 특성
✔ 솔루션에 포함할 기능/개선점에 대한 우선 순위를 부여한다.
✔ 개발 주기는 30일 정도로 조절하고 개발 주기마다 실제 동작할 수 있는 결과를 제공하라.
✔ 개발 주기마다 적용할 기능이나 개선에 대한 목록을 제공하라.
✔ 날마다 15분 정도 회의를 가져라.
✔ 항상 팀 단위로 생각하라.
✔ 원활한 의사소통을 위하여, 구분 없는 열린 공간을 유지하라.
스크럼 용어(Jira 이용)
-
Sprint: 반복적인 개발 주기. 계획 회의부터 제품 리뷰가 진행되는 날짜까지의 기간이 1 스프린트.
-
Epic (큰틀) : 여러 스프린트에 걸쳐서 끝나지 않고, 여러 스토리들의 집합입니다.
-
Story : “{사용자} 로써 {무엇}을 하고싶다” 에 대한 액터의 유즈케이스
-
Chore : 사용자와는 직접적으로 관계되지 않는 개발 (DB 세팅, 분리 등)
-
Task : 구현에는 직접적으로 관련이 없는 업무 (문서작성 등)
-
Issue : 이슈 사항 (서버 다운, 클라우드 계약 등)
-
Bug : 테스트 엔지니어로부터 버그로 리포팅된 타입
-
Sub Task : 스토리 혹은 초어들을 개발하기 위해 진행되는 실제 세부 개발사항들
스크럼 진행 순서
1. 제품 백로그 준비
- Project Owner는 프로젝트 요구사항에 맞추어 Epic들을 생성한다.
2. 릴리즈 계획 수립
- Project Owner는 1단계 에서 생성한 Epic들을 가지고 프로젝트 릴리즈 계획을 세운다.
3. 스프린트 계획 수립
3-1. Task 만들기
- Project Owner와 Scrum Master는 릴리즈 계획에 포함된 Epic들을 Task로 쪼갠다.
- Scrum Master는 만들어진 Task를 팀원들에게 배분한다.
- Scrum Team은 Task의 수행시간을 예측한다.
📌 __고려사항__ ✔ 팀원의 가용 시간 ✔ 각 Task에 대해서 수행 시간 예측 ✔ Task 설정시 구체적인 종결 행위를 기반으로 Task 설정 하는것이 좋습니다. ✔ Task 설정시 분석,설계 / 구현 / 테스트 → 1:1:1 의 리소스 분배가 좋습니다. ✔ 주요 Task에 대해서는 어떤 형식으로든지 리뷰를 하는것이 좋습니다. ✔ Task 기간 설정시 20%의 버퍼를 두는것이 좋습니다.
3-2. 스프린트 만들기
- Scrum Master는 위에서 만든 Task를 2주단위의 Sprint로 조합한다.
- Sprint를 만들때에는 Task의 __긴급도, 난이도__에 따라 우선순위를 두고 작업 순서를 정한다.
3-3. Task 작업
- Task를 할당받은 Scrum Team은 Task를 실제 작업의 세부단위로 Sub-task를 작성하여 작업을 진행한다.
5. 스프린트 종료
- 스프린트의 정해진 기간 단위로 스프린트를 종료한다. 만약 Task의 이슈사항으로 마정해진 기간내에 마무리 하지 못했다면 해당 Task를 다음 Sprint로 넘긴다.
- Team은 Task의 구현이 테스트까지 완료되엇을 때 Task가 종료되어야 한다
- Team은 종료일에 일일 스크럼대신 스프린트 리뷰 진행
- Project Owner는 완료된 스프린트의 작업사항들을 통해 Q&A 진행
6. 백로그 업데이트
- Project Owner는 스프린트 리뷰 결과를 반영하여 백로그를 업데이트 한다.
7. 회고
- Team은 스프린트 작업에 대한 리뷰가 아닌 스크럼 자체에 대한 리뷰를 진행해 더 좋은 스크럼 프로세스를 찾아 개선해 나간다.
8. 스프린트 재시작
- 스프린트 계획을 수립하는 3단계 부터 다시 시작한다.
