들어가며,

세 번채 회사로의 이직의 가장 큰 이유는! 찐(?)개발팀의 체계를 접해보지 못한 아쉬움인데

• 그 경험 부족으로 인해 프로젝트가 지지부진했던 기억
  • 당시 그 경험 부족이 너무나 간절함과 아쉬움

이번 회사에서는 철저히 스프린트에 맞춰 개발이 진행되었다!
다만, 조금 더 효율적으로 전사 차원에서 스프린트 방법을 바꾼다기에
추 후 as-is 와 비교해보기 위한? 그리고 경험적으로 너무나 좋았던 지금의 개발 프로세스이기에 기록해본다

---

개발 프로세스

데일리 스크럼

• 매일 스프린트 구성원끼리 10~15분 내외로 데일리 스크럼 미팅을 한다
• 구성원의 아래 내용을 토대로 진행한다. 예를 들어,
  • 한일 : 스프린트 작업(댓글 UI 만들기, api 설계, api 연결 및 단위 테스트)
    • 핫픽스(PC일 경우 직광고 영역 제거)
  • 할일 : 스프린트 마무리 및 QA 준비
    • 스크럼 워크샵
  • 방해요소 : 핫픽스
  • 어제 스프린트 기여 시간 : 6(4.5소멸, 1.5시간 핫픽스)
• 팀 리드는 구성원의 방해요소를 최대한 제거할 수 있도록 한다

---

0. Agile을 추구하는 이유

결론? 기민하게, 빠르게, 민첩하게 요구사항을 반영하기 위해

Agile 개념

너무나 유명하기에 간단히만 정리!

사전적 정의

• 밀첩한, 기민한
• Agile 소프트웨어 개발(Agile software development) 혹은 Agile 개발 프로세스는 소프트웨어 엔지니어링에 대한 개념적인 얼개로, 프로젝트의 생명주기동안 반복적인 개발을 촉진하는 방식

Agile이란 특정 개발론이 아니다

• Agile(기민하게 좋은 것을 빠르고 낭비없게 만드는 것) 개발을 가능하게 해주는 다양한 방법론 전체
• Agile은 개념이고 인본주의 협업 문화

Agile 배경

개발 흐름의 변화

• 벤더 중심 → 서비스 중심 → 사용자 중심
• 개발 영역의 세분화
• 변경은 바람직하지 않고 계획 중심의 통제가 중요하다는 인식 탈피
• Waterfall → Agile → Lean Startup
  • Known → Unknown
  • Step → Innovation
  • Simple → Complex

💡Agile을 잘 했다? 프로세스 계획을 잘 완수했나?가 아닌 고객에게 가치를 잘 전달했느냐

---

1. 기획: 백로그 그루밍과 POC(Proof of Concept)

• 우선 순위 개발 백로그 선정
• 선정된 백로그가 실제로 실현 가능성이 있는가를 검증
  • 효과와 효용, 기술적인 관점에서부터 점증을 하는 과정
• 검증이 끝났다면 정책 공유, 기능 공유, 디자인 공유, 의견 취합, 개발 이슈 검토 등 진행
  • 이 과정은 매주 진행되었고 실제 개발해야 하는 기능을 구체적으로 이해하는데 도움을 주었다
    • 이 백로그를 진행하게 되면 가져올 효과와 임팩트 공유를 통해 구성원의 동기부여
    • 소통을 통해 기술적으로 검토해야 하는 부분, 준비해야 하는 부분 등 미리 대략적으로 설계 가능
  • 그리고 다음 개발이 어떤 것인지 파악할 수 있게 해주는 데에도 도움이 된다

---

2. 스프린트 계획회의 1차

2-1. 개발 백로그 공유

• 여러번의 백로그 그루밍을 통해 선정된 실제 진행하게 될 백로그 공유
  • 사실 백로그 그루밍을 통해 다음 스프린트에 어떤 개발을 하게 될 것인지 예측 가능하다

2-2. 개발 범위 파악

• 개발할 기능의 정책, 디자인, 기술적 검토를 하고 공수추정(플래닝 포커를 사용하기도 한다)을 한다
  • 예를 들어, 댓글 기능을 개발한다면
    • 댓글 입력창을 만들어야 하고 api를 연결해야 하는데
      • 댓글 입력창 UI를 개발하는데 1시간
      • api 연결하는데 1시간
    • 이렇게 추정된 내용을 지라 티켓으로 등록

---

3. 스프린트 계획회의 2차

• 이 회의는 바로 다음날에 바로 진행되는데 각 직무별 공수 추정 바탕으로 개발 가능 일정 산정하는 회의다
  • 혹은 오후 끝무렵에 진행되기도.. 각자의 공수추정 후 바로 진행한다

담당자	4/1	4/2	4/3	4/4	4/5	여기까지	4/8	4/9	4/10	4/11	4/12	여기까지
백엔드	5	6	6.5	6.5	연차	24	5	5	6	6	6	28
프론트엔드	5	6	6.5	6.5	5	29	5	3	6	6	6	27
IOS	5	6	6.5	6.5	6	30	5	5	6	6	5	27
AOS	5	6	6.5	6.5	4	28	5	5	6	6	연차	22

• 이렇게 각자의 기여 가능한 시간을 공유하고 개발 마무리 날짜, QA 진행 일정, 배포일자를 예측한다
  • 개발 마무리: 만약 이번 스프린트의 개발 공수 추정이 평균 30시간이 소요된다면 4/8 오전이 마무리 시점이 될 것인데, 백엔드는 4/9일까지 마무리하는 것으로 정한다
    (공수 추정이 많이 차이난다면 백로그 중 개발해야 할 것들을 추가해서 소요 시간을 맞추도록 한다(노는 사람은 없다!))
  • 배포일자: QA 기간을 고려하여 배포일자를 예측한다
• 이때 팀 리드는 팀 단위 여유 시간을 1~2일 정도 가져갈 수 있도록 한다
  • 예기치 못한 이슈 발생 등을 대응하기 위해
  • 공수추정 시간보다 오래 소요될 상황을 대비하기 위해?
    • 이런 경우는 회고를 통해 반성한다..

이 방법이 좋았던게 어떤 기능이던 2주라는 시간에 맞춰 개발하기 보단,
개발하는 기능에 따라 계획하고 스프린트(보통 2주를 넘기진 않았다), 스파이크(2~3일 개발)로 진행할 수 있었다는 것. 추 후 변경되는 스프린트는 무조건 2주라는데..(그 기능이 무엇이든??) 좀 걱정되기도 한다

---

4. 스프린트 시작

4-1. 개발 시작

• 열심히 개발하고 개발하고..
• 코드 리뷰도 열심히 하고..

4-2. QA

• 세 단계에 나눠서 QA가 진행되었다
  • 개발QA: 개발자만 사용하는 개발서버에서의 기능 QA
    • 버그를 잡고 예기치 못했던 이슈에 대응한다
    • 보통 2차까지 진행했었다
  • 통개QA: 이해관계자가 모두 사용하는 개발서버에서의 QA
  • 운영QA: 운영서버에서의 사이드 이펙트 확인 등 확인 검증 QA

4-3. 배포

• 배포 및 모니터링

---

5. 회고⭐️⭐️⭐️

팀 리드께서 말씀하시길 이 단계가 가장 중요하다고 하셨다 ⭐️⭐️⭐️

5-1. 번다운차트 공유

번다운차트1	차트2

• 번다운 차트를 보며 지연된, 일찍 종료된 사유 등을 이야기 나누는 단계
  • 예측보다 일찍 끝났다고 좋은건 아니다. 왜 추정이 잘못되었는지를 파악해야 한다

5-2. 시간측정 회고(5분)

• 구성원 각자 추정한 시간이 적절했는지 등을 회고
• 시간 측정이 적절했는지, 적절하지 않았다면 사유와 함께 공유하기
  • 예를 들어,
    • 웹) 기존 코드 파악 시간이 생각보다 길어 추정 시간이 맞지 않았다
    • 안드) 예상했던 추정시간에 거의 근접하게 진행되었다
      등등..

5-2-1. 의견나누기(10분)

• 이번 스프린트에 대해 전반적인 구성원들의 이야기 듣기
• 처음 시작할 때 티켓은 모두 All에 위치하고 하나씩 이야기하며 해당 카테고리로 티켓을 옮긴다
  • 종료된 상태의 티켓 현황
    

5-2-2. 더 이야기 해보기(15분)

• 위의 티켓들 중 공감하는 내용에 투표해서 추가로 더 이야기 나누는 시간
  
• 이 티켓들은 위의 의견나누기에서 끌어 놓은 티켓들
• 좋은 점과 안좋은 점에 해당하는 티켓들을 한 두개 정도를 추려 추가로 이야기하는 시간이다

5-2-3. 잘된점⭕️, 부족한점❌

• 이번 스프린트에서 잘 된점, 부족했던 점을 이야기 한다. 구성원들이 각자의 이야기를 공유한다
  • 예를 들어 기획 변경이 있었는데 히스토리가 분산되어 파악하기 힘들어서 파악하는 시간이 추가로 발생. 결국 지연됐다.. 등의 이야기
  • 또는 슬랙 채널에서 소통이 잘돼서 별도의 문서 찾아보지 않아도 수월하게 개발이 진행되었다는 점 등의 이야기

5-3. 지난 액션 아이템 회고 & 다음 액션 아이템 (10분)

계속하자

• 보통 지난 액션 아이템을 토대로 잘 진행되고 있는지
• 추가로 계속 액션해야 할 아이템을 추가하여 정리한다
• 예를 들어
  • 코드리뷰도 업무다
    • 코드리뷰 시간도 작업량에 추가
    • 빠르게 리뷰할 수 있도록 코드리뷰 규칙을 정의하자
      • 규칙을 지키도록 노력하자
    • 예) 업무에 일정시간을 정해서 코드리뷰 하기(출근 후 30분 리뷰, 퇴근 전 30분 리뷰)

바꿔보자

• 마찬가지로 지난 회고에서 바꿔보기로 했던 내용들을 미리 기재되어 있고
• 개선이 되었다면 삭제, 그렇지 않다면 남겨두고 다음 회고에서 또 이야기 한다
• 예를 들어
  • 데일리스크럼 때 최대한 많은 정보를 간단히 공유
    • 원래 일하기로 한 시간 > 실제 작업 시간 ⇒ 방해요소?
      • 내가 일하기로 한 시간 : 계획회의 때 예상한.
      • 실제로 작업한 시간 : 기록.
      • 방해요소는 무엇인가?
      • 해당 시간의 오차로 인해 지연되고 있는 이슈와 시간
      • 해당 시간의 오차를 극복할 계획

---

마무리,

이렇게 한 스프린트가 종료된다!!
이직 후 이런 스프린트를 경험한지 4개월정도 되어가는데,
내가 경험하고 싶었던, 개발 주기를 실제 경험해보면서 왜 개발자들이 스프린트를 외쳤는지 이해가 되었고
말 그대로 신세계였다👍

그리고 5월부터는 새로운 스프린트 룰이 적용되는데
과연, 변경된 스프린트 룰이 더 효율적일지 기대가 되기도 하고 걱정도 되기도 하고..
추 후 to-be 스프린트에 대해 작성해보고 비교해봐야겠다!