코드잇 부트캠프를 하면서 초급, 중급 프로젝트에서는 주어진 피그마 시안을 보고 프론트엔드끼리 구현하는 훈련을 했다.
이 과정을 통해 프론트엔드 개발자의 메인 업무를 간접체험할 수 있었다. 프로젝트 경험이 전혀 없는 비전공자였던 나는 위 단계를 꼭 거쳐야 했고, 배운 점도 분명 많이 있다.
하지만 아쉬웠던 점은, api 명세서가 이미 만들어져서 추가 기능을 구현하고 싶거나 구현해야 하는 부분도 못하는 불상사가 발생했다. (실제로 delete api가 없어서 삭제기능 없이 프로젝트를 진행했다ㅜ..)
또, 초급&중급 프로젝트 때에도 소통이 있었지만 현업에 나가면 프론트엔드 개발자 뿐 아니라 다양한 직무의 사람들과 소통해야 하기 때문에 미리 경험하고 질 높은 소통을 위한 나만의 노하우를 쌓고 싶었다. 그래서 고급 프로젝트 때에는 디자이너, 백엔드 분들과 함께 기획부터 시작하는 협업을 선택하게 되었다.
개발에 앞서 먼저 정해야 하는 중요한 것이 소통이라고 생각한다. 프론트엔드끼리의 회의 혹은 연락 방식은 프로젝트 시작 전 팀 편성이 되고 충분한 대화를 통해 이미 정해진 상태다. 그렇다면 백+디분들과는?! 빨리 정해야겠다. 정해진 결과는 다음과 같다.
일정 관리 툴인 지라는 사실 한 번도 써본 적이 없다. 프론트 팀원들 모두 모르고 있었고, 백엔드 1분이 최근 현업에서 많이 쓰이는 추세라 해서 모두의 동의 하에 지라를 사용하기로 결정됐다. 지라에 대해 조금 알아보니 깃허브의 프로젝트 task 관리 기능과 상당 부분 비슷하다는 생각을 했다.
커리큘럼 상 실제 프로젝트 시작 날짜는 다음 주 월요일(5/20)이었지만 디자이너분(1명)과 백엔드분(2명)이 합류해서 인사를 나눈 이상 미리 시작해서 나쁠 것 없겠다 해서 바로 기획에 들어갔다. 우리에게 주어진건 '여행'이라는 대주제와 필수 기능 구현 사항들뿐이었다. 기획 시작은 아래와 같은 주제로 걸음마를 뗐다.
문제와 배운 점을 균형 있게 정리하신 회고가 인상적입니다. 저도 비슷한 프로젝트를 많이 하면서, 결국 다음 사이클에 반영될 수 있는 작업 단위로 남기는 게 중요하다고 느꼈습니다. 그래서 Plexo를 만들었고 AI Task Breakdown으로 회고 내용을 바로 실행 가능한 WBS로 변환하는 흐름을 강화했습니다. https://plexo.work/ko 회고 내용을 다음 스프린트 백로그로 옮길 때 어떤 기준을 쓰시는지도 궁금합니다.