gitlab 프로토콜 1.3

2018년 6월 25일
|In 아카이브
|By 상돈

1.3 변경 목표

  1. gitlab 제품의 설계 목적에 맞게 활용하여 추후 gitlab의 기능을 폭넓게 활용할 수 있도록

이번 프로토콜의 업데이트는 gitlab 제품이 설계된 방향성에 맞게 gitlab의 기능을 쓰기 위해 이루어집니다. 내부 프로토콜에는 큰 변화가 없습니다.

라벨 legend

  • A: 기획, 디자인
  • B: 기획완료, 디자인완료
  • C: 준비완료:milestone, 준비완료:sprint,
  • D: aOS, iOS, Front-end, Back-end
  • E: 제품명
  • F: 운영요청, 긴급, TD, 기능부채, 기술부채

메인 시나리오

아이디어 등록

  • (구성원) 제안할 아이디어나 해결할 이슈가 있으면 Reception 프로젝트에 이슈를 등록한다.
    • 이슈 등록 시 권고사항
      • “문제→솔루션” 또는 “제안→기대효과”를 간단하게 작성한다.
      • 상세기획 or 솔루션을 제안하지 않도록 노력한다.
    • E라벨은 필요 시 선택적으로 단다.
    • 단, 장기 토론이 필요한 아이디어는 장기아이디어 프로젝트에 등록한다.
  • 신규 이슈의 내용을 살펴보고 필요한 조치를 취한다.
    • (PO) 당장 실행하기 어려운 아이디어는 드랍하거나, 장기아이디어 프로젝트로 이동시킨다.
    • (PO) 토론 후 디벨롭을 할 필요가 있는 이슈는 A라벨을 단다.
    • (VP) 운영대응이 필요한 경우 assignee을 배정한다.
    • (PO+VP) 그 외 적합한 조치를 현 체계 안에 상의하여 적용한다.

A라벨 POOL에서 꺼내가기

  • (PO+PD) A라벨 POOL에서 작업 여력이 있을 때 pulling하여 작업한다.
    • 작업이 시작되면 assignee를 본인으로 설정하고 완료되면 해제한다.
    • 기획/디자인이 완료되면 B라벨을 단다.
  • (PO) 기획or디자인 필요한 것 다 완료하면 C라벨을 단다.
    • App Client 포함 여부에 따라 milestone/sprint를 구별한다.
    • B라벨을 제거하고, 적합한 D/E라벨을 붙인다.
    • 중요도에 따라 weight를 단다.
      • 중요하면 1, 그렇지 않으면 9

전사회의에서 공유

  • 공유할 이슈
    • Reception gitlab – B/C라벨을 단 신규 이슈
    • 아이디어 gitlab – 등록된 모든 이슈
  • 발표자
    • Reception gitlab – 담당 PO
    • 아이디어 gitlab 이슈 – 제안자
  • 참석자
    • 전사 참석을 권장하나 필수는 아님

C라벨 POOL에서 꺼내가기

  • (VP) 마일스톤 산정회의를 통해 마일스톤/스프린트에 적합한 이슈를 선정하여 포함시킨다.
    • 일정: 새로운 마일스톤 시작 2주 전, 월요일
    • 참석 대상: 제작팀 전체
    • 산정 대상 이슈: C라벨 이슈
  • (CPO) 단, 제품 리드는 반드시 들어가야 할 소수의 이슈를 선정할 수 있다.

예외 시나리오

TD case(CPO)

  • 마일스톤을 파자. 주제를 적자.
  • 세부사항은 이슈로 나눠서 담자. TD태그
  • 큰 주제일 경우 마일스톤 설명으로 작성하자.

Devops case

  • 운영요청 POOL에서 꺼내가기
  • F 라벨이 달리면 slack #devops 채널로 update를 하여 즉시 대응한다.
  • 대응 가능한 개발자가 pulling하여 대응한다. (본인을 assignee로 지정)

아카이브