[ETON 프로젝트] 회고록 1

2020년 2월 3일 # sprint 1. 프로젝트 기획하기 + 코드작업 1일차

 

1. 업무 분담의 필요성
첫날 SR은 공통 Task (구현하고 싶은 기능을 리스트업하고, 스키마 구조 설계)를 가지고 팀원 모두가 함께 진행했다.
협업툴이라는 공통 주제가 제안되어 아이디어 선정은 빠르게 진행되어 좋았다.
하지만 한정적인 자원 (짧은 기간, 적은 팀원)으로 SR을 마무리 해야했기에 조급한 마음이 들었다. 
그때 우리에게 주어진 시간은 2주 * N명 이므로, 각 팀의 역량에 맞게 작업을 진행하라는 말이 기억났다. 
그래서 둘째날 SR은 Task를 분배(와이어프레임, API 문서, 기능 흐름도)했다. 대신, 실시간으로 질의응답을 진행하였고 그 덕분에 둘째날에 SR의 대부분을 마무리했다.  

2. SR의 중요성
나는 기능 흐름도를 맡았다.
총 4개의 카테고리 (Intro, Main, Board, Card) 로 설계를 하였고, 중간에는 귀찮은데 이것을 꼭 해야할까 라는 의문이 들었다.
그전까지는 2주 프로젝트 중 SR을 왜 최소 2일~3일을 투자하라는지 이해하지 못했기 때문이다. 
하지만, 덕분에 빠트린 기능을 캐치할 수 있었고 event 발생 상황도 파악할 수 있었다. 무엇보다 전체적인 큰 그림을 확인할 수 있었다.
코딩테스트 준비를 할때 의사코드 (생각/로직의 흐름) 를 강조하는데 기능흐름도는 프로젝트 의사코드 같은 느낌이었다.
즉, SR은 필수라는 것이다. 세세하게 기획하지 않는다면 코드를 작성할 수 없을 것이다.

3. Task 카드 쪼개기 및 작은 단위 성취감2월 3일 sprint1. SR 회고록
처음 Task 카드를 만들었을 때는 큰 기능 단위로 작성하였다. SignIn / SignUp / SignOut 이런식으로 말이다.
하지만, 팀원분께서 작은 단위로 하나씩 해나가는 것이 중요하다고 코멘트를 주셨다.
거기서 착안해서 각 기능을 세세하게 업무를 쪼개보았다. 
[프론트] 기능1 : 와이어프레임 문서 점검 / 파일 생성 / grid, flex 위치 잡기 / CSS 꾸미기 / state 정의 및 handler 연결
[백엔드] 기능1 : 서버 생성 / MVC 패턴 파일 디렉토리 생성 / API 문서 점검 / end point 한개씩 코드 작성

매일 아침 Stand Up 미팅에 업무 리스트를 분배하고 오후 3시, 오후 9시 중간점검을 진행하는데
세세하게 Task 를 쪼갠 덕분에 팀원간의 진행도를 파악하기가 쉬웠다. 그리고, 막힌 부분을 바로 체크하고 백업할 수 있어서 좋았다.
또한 이슈 카드 단위로 commit 및 P/R 을 진행하고 close 하기가 용이했다.

4. 우리의 역량을 과대평가한건 아닌지, 일정/체력 관리의 중요성
나는 팀원들을 신뢰하고 그들에게 해낼 수 있다는 자신감을 붇돋았다. 나는 팀장으로서 흔들리지 않는  확신을 보였다. 

하지만 오늘 목표였던 Task를 다 진행하지 못하였다. 코드 작업 상 예상치 못한 상황을 맞딱들일 수 있다는 것(오늘만해도 AdBlock이 react map render 방해를 하다니) 을 생각하지 못한채 스케줄을 잡았기 때문이다. 여유로운 스케줄이 필요함을 캐치하고 마지막 Task를 임시로 포기했다. 뿐만 아니라 3일 연속으로 12시간 이상 회의 및 코드 작업을 진행하다보니 체력적 한계를 느끼게 되었다.
필자의 경우 한번 꽂히면 끝까지 매진하는 스타일이다. 하지만, 이건 당일치기 과제가 아니었다. 그래서 이번 주말에는 쉬는날을 정하였다. 그날을 바라보면서 롱런하자.

5. git workflow

배운 것은 아래와 같다

- github Projects, Issue, Milestones, Wiki 작성 방법

- github P/R & link Issue card to close

- dev branch 에서 feature branch 따는 이유 : dev는 최신 버전, feature는 local 작업을 위해서

- Projects Kanban Board 사용법

- P/R은 최소 기능 단위로 하는 것이 upstream repo에서 Merge 시 좋을 것 같다. 고로, issue card는 최소 단위로 쪼개자.

- Merge 시 파일간의 충돌을 줄이기 위해 기능 단위로 작업 파일을 분리하는 방법도 좋을 것 같다.

front의 경우에는 page 및 component 단위로 파일을 분리하고 작업해서 Merge 시 충돌이 적었다.

- stash 유용함 : 코드 작업 시 pull 및 branch 를 분리할 때 용이하다.

 

위의 내용을 배우고 실제 협업을 하면서 서로의 코드를 병합하거나, issue Task를 연결하고 하는 모든 작업이 너무 재밌게 느껴진다. git의 다양한 기능을 이제라도 알게되어 좋다.

 

그리고, 이제 남은 시간은 AWS 배포 작업을 공부할 것이다.