이번 프로젝트 전까지는 클론 코딩으로 웹페이지를 만들거나, 학교에서 요구하는 수준의 프로젝트가 전부였다.
제대로 진행하는 첫 프로젝트다 보니 어디서부터 손을 대야 할지도 몰랐고 나를 포함한 팀원 전부가 제대로 된 협업을 해본 적이 없어서 우왕좌왕했었다.
그래서 일단 개발 시작하면 되는 거지~?로 흘러 들어가기 직전 멘토님께서 많은 도움을 주셨는데 그 내용은 다음과 같다.
협업 전략
수없이 많은 커뮤니케이션 방법과 다양한 규칙들이 있다. 그렇다면 무엇을 적용해야 할까? 멘토님께서 항상 팀에 맞는걸 선택해야 한다고 말해주셨다. 구글에서 시행하고 있는 것을 그대로 가져와봤자 지키지 않으면 아무 의미가 없기 때문에 항상 지킬 수 있는 것을 선택하고 유지하자
그라운드 룰
학교 내에서 진행하는 프로젝트다 보니 원래 친했던 친구들과 팀을 이루게 되었다. 이 때문에 더 명백하고 확실하게 규칙을 정할 필요가 있었다.
그라운드 룰이란?
그라운드 룰이란 사전적 의미로는 경기장의 사정에 따라 정식 경기 규정을 적용할 수 없는 경우에 임시로 정하는 경기 규정이다. 조직에서는 리더와 조직 구성원이 함께 지켜야 하는 기본 규칙을 말한다.
다음은 팀에서 정한 그라운드 룰이다.
데일리 스크럼 지각 시 1분당 500원
모든 회의, 미팅은 목적, 목표, 종료 시간을 정한 뒤 시작
의견 차이 발생 시 서비스 설계 원칙에 따라 결정
이슈 발생 시 하루 안에 해결 못하면 다음 데일리 스크럼에 보고
서비스 설계 원칙
팀 프로젝트는 모두의 경험이 다르고 추구하는 배움의 방향이 다르기 떄문에 의견 차이가 필연적이다.
팀 내에서는 백엔드로 go, js 중 어떤 언어를 사용하느냐에 대해 의견 차이가 있었다.
이를 해결하기 위해 우리는 서비스 설계 원칙을 다음과 같이 정의 했다.
서비스 설계 원칙이란?
팀 내 모든 결정의 기준이 되는 원칙
- 어떤 언어를 경험하는 게 중요해!
- 2월 1일까지 결과물을 만들어 내는 게 중요해!
- 프로젝트의 완성도가 중요해!
- 개인의 성장이 중요해!
등등.. 많은 원칙을 세울 수 있지만 우리 팀은 프로젝트의 완성도에 도움이 되는 방향으로 결정의 기준을 정했다.
js, go 둘 다 개인의 성장에 많은 도움이 되지만, js를 선택했을 때 frontend와 backend의 언어를 통일 할 수 있다. 그뿐만 아니라 nodejs에 관련한 레퍼런스가 매우 많고 지원하는 API의 종류도 훨씬 많았다. 때문에 기간 내에 프로젝트의 완성도를 최대한으로 끌어올릴 수 있다고 생각했고 그 결과 nodejs가 선택되었다.
2022/12/28 재작성
꼭 필요한 라이브러리인 aspose가 자바(maven)로만 동작해서 spring사용하는 것으로 재결정 되었다.
애자일(Agile)
지금까지 개인적으로 진행한 프로젝트와는 다르게 이번 프로젝트에는 고객이 존재한다.
2022/12/18 재작성
요구사항 구체화를 위해 기업과 몇차례 미팅을 가졌으나 계속해서 학생들의 판단, 자율에 맡긴다는 결론이 나와서 기능별로 구현 후 기업 담당자의 피드백을 받을 수 밖에 없었다. water fall로 개발하다가 원하는게 아니면 어지러워지는 상황이 발생할 수 있기 때문이다.
redhat은 애자일을 다음과 같이 정의하고 있다.
협업과 워크플로우를 바라보는 하나의 관점이며, 우리가 무엇을 어떻게 만들지에 관한 선택을 안내하는 가치 체계입니다.
구체적으로 말하자면, 애자일 소프트웨어 개발 방법론의 핵심은 작동하는 소프트웨어의 작은 구성 요소를 신속하게 제공하여 고객의 만족도를 개선하는 것입니다.
이는 방법론이 아니라 사상 혹은 철학이며 소프트웨어 개발에 대한 새로운 접근 방식을 제안한다.
애자일 소프트웨어 개발 선언
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다.
이 작업을 통해 우리는 다음을 가치 있게 여긴다.
- Process와 Tool보다 개인과 상호작용을
- 포괄적인 문서보다 작동하는 소프트웨어를
- 계약 협상보다 고객과의 협력을
- 계획을 따르기보다 변화에 대응을
이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.
© 2001, the Agile Manifesto authors
This declaration may be freely copied in any form, but only in its entirety through this notice.
결국 이 개념은 시간에 따라 변하는 고객의 요구 사항에 대응하는 민첩한(agile) 아이디어다. 그러므로 협력과 피드백을 빨리, 자주, 잘 하는것이 중요하다.
우리 팀은 협력과 피드백을 극대화 해 개인의 성장과 프로젝트에 대한 이해를 높이기 위해 몇 가지의 방법론을 채택했다.
- 스프린트 단위의 개발 스코프
- 데일리 스크럼
- 회고
- 코드 리뷰
- 데모 시연
- 기술 세미나
각 기능 별로 1~4주로 스프린트를 계획한다. 스프린트는 주요 마일스톤을 수립한 뒤 트렐로의 칸반 테이블을 통해 관리하고 스프린트가 끝나는 날은 회고 시간을 갖는다.
개인 별로 맡은 기능이 다르기 때문에 프로젝트를 팀원 전체가 온전히 이해하기 위해서 스프린트가 끝나는 날은 데모 시연, 기술 세미나를 진행한다. 이번 프로젝트는 개인의 성장에 많은 초점이 맞추어져 있기 때문에 기술 세미나가 특히 중요하다.
코드 리뷰는 고만고만한 수준인 우리가 해도 어떤것이 잘못 되었고 어떤 것이 옳은 방향인지 알 수 없을 것 같아 현업에 계시는 분께 부탁을 드렸다.
지금까지의 프로젝트에서는 내가 맡은 기능만 제대로 구현하면 끝이었다. 하지만 프로젝트를 팀원 모두가 이해하기 위해서는 각 파트에 대한 이해가 필수다. 때문에 파트별 소스 코드 리뷰와 정리된 기술 문서, 데모를 가지고 세미나를 진행하고 세미나를 마쳤을 떄 해당 파트를 진행하지 않은 누구라도 같은 작업을 할 수 있어야 한다 를 기준으로 정했다.
사실 나를 포함한 팀원 모두가 개발경력이 없고 제대로 진행되는 첫 프로젝트라 모든 활동이 새롭다. 새로운 것을 꾸준히 하는것은 굉장히 어려운 일인데 한번 귀찮아서 생략하게 되면 계속해서 생략하게 되니 서로 도와가며 진행하는 것이 매우 중요할 것 같다.
