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

이전 회사에서 SSD FW를 개발할 때에는 sprint에 작업하기로 한 task가 변경되는 일이 거의 없었습니다. 제품의 완성 기한이 정해져있고, 필요한 기능들이 추가되면 수시로 backlog에 넣지만, 이 sprint에 작업 순서를 바꾸거나, backlog에 우선순위를 높여서 먼저 처리하도록 등록하는 일도 많지 않았습니다. 일정을 크게 나누어서 - SSD의 일반 동작부터 개발/검증 하고 - 특수 상황의 동작을 개발/검증 하므로 큰 일정 내에서는 급하게 순서를 변경할 필요가 없었어요. 간혹 특정 모듈이나 기능에서 예상 보다 버그가 많이 나오거나, 해결에 시간이 오래 소요되면, 하던 작업을 멈추고 투입되기도 했지만요. 현재 회사에서는 서비스를 제공하기 때문에, 주기/비주기적으로 개선 버전을 배포합니다. 이 때, 배포 주기와 개발 sprint 기간이 일치하지 않다보니 기획적으로 기능의 배포 순서가 바뀌면 backlog task의 우선순위가 바뀌거나, 예정에 없던 task가 생기기도 합니다. 작업량이 많아서 두 sprint로 나눠서 작업하려다가, 중간에 우선순위가 바뀌면 참 찝찝하기도 하고, 우선순위가 바뀔정도로 급한 일이 들어왔다는 얘기라서 task 크기에 따라 정신없이 바빠지기도 합니다. ... 좀 여유가 생길까 했더니 다시 바빠졌네요 ㅠㅠ