🐋 7월 22일 회의

회의 기록자 : 바다 회의 MC: 테드

1. 업무 진행 방식에 대한 논의 제기 (by.테드 & 커비)

주말에 테드와 커비가 맡은 이슈를 처리하려다 논의하게된 내용입니다

문제 상황

1. 현재, 구현하려는 기능을 정하고 시작할 때 와이어프레임도 같이 시작
2. 정의된 사항을 보고 개발하는 것이 아니라 논리적으로 그때그때 구현해야 할 기능들을 구현하다가 와이어프레임이 나오면 그때 비교
3. 프론트, 백엔드 주고받아야하는 데이터가 확실하지 않음 (어제 올리 에러 발생과 같은 케이스 발생) -> 확정된 와이어프레임이 미리 필요하다
4. 상상으로 하기 어렵다. -> 회의 + 문서가 필요하다.
5. 각 기능별 예외 검증 사항 정리된 게 없다.(각 이슈에 산발적으로 분포) 즉, QA 리스트가 없다. -> 역시 문서가 필요하다.

제안 방법

1) 2주 장기 스프린트 시작 회의

여기서 2주 장기 스프린트란 데모데이랑 같이 가는 스프린트를 말한다.

• 이전에 잡았던 스프린트 일정 공유
• 이번 스프린트에 필요한 와이어 프레임 함께 다 짜기
  • 모두의 의견을 하나로 맞추기는 어렵다. 보편적인 와이어프레임을 짜고 레벨 4때 이를 수정/업데이트 하자
• 단기 스프린트 기간별 목표 설정
• 분야별 목표도 기간 배분 (예: 백엔드(CI와 쉘 스크립트 등을 활용한 배포 자동화))
• 와이어 프레임 보면서 화면정의서에 검증 내용 추가하기 → 화면 정의서로 문서화

화면정의서? : 와이어프레임 + 기능명세(검증할 것들)

• 프론트, 백엔드 모두 기능 구현하면서 계속 참고할 수 있는 문서
• 추후 각 단기 스프린트 마지막에 QA에도 활용

• 회의 후, 백엔드는 swagger로 빠르게 api 문서만들어서 프론트에 공유
• 그 후부터는 단기 스프린트 회의 후, 분야별 진행
• 와이어프레임, 단기 스프린트 목표 설정은 스프린트 시작일로부터 2일 내에 확정

2) 1주 단기 스프린트 회의

여기서 의미하는 1주 단기 스프린트란 팀 내의 2주차별 스프린트를 의미한다.

• 단기 스프린트 시작 때 간단히, 단기 스프린트 목표 공유 (위의 스프린트 시작 회의때 정해놨으니까)
• 단기 스프린트 마무리마다 QA 진행

3) 추가 회의 필요 사항

1. 스프린트 시작 회의 이전에 레벨 3에서 구현할 최종 목표 설정
2. 우테코에서 정의한 스프린트 시작 전에 다음 스프린트에서 진행할 목표(화면과 기능)을 설정

장점

• 적응되면 속도가 빨라질듯
• 회의 2주에 한 번 제대로 뽝(좀 걸리더라도)
• 그 이후로부터는 방향 헷갈리지 않고 해야할 구현 뽝
• 단기 스프린트는 그대로 가져가서 프+백 협업이 자주 일어나는 장점도 뽝
• 실제 현업 구현 사이클 경험

FAQ

1. 스프린트 시작 회의 때, 와이어 프레임 다 잡고 가는 거 시간때문에 걱정이다.
   • 레퍼런스보고 너무 오래 고민하지 말고 빠르게 하자.
   • 그리고 다음 스프린트 또는 다음 레벨때 피드백 후 보완

2. 화면정의서를 어떻게 작성할 것인가?

화면정의서 문서

• 테드가 작성한 I&A 화면정의서

화면정의서 예시

3. 7/22-7/26 단기 스프린트 목표 및 화면정의서

단기 스프린트 목표

• 리뷰 작성
• 리뷰 목록
• 리뷰 상세 페이지

화면 정의서

• 구글 폼
• 화면 정의서 피그마

아루 선생님의 CI/CD 강의

• 블로그 링크

다음 장기 스프린트

• 리뷰 그룹 생성
• 깃허브 연동된 로그인