스프린트#9 (07.21 ~ 08.03) 요약
Agenda: Jira 자동화
스프린트 변경사항
스프린트 특이사항
Jira 자동화 및 연동
Jira Board 도입 이후 개발자의 불필요한 작업을 줄이기 위한 자동화 작업을 진행하였다.
Jira
- 'To Do'로 이동 시 현재 이동한 사람 자동 할당
- Jira 이슈와 같은 Github origin branch 가 push 되면 ToDo 이동
- Github PR 등록 시 'In Review'로 status 변경
- Github PR Merge 시 'Done'으로 status 변경
Slack
- PR Merge 시 qa 채널에 알림
- Bug Borad의 이슈 등록 시 안드로이드 채널에 알림
Firebase
- Crashlytics 속도 이슈 발생 시 BugBoard 등록
- Crashlytics 해결 이슈 재발생 시 BugBoard 등록
Etc
- Zendesk 연동
- Zeplin 연동
Jira Release 활용
기존 App Distribution 의 Release 노트를 활용하여 개발 작업들을 공유해왔었다.
Jira 를 도입한 이후로 Jira 에서 직관적으로 관리를 하기 위해 Jira 프로젝트의 Release를 활성화하여 버전관리를 시작하기로 했다.
해당 이슈가 어떤 버전에서 릴리즈 됐는지 기록도 되고 타그룹에서는 이번 버전 릴리즈 내용을 쉽게 조회할 수 있게 되었다.
Github Actions
Build Test
빌드 테스트를 위한 Github Action을 추가하였다. 하지만 빌드속도가 10분정도 걸리는데 PR 등록 때마다 돌리기에는 월 3000분 제한에 금방 걸릴 것 같아서 사용하지 않기로 결정하였다.
Apk/Aab Build
apk/aab 생성에 시간이 5~10분정도 사용되어 이 부분을 remote로 돌리면 효율이 증가할 것으로 기대했다.
Github Action에서 돌리면 20분 정도 걸리긴 하지만 그 시간동안 따로 로컬 리소스를 쓰지 않기에 앞으로 활용 예정이다.
안드로이드 그룹 문화 전/후 테스트
목표: 업무프로세스 변경 테스트를 통한 업무 진행 효율 실험.
기간: 2~3회 스프린트 (4~6주)
방향: 스프린트 회고를 통해 장/단점 분석 후 최종 결정 예정
공유 자료
스프린트 관리와 개발자 리소스 활용을 위해 ToDo 작업은 개발자를 미리배정하지 않을 예정입니다.
- 안드로이드 그룹 내 Collective code ownership 추구
(업무가 할당되지 않고 자발적으로 업무를 선택)
- 안드로이드 그룹 Velocity 측정 및 실험 이후 Velocity 수치 활용 예정입니다.
- 스프린트 업무가 Merge Day를 넘어가는 것을 방지합니다.
- 스프린트 업무가 예상보다 일찍 끝날 경우 개발자 성장을 위한 랩데이로 활용 예정입니다.
(ex. 그룹 내 공유, 신규라이브러리 도입, 개발자 실험, 개발자 이슈 생성 및 관리)
Squad 소속 개발자의 연차 혹은 개발자가 바빠서 힘들 것 같다고 작업을 줄여서 가져오지 않으셔도 됩니다.
안드로이드 개발자는 혼자가 아닙니다. 😉 스프린트#3-2 회고
Good
- Jira 자동화로 스크럼 관련 불필요한 행위가 감소.
- Github Actions 빌드 구현 함.
- Build Test 시도함. (성능이 좋지 않음)
- 회고에 참여하여 앞으로의 방향성을 알 수 있어서 좋았다.
- JIRA 도입으로 진행사항 확인하기 굉장히 용이.
- 올린 이슈의 처리사항 확인 가능한 점이 이후 업무가 남았을 경우 시간 예상하기 좋았음.
...후략...
To improve
- 스프린트 초반 기획 안된 Todo가 많아서 작업이 애매했었음.
- Crash 가 너무 많아서 제대로 관리하지 못한 느낌.
- Bugfix 가 Sprint planning 쪽으로 들어간 경우 follow up 하기 여전히 조금 어려움.
- 타팀 소관의 QA (General QA 이외) 항목과 결과를 알지 못하여 불안(...). General QA에서 영향을 미치는 부분이 있을 경우 리소스 낭비하게 될 가능성이 있음.
- 릴리즈 지연되면서 다시 스프린트 거의 내내 QA와 릴리즈 단계 조정 진행 중 😭
- 문서에 있는 기능을 구현 누락함.
- 실험 관련 이슈
- 리디자인 관련 새로운 Crash 들
...후략...
Action Items
- 실험 관련 이슈
- baseline 적용 → ALANFIX
- 다음 실험 (1 → 2) → ALAN
- Bugfix 가 Sprint planning 쪽으로 들어간 경우 follow up 하기 여전히 조금 어려움.
- Bug borad에서 관리
- Release 별 이슈 기록 (이슈탐색 사용하기)
- 타팀 소관의 QA (General QA 이외) 항목과 결과를 알지 못하여 불안(...). General QA에서 영향을 미치는 부분이 있을 경우 리소스 낭비하게 될 가능성이 있음.
- Notion 기획서 내부에 예상 QA 기록, 기획서에 QA결과 기록하는 것을 요청
- 문서에 있는 기능을 구현 누락함.
- 스프린트 도중 기획 완료된 건은 개발자와 싱크회의가 있으면 좋겠다.
- 기획서/디자인 90% 내용들만 스프린트 플래닝때 포함한다.
Digital Nomad를 꿈꾸는 Android Engineer