기획 심의 리뷰
심사위원이 좋게 봐준 것 같다.
문제상황에 공감은 잘 해주신 것 같다.
발생할 수 있는 문제점들을 다 생각은 해봤다라는게 어필이 된 것 같다.
기프티콘을 서버로 넘겼을 때, 해법이 없는 상황은 맞다
메타 정보는 상관없지 않나?(금액, 브랜드 꺼 )-구현 범위가 달라지긴 할 것
지라 활용
보드->오른쪽 상단 더보기 버튼-> 그룹화 기준 ->하위 작업
작업 task가 보드 내에서 볼 수 있게끔 활용해야 함
아직 티켓이 활성 스프린트에 진우의 개발 티켓 만 있는 상태
다른 사람의 개발 티켓도 할당이 되어야 함
ex) 회원가입한다라는 스토리가 작성되어 있는 상태
시나리오 ~~~ 가 있음
스프린트 백로그 ~~~ 가 있음
이 이슈티켓에서 한정해서 봐야할 하위이슈는 회원가입과 관련된 내용의 산출물만 정리되면 된다.
api, 기획안, 와이어프레임, 프론트의 개발 task, 테스트 이슈 등
각각의 담당자들이 할당되어야 함
스토리 이슈는 스크럼 마스터가 만든다
스토리 등록에 대한 책임은 스크럼 마스터가 진다.
사용자 스토리 정의: 사용자가 회원가입을 이메일과 패스워드로 한다. (기술적 이야기 X )
각각 담당자들의 하위이슈를 만든다.(FE, BE, 서버사이드 등)
에픽 바로 아래에는 하위이슈를 가질 수 있고, 맨 마지막 역할을 하는 티켓은 하위이슈가 없다.
에픽(대분류) 밑에 작업, 스토리(중분류), 하위작업(소분류)등이 올 수 있다.
중분류에서의 산출물
요건, 산출물 정의 (최대한 보는 사람들의 해석이 다른 것을 없게끔)
요건: 이게 해결되면 이슈를 완료시킬 거야라는 의미
기존의 ‘스프린트 백로그’는 개발 요건에 해당하는 것 같다.
하위 Task(하위 이슈 추가)
[dev][FE] ~~
하위 task는 할당된 담당자가 구체화 해야 함
산출물 정의 작성
하위 task를 언제까지 할래는 Stroy point estimate
기능에서 추정을 시간으로할건지 스토리 포인트로 할 건지 선택 가능
개발이 완료된 이후에 소통은?
보드에서의 워크플로우
댓글에서는 업무요건에 대해서 커뮤니케이션 할 수 있다.
캘린더를 넣어서 개발 일자를 넣어줘도 됨
댓글에 반응은 필수
검토 상태
검토는 컴포넌트에서 함(팀에서 관리하는 거여서 컴포넌트 메뉴가 없다(?))
컴포넌트는 역할과 같음(기획, 스크럼마스터, BE, 등등)
프론트는 기획자한테 리뷰를 받으면 됨(컴포넌트를 기획에다 함)
조직에서 관리할 수 있는 걸로 설정을 바꾸면 컴포넌트 메뉴가 생길 것
지금은 보고자==리뷰어로 생각하고 하자
댓글에 데모 링크 같은게 있으면 그 코멘트에 따라서 리뷰를 해줌(댓글을 달아줌)
다하면 검토 완료 상태로 바꾸면 됨(이슈가 끝남)
워크 플로우 하나를 더 추가해서 검토 완료 상태를 줌
코드 검토는?
지라랑 깃허브 레포 연결
특정 이슈 하나 당 github 브런치를 하나씩 갖게 됨
스토리 리뷰는?
해당 스토리에 검수 티켓을 하위이슈를 만들어서 리뷰를 할 수도 있음
숨겨진 일들도 티켓을 만들고 할당을 하면 어떤 상황이든 정의 내려서 업무를 수면 위로 올릴 수 있음
개발 뿐만 아니라, 환경 구성도 하위 이슈로 추가할 수 있다.
시간기록을 잘 해야 함
스크럼마스터가 이슈를 정의하고 요건을 넣는거에서 시작하고, 그 요건에 대한 하위태스크를 추가해서 해당 스토리를 완료짓게끔 구성한다.
거기에 필요한 시간추적을 해놓으면 더 좋다. 스크럼 마스터는 한사람을 특정해서 하는게 좋다.
스크럼 마스터가 정한 우선순위에 움직일 것
공부가 필요할 때는
스토리안에다가 공부하는 티켓을 만들고 시간을 포함해도 좋긴함
공부하는 것은 별도의 에픽을 만들고 거기에서 시간을 할당하는게 좋을 듯
검수하는 것도 티켓을 넣는 것도 좋다.
시간이 얼마나 걸리는지 객관화가 필요하다.
워크플로우 보강이랑 레포지토리 연동도 필요
스토리를 정의하고 이걸 다하면 프로젝트는 끝이다.
스토리를 작성하는 시간은 어떻게 기록?
개인의 백로그에서 시간 기록 할 수 있음
그 스프린트마다 작성하면 됨
이슈 검토하는 시간도 작성하면 됨
기능 명세를 잘 이야기를 안하고 해서 문제가 생기고 있다.-> 깊숙한 합의가 필요
멘토님 의견
이번 주는 스터디하는 시간으로 가지는게 좋을 것 같다.
에픽보다 스토리가 정의되면 되는데 스토리를 잘 정해야 할 것이다.
기획에 대한 합의가 먼저임
좋은 유저 반응을 받을 수 있을 만한 MVP를 만들어야 한다.
우리 앱을 이용했더니 버려질뻔한 기프티콘을 잘 쓸 수있어요 라는 경험을 줄 수 있는 MVP를 만들어야 함
MVP는 핵심만들어있으면 됨
다음 멘토링
MVP에 뭐가 들어갈건지에 대한 이야기를 다음주에 할 것
와이어프레임 혹은, 와이어프레임을 보여줄 수 있는 스케줄을 보여주자
미니프로젝트할거면 계획만 있고 서로의 상상을 맞춰주면 좋을 듯
MVP가 언제쯤 나오겠다라는 것도 다음 멘토링 때 나올 수 있을 듯
와이어프레임의 범위를 어디까지 해야 할지 이야기 해보자