스스로 생각하기에 비전공도 전공도 아닌 애매한 포지션의 나… 본과정이 시작되면서 처음으로 팀에서 스프린트를 진행했다. 그 전에도 이슈를 관리하면서 개발하고 있기는 했지만, 제대로 스프린트 주기를 잡고 이슈를 배분한 건 처음이었다.
첫 스프린트는 멘토님께 기간이나 범위 설정에 있어서 조언을 받은 후 시작하게 되었다. 일단 기간은 3일로 잡았고, 우리가 할 수 있는 일의 범위를 과대평가하지 않는 데 신경써서 이슈 범위를 설정했다.
다만 실제로 스프린트를 진행하니 다음과 같은 문제가 생겼다.
- 팀장에게만 너무 많은 일이 집중되는 구조
- 처음 이슈 배분은 estimate가 비슷하도록 배분했음
- 그러나 현업 경험이 있는 팀장과 비전공자+애매한 나()로 구성된 팀이다 보니 대부분의 리뷰가 팀장에게 몰림, 일부러 몰아줬다기보다는 스스로의 판단을 신뢰하지 못해 결국 최종적으로 팀장이 리뷰하는 상태
- 팀장은 이슈와 리뷰를 함께 해결해야 하니 다른 팀원보다 훨씬 많은 작업을 하게 됨 -> 병목 발생
- 어디까지 알고 어디까지 모르는지에 대한 파악이 안됨
- 에이전트를 활용하니 문법이나 이런 부분에서 문제가 생기는 경우는 적으나, 알고 모르는 범위에 대해 서로 모름
- GraphQL Fragment를 써야 된다는 피드백 -> Fragment 자체를 몰랐다 보니 처음 구현할 때 고려하지 못했던 부분
- 서로가 서로의 블로킹이 됨
- 이슈를 도메인이나 이런 부분에 따라 나누지 않았다 보니 한 명의 이슈가 정체되면 계속해서 정체 발생
- 이슈 범위 예측 오류
- 처음에는 한 이슈로 충분하다고 생각했지만, 생각보다 비대한 범위를 작업해야 하는 경우가 있었음
- 인지했을 때 바로 논의하거나 이슈를 나눌 필요가 있었다
이에 회고를 통해 다음과 같은 결론을 냈다.
- 이슈 범위는 스프린트 구성 시 따로 시간을 내서 논의
- 생각보다 넓으면 겁내지 말고 바로 공유하기
- 바보같은 질문 할당량제 -> 질문 겁내지 말고 바로바로 하기 위해 (ㅋㅋㅋㅋ)
- 일단은 팀장님 PR은 리뷰 바이패스 & 팀원들은 스프린트 사이클 내에 PR에 질문 하나 이상 남겨두기
- 멘토님을 더 잘 활용하자! (지금은 팀장을 멘토처럼 활용한다)
이러한 보완점을 인지한 후 멘토링에서는 지금 당장은 팀장은 코드를 짜기보다는 리뷰에 집중하는 게 좋을 거 같다고 말씀하셨고… 일단은 몇번 더 스프린트를 해 보면서 우리 팀에 맞는 방식을 찾아가야 한다고 하셨다. 사실 개발 방법론에 대한 부분도 소마를 시작하면서 처음 공부해봤고, 제대로 팀 단위로 개발을 해 보는 경험 자체가 처음이라 생소한 것들이 많지만, 그만큼 열심히 찾아보면서 계속해 봐야 할 것 같다.
정리
- 스프린트는 몇 번 더 해보기
- 질문 하는걸 주저하지 않기
- 어떤 모르는 사실들은 에이전트를 통해 커버하기 어렵다 -> 계속 공부하기