애자일

기존의 폭포수 방식은 프로젝트 기획 단계에서 기간을 산정하여 순차적으로 진행되어 프로젝트가 끝나기 전까지 결과물 확인이 불가능하다. 따라서 기획가 맞지 않은 개발이 진행될 수도 있다. 반면, 애자일은 전체적인 기간 산정이 중요하지 않다. 일정한 주기의 루틴을 가지고 빠르게 제품을 출시하여 고객의 요구사항, 변화된 환경에 맞게 요구를 더하고 수정해나가는 탄력적인 방법론이다.

 

구성원

PO(Product Owner)

• 기능적으로 회사의 이익을 가져올 사업부 같은 느낌! (MD나 마케터 같은 역할)
• 기능에 대한 방향성을 담당
• 의사결정자

PM(Project Manager)

• 프로젝트 매니저
• 실제로 결과물을 만드는 사람들을 관리
• 스크럼 팀원들과 소통하지 않고 SO와 소통

Scrum

• 실제로 결과물을 만드는, 프로젝트를 담당하는 하나의 독립된 팀 단위
• 스크럼 팀에는 개발자, 테스터, 디자이너, UX 전문가 및 운영 엔지니어가 포함됨

SO(Scrum Owner)

• 스크럼 팀원들을 관리

 

 

애자일 단계

'애자일 프레임워크' 라고 하며 정해진 과정과 틀에 따라 동작하여 성공적으로 프로젝트를 완성하기 위한 메커니즘

---

스프린트 플래닝

• 어떤 기능을 만들지, 얼마나 걸릴지, 복잡도는 얼마나 되는지 논의 하여 하나의 스프린트를 만드는 것

• 기능의 부피 → 에픽 > 유저스토리 > 스프린트

에픽(Epic): 큰 볼륨의 기능 단위

유저스토리(User Story): 스프린트 플래닝의 핵심 내용이 될 기능 명세서,
     PO가 작성하며 구현해야할 기능에 대한 내용을 작성한 시나리오를 말한다.

스프린트 포인트(Sprint Point): 유저스토리에 대해 평가를 매기는 것, 
     보통 1~5점으로 매기는데, 유저스토리를 작업하는데 걸리는 시간을 수치화 하여 포인팅 하는 것
     SO는 스프린트 플래닝 전, 각 팀원들의 하루에 정해진 근무 시간 내에 스프린트 기간동안 가능한 업무
     시간을 미리 조사하여 이 포인팅을 조절한다.

AC(Acceptance Creteria): 유저스토리에 대한 동의서,
     유저스토리를 완료 처리하기 위해 충족해야 하는 미리 정의된 요구 사항 집합

스프린트

• 보통 2주 단위로 이루어지는 하나의 기능을 만들기 위한 작업 단위

데일리 스크럼

• 스크럼은 매일 오전에 짧은 미팅을 한다. 어제 했던 일은 무엇이고 오늘은 무엇을 할건지 또는 어떤 문제가 있는지 공유하게 된다.
• 이를 통해 스프린트 진행에 문제가 있다고 판단되면 ‘트럼 미팅’을 통해 SO는 PM과 협의 하여 해결 방법을 찾는다.

데모 리뷰

• 스프린트 하나가 끝날 쯤 데모 리뷰를 통해 기획에 맞게 구현이 제대로 되었는지 PO와 함께 확인 과정을 거침

각 스크럼은 데모 리뷰 며칠 전부터 코드 커밋과 코드 리뷰를 체크하고 각 스크럼의 코드를
합치는데. 합치는데 걸리는 시간을 단축하기 위해 CI/CD를 구성한다.
(2주 마다 이루어지는 스프린트에 대응하기 위해 각 스크럼이 구현한 코드들은 빠르게 합쳐저
하나의 기능이 완료되어야 하기 때문에 시간 단축은 애자일에서 굉장히 중요하다.)

 

간단하게 정리해보았지만 애자일은 생각보다 굉장히 체계적이고 촘촘하다. 그리고 우리나라의 기업은 미국과 같은 세계적인 빅테크 기업들에 비해 애자일을 제대로 사용하고 아는 기업은 몇 안된다고 한다. 그래서 애자일에 대해 제대로 알려면 해외 글들을 찾아보는게 좀 더 정리가 잘되어 있고 자세히 알 수 있다.

 

참고 ->

(아래에 첨부한 글만 보아도 굉장히 세세하고 단계별로 진행되는 것을 알 수 있다.)

https://www.atlassian.com/ko/agile/manifesto

소프트웨어 개발을 위한 애자일 매니페스토 | Atlassian