1주차 멘토링

자기 소개 (TMI)

• 세영:
  • 비전공자
  • 아이스크림 좋아함
• 도훈:
  • 생일 → 삼일절
• 주영:
  • 멋사 → FE
  • 게임 좋아함
• 원희
  • 비전공자: 졸업함
  • 고양이 두 마리 집사
  • 배경사진 의미?
    • 계획을 잘 못지켜서 팀원들한테 민폐를 끼친적이 있나?
    • 아니요
• 원종
  • 굿닥 FE 개발자 (3년차)
  • 비전공자
  • 모르는 부분은 같이 고민하고 찾아나가 봐요

이번주 어떤 작업?

• 예상 시간 산출

• 기획서 디자이너가 한것같이 잘하셨네요
  • 감사합니다 🙂 ❤️
• 다하신건가요?
  • 네
• 같이 작성하신건가요?
  • 네

• 이 프로젝트에서 가장 중요한 기능?
  • 공유 문서를 작성할 수 있는 에디터
  • WebRTC 기반의 화상회의

• 여러분들이 생각하기에 개발을 본격적으로 할 때 하루에 몇개의 스토리 포인트가 가능한가?

  • 스토리 포인트
    • 다른 예외 제외
    • 이 작업을 하기 위한 모든 선수 작업이 수행되었다라는 전제하에
    • 순수 개발 시간
  
  

  • 현재 예상 시간: 개발 하는데만 걸리는 시간

  • 최종 예상 시간: 현재 예상 시간 * 3

    • 마스터 클래스
    • 코드 리뷰
    • 학습 등등

  • 그럼 하루에 6시간으로 예상

    → 이 방법 좋으나, 불명확한 부분이 많다.

    → 백엔드 API 기능 개발 이후 연동 하는 태스크들

    → 앞의 태스크가 완료되길 기다려야 함.

  
  
  • 하루에 스토리 포인트 몇 정도 할 수 있는가?
    • 하루 종일 작업한다고 가정 → 6
      • (4 + 6 + 4 + 6) * 4(4명) ⇒ 1주에 80 예상 작업 시간
      • 80 * 4 = 320 ⇒ 산술적으로
        • 마지막주까지 기능 개발을 붙잡고 있는것은 바람직하지 못하다.

❗1주차 목표

• 우리 팀이 이번 그룹 프로젝트에서 어느 사이즈의 프로젝트를 할 것인지 정량적으로 예측(estimation) 해보기.
• 스크럼마다 매일 어떤 진행속도로 진행이 되는지를 확인해야 함.
  • 우리의 Goal이 있는데 여기에 현실적으로 다가갈 수 있는 속도
• 우선순위 산정
  • 상, 중, 하
  • P1 ~ P5 (숫자가 낮을수록 우선순위가 높은 작업 티켓)

질의응답

Q. 이거 가능한 사이즈인가요?

• 저희가 생각하기엔 엄청 빡셀것같은 기능인데 예상시간이 너무 작아요

A. 예상시간 어떻게 잡으셨나요?

• 태스크별로 조금의 요구사항은 적어주는게 좋다.
• planning poker 사용해보세요
  • 가정: 이 작업을 위한 모든 선수작업이 수행되었다.
    • 기획, 디자인, 백엔드 API 등
  • 너무 다르면 토론 → 티켓에 대한 이해도가 올라감
• 본격적으로 작업 시작하기전에 해보는거 추천

Q. 우선순위 상 중 하는 어떤 기준으로 나누나요?

• 이런 식인가요?
  • 이건 무조건 해야한다 → 상
  • 이건 시간 부족하면 버려도 된다 → 하

A. 저는 이렇게 합니다.

• 상
  • 하늘이 무너져도 구현되어야 함
  • 뒤에 다른 기능들을 구현하기 위해 빨리 개발되어야 함
  • 중요도 & 시급성
• 중
  • 일반적인 기능들
• 하
  • 있으면 좋지만 없어도 서비스에는 크게 지장이 없는 기능

조언

• 첫 배포를 빨리 하는 것이 생각보다 도움이 될수도 있다.

  A. 저희도 그렇게 생각합니다!

  • 첫날부터 하려고 했어요
    • 아.. 그렇게 일찍은 예상 못했는데

• 페이즈별로 나눠보기
  • 에디터
    • Phase 1(우선순위 상)
    • Phase 2(우선순위 중)

• 그렇다고 미완됐는데 배포? → 이건 비추. 그렇게까지?

• 주기적으로 배포 추천!

• pre-commit husky 설정 추천 👍
  • git commit 하나하나 할 때마다 코드 컨벤션이 맞춰짐

• git branch 전략
  • git flow vs github flow
    • 초기 스타트업 같은 곳은 github flow가 좋다.
      • 안전성은 떨어지지만 개발 생산성이 뛰어나다.
    • 환경 한개 vs 두개 (production, develop)
      • 개발자가 feature하려면 branch를 따야함.
      • merge를 할 때 실제 배포 환경에 바로 해버리면 위험하다.
        • 실 사용자들이 바로 피해를 봄 → 안전성이 떨어짐
        • 안전장치를 두는것
      • 개발 서버를 하나 두고 잘 돌아가는지 확인하고 → production으로 반영

Wrap Up

1. 스토리 포인트 (예상 시간) 예측
   1. 우리 팀의 속도
   2. 각 태스크에 대한 예상시간 산정
2. 태스크의 우선순위 설정
   1. 상, 중, 하 or P1 ~ P5
   2. 배포를 자주 빠르게 하면 좋다.
      1. 기능 단위 배포 (에디터, 화상 채팅 서비스)
      2. Phase1(우선순위 상) Phase2(우선 순위 중)…
3. 환경설정 먼저 해 놓으면 좋다. (생산성, 심리적)
   1. CI/CD
   2. Convention (eslint, prettier, husky)
   3. git branch

다음 멘토링: 11/16일 수요일 9시

추가 질문있으면 슬랙에 부탁합니다 🙂