# 기능 하나 정의할 때 (프로세스)

• 기획에서 A라는 기능을 요구를 한다. ⇒ 월요일 회의 전달

  ⇒ 전달하고 → 그 다음 스텝 준비

• 개발팀 (기획 회의 이후) 월요일에 회의 → A라는 기능을 어떻게 구현할지 논의 (front-back같이 논의 ⇒ api명세) -애매한 게 있네? 기획이랑 다시 논의를 해야 하는 상황이 생길 수도 있음)

  • backend 먼저 작업을 시작 - 화요일 ~ 수요일 → 넘겨줘
  • front가 작업을 ⇒ 테스트 ⇒ 버그 ⇒ 개발팀 수정 ⇒ 목요일 금요일
  • ⇒ 토요일 일요일 테스트 → 버그 수정 요청 ⇒ 테스트 → 버그 수정 요청

• 2주 단위로 진행

• 각 파트별 비어있는 텀은 → 각자의 포지션에서 개선 가능 방향으로 진행

• (문제) 단, 기능 하나가 오래 걸릴 수 있음 + 기능만 구현하기 급급해지면 안 됨

  ⇒ (해결) 스프린트 회의 전 체크하기

# 시스템을 잡으려면

PM/PO의 역할

1. 시스템을 정한 후, 개발 주기 컨트롤 할 수 있어야 한다.

   • 2주 기간 → 늘어질 수 있는데, 계속 알림을 주어야
   • 요청한 기능이 생각보다 더 걸리면 ⇒ 기간을 더 늘리면서 + 다른 사항들 유동적으로 컨트롤

2. 스프린트 회의 전

   1) 체크

   • 프론트/백 지금 진행 중인 게 있는지 + 급하게 해결해야 하는 게 있는지

   • 앞서 체크하고, (기획) 분량 조절해서 전달

     ⇒ 슬랙 룰로 활용 (특정 요일에 프론트/백 뭐 할지 적어달라고 하기 → 그에 맞춰서 분량 조절)

     (그러기 위해서는)

     • 일단 기능 명세들 먼저 만들기 + 중요도에 따라/우선순위에 따라 전달할 것
     • 프론트, 백엔드 따로 전달할 거는 회의 때 X ⇒ 슬랙 팀 채널로 전달할 것

   2) 스토리 보드 준비 (프/백 그 다음 논의 진행할 수 있도록)

   • 스토리 보드 : 컴포넌트와 기능 + 동작 + 동작과 동작 사이의 전개 흐름

     ⇒ 회의 전까지는 이걸 확정 짓고 → 전달하면, 디자인만 입혀야

   • 디자인은 프론트가 작업을 시작하기 전까지만 전달하면 됨

3. 스프린트 회의 때

   • 기획팀이 개발팀에 빠르게 전달하고 → 될지 / 안 될지를 판단하는 목적

     (즉, 개발 팀이 기능 명세를 진행하기 위한 회의)

   • 회의 주기

     • 2주에 한 번 → 월/금 베스트
     • 모든 팀원 참여 부탁
     • 1주에 한 번은 → 프/백 파트 적어도 한 사람씩만 가볍게 들어와서 + 상황 공유 + 문제점들 정도만

4. 스프린트 회의 이후

   • 그 다음 개발 회의로 넘길 때, 대강 얼마나 걸릴지 알려 달라고 하고
   • 전달 받아서
   • 그 다음 사항들 진행과 현재 진행을 유동적으로 정해야 함