2주차 멘토링

Jump to bottom

백도훈 edited this page Nov 18, 2022 · 2 revisions

협업

스크럼 기록을 매일 작성하는 과정에서 어려운 점?
- 어제 한 일, 오늘 할 일, 방해되는 것 — daily sync
  - 구체적인 이야기들을 하게 될 때가 있다.
    - 어떤 이슈가 언급된다면 코멘트까지만 하기.
    - 특정 이슈에 대해서 말해야 한다면 따로 시간을 잡아서 해결해요.
  - 숙제검사하듯이 하진 말아요. 너무 딱딱한 비즈니스 관계로만 이뤄지지 말아요.
    - 전날 아무런 작업을 하지 않아도 서로 이해해줘요. (이건좀.. 도훈님..열심히 하셔야죠….)
    - 작업을 잘 하는게 중요 → 서로 공유될 수만 있도록
    - 포장하는건 non goal
  - Assign → 스크럼때 결정
    - 스프린트 초반에(시작하는 첫째날이면 Best) 계획 회의
      - 그 주에 어떤 작업들을 할지
      - 누가 어떤 작업을 맡을지 (Assign)
      - 1 ~ 2시간 회의 해서 결정
      - → 작업 시작
  - 충고
    - 이정도 충분해요. 그런데 플러스 알파
    - 한 주 단위의 목표, 전체의 목표에 대해서 진행상황 체크해보기
    - 20일의 개발시간이 있는데 20%만큼 진행을 완료했는지?
    - 주기적으로 꼭 해야함 (매일매일 할 필요는 없음)

예상시간
- 0시간을 말씀하셔서 당황스러웠어요.
  - 왜 0으로 답하셨나요? 누가 했나요?
    - 모두다..했어요..
    - 균형을 맞추기 위해서 0시간이 필요했어요.
    - 실제로 작업이 그만큼 오래 걸릴 것 같지 않아서
      - 멘토님: 이해합니다.
  - 왜 당황스러웠나요?
    - 0시간은 사실 1시간도 아니고 진짜 0이잖아요. → 현실성이 없다
    - 자기 생각에 정말 얼마나 걸리는지 확인하고 싶었다. 이걸 기대했던것 같다.
  - 피보나치보다 조금 더 작은 단위를 써도 좋을 것 같다. (1, 2, 3, 4, 5 정도)
  - 나는 생각하지 못한것들을 다른 사람들은 생각한다. → 시간 차이가 난다. → 회의를 한다. → 태스크를 쪼개거나 추가한다.
    - 멘토님이 원하던 방향 👍

테크 스팩
- 테크 스팩을 도입하게 된 건 너무 잘하신 방향
- 사실 미완성이에요.
- 만든 계기는 마스터 클래스에요.
- 같은 곳을 바라볼 수 있게 됨
  - 스토리 단위 (10개 좀 많음)로 테크 스팩을 작성해보세요.
  - 해보고 별로다 싶으면 안해도 됨.
  - 그런데 싱크를 맞추는건 너무 중요함

백로그에 만들어둔 태스크 외에 발생하는 이슈들에 대한 일정 관리
- 백로그는 기능
- 그 외에 버그 픽스나 개선을 위한 티켓들은 따로 처리 (Wabinar는 github issue)
  - 멘토님도 Gihub issue를 사용하지만 예상시간을 산출하지 않음.
  - 시간을 고려하지 말고 작업하기.
- 쓸 수 있는 시간을 확보해놓고 자율적으로 처리하기
  - 버그 픽스나 개선할것들이 너무 많다면 쓸 수 있는 시간을 줄여 보세요.
  - 너무 큰 버그나 개선이면 스토리 포인트를 잡아보고 예상시간 산출해보기. 티켓 달기
- 기본적으로는 신규 기능 개발 / 버그 픽스, 리팩토링은 구분해서 작업을 고려합니다.
  - 신규 기능 개발 → 예상 시간 산정 포함
  - 버그 픽스 / 리팩토링 → 예상 시간을 산정하지 않고, 하루에 이러한 작업을 할 수 있는 Buffer시간을 책정해서 작업을 진행
    - 하루 코딩 시간 어느 정도? (학습, 마클 이런거 다 제외)
      - 5-6시간 정도
      - 스토리 포인트 → 4
      - 버그 픽스/리팩토링 → 1-2
    - 만약 위 작업이 많을 경우, 따로 티켓을 만들고 예상 시간을 산정해서 진행해도 좋음

기술

yarn berry
- 왜 사용?
  - zero install → build 시간 단축에 도움.
- 어떤점이 안됐나요?
  - 패키지 불러오는 부분에서 에러가 발생.
  - 백엔드는 모듈을 못불러옴
  - 프론트엔드는 에디터의 자동완성 기능을 사용할 수 없게 됨
- 현재 npm사용 중
  - build 시간이 너무 오래 걸려서 CI가 오래걸려요.
- 멘토님의 답변
  - yarn berry가 생각보다 잘 안되는 상황
    - 이런 상황을 문서화 해놓기
    - 나중에 yarn berry를 다시 사용할 수 있고, 다른 팀에서 이런 문제를 겪고 있을 수 있고, 나중에 다시 해보려고 할 때
    - 문서화를 잘 해놓는다면 트러블 슈팅하는 시간이 아깝지 않게 됨
  - build 시간
    - 해결해야하긴 함.
    - 고민하는건 너무 좋아요.
    - npm → yarn berry 외에도 많은 방법이 있음
    - 지금 고민하기엔 우선순위가 높지 않은것 같아요.
API naming convention은 어떻게?
- 보통은 이 부분 고려하지 않는데 나중에 복잡도가 많이 올라가는 부분
FE에서는 마크업 후 데이터 처리 작업을 하나요?
- 멘토님도 이렇게 함.
- BE하고 데이터 스키마에 대해서 이야기를 하면서 FE 페이지별, **컴포넌트별**로 어떤 데이터가 들어오고 어떻게 처리를 해줄지 mock 데이터나 mock api 등으로 API 완성되기 전에 붙여가면서 하는 방법도 권장
CI에서 빌드나 테스트가 막힐 때마다 뿌듯해요 → 이 말을 이해를 잘 못했어요 😥
- 빌드가 실패하면 머지가 안됨 → 제대로 일을 하고 있구나!

질의응답

Q. Assign을 정하는 기준이 있나요?

A.

Q. 분업을 못하고 있어요.

기능단위로 들어갈만큼 큰 기능들이 정리되지 않음

task의 순서가 있어서 Assign을 하기 어려움

팁

2, 2(이건 그냥 예시) 나눠서 front, back 나눠서 작업

f1, b1 → 스토리 1 작업

f2, b2 → 스토리 2 작업

어느 한 쪽이 일찍 끝나면 다음 스토리 진행

A. 저희는 3:1이에요. 풀스택 하고 있어요.

Role을 주단위로 바꿔봐도 좋겠지만 한주가 생각보다 빨라요.

FE하다가 제대로 마무리 못하고 BE로 넘어가는 상황이 발생할 수 있음. ← 이거 조심만하면 추천

풀스택으로 하는거 개인적으로 추천

소감

저희도 일과시간을 기능 개발 / 개선 몇 시간씩 쓸 수 있는지 정해두면 좋을 것 같아요

하루에 저희가 산정한 시간 기준으로 10포인트 정도씩 작업하니까

한 사람 기준 2~3

wab