일정관리를 위한 첫 Jira 사용 회고 -2
칸반 보드, QA, 백로그, 회고
이전글: 일정관리를 위한 첫 Jira 사용 회고 -1
다음글: 문제는 어떻게 바라보고, 질문은 어떻게 해야할까?
나의 칸반 보드 활용법
칸반 보드는 프로젝트의 전체적인 현황을 파악하기 위한 목적으로 활용했습니다. 칸반 보드에서는 각 이슈에 대해 다음과 같은 상태 값을 설정하여 사용했습니다.
할 일(To do) - 작업 전
진행 중(In progress) - 작업 중
지연 or 보류(hold) - 검토가 필요한 작업
완료(done) - 작업 완료
칸반 보드 샘플 (출처: Jira)일정을 관리할 때, 가장 중요한 건 프로젝트의 진행 상황을 모두가 인지하고 있는 것으로 생각했습니다.
그래서 매일 스크럼을 진행하면서, 칸반 보드에 자신의 업무 상황을 최신화하도록 요청했습니다.
또한, 각 담당자가 업무에 대한 책임감을 느낄 수 있도록 진행 상황을 직접 물어보며 관리했습니다. 하지만 중요한 것은 프로젝트 일정이 동료들에게 스트레스로 다가오지 않게 하는 것이었습니다. 그래서 저는 일일이 확인하며 지시하기보다는, 함께 논의하며 동료들의 양해를 구하면서 진행상황을 확인했습니다.
즉, 정리하자면 다음과 같습니다.
1. 프로젝트의 진행 상황을 모두가 알 수 있도록, 칸반 보드를 자주 확인할 수 있게 유도하려 함
2. 동료들이 일정으로 스트레스받지 않도록 부드럽게 커뮤니케이션하려 함
QA 진행 및 백로그 관리
여러 프로젝트를 진행하면서 깨달은 것 중 하나는 개발이 변동성이 크다는 점입니다. 예상치 못한 곳에서 이슈가 발생하여 기획한 기능을 개발하지 못하거나, 뜻밖에 버그가 발견되는 경우가 많았습니다. 그래서, 현 일정에서 진행하지 못하는 업무들은 백로그로 두고 문서로 정리하는 작업이 필요했습니다.
백로그
백로그를 관리할 때는, 단순하게 해당 이슈의 상태를 backlog로 변경했습니다. 그리고 저희 팀은 여러 프로젝트를 동시에 진행하고 있었기 때문에, Jira의 백로그 화면만으로 이슈들을 관리하는 것이 어려웠습니다. 그래서 백로그로 변경된 이슈들에 대한 문서화 작업을 추가로 진행했습니다.
백로그 샘플 (출처: Confluence)제가 생각했을 때, 백로그에서 중요한 점은 다음과 같습니다.
1. 백로그 리포팅 순서가 아닌 프로젝트의 우선순위를 기준으로 정렬하는 것
2. 우선순위가 높은 백로그의 경우 작업 리소스를 기준으로 구분하는 것
(일정이 생겼을 때 업무의 범위를 효율적으로 논의하기 위함)
QA
기존 보드와 QA의 차이점은 크지 않지만, 기존 '할 일, 진행 중, 지연 or 보류, 완료'에서 '해결됨'을 추가했습니다. 당연하게도 버그에 대해 수정했어도 사용자 입장에서 한 번 더 검증하는 절차를 거쳐야 했기 때문입니다.
QA 과정에서 버그가 발견되는 것은 일상적인 일이지만, 가끔은 중요하고 기본적인 부분에서 버그가 나타날 때가 있었습니다. QA 업무를 처음 시작했을 때, 개발 QA를 진행했을 텐데도... 이런 기본적인 버그들이 확인되는 것이 마음이 아주 아팠습니다.
하지만 프로젝트 경험이 쌓이면서 생각했던 점은 다음과 같습니다.
1. 사용자 입장에서 간단한 기능도 개발에서 어려울 수 있다.
2. 기획에서도 에지 케이스를 고려하지 못하거나 누락이 발생하는 경우가 있다.
3. 버그를 확인했다면 해결하면 된다.
회고
이번 프로젝트에서 Jira 도입으로 일정 관리가 훨씬 수월해졌습니다. 그런데, 아쉽게도 후반부에 업무가 집중되면서 계획에 없던 야근을 해야 하는 상황이 많이 발생했었습니다.
상황을 예시로 설명드리자면, Z기능에 대한 일정을 개발자분에게 확인했을 때, 3일이었지만 작업을 하다 보니 3일이 4일이 되고 5일이 되는 상황이 발생했었습니다.
그 원인을 살펴보니, 기획이 반영되지 않은 부분이 있어 일부 기능을 다시 수정해야 했고, 개발 과정에서 예상치 못한 작업량이 확인되기도 했습니다. 또한, QA 과정에서 예상보다 많은 버그가 발견되어 프로젝트 일정이 지연되었습니다.
비록 커뮤니케이션을 충분히 했다고 생각했지만, 문제가 발생한 것을 보면, 단순히 많이 하는 것보다 어떻게 더 효과적으로 할 수 있을지 지속해서 고민할 필요가 있음을 느꼈습니다.
이 글을 쓰며 다시 한번 회고합니다.
KPT 회고
KEEP
- Jira의 도입과 모두가 일정에 대한 책임감을 가질 수 있게 노력한 점
- 사건 사고가 잦았지만 무사히 정해진 일자에 론칭을 한 것
Problem
- QA에 대한 일정을 제대로 고려하지 못한 점
- 개발에서 확신이 서지 않는 부분이 있을 때 기획자와 소통하여 해결할 수 있는 분위기를 제공하지 못한 점
- A부터 Z까지 각 기능별로 일정을 세운 것이 아니라, 전체 프로젝트 단위로 일정을 계획한 점
- 개발 기간이 지연되는 상황이 발생했을 때, 그 원인을 파악하지 못한 점
Try
- QA를 고려해서 일정을 계획하고 관리하기
- 지속해서 기획 내용을 공유하고 편하게 기획자에게 물어볼 수 있는 분위기를 형성하기
- A to Z 각 기능별로 일정을 디테일하게 세우기
- 개발이 지연되는 상황이 발생했을 경우, 그 원인에 대해 꼼꼼하게 물어보기
