파이널 프로젝트 준비

지난 세미 프로젝트때는 협업을 처음 경험해보았기 때문에 중간중간 아쉬운 점들이 있었다. 이번에도 조장 역할을 맡았기 때문에 전보다 체계적인 협업 프로젝트를 진행해보고 싶다.

세미 프로젝트에서 아쉬웠던 점

1. 사람마다 코드 스타일이 다르기 때문에 다른 사람이 작성한 코드를 이해하는 데에 시간이 걸린다.

2. 프로젝트에 대한 정보가 가장 적은 시점인 초반부에 역할 분담이 이루어지기 때문에 비효율적인 역할 분담이 이루어진다.

   • 나는 분담한 작업을 완수한 후에 팀원들이 마칠 때까지 기다렸다. 하지만 계획보다 지연되어 뒤늦게 팀원들을 도왔지만, 결국 프로젝트가 미완성으로 마무리 되었다.

3. 이슈와 풀 리퀘스트가 초기 의도와 달리 형식적으로 사용되었고, 작성 방식이 통일되지 않았다.

   • 초기 의도 : 효과적인 프로젝트 관리 및 코드 리뷰

4. 풀리퀘스트를 너무 큰 단위로 하였기 때문에 코드 충돌이 잦았고, 해결하는 데에 시간이 꽤 소모되었다.

5. Merge pull request 방식을 사용하였기 때문에 커밋 가독성이 떨어졌다.

   • 중간에 Squash and merge 방식으로 전환

6. 디자인 만으로는 페이지를 구성하는 각 요소들이 무슨 역할을 하는지 알기 어렵다.

프로젝트 고민

1. 개발 방법론

소프트웨어 개발 방법론에는 크게 애자일과 워터풀이 있다. 둘의 차이점을 간단하게 말하면, 워터풀이 한 번의 개발 사이클을 도는 동안 애자일은 여러번의 개발 사이클을 돈다는 것이다.

이번 협업 프로젝트는 개발 기간이 4주 정도로 짧기 때문에 어떤 방식을 사용하든 두 방식의 성격을 자연스럽게 띈다. 현 시점에서는 둘 간의 구분을 명확하게 하는 것보다는 효율적인 개발 방법을 추구하는 것이 맞다고 생각한다.

칸반 방식을 도입하면 개발 효율성이 높아질 것 같다. 작업 흐름을 시각화 할 수 있고, 역할 정의를 하지 않아 효과적인 작업 처리가 가능하기 때문이다. 또한, 깃허브 자체에서 칸반 보드를 지원한다.

참고자료

• 애자일과 워터풀
• 칸반과 스크럼
• 칸반
• 칸반과 백로그

2. 개발 단계

• 대략적으로 아래와 같이 나누고, 각 단계를 마일스톤으로 규정하면 될 것 같다.
• 각 마일스톤 별 구체적인 내용은 칸반 보드의 백로그에 정리할 생각이다.

1. 주제 선정
2. 계획 : 프로젝트 일정, 범위, 마감일, 결과물에 대한 정보 등을 수립
3. 설계 : 이슈/풀리퀘스트 컨벤션, 커밋 컨벤션, 코드 컨벤션, 깃 브랜치 전략, api, 테이블, IA 문서 작성 등
4. 디자인
5. 프론트 개발 : html, css, js 개발
6. 백엔드 개발 : repository, service, controller, view 개발
7. 테스트
8. 배포
9. 유지보수