[국비교육 자바JAVA 팀프로젝트]4. 첫 기능통합과 아쉬웠던 점, 팀장의 결단

첫 기능통합과 그 후

첫 스프린트와 두번째 스프린트가 끝났다.
사실 이걸 스프린트라고 부르는 줄은 몰랐고 개인적으로 다년간의 팀프로젝트를 경험한 결과 마감기한이 없으면 늘어지기 마련이라서 함께 마감기한을 정하자고 회의안건을 올렸고 팀원들과 동의하에 스프린트마감일을 정했다. 용어가 있나싶어 검색해봤더니 이러한 방식을 스프린트 방법론이라고 한다고 한다.
하나 배웠다!

첫 기능 통합을 했다. 통합은 팀장인 내가 전적으로 맡아서 진행했다.
아래와 같이 두가지 방식을 사용하여 기능통합을 했다.

• 통합순서
  1. 각 브랜치들을 메인브랜치로 머지.
  2. 충돌방지를 위해 공통설정파일과 공용파일들은 따로 소스코드를 받아서 직접 푸시.

첫 기능통합 후 다음 계획은 팀원별 다음 기능개발이었다.
하.지.만. 소스코드 통합 후 기능 테스트부분에서 많은 아쉬움이 있었다. 통일되지 못한 CSS, 자잘한 오류들을 테스트할때마다 새롭게 발견했다.
혼자 통합 후 테스트를 하는데 시간이 꽤나 걸리는 일이었다.
이래서 기업들이 테스터 담당자를 뽑는 구나….

처음엔 혼자서 자잘한 오류를 해결해나갔다. 하지만 오류코드의 양이 많아지고 어떤 부분에서 어떠한 오류가 있는지 그리고 개선안까지 적다보니 혼자서 지쳐갔다.
특히 가독성이 좋지않은 소스코드들(심지어 주석하나도 없음…이건 팀플인데…왜 주석이 없죠?)도 있어서 정말 난감했다.

이때 첫번째로 든 해결책은 테스터 담당 팀원 배정이었다.
하지만 다시 한번 곰곰히 생각해보니 팀원 다같이 테스트하는 것이 낫다는 판단이 들었다.
이는 크게 2가지 이유때문이었다.

• 팀원 모두 테스터하면 좋은 점
  1. 테스터가 발견 못한 오류나 에러 발견 가능성 높음
  2. 다른 팀원이 어떤 기능을 어떻게 구현했는지 확인하여 프로젝트의 이해도 제고

팀원 모두가 테스터, 그 결과는?

먼저 첫 기능 통합한 main브랜치를 모든 팀원이 pull해서 기능테스트를 해달라고 요청했다.
그냥 하라고만 하면 다들 잘 안하니까 (후후 난 다 RGRG) 각자 아쉬운 점 2가지씩 생각해서 댓글을 달아달라고 덧붙였다.
그리고 예시로서 내가 통합시 생각해두었던 아쉬웠던 점 2가지와 개선방향을 먼저 작성했다.

그 결과!! 괜히 고민했다 싶을 정도로 다양한 아쉬운 점들이 나왔다. 다들 꼼꼼하게 테스트해주었고 개선점까지 적어주었다. 너무나 만족스러운 결과였다. 다양한 개선안을 보고 각 기능 담당자가 고도화를 하기로했다. 따로 정리하지않아도 자신이 담당한 부분만 찾아서 읽으면 되기때문에 정리 할 시간이 필요없었다.
각 기능별 개선점을 따로 정리 할 시간이 필요없는 점도 정말 만족했다!

• 좋았던 점
  1. 8명의 의견이 모이니 나혼자서 찾지못했던 아쉬운 점을 발견하여 프로젝트 완성도를 높일 수 있었다.
  2. 테스터 혼자했다면 한두시간은 걸릴 일이였을텐데 팀원 다같이 해서 1시간안에 다양한 개선점이 나왔다.
  3. 게시글의 댓글형식으로 달다보니 따로 개선방향을 정리 할 필요없이 담당자가 자기가 해당하는 부분만 직접 찾아보면 된다.
• 배운 점
  • 괜히 혼자 고민했다. 팀원들과 고민하면 이렇게 쉽게 해결될 것을! 함께하니 시간도 절약되었다. 또 하나 배웠다! 고민을 함께 나누면 해결점을 빨리 찾을 수 있다!
  • 역시 예시가 중요하다. 개선방향까지 답을 끌어내고 싶어서 예시를 작성할때 개선방향까지 적은 점이 효과가 좋았다.

스프린트 계획

순차	기간	목표
첫번째 스프린트	10월 21일부터 11월 1일까지 (11일)	페어별 도메인단위 기능구현
두번째 스프린트	11월 2일부터 11월 4일까지 (2일)	기능 테스트 후 기능고도화
세번째 스프린트	11월 4일부터 11월 11일까지 (7일)	담당자별 도메인단위 기능구현
네번째 스프린트	11월 12일부터 11월 15일까지 (3일)	기능 테스트 후 프로젝트고도화

첫 스프린트와 두 번째 스프린트가 나에게 남긴 것

• 선택과 집중을 배우기
• 모두가 나같지 않다. 마음비우자!
• CSS 그만 건드리고 로직을 중점적으로 보자.
• 팀플에 에너지 몰빵말고 내 공부를 위한 에너지를 적절히 분배하자

윈윈게임을 좋아하는 팀장의 결단

내가 원하는 팀플은 모두가 원하는 것을 한가지씩 가져가는 팀플이다.
팀원분들 중 한 분이 자신은 앱개발쪽으로 생각하고 있다고 지나가는 말을 해주셨다.
지나가는 말이었지만 계속 머리속에 맴돌았다.

남은 짧은 기간동안 어떻게 해야 윈윈 할 수 있을까?
팀플젝을 안드로이드로 구현할 수 있는 방법은 없을까?

먼저 웹을 기준으로 DB에서 데이터를 끌어와서 앱에 뿌릴 수 있는지 검색해보았다.
현재 팀플젝은 Mysql DB를 사용하고 있는데 안드로이드는 내장 sqlplus를 주로 사용하고 mysql연결이 꽤나 복잡하다는 글이 많았다.
어떻게 해야하나… 모두가 하나씩 원하는 것을 가져갔으면 좋겠는데…
발을 동동 구르며 다양한 방법들을 찾아보면서도 한편으로는 프로젝트 발표일이 2주밖에 안남았는데 한 명이 빠지면 프로젝트완성도가 떨어지지 않을까하는 걱정도 들었다.

난 참 사람에 관심이 많아서 탈이야… 괜한 오지랖일지도 몰라

학원에서 배운 안드로이드수업은 아주 기초적인 것이여서 우리가 어느 정도의 앱을 구현할 수 있는지가 감이 오지않았다. 고민하다가 담임강사님께 물어봐야지하며 잠들었다.
그리고 다음날 아침에 그 팀원을 강의실에서 만났다. 그래서 내가 가장 궁금했던 mysql DB를 안드로이드에 연동해서 화면에 출력할 수 있는지를 물어봤다. 그 팀원분은 가능하다고 했다.

그러자 내 마음에 확신이 들었다.
‘좋았어. 내가 2인분한다.’

그리고 어제내내 고민했던 내용을 그 팀원분에게 털어놓았다.
내가 생각하는 팀플과 지금 개발하시는 기능들은 제가 담당할테니 앱개발하시면 어떻겠냐고 물었다. 웹기능 전체 구현은 남은 시점에서 힘드니까 간단한 기능을 앱으로 구현해주시면 좋을 것 같다는 말과 함께.
팀원분은 그럼 참 좋겠다고 답해주셨다.
그 답변을 듣자마자 내 입밖으로는 “그럼 그렇게 합시다!”가 튀어나왔다.
그리곤 마음속으로 이렇게 되뇌였다.

그래! 내가 1인 2인분을 해내면 돼! 난 할 수 있어! 할 수 있을…거야! 할 수 있다!

이제 팀 전체의 동의를 구해야했다. 정기회의날에 회의안건으로 올리고 솔직하게 이야기를 했다. 내가 책임지고(?) 2인분을 하겠다는 말과 함께.
신뢰가 나름 두터운 터라 팀원분들이 흔쾌히 동의해주었다.
괜한 오지랖이 되지 않도록 더 열심히 2인분 아니 3인분의 코딩해야겠다.
힘내자! 할 수 있다!