[YAPP] 초보 TPM으로 첫 스프린트를 마치며

1차 스프린트 목표

우리는 유기견 봉사 및 커뮤니티 플랫폼 웹 서비스 출시를 목표로 프로젝트를 진행하고 있다.

우리 팀은 디자이너 1명, PM 1명, 프론트엔드 개발자 3명, 백엔드 개발자 2명으로 이루어져 있다.

개발 기간은 5월 28일부터 8월 5일까지이고, 이 기간을 총 3개의 스프린트로 나누어 진행하기로 하였다.

• 1차 스프린트 기간: 2023.5.28 ~ 2023.6.18 (총 3주)
• 작업 범위
  • 공통 컴포넌트 개발
  • 랜딩 페이지
  • 로그인/회원가입 - 개인 봉사자
  • 로그인/회원가입 - 보호소 파트너
  • 보호소 정보 수정

---

TPM.. 그게 뭔데

다른 개발 팀원보다 경력이 있고 스타트업에서 주도적으로 일도 해봤고 시간적 여유도 있고 등의 이유로 TPM을 맡게 되었다.

TPM이란 게 굉장히 생소했지만 다음과 같은 역할을 하는 것으로 이해했다.

• 개발 팀원들의 리소스 관리, 이슈 체크
• 개발 일정 조율
• 개발 진행 상황을 팀 전체에 공유

PM님, 디자이너님과 적극적으로 커뮤니케이션하면서 스프린트동안 태스크의 우선순위에 맞게 업무를 유기적으로 진행할 수 있도록 조율하려고 노력했다.

 

TPM으로서 한 일들

Jira로 개발 태스크 관리하기

PM님이 공유받고 싶어 한 정보들은 다음과 같다.

• 피쳐별 담당자가 누구인지
• 피쳐별 예상 공수와 예상 완료 시점
• 기획 / 디자인에 확인 요청할 사항이 있는지
• 개발 작업 중 구현에 어려움이 있어 기획 / 디자인 쪽 변경 희망 사항과 그 이유

5명의 개발 팀원들 사이에서도 누가 어떤 작업을 언제까지 진행하는지 확인해야 할 필요가 있었다.

 

이런 요구사항에 맞추어 Jira를 세팅하고 Ground rule을 만들어 공유하였다.

 

예) 개발 중 확인 또는 검토가 필요한 사항을 공유하기

워크플로우: 할 일 → 진행 중 ↔ 검토 요청 → 완료 

• 태스크 진행 중에 기획 / 디자인 / 개발에서 검토가 필요한 사항이 있을 시 검토 요청 상태로 보내기
• 검토 요청 상태로 보낼 때는 항상 하위 이슈를 만들고 검토 요청 대상을 담당자로 지정하기
  • 하위 이슈에 담당자를 지정한 후 검토 요청 내용, 이유, 희망 방향을 작성

 

팀원들이 Jira를 잘 업데이트하고 자주 확인을 할 것인지 걱정되었다.

이미 Notion, 디스코드, 카톡을 협업 채널로 사용하고 있었기 때문에 채널이 하나 더 늘어나는 것이 부담스러울 수 있을 것 같았다.

우선 1차 스프린트는 Jira로 진행해 보고 회고 후에 유지할 것인지 바꿀 것인지 결정하기로 했다.

 

태스크 세분화 및 담당자 할당

먼저 큰 단위로 작업을 나누어 Jira에 에픽 카드로 올렸다.

그다음 이를 다음과 같은 기준으로 더 작은 단위의 태스크로 나누었다. 

• 작업은 최대한 다른 작업에 의존적이지 않아야 한다.
• 하나의 작업은 한 명의 담당자가 처리한다.

 

이렇게 작업을 미리 나눠놓으니 필요한 개발 공수가 전보다 명확하게 드러났다.

각 태스크의 공수에 대해 논의한 후 각자 태스크를 가져갔다.

가져가는 기준은 아주 합리적이고 프로젝트 목표에 걸맞은 기준이다. 그냥 자기가 하고 싶은 작업을 하나씩 골랐다

(회사 프로젝트가 아니라 하고 싶은 걸 해보는 사이드 프로젝트니까!😄)

 

개발 일정 조율과 작업 우선순위 공유

아직 와이어프레임이 거의 나오지 않은 상태에서 1차 스프린트가 시작되었다. 

개발팀은 기획과 디자인이 나오기 전에 할 수 있는 작업들을 찾아 진행하기로 했다.

여기에는 협업 환경 세팅과 CI/CD 구축 등이 포함되었다.

 

개개인의 리소스를 파악하여 개발 일정을 조율한 후에는 기획과 디자인 쪽에 우선적으로 작업해 주시면 좋은 사항을 요청드렸다.

• 디자이너님께는 디자인 시스템과 공통 컴포넌트 UI부터 작업해 달라고 요청드려서 최대한 FE 쪽에서 빠르게 작업을 시작할 수 있도록 하였다.
• 기획에서는 회원가입 관련 요구사항을 먼저 요청드려서 BE 쪽이 auth 관련한 개발을 시작할 수 있도록 하였다.

이 두 가지는 다른 기획이나 디자인에 의존적이지 않는 것들이고, 백엔드와 프론트엔드에서 각각 독자적으로 진행할 수 있는 작업이다. 또한 프론트의 경우 페이지를 구현하기 전에 우선적으로 진행해야 하는 것들이었다.

 

스프린트를 진행하면서는 개발에 어떤 이슈가 있는지 주기적으로 체크하고 팀 전체에 공유하면서, 그때그때 피드백을 주고받을 수 있도록 노력했다.

---

1차 스프린트 결과, 그리고 개발팀 회고

결과적으로 스프린트 기간 내에 목표를 달성하지 못했다.

목표 기간에서 2일이 초과하였고 일부 태스크는 완료하지 못하고 다음 스프린트로 넘겼다.

스프린트 막바지쯤엔 기간에 쫓겨 정신없이 개발을 하느라 팀원들이 많이 지쳐했다.

 

폭풍 같았던 1차 스프린트가 끝난 후 개발팀끼리 Start-Stop-Continue 회고를 진행하였다.

 

Start: 개선에 필요한 액션들

가장 많이 나오고 모두가 공감했던 것은 개발 '공수 계산에 좀 더 노력을 기울이자'였다.

작업별로 세세하게 목표 기간을 설정하지 않고 큰 단위로만 기간을 산정했었는데, 이 것 때문에 막바지에 갑자기 태스크가 몰렸던 것 같다.

예상치 못한 오류나 기획 변경 등으로 실제 개발 기간이 늘어났는데, 이런 가능성까지 고려해서 좀 더 신중하게 공수를 계산해야겠다고 생각했다.

그 외에도

• 빠른 이슈 공유 - 막히는 부분이 있다면 주저하지 말고 이슈를 공유하고 도움을 요청하자
• 기획 / 디자인 쪽에서 중요도를 미리 나누어서 공유해 주셨으면 좋겠다

등의 의견이 나왔다.

 

Stop: 프로젝트에 부정적인 영향을 줬거나 비효율적이었던 액션들

백엔드 쪽에서는 한 브랜치에서 너무 많은 작업을 해서 중간에 서로 다른 부분(코드 스타일 등)이 있을 때 바꾸기 힘들었다고 공유해 주셨다.

프론트엔드도 비슷하게 뒤로 갈수록 PR을 자주 날리지 않아서 막바지에 코드를 합치느라 힘들었던 것을 공유했다.

코드를 자주 합치지 않다 보니 다음과 같은 문제점이 있었다.

• 담당자가 명확하지 않은 태스크를 중복 작업하게 될 가능성이 높다.
• 컨플릭트가 커져 수정하는데 시간이 걸리고 코드가 꼬일 가능성이 있다.
• 다른 개발자의 진행 상황을 정확히 파악하기 힘들다.

 

다음 스프린트부터는 중간 작업물을 합치는 브랜치를 따로 파서 아직 완벽하지 않은 코드라도 PR을 날릴 수 있게 진행하기로 결정했다.

 

Continue: 프로젝트에 긍정적인 영향을 줬거나 앞으로도 유지할 액션들

모든 팀원들이 입을 모아 얘기했던 것은 적극적인 코드 리뷰였다.

그렇게 바쁜 와중에도 코드 리뷰를 한 사람도 빠짐없이 매우 적극적으로 해주었다.

덕분에 코드 스타일이 일관성 있고 코드가 그때그때 리팩터링 되면서 깨끗하게 유지될 수 있었다.

또, 리뷰를 하면서 코드에 대한 이해도가 높아져 다른 개발자가 작성한 코드를 쉽게 재사용할 수 있었던 것 같다.

 

그 외에도 격려와 칭찬과 응원이 난무하는 우리 팀 분위기는 앞으로도 쭉 이어질 예정이다🤗

 

---

결론

기한을 맞추지 못한 것과 막바지에 몰린 태스크 때문에 팀원들이 지쳤던 것이 너무 아쉬웠다.

TPM으로서 일정을 잘 조율하지 못한 것 같아 팀원들에게 미안한 마음과 큰 책임감을 느끼고 있다.

공수를 계산하고 마일스톤을 짜는 일은 언제나 어려운 것 같다.

 

비록 폭풍같이 지나갔지만 처음 서로 합을 맞춰봤던 스프린트인 만큼 실패했다고는 생각하지 않는다.

회고를 통해 어떤 점이 부족했는지 깨달았고, 개선 방안을 찾아냈으며, 이를 바탕으로 2차는 훨씬 잘 해낼 것임을 확신하기 때문이다.

 

2차 스프린트 때는 팀원 개개인의 컨디션과 이슈 사항을 더 꼼꼼히 살펴서 모든 팀원이 지치지 않고 마지막 스프린트까지 즐겁게 달릴 수 있도록 할 것이다