왜 Sprint Demo를 해야 하는 가 ?

Demo를 한다는것은 "지속적으로 완성되어 가고 있는 Product를 보여주는 것" 이다.

Project  구성원들은 이루어 낸 결과물에 만족감을 느낄 수 있다. 
만약 만족스럽지 못하다면 자극을 받을 것이다. 결국 동기 부여가 된다는 이야기다. 

Project구성원들이 Project를 확인 할 수 있다. 맡은 부분이외의 것들을 Demo를 통해 확인 할 수 있다.

Product에 대한 Feedback을 받을 수 있다. 매 Sprint 마다 피드백을 받음으로,  Product가 Agile해 질 수 있다. 
프로젝트가 산으로 가는 지 바다로 가는지 확인 할 수 있다.

점진적으로 프로젝트 완성도가 높아진다. 
Demo를 위해선 부분 기능들을 100% 완료 해야한다.  90%해놓고 나중에 하는 일이 없어진다.
왜냐하면 고객에게 보여줘야 하기 떄문이다.

Sprint Demo는 어떻게 해야 할까?

Sprint Demo는 해당 Sprint 목표에 충실한다. 
간단한 버그, 사소한 개선사항등은 구지 보여 줄 필요 없다. 
해당 목표를 명확히 프로젝트 관계자들에게 보여주면 된다. 

데모는 Presentation이 아니다. 
정교하게 보여주기 위해, 시간을 많이 들일 필요 없가 없다. 돌아가는 Product만으로 충분하다. 
기술적인 내용도 자제하고, Product가 어떻게 돌아 가는지만 보여주면 충분하다. 그것이 Point다. 

저작자표시 비영리

BackLog란 무엇인가 ? 



스크럼 백로그는 프로젝트 네비게이터다. 

네비게이터는 우리가 길을 떠날때, 우리가 가야할 방향, 예상 소요시간등을 제시한다.

스크럼 백로그는 해야할 일 목록, 소요 시간등을 포함한
프로젝트를 완료에 필요한 모든것들을 우리에게 보여준다.

BackLog에는 무엇을 어떻게 써야 하는가 ?

1. 형식

아이디는  Log Item에 대한 유일한 ID이며, 경우에 따라서, Issue Tracker ID와 동일 시 될 수 있다. 
BackLog의 형식은 프로젝트 의 특성, 개발팀의 성향 등에 따라, 가감하여 사용된다.

그러나, "우선순위" 와 "추정시간"을 빼버리는 일은 해서는 권장하지 않는다.
우선순위가 없다면, Scrum을 할 이유도, 할수도 없다. 

그렇다고 위의 예시 대로 따를 필요 없다.
말 그대로 Agile하게, 프로젝트별로(혹은 개발팀성향에 맞게) Customizing해서 사용하면 된다. 

2. 내용

BackLog에는 프로젝트에 수행에 필요 한 모든 내용이 기록되어야 한다. 

개발 기술, 제품의 기능만이 아니라, 개발에 필요한 모든 것들을 기록해야 한다. 
특히 개발에 걸림돌이 되는 것들은 높은 우선순위로 기록하여, 먼저 제거 하도록 해야한다.

BackLog는 누가 쓰고 관리하는가?

BackLog는 오직 Scrum Master만 이 쓰기 권한을 가진다.

Scrum Master는 고객, 외부팀, 개발팀 등의 의견을 고려하여, Project Back Log 를 작성한다.
Scrum Master만이 BackLog를 작성함으로, 얻는 이득은
커뮤니케이션 창구의 단일화다.

Scrum에서는 개발자들은 더이상 기획자들에게서 Interrupt를 받을 필요가 없다. 

BackLog는 언제 쓰는가?

최초에 BackLog는 프로젝트 시작전 , 스프린트 시작전에 작성된다.
그러나 BackLog는 항상 갱신되어야 한다. 

Sprint에 대한 BackLog를 수정하는 일은 최대한 기피하여하 하지만 
프로젝트 BackLog 는 시시때때로 갱신되어야 한다. 

Sprint에대한 Back Log은 최대한 변경을 자제해야만한다.
만약, 전반적인 수술이 필요성이 느껴진다면, Sprint를 취소하는 것을 고려해야 한다.

저작자표시

+ Recent posts

티스토리툴바