이번 스프린트 역시 긴급 태스크가 발생하였다.
이상적인 일들만 발생하면 좋겠지만 등록된 긴급 태스크는 Google Play Featured와 관련된 작업이라서 스프린트 일정을 따르면 불가능한 작업들이었고, 해당 작업은 Bug Board에 등록되어 현재 staging branch 로 진행중이다.
기획이 완료되지 않은 태스크지만 중요도가 높은 상태로 스프린트 플래닝에 들어오는 상황이 지난 스프린트 진행되는 동안 빈번히 발생해왔다. 그렇다고 이번 스프린트에 포함되지 않으면 배포가 너무 밀려버리는 문제점이 생기다보니 어쩔 수 없이 스프린트에 기획이 완료되지 않은 태스크가 추가되어왔다.
각 태스크들이 바로 시작가능하다고 가정하고 스프린트 플래닝 때 개발범위를 추정하다보니 작업 우선 순위가 꼬이는건 당연하고 스프린트 초기에 진행 가능한 작업이 애매한 상황도 발생했다.
스프린트#2-6부터는 기획이 완료되지 않은 작업들에 대해서는 이상적으로 Backlog/Planning에는 기획이 완료된 태스크들에 대해서만 올리도록하고, 현실적으로 스프린트에 포함되어야하지만 기획이 마무리되지 않은 이슈들은 External meeting에서 중요도 포인트를 산정한 이후에 플래닝 시점에 -50점을 처리하였다.
'구매페이지 문구 변경 실험'은 우선순위가 130으로 배정되었지만 기획이 완료되지 않아서 중요도를 80으로 놓고 플래닝을 진행하였다. 이번 스프린트 작업에는 태스크가 많지않아서 스프린트에 포함되었지만 비슷한 케이스가 다시 발생하면 스프린트에 포함이 안되는 상황이 올 가능성이 생겼다. 작업 순서도 기획이 완료된 작업이 중요도가 높게 잡혀 스프린트 시작이후 개발자들이 바로 작업을 시작할 수 있었다.
해당 방식은 Android Group에서 일정을 관리하는데 유용하게 판단되어 유지하기로 하였다.
Android Group 개발자가 2명뿐이다보니 branch 작명 룰이나 commit message 는 자유롭게 작성해서 사용해왔었다. 문제는 2명의 스타일이 많이 달라서 branch와 commit이 어떤 개발자가 작업했는지 구분이 될 정도였다. 현재 지속적으로 채용을 하고 있기에 룰을 정할 필요하 있다라고 판단하여 작명 룰을 정하였다.
Branch Rule: feature/*, hotfix/*, refactor/*
Commit Rule: [{Team 이름}] {내용}
// ex) 'feature/new-function' branch: [Subs] 새로운 기능 추가
// ex) 'refactor/main' branch: [Android] 메인 리팩토링
크게 사용에 불편함이 없었기에 규칙을 유지하기로 하였다.
Android Beta, Production 두 트랙에 대한 Staged roll out & Monitoring Policy를 일부 변경하였다.
스프린트 종료시점 월요일을 시작으로 아래와 같은 단계로 단계적배포를 진행하기로 결정하였다.
Beta 50% (월) > Beta 98% (화) > Beta 100% (수) > Prod 40% (목) >Prod 70% (금) > Prod 98% (월) > Prod 100% (화)
이번 스프린트 배포부터으로 위와 같이 적용해서 진행중이다.