[팀 프로젝트][KPT 회고] 5. 타워 디펜스 온라인 웹게임 제작

시작 화면

 

게임 플레이 화면

개요

이번에는 3명의 팀원들과 함께 간단한 타워 디펜스 온라인 웹게임을 제작하였다. 언제나 그랬듯 7/11~7/18까지 총 7일동안 협력하면서 무엇이 좋았고, 어떤 문제가 발생했었는지, 그리고 문제를 어떤 식으로 해결했는지 또는 어떤 식으로 해결하면 좋았을 지 KPT 방식으로 회고해보자.

 

팀에서의 내 역할: 팀장

 

참고

• 이번에는 내가 팀장이었지만, 프로젝트가 끝나자마자 최종 프로젝트를 시작하여 팀원들의 KPT회고록은 따로 없다. 그렇기 때문에 이번에는 개인적인 의견만 적어놓았다.

https://github.com/pledge24/TowerDefenseOnline

GitHub - pledge24/TowerDefenseOnline

 

---

Keep - 현재 만족하고 있는 부분

깃헙 이슈, 프로젝트 기능 사용 

• 저번 타워 디펜스에서도 이슈와 프로젝트를 사용했었는데, 팀원들과의 협력에서 긍정적인 효과들을 체감해서 이번에도 깃헙에서 이슈와 프로젝트를 사용하게되었다. 필자가 리더역할을 맡은지라 누군가의 허락을 받을 필요없이 편한대로 만들게 되었는데, 결과적으로 좋은 평을 받아 팀원들도 적극적으로 활용해주었다. 이렇게 이슈와 프로젝트를 연결하여 사용하니, 기존에 노션에 따로 협력과 관련한 내용을 정리해놓는 방식보다 프로젝트에 대한 내용을 찾기도 쉽고, 직관성도 훨씬 높다고 느껴졌다. 일주일동안 사용한 경험이 매우 긍정적이므로 다음 프로젝트에도 사용해야겠다.
   

팀원별 작업 리스트 정리

작업 리스트 트렐로 뷰

로드맵 뷰

이슈

code convention 정하고 시작 ( 내 의견 )

• 저번 프로젝트와 동일하게 이번에는 확실하게 모든 코드 작성 방법들(camelCase, pascalCase, 함수 이름은 동사로 시작 등등...)을 정하고 가니 나중에 다른 사람들의 코드를 볼 때 너무나도 편하고 좋았다. 이렇게 code convention을 꼼꼼하게 정하고 가니 삽질하는 경우도 훨씬 줄어들고 다른 사람의 코드의 로직을 이해하는데도 한결 편했던 것 같다. 앞으로도 code convention을 미리 작성하고 가도록 해야겠다. 

Problem - 불편하게 느끼는 부분

코드 확인을 소홀하게 하여 발생한 기능 누락

• 이번 프로젝트는 여러 이유로 상당히 시간이 촉박한 팀 프로젝트였다. 팀원이 필자 포함 5명으로 시작했는데, 한 분이 심하게 독감에 걸리는 바람에 사실상 4명에서 프로젝트를 하게되었고, 주말에 자리를 비우는 팀원도 있는 지라 사실상 작업일은 월, 화, 수요일 밖에 없었다. 그래서 다른 팀원들이 PR한 내용을 자세하게 검토할 수 있는 시간이 없어 팀원을 믿고 그대로 merge를 했는데, 충돌은 각 팀원이 확인하고 올리는거라 큰 문제는 없었지만 기능 누락까지는 확인이 되지 않아 사소한 내용의 기능들이 정상작동하는 지 알 수 없었다.
  예로, 한 팀원이 로그인한 유저의 최고점수를 저장하는 로직을 게임이 종료되었을 때 DB에 저장해야했었는데 따로 구현이 되어있지 않아도 게임을 실행하는데 있어 문제가 발생하지 않는 기능이라 발표 10분 전까지 알아차리지 못했다. 그래서 팀원들도 깜짝 놀라 발표 내용을 바꿔야하나 고민을 했었다. 결국, 바꾸는 방향으로 정해 누락된 기능을 발표에서 제외한 다음 시연하였다.

 

Try - Problem에 대한 해결책, 당장 실행 가능한 것

QA역할에 대한 책임은 모든 팀원이 가지고 있어야한다

• 기능 누락이나 버그같은 것은 각 팀원이 책임을 가지고 QA역할을 어느정도 가지며 발견해야 한다고 생각한다. 본인 코드의 품질을 높이고 버그를 잡고 PR을 하는 것도 꽤 힘든 일이지만, 시간적 여유가 발생하는 경우 반드시 다른 사람의 코드가 문제가 있는 지 주체적으로 찾아야한다. 한 사람이 맡아서 하면 그것이 Best이겠지만, 한 사람 한 사람이 고픈 팀 프로젝트에서 QA역할을 따로 만들어 한 사람에게 배정할 순 없다. 
  정말 어려운 말이지만 기능 누락 또는 버그는 서로가 알아서 잘 해줘야된다.

RuleSet으로 팀원들의 브랜치 merge를 제한 한 것이 과연 올바른 선택이었을까

• 이번에 처음으로 적용해본 기능으로 중요한 브랜치에 merge할 수 있는 권한을 팀장인 나만 가지고 있게 한 것이 있다. 다른 사람을 믿지 못해서가 아닌, 프로젝트 작업 관리의 흐름을 파악하고, 잘못된 merge에 대한 책임을 한 사람에게 물을 수 있어 보다 협력하는데 편하지 않을까? 하는 생각에 ruleSet을 통해 팀원들에게 merge를 못하도록 막아놓는 설정을 해두었다.
  팀 프로젝트가 끝나고 여러 팀원들의 목소리를 들어봤지만 기대한 것처럼 '훨씬 편했다'라는 말이 나와서 괜찮았구나 생각하지만, 정작 튜터님들은 그런 merge통제에 대해 약간은 부정적인 관점으로 바라보셨다(SPOF나면 어떻게 할거냐라는 장난섞인 피드백을 받았고, 다른 피드백으로는 관리하는 사람이 하는 일이 너무 많아진다는 작업량에 대한 불균형성 문제도 있었다.) 그래서 merge 통제는 다음 프로젝트에 적용할 건 지는 생각을 조금 해봐야겠다.

흠... 그렇게 별론가..?(PR시 ruleset으로 인해 나타나는 경고문)

 

---

마지막으로...

팀 프로젝트를 여러 번 하면서 눈에 띄게 깃헙 활용도가 늘어나는 것 같다. 다음 프로젝트에서는 milestone도 사용해볼까 하는데, milestone이 특정 기능 구현에 대한 완성도를 진행 바(process bar)로 확인할 수 있어 편리해보이기 때문이다.  생각이 여러모로 많이드는 팀 프로젝트였지만 바로 최종 프로젝트에 돌입하는 시기라 이번 프로젝트는 조금 쉬어가는 타임으로 작업했었던 것 같다.