스프린트#5 (05.26 ~ 06.08) 요약
Agenda: 문구 수정 및 리디자인
스프린트 변경사항
스프린트 특이사항
개발 완료 관계자 Noti
스프린트#4에서 개발 완료된 항목에 대해서 완료됐는지 확인이 어려워 테스트에 딜레이가 발생했다는 회고가 있었다. Notion의 특성상 알림을 따로 설정해두지 않으면 Property가 변경되었다고 해도 작성자에게 알림이 가지 않는다. 개발자가 스프린트 보드의 Done 처리를 하거나 버그보드에서 완료 안내를 하더라도 노티를 받기 어려웠다.
지난 회고 때 완료 후 Comment 로 관계자를 태그하여 알림을 주자라는 Action Item 이 나왔고,
개발자들은 스프린트#5 동안 Done으로 옮기면서 해당 Issue/Task 글 작성자 혹은 관계자를 태그하였다.
결과는 앞으로 새로운 방법을 찾기전까지 유지하기로 하였다.
개발자 입장에서는 Done 처리하면서 태그를 하는 것은 큰 노동이 아니었고 담당자들 입장에서는 빠르고 편하게 진행상황을 확인할 수 있었다.
Firebase Crashlytics 최신화
기존 사용되던 Firebase Crashlytics 에는 2가지 문제점이 있었고,
문제들은 Firebase Crashlytics 버전 업그레이드를 진행하고 모두 해결되었다.
문제점 첫번째는 Migration 관련 알람으로 2020년 11월 15일 이후로 Fabric Crashlytics는 Crash Report 전송 안할거라는 안내가 나오고 있었다.
Firebase Crashlytics SDK 를 업그레이드하는 가이드라인은 Firebae 문서에 잘 나와있다.
두번째는 원인을 파악하진 않았지만 Proguard 때문이지 module의 method 명칭들이 아래처럼 minify된 값이 와서 Crash Report로는 버그 수정이 힘든 상태였다.
at droom.sleepIfUCan.MainActivity.c(SourceFile:1)
at droom.sleepIfUCan.MainActivity.b(SourceFile:1)코드반영 시점 가장 최신 버전으로 진행하고 업그레이드를 진행하면서 몇몇 관리들을 추가하였다.
com.google.firebase:firebase-crashlytics:17.0.0-beta04
com.google.firebase:firebase-crashlytics-gradle:2.0.0-beta04
(글을 쓰는 시점에 Beta가 끝나고 com.google.firebase:firebase-analytics-ktx:17.4.3 / com.google.firebase:firebase-crashlytics-gradle:2.1.1 가 나왔다.)
스프린트#2-5 회고
Good
- 주요 페이지들에 개선이 빠르게 적용 되어가고 있다.
- String 개선 관련해서 Slack 을 통해 진행상황을 문의/공유해주셔서 좋았다. 중간에 문의하거나 개입해야 하는 경우 관련멤버가 누락될 가능성이 적었다.
- 긴급한 것 없이 모든 이슈를 완료했다!
- 포인트가 적게 시작되서 걱정했는데 딱 맞게 진행되었다.
- 스프린트 플래닝 Task 전부 완료
- 스프린트 반복되며 git flow 에 점점 더 적응
- Crash Log 보기 편해짐
- Firebase 크래시리틱스가 신규 버전 적용이후로 여러 문제들이 해결되어 버그를 수정하기 편해짐
- 파이어베이스 크래시리틱스 많이 정리했다.
...후략...
To improve
- PR이 쌓여서 밀리는 경우가 생겼다.
- Branch 작명 룰 / Commit 작명 룰을 통일하면 좋을 것 같다.
- Bug 의심 상황일때 슬랙 / 노션 / 오프라인으로 문의가 와서 버그인지 헷갈리는 상황이 있었다.
- 기획이 완료되지 않는 내용이 중요도가 높아 순서가 살짝 꼬였다. 플래닝때 고려가 필요해보인다.
- String 수정을 요청하는 주체가 분산되어 중복 작업 및 혼선이 있었다.
- 타 팀과의 중복 태스크들이 생길 경우 중복 태스크가 여러 경로로 안드에게 넘어간다.
- 플래닝때 넣지 않은 긴급 태스크가 생길 경우 태스크 건의 프로세스가 애매했다.
...후략...
Action Items
- 플래닝때 넣지 않은 긴급 태스크가 생길 경우 태스크 건의 프로세스가 애매했다.
- (이상) 최대한 다음 스프린트 Backlog
- (현실) Bug Borad → 판단 후 Backlog
- 기획이 완료되지 않은 내용이 중요도가 높아 순서가 살짝 꼬였다. 플래닝때 고려가 필요해보인다.
- (이상) 기획이 완료된 것들을 Backlog / 플래닝 에 올린다.
- (현실) 산정된 점수에서 [ -50 ] 으로 우선순위 정렬
- Branch 작명 룰 / Commit 작명 룰을 통일하면 좋을 것 같다.
- Branch Rule: feature/, hotfix/, refactor/* 을 사용해본다.
- Commit Rule: [{Team 이름}] {내용}
