에자일하다 - Sprint( epic과 user story.. 시연, 회고까지)

1. Journey 디자인, 공유, 리뷰 #PM

초기 컨셉에 해당하는 core 타깃의 여정을 디자인하고 구축 예정인 서비스에 유입되는 시점부터 최종 딜리버리되는 과정에 대한 플로우를 그린다

 

2. epic 가이드 설정, 공유, 리뷰 #PM

epic은 이해관계자별로 구분하되 각 epic은 완결형으로 구성한다. 여기서 완결형은 해당 epic 단독 그 자체로 원하는 바 실행이 가능한 유의미한 단위를 지니는 사용성을 말한다

*다만 릴리즈된 이후에는 퍼널분석을 통해 kpi을 관찰하며 epic을 설정한다 #PO

 

3. 실행( 하나의 스프인트 단위 1/4) - #서비스기획

epic이 포함하는 user story, 인수조건을 작성하고 공유, 리뷰를 통해 업데이트한다

*상황에 따라 다르겠지만 ‘하나의 epic’을 ‘하나의 스프린트’로 한다는 기준으로 작성되었다

**다만 릴리즈된 이후에는 ‘하나의 스토리’를 ‘하나의 스프린트’로 설정한다

 

3. 실행( 하나의 스프인트 단위 2/4) #프로덕트 디자인

각 스토리별 GUI 설계한 후 공유, 리뷰를 통해 업데이트한다

 

3. 실행( 하나의 스프인트 단위 3/4) #개발

프로토타입을 살펴보고 이슈발행한다. 모든 이슈가 해결되면 개발설계, 개발 후 시연한다

 

4. 시연 후 회고( 하나의 스프인트 단위 4/4) #모두

단위별 사용성 테스트를 진행한다. 회고 후 릴리즈할지 드롭할지 결정한다

초기 컨셉에 해당하는 core 타깃의 여정을 디자인하고 구축 예정인 서비스에 유입되는 시점부터 최종 딜리버리되는 과정에 대한 플로우를 그린다

 

 

5. 오해

에자일이나 린스타트업 모두 MVP를 시작으로 컴포넌트( 또는 모듈 형태의 기능) 단위로 확장해나간다. 해당 컴포넌트는 내부 회고나 베타 테스트를 통해 릴리즈 또는 추가된다.

이때 TF가 유념해야 할 점은 기획자는 리더가 아니라 사용자와 소비자를 대변하는 역할( 리더가 아닌 자가 내부 TF를 설득하는 과정에서 자연스럽게 데이터가 주요한 도구로 사용됨)이라는 점, 디자이너는 스타일링뿐만아니라 기획력을 특히 수반해야 한다는 점( 이쁜 쓰레기가 아닌 쓸모있는 썸띵). 개발자은 레고, 퍼즐 또는 자석처럼 딱 떨어지는 효율성있는 조각을 생산하는 것이 아니라 단추, 볼트너트 또는 암수가 있는 고리 형태의 조각을 생산하는( 연결과정에서 공간적 중복으로 인한 로스 포함한) 것임을 인지해야한다. 

공통으로는 오너십을 갖되 애착에 빠져서는 안된다는 점이고 특정 스프인트 과정에서 드롭된 컴포넌트들의 경우에도 그냥 폐기하지 않고 재사용할 수 있는 수준으로 쟁여( 유효 자산으로 백업)놓아야 한다.