회사에서 일하는 방식 2 - 개발 리더

이전에 작성했던 Agile 도입 전 프로세스의 문제 점

1. 기능 요청이 기획서 없이 피그마를 기반으로 전달되는 상황
2. 배포 주기가 따로 정해지지 않고 기획서를 기준으로 개발자가 배포시기를 전달
3. 여러가지 기획에서 우선순위가 지정이 되지 않은 상태로 지속적으로 요청이 지속적으로 발생
   - 이부분에서 인하우스 개발자지만 외주처럼 느껴졌습니다.
4. 운영 배포 후 변경 요청이 다수 발생
   - QA가 제대로 이루어지지 않았다는 것을 증명한다고 생각하였습니다.
5. 소통이 여러 곳에서 이루어지고 있음
   - 슬랙, 유트랙, 개인 대화로 기능을 요청하고 이야기하는 문제가 있었습니다.
      (해당 문제 해결방법은 개발팀 리더에서 설명하도록 하겠습니다.)
6. 유트랙의 워크플로우의 이해도가 일치하지 않음
   - 각각의 워크플로우를 팀에서 사용하는 방식이 달랐습니다.

해당 글은 제가 회사에서 경험했던 내용을 기반으로 작성하였으며, 개인의 경험으로 작성한 부분이니 정답이 존재한다고 생각하지 않습니다. 혹시라도 다른 경험을 공유해주시고 싶으시다면 댓글로 부탁드리겠습니다.

---

프로세스에 문제가 있던 부분을 수정하기위해서 구두 전달, 슬랙 등 업무요청의 폭을 줄일 필요가 있었습니다.

이를 위해서 개발자들은 개발 리더를 선정하여 이슈를 개발 리더가 처리하도록하셨습니다.

개발 리더

개발 리더는 기획자가 생성한 스토리 or 티켓(버그, 작업 등)의 첫번째 담당자가 됩니다.

여기서 2가지 상황이 존재합니다.

 

1. 워크쓰루 이후 담당자 선정

2. 스프린트 중간 발생한 이슈 담당자 선전

 

1번의 경우 스프린트를 위해서 생성된 티켓입니다. 이는 협업에서 해당 스프린트에서 진행할 작업을 나누는 중요한 작업입니다.

개발팀에서는 회의를 통해서 지난 스프린트와 연결지어서 회의를 합니다. 코어한 기능을 진행했으면 한 스프린트는 다른 업무를 하는 방식으로 전환을 하고 있습니다. 협업에서 코드리뷰를 통해서 충분히 히스토리를 알겠지만, 코어한 업무를 하다보면 지치는 경우가 있고, 부담감이라는 부분도 존재하기 때문에 한 사람이 코어한 업무를 진행한다면 다른 사람이 서포트하는 형식으로 다른 업무들(버그, hotfix 등 스프린트 코어를 제외한 업무)을 진행합니다.

 

2번의 경우는 스프린트가 항상 원하는대로 흘러가면 좋겠지만, hotfix와 버그 등 특수한 상황에서 변경이 필요한 경우가 발생합니다. 현재 제가 속한 팀은 2주 ~ 3주 스프린트를 진행 중인데, 이런 경우 스프린트 마지막 주는 운영에 배포하기때문에 요청사항을 운영에 함께 반영하면 되지만, 아닌경우 빈번한 요청을 제한하기 위해서 개발팀에서는 1주에 한 번만 기획자의 변경사항을 수용하고 변경하도록 운영하고 있습니다.(이 방식도 좋은 것은 아니나, 서로의 의견을 이해하는 쪽으로 하였습니다.) 만약 변경사항이 없는 경우 계획대로 진행하면 되고, 변경사항이 있는 경우 스프린트에 변경사항 이슈를 넣고 기존 이슈는 백로그로 이동하거나 우선순위가 medium 이상인 이슈를 low로 조정합니다.

 

개발 리더는 다른 사람의 업무가 어떤지 파악을 하고, 조율하고 이해하는 역할이라고 생각해주시면 좋습니다. 소통 창구를 개발리더로 좁히고 개발에서 필요한 티켓에 필요한 내용을 확인합니다. 부족한 경우(마감기한, 목적, 기획서, figma 등) 기획자 or PM에게 티켓을 재할당 합니다. PM과 기획자 사이에서 개발팀의 입장을 대변하고 보호하는 역할을 진행합니다.

 

개발 리더는 개발팀이 가져야할 이슈들도 PM과 기획자에게 공유합니다. 개발 이슈라 함은 리팩토링, monitoring 등 개발팀이 가져야할 이슈들을 스프린트에 제안할 수 있습니다. 이를 통해 기획뿐만 아니라 개발자들이 필요한 부분도 충족할 수 있도록 합니다.

 

개발 리더는 1~2달에 한번 씩 개발자 회고를 진행합니다. 해당 회고는 스프린트 회고와는 다른 회고입니다.

개발자 회고는 개발에서 어떤 부분이 부족했고, 개선이 필요한 부분, 개발자 이슈로 제안할 부분 등을 이야기합니다. 개발자 회고는 개발자가 객관적으로 평가하며, 서로간의 개선점을 이야기합니다. 여기서 원칙은 몇가지가 있지만 제일 중요한 건 솔직함입니다. 프로세스 개선, 협업방식 등 개선점을 말해주며 개인의 잘한 점도 꼭 말해줄 수 있어야합니다.

개발자 이슈(특정 툴 도입, 리팩토링, 써드파티 사용 등)가 많은 경우, 이야기를 통해 우선순위를 정하고 다음 스프린트에서 챙길 부분을 정합니다. 현재 제가 다니는 회사에서는 이와 같은 회의 진행은 개발 리더가 진행하고 있습니다.

 

개발 리더는 이슈를 파악하고 업무를 분할하고 협의하는 역할 이외에 어떠한 매니징도 하지 않는다고 생각합니다.
제가 생각할 때 개발 리더는 비 개발 직군의 요청사항을 1차 문지기로서 정확한 요구사항과 내용을 이해해야지만 문을 열어줄 수 있다고 생각합니다.