에자일 방법론을 직관적으로 이해하기

에자일 프로세스에 대한 얘기는 주기적으로 들어왔고 내가 프로젝트를 하면서 주 단위로 계획하고 진행했던 개발 프로세스가 에자일 프로세스와 연관되어있다고 생각되어 한번 정리해보려고 한다. 이를 위해 'UX 개론 2장-불확실성에 민첩하게 대처하라' 를 읽고 추가로 궁금한 것들을 정리해보려고 한다!!!

 

💡 에자일 방법론이란?

한정된 기능만 탑재한 첫 번째 버전을 최대한 빠르게 만들어 사용자의 평가를 반영하고, 그 후 개발을 진행하면서 사용자의 실질적 욕구에 맞춰 제품을 수정해나가는 방법. 이 때 에자일 방법론 중 가장 잘 알려진 모델은 스크럼이다. 

 

💡 스크럼이란?

프로세스의 경험적 관리, 즉 경험주의(경험을 통해 배울 수 있다고 믿는 것)에 기초한 이론이다. 스크럼은 반복적이고 점진적인 접근법으로, 예측성을 확보하고 리스크를 통제하는 데 유용하다.

 

💡 에자일 조직의 지향점

1. 프로세스나 도구보다 각 개인과 개인 간의 상호 교류를 중시함.

2. 포괄적 문서보다 실제 작동하는 소프트웨어를 신뢰함.

3. 계약 협상보다 고객과의 협업을 중시함.

4. 계획을 따르기보다 변화에 적응함.

 

에자일 프로세스는 여러 개의 스프린트로 구성된다. 스프린트는 하나의 개발주기를 의미하며 프로젝트의 특성에 따라 2~4주간 진행된다. 스프린트 중에는 스프린트 백로그(요구사항 목록)을 수정할 수 없다. 하나의 스프린트 주기가 끝나면 새로운 기능이 추가된 결과물이 도출될 것이고, 새롭게 시작되는 주에는 새로운 스프린트가 시작될 것이다.

 

💡 에자일 프로세스 과정

 

1. 스프린트 : 최소 반복 주기

2. 스프린트 계획 회의 : 스프린트 시작점에서 계획을 세우는 회의. 개발팀은 스프린트를 통해 어떤 결과를 도출할 것인지 목표 세움.

3. 일일 스크럼 회의 : 매일 열리는 회의. 팀원들은 전날 한 일과 오늘 할 일을 발표한다. 팀원 간 상호작용을 통해 동기화를 하는 과정이다.

4. 데모 : 스프린트가 끝나면 개발팀은 PO에게 프로토타입을 제출하고 PO는 프로토타입이 본래의 기대를 충족하는지 확인한다.

5. 회고 : 데모가 끝나면 스프린트를 회고하며 수행이 잘된 부분과 개선점을 정리한다.

 

출처 https://www.atlassian.com/ko/agile/scrum/sprints

위의 이미지에서 스프린트 회고가 끝나면 다시 스프린트 백로그로 돌아가 또다른 스프린트를 시작하는 반복과정을 한눈에 확인할 수 있다.

 

💡 백로그란?

기능을 우선순위에 따라 나열해놓은 목록. 아래와 같이 두 가지로 나눌 수 있다.

 

1. 프로덕트 백로그 : 제품에 포함될 모든 기능의 목록

2. 스프린트 백로그 : 스프린트의 결과물로서 개발될 기능의 목록.

 

💡 에자일 프로세스의 예시

여기서부턴 내가 경험했던 에자일 프로세스의 예시이다.

 

1. 백로그 작성

 

먼저 내가 이전에 참여했던 프로젝트 Finble의 경우에는, 다음과 같이 백로그를 관리하였다. 이 때 우선순위를 두고 개발하였고 우선순위에 따라 MVP에서의 구현여부를 결정하였다.

 

2. 테스트 개발

 

본격적인 개발기간을 시작하기에 앞서 실현 가능한지 테스트 개발을 진행했다. 약 2주간 진행했으며, 이 때 구현가능한 기능과 개발리소스가 많이 들어가는 기능을 구분하여 후의 개발계획 수립에 이 결과를 반영하였다.

 

 

3. 일일 스크럼 아닌 주간 스크럼 회의

 

약 6주간 개발을 진행하면서 다소 밀도있게 진행했음에도 불구하고, 일일스크럼은 하지 않았고 주간 스크럼 회의를 진행했다. 팀원들이 매주 세워놓은 계획을 밀리지 않고 진행했기에 주간 스크럼으로도 충분했던 것 같다. 주간 스크럼 회의 외에도 거의 매일 슬랙을 통해 개발, 디자인, 기획 간의 소통을 진행했으니 가능했던 일인가 싶기도 하다. 

 

슬랙 채널은 오른쪽과 같이 세분화되어있었는데, 몇몇 채널은 아예 사용을 하지 않았다.. 네이밍의 중요성

나는 프론트엔드 개발자였기 때문에 design, dev-all, dev-front 에서 많이 배회했던 것 같다.

 

💡 정리

다소 서비스 완성 기간이 촉박하다면, 에자일 프로세스를 좀 더 차용해도 좋을 것 같다. 주간 스크럼을 하는게 아니라 일일 스크럼을 한다던가, 백로그를 하나로 관리하지 않고 스프린트 백로그, 프로덕트 백로그로 나눈다던가 등등...

 

애매했던 에자일 프로세스 개념을 이렇게 내가 했던 프로젝트에 대입해서 보니 이해가 더 잘되는 것 같기도..! 다음엔 좀 더 밀도있는 에자일 프로세스를 차용해보는 것을 목표로 해보잣 ㅎㅎ