조규현 멘토님과의 커피챗을 통해서, 15조의 현재 프로젝트 진척 상황에 대한 전반적인 코멘트를 받았으며, 협업과 관련한 조언을 받았다. 멘토께서 코멘트 해주신 내용을 간단히 정리하자면 아래와 같다.
프론트와 백엔드가 배포를 빨리 진행해서, 배포 환경에서 개발을 진행하는 것이 좋을 듯 하다.
→ 이에, 프론트는 12월 13일 (월) 중으로 Vercel을 통해 배포를 먼저 진행하려 한다.
지라를 잘 활용을 못하고 있어서, 서로가 어떤 작업을 하고 있는지 모르는 상태이다.
최대한 티켓의 코멘트 기능을 많이 이용하면 좋다.
개인이 진행중인 이슈가 2개, 혹은 그 이상인 인원들이 있다. 일반적인 경우에 인원 당 '진행 중' 이슈는 하나가 있어야 할 것 같다. 사람은 한 가지 일밖에 못 하기 때문에.
이슈를 생성하면, 슬랙에도 알림이 가도록 Integeration 기능을 사용하는 것이 좋다.
→현재 메일과 연동을 해 놓은 상태이다. 이슈가 생성되면 메일이 온다.
Epic 기능을 사용해서 어떤 기능을 집중적으로 구현을 해야 할 지에 대해서 모르는 것 같다. Epic 단위를 지정해보자.
→ 이제껏 우리는 Epic을 '프론트', '백엔드'로 뭉뚱그려서 설정했었다. 멘토님의 코멘트를 듣고 나서는 앞으로 우리 팀이 3주차에 진행하게 될 API 연동에 초점을 두어, API Epic을 생성해 두고 해당 에픽에 필요한 백로그를 생성해 둔 상태이다.
→ 기존에는 API 관련 논의가 있을 때, 7명 전원이 모여서 살펴봤으나, 이제는 도메인을 분류하여 각자 담당자를 두고, 프론트 담당자와 백엔드 담당자가 1:1로 소통하며 업무를 진행하는 것으로 합의했다.
규현&지은님의 협업 가이드 를 보면서 감을 잡아 보자.
지라의 Workflow 를 세부적으로 나누자
→ 팀 회의 결과, 현재 워크 플로우를 변경하는 것은 시기 적절하지 않다고 판단, 현재 워크 플로우는 동결하기로 하였다.
Story Point 를 작성해서 작업의 대략 완료 시간대를 결정할 수 있다. 포인트에 대응되는 시간 단위를 커스텀으로 설정해 놓을 수 있다. 이것 없이 계획을 짜면, 기능의 대략적인 예상 개발 기간을 산정할 수도 있다.
스토리 포인트를 기반으로 스크럼을 진행할 수 있다. 가령, 오늘은 A 작업을 할 것입니다. 왜냐하면 A 작업의 story point 는 5포인트(5시간) 인데, 오늘 주어진 시간이 5시간 밖에 없기 때문입니다.
→ 이에 우리 팀은 스토리 포인트 1점을 2시간으로 설정하여 각각 도맡은 이슈들에 대한 스토리 포인트를 명시하기로 했다.
에픽 기능은 프론트, 백엔드와 같이 큰 업무 분담을 하는 곳이 아니다.