회사에서 일하는 방식1 - agile

이직하기 전에 Agile이라는 단어가 크게 와닫지 않았습니다. 지금의 회사에서 좋은 동료와 함께 Agile이라는 방식을 논하고 정의하는 부분에서 크게 도움이 됐다고 생각하여 해당 글을 작성하였습니다.

 

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

 

---

Agile이란?

agile은 사전적 의미로 기민함, 민첩함 이라는 뜻을 가지고 있습니다.

 

그럼 개발에서 agile은 무슨 의미로 사용을 하고 있을까요?

개발에서 Agile

1. 짧은 주기(2~4주)의 개발 단위를 반복하여 하나의 큰 프로젝트를 완성해 나가는 방식( 반대로 많이 나오는 방법론은 Waterfall )

2. 빠르게 결합하고 수정한다. (이는 협력과 빠른 피드백을 기반으로 가능합니다.)

 

Agile 도입 과정

현재 회사에서 Agile이 도입된 과정을 작성하였습니다.

도입 전 회사 개발 프로세스의 문제점

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

6가지의 문제를 작성하였지만, 이외에도 다양한 문제들이 많았습니다. 작성한 부분만 보더라도 팀에서 개선해야 할 부분이 많았습니다.

이는 업무를 하는 과정에서 업무의 난이도보다 이외의 스트레스로 작용하였습니다.

 

그래서 저희 팀은 Agile을 다시 정의하기로 정하였습니다.

모든 것을 한번에 하면 좋겠지만 천천히 하나씩 새롭게 맞춰나간다는 생각으로 진행하였습니다.

물론, 회의하는 시간이 다른 팀에 비해서 많을 수 있었으나, 다른 팀에 비해서 팀워크를 맞춰나가는 시간이였다고 생각하였습니다.

 

Agile 도입 방식

1. Agile 프로세스 정의
   1. 워크쓰루
      - PM과 기획자가 해당 스프린트에 진행할 기획을 개발자에게 공유합니다.
      - 이 시간은 기획의 질의를 자유롭게 공유하는 시간입니다.
      - 현재 회사의 워크쓰루는 거의 월요일에 진행하며 워크쓰루 기획은 전주에 공유합니다.
   2. 플래닝
      - 워크쓰루를 기준으로 개발자들이 티켓을 생성합니다.(프론트+백 공통 작업인 경우는 1개의 티켓을 생성합니다.)
      - 개발자들은 워크쓰루 이후에 작업시간을 계산해옵니다.
      - 개발자들 작업시간(워킹데이)을 기준으로 PM과 기획자가 티켓의 우선순위를 지정합니다.
         (우선순위: lowest < low < medium < high < highest)
      - 저희는 우선순위가 낮은 작업은 다음 스프린트에 진행한다고 합의하였습니다.(medium까지는 진행해야하는 작업입니다.)
   3. 개발
      - 개발자들이 정해진 티켓을 기반으로 작업을 진행합니다.
      - 이 기간에 기획자는 기획을 진행하며, PM은 QA 시트, 공유할 자료(서비스 지표, 상황 등)를 만듭니다.
   4. QA
      - QA 시트를 기반으로 진행합니다.
      - QA팀이 따로 존재하지 않아서, 시트에서 담당자가 지정된 상태에서 테스트를 진행합니다.
         (3가지 조건이 있습니다. F: 실패, P: 성공, N: 테스트 없음)
   5. 버그 픽스
      - QA에서 발생한 버그를 픽스하는 시기입니다.
   6. 운영배포
      - 버그픽스까지 진행된 상태에서 다시 QA를 받고 운영에 배포합니다.
   7. 회고
      - 자기반성 혹은 팀을 다시 돌아보는 시기라고 생각합니다.
      - 저희는 정해준 주제로 이야기합니다.
         1. 이번 스프린트 점수, 한단어로 이번 스프린트를 설명, 칭찬할 부분(특정인을 지칭해야합니다.)
         2. 없앨 일 - 이번 스프린트를 경험하면서 없앴으면 하는 일
         3. 시도할 일 - 다음 스프린트에서 시도했으면 하는 일
      - 작성한 글이 누군인지 알지 못하도록 비밀인 상태에서 진행합니다.
      - 자신이 작성한 글에 추가적인 설명을 하고 싶으면 작성한 글이 뭔지 밝혀도 됩니다.
      - 모두가 같은 주제가 아니기 때문에 없앨 일과 시도할 일은 PM이 선택하여 다음 스프린트 목표로 진행합니다.
      - 지난 번 회고때 나왔던 주제로 이번 스트린트에서도 점수를 부여합니다.
         (점수로 잘 진행이 됐는지 판단이 되며, 그 점수를 준 이유를 짧게 작성합니다.)
   8. 데일리 스크럼
      - 매일 10분정도 어제한일, 오늘할일을 공유합니다.
      - 회의가 필요한 부분에서는 담당자를 요청하여 스케줄을 조율합니다.

 

위에 작성한 방식은 계속해서 발전해나가고 있습니다. 부족한 부분은 계속 수정하고 보완하고 있습니다. 이를 통해서 프로세스가 많이 개선이 됐으며, 각자의 역할이 뚜렷했졌다고 생각이듭니다. 효율과 프로세스도 좋아졌다고 생각합니다.

 

각각의 프로세스는 하나씩 글로 작성하도록 하겠습니다. 글이 길지는 않겠지만, 제가 경험했던 상황과 변화과정 등을 작성하도록 하겠습니다.

1. 워크쓰루

 

개발 리더

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

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

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

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

 

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

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

 

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

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

 

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

 

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