정보처리기사 책을 보고 있는데 스크럼 기법이라는게 나왔다.
참여했던 프로젝트에서 잘하는 팀원들이 백로그, 스프린트 같은 것을 도입하자고 해서 도입했었는데, 이게 다 정해져있는거였구나,,
책에 나와있는 것을 토대로 프로젝트에서 어떻게 적용해왔는지, 어떤 것을 또 적용해보면 좋을지 생각해보자
스크럼 개발 프로세스
- 제품 백로그(Product Backlog)
미니 프로젝트 애브리플젝을 했을 당시 팀원분이 네이버 형님들도 이런 것을 사용하신다며 만들어주셨는데, 굉장히 유용하게 썼었다.
실전 프로젝트 가치마인드 역시 같은 팀원분과 함께하게 되어 이전에 사용했던 백로그를 참고해 작성했다.
이번 프로젝트는 프론트 팀원이 두명 뿐이였어서 깃헙 이슈와 프로젝트, 그리고 슬랙만으로 일정 관리가 가능했기 때문에 프로젝트를 진행하면서는 백로그를 잘 사용하지 않았지만, 팀원이 많다면 꼭 이런 백로그를 공유할 필요가 있을 것이라고 생각한다.
디자이너와 협업을 하면서 페이지 그림만으로 소통하면 어떤 기능이 어떻게 동작하는지에 대해 서로 다르게 이해할 수 있다는 것을 배웠기 때문이다. 초반에 화면설계서에 써서 공유하기는 했지만, 화면설계서는 잘 안보게 되더라,,
이렇게 한 눈에 들어오게 누가 담당하고 있는지, 어떤 기능이 어떻게 동작하는지 적어서 공유하는게 훨씬 도움되는 것 같다!
-
스프린트 계획 회의(Sprint Planning Meeting)
처음에 리더/부리더가 스프린트 형식으로 진행하는게 좋을 것 같다고 해서 스프린트 단위로 계획을 짰다. 이런 큰 프로젝트를 팀으로 함께 진행하는게 모두에게 처음이였고, 새로운 기술들을 많이 적용하게 되어 전체적인 개발 스케줄 예측이 생각대로 진행되지 않았고, 스프린트가 계속 밀리게 되어 스프린트 단위 계획은 초반에 포기했다. 나중에 개발이 익숙해지고, 예측이 가능해지면 이 역시 일정관리에 큰 도움이 될 것 같다!
-
스프린트(Sprint)
프론트/백의 작업 진행상황을 공유하기 위해 깃헙 이슈로 할일을 정리해 In Progress, In Review, Done 등 작업 status를 설정했다. 솔직히 매번 내용 쓰기 귀찮았는데 협업에 정말 도움이 되는 것 같다. 팀원분이 무슨 작업을 하고 계신지, 백에서는 어떤 작업을 진행하고 있는지 계속 여쭤보기 죄송할땐 이슈로 확인하면 되니까 좋았다 ㅎ 팀원분이 포맷까지 설정해주셔서 편리하게 사용할 수 있었다.
-
일일 스크럼 회의(Daily Scrum Meeting)
우리 팀은 매일 저녁 8시마다 회의를 했다. 어쩌다 밤을 새게 되면 아침에 일어나기도 힘들고, 뭔가 작업을 좀 하다가 회의를 하는게 할 얘기도 있고 하니까 저녁 시간으로 정했다. 서기를 정해서 회의록도 작성했는데, 서기는 내가 하기로 함 ㅎ 백엔드분들 이야기할때 잘 이해가 안돼서 초반엔 회의에 집중하기가 힘들었는데, 회의록 쓰려고 녹화해놓고 다시 듣고 하다보니 무슨 얘기 하는지 들리기 시작해서 좋았다! 하지만 한번에 잘 안들려서 녹화본을 다시 듣는게 바쁠땐 많이 밀리기도 했다. 리더가 이번주 뭐했지? 하면서 회의록 봐주면 기분 좋았음,, 헤헤
스프린트가 계획대로 잘 진행된다면, 소멸 차트란걸 만들어보면 좋을 것 같다! 그래프 형식이라 그런지 눈에 확 들어와서 쭉쭉 줄어들면 뿌듯하기도 할 듯 ㅎㅎㅎ소멸 차트(Burn-down Chart)
- 소멸 차트는 해당 스프린트에서 수행할 작업의 진행 상황을 확인할 수 있도록 시간의 경과에 따라 남은 작업 시간을 그래프로 표현한 것이다. 초기에 추정했던 전체 작업 시간은 작업이 진행될수록 점점 줄어(Burn-down) 들게 된다.
아래 두개도 나중에 할 수 있겠징?!
5. 스프린트 검토 회의(Sprint Review)
6. 스프린트 회고(Sprint Retrospective)
으아,, 팀원분들이 documentation에 진심이셔서 엄청 잘 기록해주셨는데, 다시 보니까 정말 뿌듯하긴 하다,, 기록은 이렇게 하는거구나!! 배운 좋은 경험이였다.
