컨벤션, 회의록이 문서화돼서 까먹었을 때 확인하기 좋았고, 멘토님께 질문을 할 때도 도움이 됐다.
Problem
1:1 PR approve
1:1로 책임감이 생기고 확실하게 리뷰가 생기는 것은 맞지만, 1명에 국한되고 나머지 2명이 코드의 내용을 모르는 일이 생김
코드 컨벤션 어김 + 코드 숙지 미흡 ⇒ 코드 컨벤션 리팩토링 + 스크럼 (공유)
💡
4명의 프론트엔드 주니어 개발자가 협업해서 하나의 프로젝트를 만들어 나간다는 것은 힘겨운 일입니다.
그렇기 때문에, 확실한 역할배분이 중요합니다.
Github Discussion 미숙
Discussion 탭을 사용하고자 했지만 소통의 대부분이 슬랙을 통해 일어남
💡
너무 많은 툴을 사용하려고 하다보면 오히려 배가 산으로 갈 수도 있습니다.
’현재 우리에게 정말 필요한 부분이 무엇인가?’ 에 따라서
선택과 집중을 할 수 있어야 한다고 생각합니다.
문서 파편화
문서가 여기 저기 흩어져 있어서 찾기 어려움
예 ) BE와 소통한 내용 → 정리가 필요 : 슬랙 전체 채널로 해소
💡
api문서말고도 여러가지 회의 문서들을 말씀하시는건가요?
노션등으로 잘 정리된 문서는 프로젝트가 올바르게 나아가기 위해 필요한 첫 번째 필수요소라고 생각합니다.
그래야 한번의 소통으로 두번 세번의 일을 하지 않을 수 있기 때문이죠.
백엔드 팀과 api 별로 구체적인 담당을 기록해놓지 않음
메뉴 post / get , 프렌차이즈 담당이 다른데 세부적인 담당을 알지 못해서 2번 물어보는 일이 생김.
전체 슬랙 채널 제이든 ,루카 - 둘다 호출
💡
wbs 일정관리라는것이 여기서부터 등장합니다.
각각의 api의 담당과 언제까지 개발이 가능한지 등에 따른 관리 체계를 잘 갖추어야 현업에서도
이러한 문제가 발생되지 않겠죠?
그러한 부분을 개발자들끼리만 하기에는 너무 어려운 업무일 수 있습니다.
그래서 프로덕트팀이나 다른 여러 팀들과 협업을 통해 프로젝트는 수행되게 됩니다.
하지만 현재 여러분의 경우 사이드프로젝트형태이며, 서로가 서로간의 업무에 대해 책임지고
나아가는 태도또한 이 프로젝트의 성공에 정말 중요한 요소가 됩니다.
백엔드와 소통이 너무 적음
정해진 기한 이상으로 일이 넘어갈 수는 있지만 해당 문제가 얼마나 뒤에 해결될지 알 수 가 없음 ⇒ 일요일까지 api 됩니다! ⇒ 토요일에는 안될걸 알 수 있다 ⇒ 월요일 몇시 까지 잡겠다 ⇒ 현실적 대안 (메뉴 전체조회는 쉽다)
정확한 시간을 말해줘야 ⇒ 모든 소통에서 정확한 시간 ⇒ Must를 잘못줌
💡
위의 내용과 이어지는 내용 같습니다.
정해진 기한을 넘어선다는 것은 정말 크리티컬한 문제일 수 있습니다.
왜, 기한을 넘어설 수 밖에 없었는지, 그리고 그에 따른 나머지 일정들에 대한 조율들이 필요합니다.
그렇게 여러 정해진 기한들이 넘어서게 된다면, 처음에 기획한 의도대로 절대로 진행될 수 없기 때문에,
이 프로젝트에서 무엇을 버려야하는지를 필수적으로 정해야 하는 경우가 발생할 수 있습니다.
또한 비동기적인 소통을 잘 진행하는것이 중요합니다.
API가 없이 할 수 있었던 일이 없음
Prototype 기준으로 API없이 할 수 있는 모든 기능들이 빠르게 구현됐기 때문에 API 생성이 지연되었을 때 할일이 없음
💡
api가 없으면 프론트가 할 수 있는건 디자인적인 요소와 각 페이지별 UI 만들어주는 일이 거의 대부분이라…
api가 나온 이후부터 본격적인 진행이 될 수 밖에 없긴 합니다 ;ㅅ;
작업 상황의 공유가 적음
문제가 발생했을 때 or 공통적인 부분이 있는 경우를 제외하고 서로의 작업 상황에 대해 공유가 적음 ( 공유할만한 모든 내용 : 트러블, PR )
⇒ 2시에 10분 간단 스크럼( TODO 공유 )
⇒ 6시에 시작 ( 작업상황 공유 )
전반적인 작업 흐름을 파악하기 어려웠음
💡
전반적인 흐름을 한눈에 파악할 수 있는 로드맵이 필요할 수 있습니다.
세세한 내용을 모두 공유하기에는 시간의 소비가 너무 큽니다.
이러한 부분은 체계적인 문서와 프로젝트 관리를 통해서 비동기적인 커뮤니케이션이 정말 중요한 포인트라고 생각합니다.
첫 기획에서 어떠한 큰 방향에 맞추어서 개발할지를 로드맵으로 그리고 거기에 맞춰서 이슈가 발생되고 개발이 진행되었다면, 누가 어디를 하고 있는지, 그부분을 해결하면 무엇이 가능한지 등에 대해서 좀 더 편하고 직관적으로 알 수 있었을 거라고 생각합니다.
Try
프1 백1 매일 스크럼
각 팀에서 스크럼을 진행하고 종합한 후 프1 백1이 정해진 시간에 스크럼을 진행
정확한 시간으로 작업 상황의 공유 (일정을 확실하게) → 문서화 ( 노션으로 써서 일정에 넣어주기)
BE 디코 - 내일 슬랙에 물어서 전체 회의 잡기
추가 기능 기획
API 지연 문제는 계속 지속될 것이기 때문에 추가적으로 작업해야 할 추가 기능이 기획되어야 함
⇒ BE: 합의 끝나고 나서도 할거다! 1명이라도 있어야 could까지 개발
API 체크리스트가 필요함
API 문제의 경우 담당자와 소통을 하되 한 곳에서 해당 문제들을 모아 볼 수 있어야 함
체크리스트를 공유해서 어떤 문제가 있고, 문제가 해결됐는지 체크해서 파악할 필요가 있음
API 별 담당자를 명시적으로 문서화
업무 체크리스트가 필요함
2차 스프린트 기간엔 전반적인 업무 파악을 위해 체크리스트가 필요하다.
이슈, 칸반 보드로 업무양이나 상황 파악은 좋으나 회의를 하면서 해당 내용이 반영 됐는지 확인할 땐 불편하다.
