PBL 기반의 팀 프로젝트

PBL (Project Based Learning)

이론부터, 기초부터 공부하며 학습하는 방식이 아닌, 프로젝트를 하면서 배우는 탑다운 방식의 학습이다.
여기서 중요한 키워드는 Learning!!!
문제 해결(프로젝트)는 Learning의 부산물일 뿐이다.
*그래서 학습의 창의성이 매우 중요하지는 않다.

---

PBL의 개요

토론

• 이 문제가 왜 문제인지?
  • 어떤 관점들을 가지고 있는지
• 문제를 어떻게 해결할 것인지
  • 어떤 해결 방법이 있는지

해결

• 해결을 위한 지식의 습득과 점진적 해결
  • 끝없는 디버깅, 코드리뷰(리딩) ...

평가

• 엣지 케이스(바운더리 조건)는 잘 처리 되었는지?
• 문제에 대한 답이 잘 도출되었는지 (논리적으로, 시간적으로)
• 코드는 아름다운지! (스타일, 가독성, 성능)
• 이 문제와 연관된 지식을 잘 습득했는지
  • 이게 가장 중요한 부분이다.

---

지금까지 우리가 했던 팀 활동의 나쁜 예시를 돌아보자.

(당연히 팀 단위의 프로젝트라고 가정한다)

• 해야할 프로젝트(과제)가 생겼다! 팀 과제/캡스톤, 동아리, 경진대회 등등의 이유가 있겠다.
• 첫 미팅에서는?
  • 팀장을 정하고, 뭐할지? 과제 논의하고, 팀원들 사이에서 칼 같은 역할(작업) 분담이 진행된다.
• 두번째 미팅에서는?
  • 각자 맡은 부분을 논의하고,
  • (저번주 미팅에서 역할 분담하고 봤더니 내 파트 양이 너무 많다;;;) 그래서 내가 맡은 부분이 너무 과하다고 토로한다. 하지만 딱히 유의미한 변화를 불러일으키지는 않는다.
• 이후는?
  • 그냥 각자 맡은 부분 열심히 한다. (열심히 하기라도 하면 다행이다)
  • 문제는 절대 논의는 없고, 다른 사람 작업에 전혀 개입하지 않는다.
  • 다들 바쁜 와중에 특히나!!! 바쁜 팀원이 생긴다. 근데 나도 바쁨;
• 마감 며칠 전 '합치기' 미팅
  • 쉽게 합쳐지(겠냐?)지 않는다, 바쁜 팀원은 자기 업무 반도 못했다.
  • 명시적/묵시적 갈등/비난 상황이 발생하고, 조정이 잘 안 되며, 멘탈은 붕괴된다.
  • 바쁜 팀원이 하지 못한 작업을 버스 드라이버(대게는 팀장)가 어찌저찌 해결해보고자 한다.
• 마감 전전날 두번째, 그리고 마지막 '합치기' 미팅
  • 역시나 안 되(겠냐?)고 있다.
  • 퉁치고 넘길 꼼수 방법을 찾는다. 되는 '척'이라도 하려고.
• 결과 발표
  • 자기가 맡은 부분 자기가 발표 하거나,
  • 룰렛 돌리기;
• 회고
  • 따위 없다.
  • 애초에 실제 유저가 사용하는 서비스를 만든 적이 없고, 그저 일회성 '졸업작품'을 만든 것에 블과하기 때문에.

---

그렇다면 어떻게 했어야 하나?

일의 분담

• 문제의 정의(만들어야할 것)가 충분히 된 후에
  • 각자의 문제에 대한 관점을 공유하고 정리
  • 학습과 토론 과정을 거쳐 (거의 같은) 문제를 인식한다.
• 분담과 동시에 같이 배울 수 있는 협업 구조 및 툴을 정의한다.
  • 다른 사람의 작업 진행을 볼 수 있고, 리뷰와 코멘트 그리고 QA가 가능해야한다.
• 도구를 연동한다
  • GitHub의 이슈 트래킹, PR/Merge, Project, Wiki) + slack 연동
• 여기까지를 전체 프로젝트 기간의 1/3으로 써도 세상이 망하지 않는다 라고 이민석 교수님께서 말씀하셨다. 동감

Lean한 방식의 진행 (점진적 개발)

• '만들고, 리뷰하고, Test하고 ... 리뷰 후 기능 추가하고' 를 반복한다 -> 애자일하게!!!!
• 즉, 합치면서 만들기 그리고 리뷰를 통해 거기까지 배운 것을 공유하기
  • 이거 정말 좋다. 파트가 다르면 리뷰할 생각을 못했는데, 바로 적용해야겠다.
• 발표가 필요하면, 모두 아는 내용을 발표 제일 잘하는 사람이...
  • 정말 동감하는 내용이자, 나는 발표자가 프로젝트의 모든 것을 이해하고 있어야한다고 생각한다. 단순 스크립트 암기는 프로젝트에 대한 예의가 아닌 것 같아..
• 그리고 회고 (책임을 묻는 것이 아니다. 배우기 위한!!! 회고)
  • 기술적인 부분 (기능, 기능의 우선 순위, 적용 기술...)
  • 방법적인 부분 (개발 도구, 협업 도구, 소통 방식...)
  • 태도적인 부분 (주로 개인적인 이슈에 의한 문제 해결 방식...)

---

개인적으로,

• 아주 작고 단단한 기능(서비스)로 시작해서
• 유저를 모아 조금이라도 트래픽 이라는 것을 경험하고'
• 유저의 반응을 관찰하고 분석해서
• 그것을 서비스에 적용하고

이게 정말 좋은 그림같다. 이번에 꼭 해보고 싶은 부분.

---

Reference

국민대학교 소프트웨어학부 이민석 교수님의 말씀