FIRE는 이렇게 협업했다

FIRE는 이렇게 협업했다

FIRE팀이 모도코를 개발한지 어느새 7개월이 넘었다. 소프트웨어 마에스트로과정도 이제 끝이 보이고 (글쓴 기준 25일정도 남았다) 우리가 어떻게 작업했었는지 정리할겸 작성해보았다.

팀 구성

팀 구성은 나(팀장이자 FE) 외 두명(FE, BE)로 이루어졌다. 팀은 모으는것도 정말 쉽지 않은 길이였다. 소프트웨어 마에스트로 과정이 아무래도 고등학생부터 대학교 졸업자까지 아우르는 활동이기에 나에게 딱 맞는 사람을 모으고 싶었다. 우선 소프트웨어 마에스트로에 100% 진심을 다해서 진행할 사람. 물론, 창업을 염두에 두고 한 말은 아니였고, 그냥 11월까지 정말 알차게 공부 및 개발 할 사람을 뽑고 싶었다.

그래서 나의 제외대상은 고등학생과 졸업자였다. 고등학생은 아무래도 학교를 가야되니 함께 활동을 하기 힘들것 같았고, 졸업자는 아무래도 취준을 하고 취업하면 병행을 못하기에 팀에서 두명만 남는 상황을 피하고 싶었다. 그리고 웹서비스를 해보고싶은 사람. 물론, 앱개발, IoT, Game 모두 훌륭하지만, 이번에 웹 프로젝트를 하며 커리어를 쌓고 싶었다. 그래서 처음 모집당시에는 실시간 통신을 하는 웹 플랫폼을 만들고자 했고, 나와 같이 해보고 싶은 사람들을 모집하게 되었다.

그리고 운이 좋게 너무나도 좋은 사람들과 오랜기간 협업을 하게 되었다 ㅎㅎ

프로젝트는 결국 처음 생각했던것과 유사하게 흘러가긴 했지만, 처음에는 기획 때문에 스트레스를 정말 많이 받았다. 세명이서 열심히 아이디어를 만들어서, 기획을 다듬고 멘토님꼐 가면 Business Model이 부족하다던가, 시장에서 먹힐것 같지 않다거나 부정적인 이야기들을 정말 많이 들었다. 결국 Business Model 그런거 잘 모르겠고, 우리가 하고싶은것, 재미있는것, 사용자들이 많이 사용할만한것만 보고 현재의 모도코가 만들어졌다.

Ground Rule

우리팀은 결성당시(4월)에 3명다 프로젝트에 100% 시간을 쏟기 위해 휴학을 하자고 결심했다. 그럼 가장 중요한게 그라운드 룰 이라고 생각했다. 우리의 주요 그라운드룰은 다음과 같다.

Project

• 코어 타임, 평일(공휴일 제외) 13:00 ~ 17:00

  • 주 50시간, 주말 포함 (센터에 상주)
  • 오프라인 단체 활동(세미나) 하루 10시간 취급

• 스크럼 회의 13:00 시작

  • 스크럼 때 할 일은 Jira의 Issue기반으로 얘기할 것

• 스프린트 단위

  • 2주
  • 스크럼 마스터도 2주 단위로 바꾸기

Work Life Balance

• 소원권 (팀 빌딩 관련 이어야 됨, 여행 가능)

  • 한 달 하나
  • 누적 X (말에 무조건 써야됨)

• 개인 휴가권

  • 누적 가능에 한달에 2번
  • 최소 일주일 전에 캘린더에 말해주기

• 아프면 쉬기

  • 건강이 우선이다!

• 회의 안 되는 날은 최소한 1주일 전에 아래 캘린더 일정에 기록해두기!

• 회고는 특별한 곳에서

  • 고양이 카페, 한강 코딩, MT 등

Life and Culture

• 개인 운동 인증
  • 카톡방 인증
  • 개인 목표
  • 일주일 3번

Penalty

• 운동 안 지키면

  • 커피

• 코어 타임에 늦으면

  • 커피

• 주 50시간 못 채우면

  • 커피
  • Expert님 회사 가서 시간 채우기

처음에는 되게 거창하게 이것저것, 재미있을 것 같은것(소원권 ㅋㅋ)도 있었지만, 개발을 하다보니 시간에 쫓기고 게을러져서 그라운드룰에 대한 의미가 퇴색됐던 것 같다. 그래도 코어타임, 스프린트, 회고 등 프로젝트에 관한 그라운드룰은 꽤나 잘 지켜졌던 것 같다.
그래도 팀원들이 해이해진건 아니고, 다들 밤을 새면서 개발하고 멘토링 일정이 꼬이고 하는 바람에 잘 안지켜졌던 것 같다.

Google Calendar

우리팀은 13시부터 22시까지 센터에서 오프라인으로 프로젝트를 하는것이 기본이였으므로, 일정관리를 되게 열심히 정리했다고 생각한다. 구글로 일정을 알려주는 공유 캘린더를 하나 만들어, 개인일정 및 팀 일정을 관리했다.

적당히 널널했던 6월의 일정

점점 바빠지는 11월의 일정..

아마 사용했던 협업툴 중에 가장 활용도가 높았던 것 같다.

Sprint

애자일 방법론을 택하고 사용한 스프린트. 처음에는 정말 힘들었다.

처음에는 2주로 했다가 잘 활용 하는것 같지도 않고, 너무 어려워서 1주로 바꿨다 추후에 스프린트에 익숙해지면서 다시 2주로 늘어났다. 팀마다 다르겠지만, 익숙하지 않을수록 짧게 가져가고 빠른 회고를 하는것이 적응하기 편할 것 같다.

우리는 스프린트를 시작하기 전 해야 할 스토리들을 엄청나게 만들어 두었다. 그리고 충분한 스토리를 생성한 후, 이번주에 어떤 스토리들을 해결해 나갈지 결정하고 백로그에 넣어둔 뒤 스프린트를 시작했다. 그리고 1주 혹은 2주 후 스프린트를 마무리 지으며 회고를 하는 방향으로 했다.

회고는 처음에는 AAR(After Action Review) 라는 회고 방식을 사용했었다.

1. 의도한 결과
2. 일어난 일
3. 계획과 실제의 차이
4. 배운것

이렇게 회고를 하였고, 옛날 KATUSA 시절에 미군부대에서 사용했던 회고 방식이여서 추억이였다 ㅋㅋ

그러고 여러 회고들을 해보다 결국 KPT(Keep Problem Try)회고로 정착했다.

회고는 우선 이번 스프린트가 어땠는지에 대한 간단한 평을 진행하고 해당 스프린트에 대한 Keep Problem Try순으로 정리했다.

그리고 회고록이 쌓여 가는걸 보면 기분이 매우 좋다!!

Jira

Jira도 처음사용해본 것 치고 정말 활용을 잘했다고 생각했다

우리는 Jira를 크게 3단계로 나눠서 관리했다.

1. 에픽
2. 스토리
3. 하위이슈

에픽

우선 에픽은 우리가 두개 혹은 세개의 스프린트중 완성할 수 있는 단위로, 기능의 구현의 단위로 끊었다.
예를 들어, [DM 개발] 이나 [프로필 화면] 처럼 큰 단위로 묶어서 관리했다.

화려한 우리의 로드맵과 에픽들..

스토리

다음은 그 에픽에서 구현하게될 스토리로 쪼갰다. 스토리는 주로 스프린트가 끝났을 때 데모 가능한 단위로 설정했다. 예를들어 [프로필 화면] 이라는 에픽이였다면, 스토리로는 [프로필 화면에서 통계를 확인할 수 있다], [프로필 버튼을 통하여 친구의 프로필 페이지로 넘어갈 수 있다], [내 프로필의 정보를 수정할 수 있다] 등 데모 가능하게 정했다. 그리고 추가로 스토리포인트라는 해당 스토리가 얼마나 걸릴지에 대한 시간 예측도 해보았는데, 생각보다 잘 맞지는 않았다 ㅠㅠ

몇개는 아직도 해야 할 일로 등록되어있다 ㅠㅠ

하위이슈

마지막으로 하위이슈는 해당 스토리를 구현하기 위한 하위 작업들이였다. 하위이슈에서는 내가 어떤 작업을 할건지, 결과물은 어떤 형식이고, 참고할 페이지는 어떤것이 있는지 적어서 올려뒀다. 그리고 스토리와 마찬가지로 해당 이슈가 얼마나 걸릴지에 대한 스토리포인트를 지정해두었는데, 주로 3-4시간어치 이슈였고, 스토리보다는 더 정확도가 높았던 것 같다.

개발 할 때는 미리 연동해둔 Github를 활용하여, Branch를 만들고 커밋 혹은 빌드를 하면 다음과 같이 자동으로 연동이 된다!

그래서 티켓 번호만 알고 있다면, Github가 아닌 Jira에서 빠른 확인이 가능하다.

그리고 마지막으로 누적 플로우 다이어그램을 보면 얼마나 열심히 그리고 꾸준히 살았는지 한눈에 확인 할 수 있다.

처음 계단형식에서 일자형식으로 발전한 우리의 누적 플로우 다이어그램

Confluence

컨플루언스는 우리의 Wiki 저장소로 활용되었다. 앞서 보였던 회고록 부터 시작해서 데일리 회의록이나, 개발관련 API문서, 관련 자료 등등 모두 기록을 했었다.

우리가 정말 팀 중에 가장 문서를 잘 정리한 팀 중 하나라고 해도 될 만큼 문서 정리에 진심이였다. (사실 나보다 문서에 미친 팀원분이 정말 정리를 열심히 해주셨다) 한창 기획을 하느라 바빴던 5월은 회의록만 18개가 나왔을 정도였고 희의록 하나하나의 양도 정말... 말도 안나올 정도로 많았다.

한창 기획을 하던 5월의 어느날의 회의록..

회의록 말고도, 개발에 관한 컨벤션이나 API 문서화도 최대한 깔끔하게 정리를 했었다.

프론트엔드 컨벤션 문서중...

Github

그리고 마지막으로 실제로 개발을 진행한 Github

처음에는 Jira, Confluence, Bitbucket이 세트로 움직이면 정말 편하다는 말을 많이 들어 혹했지만, 그래도 아직까지는 한국에서 Github를 많이 활용하고, 포트폴리오로도 사용하기 간편할것 같아 Github를 활용하였다.

README

>> 우리의 깃허브 <<

최대한 README도 이쁘게 하고 바로 우리의 프로젝트를 확인할 수 있게 만들었고, 순서는 다음과 같다.

1. 프로젝트 소개
2. 실행방법
3. Stack
4. 동작화면
5. 기능
6. 아키텍처
7. 그 외

내가 열심히 꾸몄던 FE README

Development

커밋로그 같은 경우에는 Jira ticket만 잘 명시해두면, Jira에서 확인이 가능하여 크게 신경쓰지는 않았다.

근데 이것도 컨벤션을 만들어서 적용해 두었으면 더 좋았을 것 같아 후회도 된다

그리고 브랜치 전략은 간단한 트렁크 기반의 전략을 사용했다. dev를 현재 개발하고 있는 브랜치로 활용하고, main을 본 프로젝트의 배포된 형태로 사용하였다. 그러다 Jira Issue가 생기면, 브랜치를 하나 만들어 개발 후 PR을 날리고 동료가 Approve후 Merge 할 수 있는 시스템을 사용했다. 그리고 main은 어느정도 기능이 완성되고 안전하다고 판단 되었을 때 code review 및 검증 단계를 거친 후 배포되었다.

분명히 이론은 완벽한데 이상하게 생긴 브랜치...

후기

정말 간단하게 우리의 프로젝트 과정을 설명해봤는데, 생각보다 양이 많았다. 휴학을 하고 진행을 한 프로젝트라 시간이 아깝지 않게 열심히 노력한 프로젝트였는데, 정리를 해 보니 꽤나 열심히 살았던 것 같아 뿌듯해진다. 이렇게 프로젝트를 기획부터 배포 그리고 유지보수까지 해볼 경험이 많지 않은데, 정말 값진 경험을 했던 것 같고 너무나도 좋은 팀원과 멘토님들을 만날 수 있어서 영광이였다.

하지만 모도코는 아직 끝나지 않았다... 소프트웨어 마에스트로가 끝이나도 서비스는 운영됩니다..