📍 스크럼은 무엇인가!

Agile은 방법론 보다는 방향성(?)에 가깝다고 생각한다. 프로젝트의 우선순위를 세우는 것을 최우선으로 하자! 작은 기능들부터 시작해서 시장의 검증을 통해 작은 개발 싸이클을 iterative하게 하자! 같은 방향성, 혹은 사상같은 느낌이다.

따라서 agile하게 개발하기 위한 여러 구체적 프로세스가 나왔고, 그 중 하나가 이번에 우리가 하게 된 Scrum이다!
개발 언어와 상관없이 효율적인 프로세스이며, 심지어 개발 프로세스가 아닌 프로젝트에도 적용하면 효율적으로 프로젝트를 관리할 수 있다고 한다.

위의 그림과 같이 크게 3가지의 role이 있다.

• Product Owner
• Scrum Master
• Development Team

스크럼에선 프로젝트를 단위 시간별로 나누고 아래와 같은 이름으로 부른다

프로젝트 전체 시간: Scrum
이것을 일주일 단위로 쪼개서: sprint (보통 1~4주 간격으로 나눈 하나의 개발 cycle을 sprint라고 한다)
이것을 다시 하루 단위로 쪼개서 : Daily Scrum

주의! 이번에 한 스크럼은 완전한 role player들을 갖추고 한 스크럼이 아니기 때문에 실제 이론이랑 많이 틀릴수도 있음둥!

📍 각 사람의 역할

Product owner

프로젝트에서 만들 제품을 총괄하는 사람이다. '세상을 바꿀 질문을 던진 사람'이라고 거창하게 얘기하고 싶다. 제품이 소유하고 있는 Business value와 방향성을 큰 그림에서 보며 product backlog를 작성/관리 하는 사람이다.

Scrum master

사실상 Development Team의 리더와 같은 역할이다. 패스파인더 멤버들 사이에선 요정이라는 이름으로 불린다. 원래는 scrum master의 역할이 별도로 있겠지만 우리 팀에선 각 개발자가 돌아가면서 scrum master를 하기 때문이다!

매일 하는 daily scrum에서 agile이 잘 유지되고 있는지, 팀의 방향성이 흩어지진 않는지, 팀원간 aligning이 잘 되있는지 등을 확인하는 역할이다. 시간 관리자 역할도 맡고 있으며, 의미 없는 프로세스에서 시간이 너무 낭비되지 않도록 중재한다!

Development Team

PO와 SM에게 채찍을 맞으며 열심히 일을 한다.

📍 Scrum Process

일단 우리는 프로젝트 기획부터 시작했기 때문에
문제 인식 -> 가치 설정 -> 가설 설정 -> User story mapping을 Scrum 전 단계에서 했다.
모든 유저의 story를 설정하고 난 뒤에 scrum을 시작했다.

스토리란? 사용자 관점에서 우리 제품에서 느끼는 경험
(e.g. 당근마켓: 로그인을 한다 -> 내 지역을 설정한다 -> 메인화면에서 어떤 것들이 잘 팔리는 지 구경한다
-> 좋은 상품의 상세화면을 읽어본다 -> 톡을 보낸다 -> etc...)

Scrum 시작 시

Product Backlog를 작성

• 시스템 설계 사항이 아니라 유저의 관점에서 가장 필요한 기능 (story)를 기준으로 우선 순위를 세운다.
• 즉, 개발할 제품의 모든 스토리가 우선순위 순으로 product backlog에 정리된다.
• 대략적으로 몇 번의 sprint 후 MVP가 나올 것인지 release planning을 짠다. 각 스프린트마다 해야하는 story 역시 대충 짠다. (어차피 계획대로 안되기 때문에 대충 짠다. sprint를 하는 이유도 최대한 작은 계획으로 나눠서 planning fallacy를 줄이기 위해서다!)

Product Backlog가 작성됐다면 바로 1~4주 단위로 프로젝트를 쪼갠 sprint로 넘어간다!

매 Sprint 마다 해야 할 것

Sprint 시작 시 :Sprint planning 미팅

• Product Backlog에서 이번에 완성시킬 story를 가져온다. (story를 feature라고도 부른다)
• Story는 유저 입장의 경험이기 때문에, 이를 개발적인 관점의 task로 다시 세분화해서 나눈다.
• 여기서 여러 가지 story를 동시에 하려고 하면 안되며, 모든 팀원이 하나가 되어 한번에 한 story를 해치워야 한다!
• 따라서 여러가지 방면으로 이번에 할 story의 우선순위를 결정하고, task를 나눠서 sprint 기간 내에 언제 어떤 일을 할지 대략적인 계획을 짠다.

Sprint 중 : 매일마다 Daily Scrum 미팅

• 끊임없이 서로 Aligning하기 위한 과정이다.
• 어제 한 일, 오늘 할 일, 장애와 문제 보고, 공유 사항등을 나누며 모두가 같은 story를 해결하기 위해 task를 하나씩 수행하며 맞춰가고 있는 것을 확인하고 일이 agile하게 잘 되는지 매일 검증하기 위한 수단이다.

Sprint가 끝날 때 : Sprint review & retrospective

Sprint review

• Sprint demo라고도 한다. 이번 sprint 동안 했던 내용을 다른 사람들에게 보고하고 시연한다. 이 때 쓸만한 user feedback을 받을 수 있으며, 이는 다음 sprint 때 수정사항으로 들어갈 수도 있다.

Sprint retrospective

• 좋았던 점, 아쉬운 점, 고마운 점 등을 나누며 이번 sprint를 다같이 회고하는 시간이다. 일정이 잘 진행되지 않았다면 어떤 이유였는지 분석하고, 생각보다 잘 된 부분이 있다면 왜 그랬는지 찾아본다.
• 팀원들이 best synergy를 내기위해 sprint를 한번 하는 동안 느꼈던 부분들을 서로 공유한다. 마지막으로 다음 스프린트 때 계속 유지시키고 싶은 점, 개선할 점을 한가지 씩 뽑아서 다음 sprint에 적용해본다.

---

scrum을 정리하며 쓰다보니 다시 한번 놀라게 된다. 제품 개발을 선형적으로 가는 것이 아니라 작은 cycle로 나눠놓고, 그 작은 cycle 역시 더 작은 cycle로 나눠놓으며 계속해서 방향성을 수정하는 철저한 방식이라는게 느껴진다. 제품만 agile하게 생산하는 것이 아니라, 팀원 간의 협업도 agile하게 계속 맞춰간다. Doing agile과 Being agile을 차이를 조금 알 것도 같다.

다음 게시물 부터는 그냥 내가 느낀 점들과 어자일 코치들에게 배운 점을 나열하는 간단한 내용이 될 것 같다.

즐코!