[🐾놀멍 회고] 3. 10일 동안 640명이 쓴 서비스 만들기(1) | 애자일 방법론(Scrum), 유레카 최종 프로젝트 우수상

이 게시글은 이효린의 애자일 방법론 적용기시리즈 중 하나입니다.

1.[🚖모여타 회고] 1. 좋은 팀원을 만나기까지 | 팀 구성, 팀원 모집의 과정
2. [🚖모여타 회고] 2. 이름뿐인 애자일 | MVP? MXP!
3.[🐾놀멍 회고] 3. 10일 동안 640명이 쓴 서비스 만들기(1) | 애자일 방법론(Scrum), 유레카 최종 프로젝트 우수상

4. [🐾놀멍 회고] 4. 10일 동안 640명이 쓴 서비스 만들기(2) | 서비스 배포 과정, 유레카 최종 프로젝트 우수상

 

 

이전 글에서 실패한 애자일 프로세스 경험을 공유해드렸는데요,

그때의 경험을 반면교사 삼아 ‘놀멍’ 프로젝트에서는 애자일 프로세스를 성공적으로 적용했습니다.

 

그 결과, 서비스 운영 10일 만에 640명의 유저를 확보하며 초기 목표를 크게 초과하며 달성할 수 있었습니다.

 

이번 글에서는 ‘놀멍’ 프로젝트에서 사용한 애자일 프로세스의 구체적인 적용 방법를 공유하고자 합니다.

성공적인 애자일 도입을 고민 중인 분들께 도움이 되길 바랍니다 !

 

 

모여타의 문제점을 개선했나요 ?

문제 1. 쉽지 않은 일정관리

모여타 프로젝트에선 팀원들이 모두 학생 신분이었기 때문에 일정 관리가 쉽지 않았습니다. 그러나 이번 프로젝트는 부트캠프에서 진행한 프로젝트였기 때문에 팀원 모두 프로젝트에만 몰입해 개발할 수 있는 환경이었습니다.

 

문제 2. MVP가 아닌 MXP

최종 프로젝트에 참여하며 가장 중요하게 생각한 부분이 "1차 MVP엔 정말 최소 기능만 넣자 !" 였습니다. 

유레카 측에서 주제 4개, 그리고 각 주제에 대한 세부 과업들을 제시해주었습니다.

 

전 여기서 세부 과업이 가장 적은 '반려견 동반 가능 시설 공유 서비스' 주제를 택했습니다. 

 

전 제시된 세부 과업만으로 1차 MVP를 출시하는 것이 옳다고 판단했습니다.

그러나 모든 팀이 의욕적으로 추가 기능 기획에 나서는 분위기에 영향을 받아, 우리 팀도 추가 기능에 대해 고민하게 되었습니다.

 

 

추가 기능 기획 원칙

 

 

1차 MVP에 포함될 추가 기능은 ‘추가’라는 이름에 걸맞으면서도
반드시 핵심 기능의 연장선이어야 한다.

 

위 원칙은 추가 기능을 기획할 때 저희 팀이 철저히 지켰던 기준이었습니다.

 

추가 기능을 통해 팀의 차별성을 강조하고 사용자 경험(UX)을 향상시키는 것이 중요했지만, 너무 많은 기능을 추가하면 또다시 MVP가 아닌, MXP로 변질될 위험이 있었습니다.

 

이를 방지하기 위해 위 원칙을 기반으로 기획을 시작하게 되었습니다.

 

저희 팀은 기본 세부 과업 중 하나인 리뷰 기능을 변형해,

일기 + 리뷰 기능을 결합한 ‘오늘멍’이라는 독창적인 기능을 기획했습니다.

 

이를 통해 세부 과업만으로 MVP를 출시하는 원칙을 지키면서, 우리 팀만의 차별화 요소를 추가할 수 있었습니다.

 

결과적으로, 이러한 MVP 개념에 대한 명확한 원칙과 이를 기반으로 한 전략이 ‘놀멍’의 성공 요인이었다고 생각합니다.

 

문제 3. 기획의 문서화 부족

MVP 기획을 완료한 후, 바로 디자인 작업에 착수했습니다.

UI 디자인을 진행하는 동시에 이를 참고하여 요구사항 정의서와 API 명세서를 작성했습니다.

 

[요구사항 정의서]

• 기능 분류, 상세 기능 설명, 중요도, 개발 담당자 등을 명시했습니다.
• 이 덕분에 정확히 어떤 기능이 어떠한 상황에서 어떤 동작을 해야 하는 지 팀원 모두 공감할 수 있었습니다.
• 이를 기반으로 팀 전체가 같은 목표를 공유하며 효율적으로 작업을 진행할 수 있었습니다.

[API 명세서]

• 초안 작성: 백엔드 개발자가 1차적으로 작성했습니다.
• 공유 및 논의: 프론트엔드 개발자와 함께 검토하며 아래 항목을 점검하였습니다.
  • API의 요청 값과 응답 값
  • HTTP 메서드(GET, POST, PUT, DELETE 등)
  • 응답 코드(200, 404, 500 등)
  • 예상되는 오류 상황 및 핸들링 로직

• 효과: API 명세를 함께 작성함으로써 다음과 같은 이점이 있었습니다.
  • 프론트엔드와 백엔드 간 데이터 구조 및 동작 정의 명확화.
  • 데이터 통신 과정에서 발생할 수 있는 문제 사전 조율
  • 개발 과정에서 테스트 기준으로써 활용
  • 추가 기능 개발 시 참조 문서로 사용

 

저희 팀 백엔드 팀원 분들께서 문신(문서의 신)이셔서 정말 수월하게 위의 문서들을 빠르고 정확하게 작성할 수 있었습니다.

 

또한 개발 시작 전, 팀원들과 함께 API 명세서를 작성함으로써 API First Design을 적용할 수 있었습니다,.

 

 

---

놀멍에서의 애자일은 어땠나요 ?

놀멍에서 저는 스크럼마스터로서 팀이 애자일 프로세스를 효과적으로 실행하고 유지할 수 있도록 다음과 같은 노력을 했습니다. 

 

1. 애자일 문화 정착

애자일 프로세스를 처음 접하는 팀원들도 많았기에 애자일 프로세스, 스크럼, 스프린트 개념을 설명하는 시간을 가졌습니다.

특히 놀멍에선 Jira를 이슈 및 일정관리 용도로 사용할 예정이었기 때문에, Jira 사용법에 대해서도 설명했습니다.

 

덕분에 팀원들은 빠르게 Jira 사용법을 익힐 수 있었고, 애자일 프로세스에 대해서도 빠르게 적응할 수 있었습니다.

 

2. 마일스톤 설정

이렇게 짧은 기간동안 진행하는 프로젝트일수록 마일스톤을 설정 및 일정관리가 매우 중요하다 생각합니다.

따라서 프로젝트 초기 단계에서 명확한 마일스톤을 설정하고 이를 팀원들과 공유함으로써 모든 팀원이 프로젝트의 큰 그림과 목표를 이해하도록 했습니다.

 

마일스톤은 개발 과정에서의 주요 단계를 기준으로 설정하였으며, 각 마일스톤마다 명확한 산출물과 기한을 정의했습니다.

 

대략적으로 설계한 마일스톤은 다음과 같았습니다.

1주차: 프로젝트 기획 및 주요 기능 정의, 와이어프레임 설계
2주차: 세부 디자인 완성 및 UI 개발
3주차: UI 개발 완료 및 주요 API 연결
4주차: 모든 API 연결 완료
5주차: 최종 테스트, 내부 QA, 유저테스트 및 서비스 배포
6주차: 사용자 피드백 반영 및 버그 개선

 

이와 같이 마일스톤을 설정한 뒤, 진행 상황을 주기적으로 점검하고 필요한 경우 일정을 유연하게 조정했습니다.

이를 통해 팀원들은 각 단계의 목표를 명확히 인지할 수 있었습니다.

 

마일스톤 설정을 통해 단순히 목표를 나열하는 것을 넘어, 각 팀원의 작업 일정을 체계적으로 계획할 수 있었습니다. 

저는 마일스톤 설정이 기능을 목표했던 기간 내에 차질 없이 구현하고, 프로젝트 계획을 따르는 데 큰 도움이 되었다고 생각합니다.

 

3. 스프린트 및 데일리 스크럼

스프린트 계획

스프린트 계획 회의땐 스프린트 기간과 목표를 정했고, 팀원들의 스프린트 기간동안의 가용시간 및 방해요소를 공유하는 시간을 가졌습니다.

 

아래 사진은 실제 저희 스프린트 계획 회의록입니다.

 

 

스프린트 기간은 기본 일주일이지만, 상황에 따라 3~4일 정도로 조정했던 스프린트도 있었습니다.

스프린트 목표는 이전 스프린트 회고 때 이야기 한 Try요소를 이번 스프린트의 목표로 설정하였습니다. 

가용시간은 팀원들이 스프린트 기간동안 쓸 수 있는 가용시간을 책정했고, 이를 바탕으로 테스크를 할당하였습니다.

방해요소는 팀원들이 스프린트 기간동안 작업에 방해되는 요소들을 공유하였고, 이를 고려하며 협업을 진행했습니다.

 

 

데일리 스크럼

스프린트가 시작된 후, 스프린트 기간 동안 매일 데일리 스크럼을 진행했습니다.

데일리 스크럼에서는 팀원들이 이번 스크럼까지 완료한 작업, 다음 스크럼까지 해야 할 작업, 그리고 작업에 방해가 되는 요소를 공유하는 시간을 가졌습니다.

 

이를 통해 팀원들은 각자의 진행 상황을 투명하게 공유하며, 프로젝트의 전반적인 상태를 명확히 파악할 수 있었습니다.

특히, 방해 요소를 논의함으로써 문제를 빠르게 해결하거나 우선순위를 조정하는 등 팀 차원에서 신속하게 대응할 수 있었습니다.

 

예를 들어

API 응답 값에 필요한 데이터가 누락되어 프론트엔드 기능 개발이 지연되는 문제가 있었습니다.

이 문제를 데일리 스크럼에서 공유한 뒤, 담당 백엔드 개발자께서 해당 API 수정 작업을 최우선 테스크로 설정해주셨습니다. 곧바로 API를 수정해주신 덕분에 문제를 신속히 해결할 수 있었고, 프론트엔드 개발도 계획대로 진행할 수 있었습니다.

 

이러한 빠른 문제 공유를 통해 팀은 작업의 우선순위를 유연하게 조정할 수 있었으며, 결과적으로 프로젝트 일정에 차질을 빚지 않고 효율적으로 작업을 이어갈 수 있었습니다.

 

 

 

스프린트 리뷰

스프린트 리뷰에서는 각 파트별로 진행 상황과 결과물을 공유하며, 설정한 스프린트 목표가 달성되었는지 확인하는 시간을 가졌습니다.

 

프론트엔드 팀

• 개발이 완료된 화면을 시연하거나, 디자인 작업물의 결과를 팀원들과 공유했습니다. 이를 통해 구현된 기능과 화면이 기획 및 디자인 의도에 맞는지 점검할 수 있었습니다.

백엔드 팀

• ERD나 Swagger 문서를 활용하여 작업 내용을 공유하며, API 설계 및 데이터 구조가 요구사항에 적합한지 검토했습니다.

 

이러한 스프린트 리뷰를 통해 각 팀원은 다른 파트의 진행 상황을 이해하고, 필요한 피드백을 즉시 반영할 수 있었습니다.

 

 

스프린트 회고

스프린트 회고에선 KPT 회고 방법을 적용했습니다.

 

Keep(유지할 점)

• 이번 스프린트에서 효과적이었던 부분과 계속 유지해야 할 사항을 논의했습니다.
• 예) 데일리 스크럼에서 문제를 공유하며 빠르게 해결했던 경험이 아주 효율적이고 좋았습니다.

 

Problem(문제점)

• 작업 중 발생한 문제와 스프린트 진행에 방해가 되었던 요소들을 공유했습니다.
• 예) 재택 / 지각하는 팀원이 Slack 답장을 빠르게 해주지 않아 소통의 불편함을 느꼈습니다.

 

Try(시도할 점)

• 다음 스프린트에서 새롭게 도입하거나 개선할 방법에 대해 의견을 나누었습니다. 이땐 위에서 언급한 K와 P를 참고해 작성했습니다.
• 예) "방해요소가 있으면 빠르게 공유합시다", "Slack 답장 빠르게 부탁드립니다." 등

 

KPT 회고를 통해 팀원들은 스프린트의 강점과 약점을 명확히 파악하고, 다음 스프린트에서 더욱 효율적으로 작업할 수 있는 방안을 도출할 수 있었습니다.

 

이 덕분에 우리 팀은 매 스프린트마다 지속적으로 성장할 수 있었습니다.

 

4. 작업 관리

위에서 언급했듯이, 가용 시간을 기반으로 작업을 할당하고 관리했습니다. .

아래 사진은 제가 참여하고있는 다른 프로젝트의 스프린트 백로그인데, 이를 보며 같이 이야기 해보겠습니다.

 

스프린트 백로그 작성

• 스프린트 계획 회의에서 스프린트 백로그를 작성합니다.
• 각 팀원은 자신이 맡은 작업을 검토하고, 해당 작업을 완료하는 데 필요한 시간을 스토리 포인트로 작성합니다.

작업 우선순위 조정

• 팀원 각각 모든 작업의 스토리 포인트 총합(전체 작업 시간)을 계산하고, 이를 스프린트 가용시간과 비교 후 작업 우선순위를 조정합니다.
• 예를 들어, 한 팀원의 가용 시간이 18시간인데 스토리 포인트 총합이 25시간이라면, 이번 스프린트에서 모든 작업을 완료할 수 없음을 의미합니다.
• 이런 경우, 우선순위가 낮은 작업은 다음 스프린트로 이동하거나, 시간이 여유 있는 다른 팀원에게 작업을 재할당하여 팀 전체의 작업량을 조정했습니다.

 

5. 팀 간 협업 환경 조성

페어프로그래밍

• 중요한 기능 개발이나 복잡한 로직 구현 시 페어 프로그래밍을 도입했습니다.
• 두 명의 개발자가 하나의 작업을 함께 진행하며, 한 명은 코드를 작성하고 다른 한 명은 이를 검토하거나 개선점을 제안했습니다.
• 이를 통해 코드 품질을 향상시키고, 팀원 간 지식 공유와 문제 해결 속도를 높일 수 있었습니다.

코드 리뷰

• 작업이 완료된 후에는 PR을 올리고, 코드 리뷰를 하며 코드의 품질과 유지보수성을 점검했습니다.
• 팀원들이 서로의 코드를 검토하며 버그를 사전에 발견하고, 최적화된 코드 작성에 기여했습니다.
• 리뷰를 통해 팀원들은 서로의 코드를 이해하고 개발 기술과 접근 방식을 공유할 수 있었으며, 이를 통해 개발 역량을 상호 발전시키는 기회가 되었습니다.
• 리뷰 과정에서 발생한 논의는 팀원 간 원활한 의사소통을 가능하게 했으며, 협업 효율을 높이는 데 크게 기여했습니다.

 

6. 그래서, 결과는?

애자일 프로세스를 도입함으로써 목표했던 '5주차: 서비스 배포'를 성공적으로 달성할 수 있었습니다.

짧은 개발 주기를 가진 스프린트를 반복하며 각 단계의 목표를 명확히 설정하고 팀원들과 협력한 결과, 프로젝트 일정에 맞춰 모든 기능을 안정적으로 구현할 수 있었습니다. 

 

 

다음 글은 서비스 배포를 준비하는 과정과 실제 배포 이후 있었던 일들에 대해 공유하는 글을 작성하도록 하겠습니다 😊