지극히 주관적으로 쓴 3개월차 회고

  • 스타트업. 사수도, CTO도 없는 열악한 환경에서 3개월동안 일하고 쓰는 회고
  • 회사 스프린트의 진행 방식은 아래와 같다.
    • 2주를 하나의 스프린트로 잡는다.
    • 해당 스프린트에서 어떠한 작업을 해야하는지 전달받는다.
    • 한 스프린트 안에서 목표한 작업을 마친다.
    • 위 과정을 반복한다

이슈

  • 스프린트를 진행하는 개발자의 역량이나 작업 소화량과는 상관없이 스프린트의 일정에 맞춰야 한다.
  • 목표치 작업을 수행할 수 있는 역량이 되지 않는다면 개발자는 일정 안에 작업을 마치기 위해 모든 시간을 거기에 쏟게 된다.
  • 여차저차 일정을 맞춰다고 해도 이번 스프린트에 대한 회고와 다음 스프린트에 대한 대비는 할 수 없는 체력적 한계를 느끼게 된다.
  • 그렇게 회고와 대비도 하지 못한 채 다음 스프린트로 넘어가며 공부도, 발전도 하지 못하는 악순환이 되풀이 된다.

개선 과제

  • 스프린트 단위를 변경하려고 하지는 않았다. 그것보다 조금 더 작은 단위부터 바꿔나가면 좋을 것 같았다. 그래서 개발해야하는 작업에대해서 너프한 기획부터 상세 기획까지의 과정에 개발자도 참여할 수 있도록 하고, 2주 스프린트에 개발 일정을 맞추는것이 아니라 개발 일정이 길어지면 그에 맞춰서 스프린트를 쪼개 수 있도록 하려고 했다.
    아래 내용은 함께 개발 스프린트를 개선하기위해 노력한 것들을 정리해본 것이다.

    1. 기획서

    • 갖춰진 기획서가 없다면 명확하고 알아볼 수 있는 유즈케이스라도 작성해서 공유하자.
    • 기획자가 유즈케이스를 작성해서 공유했다면 전달받은 유즈케이스를 꼼꼼히 읽어본 후 명확하지 않거나 어려운 기능에 대해서는 미리 이야기해두자.
    • 유즈케이스와 디자인이 기획자가 말하고자 하는 바를 다 내포하고 있을 것이다. 그곳에 없다면 기획자와 충분히 대화를 해야 한다.

    2. 플래닝

    • 기한을 정하는 것은 기획자나 PO, PM만의 역할이 아니라 모두의 역할이다. 기획자가 기한을 이미 정해서 왔다고해도 개발자만의 플래닝은 해야하고 기획자와도 공유해야한다. 정해준대로만 하다가 일정 안에 개발을 못 끝내게 되면 결국에는 개발자 책임이 된다.
    • 이제 막 시작한 주니어라면 어떤 기획서든 2주 스프린트 일정 안에 해당 기능을 다 개발할 수 있을 것 같다는 생각이 들겠지만 본인이 생각한 것보다 일주일, 많게는 열흘은 더 걸린다고 생각해야 한다. 만약 PO 또는 기획자가 ‘헐, 그렇게 오래 걸려요? 더 빨리는 안될까요?’라고 말하더라도 동요하지 말자. 일정이 딜레이 되면 더 싫은 소리를 들을 수 있다.
    • 플래닝, 테스트, 배포, QA 등 모든 것들을 스프린트 일정 안에 넣고 진행한다. 플래닝, 테스트, 배포, QA까지 합해서 2주 스프린트가 되어야 한다. 개발만 10일이 걸린다면 하나의 스프린트 일정에서 해결하기 려운 과제가 되는 것이다.

    3. QA

    • 사람들이 은근히 QA를 만만하게 보는 경향이 있는 것 같다. (그러지 말자.. 후폭풍은 감당하기 더 힘들다)
    • 기획서를 만들면서 QA 리스트를 함께 만들고, 개발이 완료되었을 때 기획서에 적힌 내용과 의도들이 잘 적용되었는지 체크해 봐야 한다. 그리고 여러 번 하더라도 QA리스트를 체크하면서 하나하나 기능과 디자인을 검수한다면 최종적으로 배포했을 때 큰 문제가 발생하는 일은 예방할 수 있을것이다.
    • QA 리스트도 함께 만드는 것이기 때문에 QA 리스트를 살펴보고 빠진게 있다면 업데이트 해주자. 리스트 안에 없다고 그냥 넘어가는 허술한 개발자는 되지 말았으면 한다.

    4. 회고

    • 일정이 무사히 끝났든, 그렇지 않든 회고하는 시간은 무조건 가져야 한다. 모든 팀원이 함께 회고를 하면서 부족했던 부분과 아쉬운 부분에 대해 이야기 나누고, 다음에는 어떻게 해야 부족했던 부분을 채울 수 있는지 논의하는 시간을 갖도록 하는 것이 좋다.
    • 또한, 스프린트를 진행하면서 잘된 점이 있다면 서로를 위해서 팀을 칭찬 수 있어야 한다. 서로가 어느 부분에서 어떻게 잘했는지 상세하게 이야기하고 잘했던 부분은 유지할 수 있도록 서로 더 노력해야한다.
    • 만약 팀 내에서 회고 시간을 갖지 못한다면 혼자서라도 갖도록 하자. (셀프 채찍, 셀프 칭찬)

유지

  • 나는 다행히도 조금씩은 포기해줄 줄 아는 융통성있고 현명한 PO를 만났다. 일정에 치이면서도 개발 실력이 따라가지 못하는 것 때문에 스트레스 받을때 PO가 기획하고 디자인 한 것에서 타협점을 찾아주었던 것이 큰 힘이되고 위로가 되었다.