백로그 Backlog

이전 회사에서 SSD FW를 개발할 때에는 sprint에 작업하기로 한 task가 변경되는 일이 거의 없었습니다.
제품의 완성 기한이 정해져있고, 필요한 기능들이 추가되면 수시로 backlog에 넣지만, 이 sprint에 작업 순서를 바꿔서 완료해야 하는 일은 거의 없었어요.

일정을 크게 나누어서
- SSD의 일반 동작부터 개발/검증 하고
- 특수 상황의 동작을 개발/검증 하므로
큰 일정 내에서는 급하게 순서를 변경할 필요가 없었어요.
간혹 특정 모듈이나 기능에서 예상 보다 버그가 많이 나오거나, 해결에 시간이 오래 소요되면, 하던 작업을 멈추고 투입되기도 했지만요.

현재 회사에서는 서비스를 제공하기 때문에, 주기/비주기적으로 개선 버전을 배포합니다.
이 때, 배포 주기와 개발 sprint 기간이 일치하지 않다보니 기획적으로 기능의 배포 순서가 바뀌면 backlog task의 우선순위가 바뀌거나, 예정에 없던 task가 생기기도 합니다.

작업량이 많아서 두 sprint로 나눠서 작업하려다가, 중간에 우선순위가 바뀌면 참 찝찝하기도 하고,
우선순위가 바뀔정도로 급한 일이 들어왔다는 얘기라서 task 크기에 따라 정신없이 바빠지기도 합니다.

네,  계속 바쁘네요