우아한테크코스 레벨3에 접어들면서 팀 프로젝트를 진행하게 되었다.
우리 팀원은 그린론, 나, 병민, 베루스, 태태, 짱구 로 이루어져 있다.
우리팀(서비스) 이름은 모아모아 이며, 기존의 (우테코 내의) 스터디 정보 파악 및 개설, 모집의 어려움을 개선하고자 하여 기획한 스터디 관련 서비스를 만들고 있다.
모아모아의 탄생?!
첫 회의
우리가 처음 모인 날은 6월 16일으로 레벨2가 끝나고 방학을 일주일 정도 지내며 각자 어느 정도 에너지를 보충하고 난 이후였다.
서로에 대해서 잘 모르고 어색한 기운도 도는 사이에서 우리는 서로가 생각해 온 2~3가지의 아이디어를 공유하기 시작했다.
여러가지 아이디어가 나왔고, 흥미로운 주제들도 많았다. 그 중에서 본인이 생각했던 아이디어를 몇 가지 나열해보면 다음과 같다.
- 우아한테크코스는 KDT(K Digital Training)와 함께한다. 따라서 우리는 출근시간(10:00)과 퇴근시간(18:00)에 QR코드를 찍어야 한다. 하지만 매일매일 이를 반복해서 해야한다는 것은 매우 번거롭고, 가끔은 깜박하는 경우도 있다. 이러한 점을 개선하기 위해서 캠퍼스에 출근과 퇴근을 할 때 처음 카드를 찍은 시간과 마지막에 찍은 시간을 바탕으로 KDT를 자동으로 체크해주면 어떨까하는 아이디어도 있었지만, HW와 연동해야하고, KDT에서 어떤 API를 공개하고 있는지 알 수 없어 현실적으로 구현 불가능하다 판단하였다.
- 우아한테크코스는 (1, 2 단계 기간에) 일주일정도 페어를 진행하고, 일주일 정도는 개인이 미션을 수행하는 방식으로 진행된다. 페어기간이 끝난 이후에도 페어와 함께 고민하고 서로 의견을 나누는 경우도 많지만, 아무래도 페어기간일 때에 비해서 다른 크루들과의 소통이 줄어드는 경향이 있다고 느꼈다. 따라서 페어기간이 아닐 때 짝꿍(페어)를 정해서 함께 일과를 보내는 것을 생각해보았다. 하지만 이 경우, 우아한테크코스 진행 방식 자체가 바뀌어야 하는 것이었기 때문에 당장 실용성을 확보하기에는 어려움이 있다고 생각했다.
이외에도, 학습 관련된 아이디어나 일정 관련된 아이디어, 투두리스트와 같이 계획을 관리해주는 아이디어 등이 나왔고, 그 중에서 "스터디 관리 홈페이지"라는 아이디어가 현실 가능성, 실용성, 확장 가능성 등을 고려하여 선택하게 되었고, 해당 아이디어를 빌드업하게 되었고, 여러가지 기능들이 도출되었다.
나의 의견이었는데, 나는 해당 아이디어에 찬성한 이유는 history에 있다.
단순히 스터디를 모집하고 관리하는 것을 넘어서서 다른 사람들이 참고할 수 있게 history를 제공하면 우리 서비스만의 차별점이나 가치를 가져갈 수 있을 것이라고 생각했다.
벌써 우테코 4기가 진행되고 있고, 본인 또한 4기 크루이지만, 1 ~ 3기 선배 기수분들이 스터디를 어떻게 진행하였는지 확인할 길이 없었다. 왜나하면 현제는 4기 스터디 레포지토리 에서 스터디가 관리되지만 이는 4기 스터디만을 관리한다. 5기 때에도 Git Organization으로 관리할지는 모르는 일이다. 또 앞선 기수분들이 이렇게 스터디를 관리했을지도 모르는 일이다.
그럼 이렇게 앞선 기수분들의 스터디를 참고하여 얻는 이점은 무엇일까? 예를 들어 Effective Java 를 스터디한다고 해도 스터디 진행 방식은 여러가지가 있을 수 있다. 각자 아이템을 하나씩 읽어와 다른 크루들에게 발표(소개)하는 방식이 될 수도 있고, 일주일에 하나의 스터디를 골라 서로 의견을 나누는 토론 방식이 될 수도 있다. 그리고 본인은 인터뷰 방식의 스터디에 참여하였고, 각자 하나의 아이템을 골라 그에 대해서 발표를 하고 인터뷰를 진행하는 방식이었다. 스터디 진행은 포키가 해주었다. 옆에서 지켜보면서 많이 힘들었던 것을 볼 수 있었다. 이전에 이러한 방식으로 진행한 스터디가 없어 "이렇게 진행하는 것이 과연 크루들에게 도움이 될까? 적절한 방식인가?" 등에 대한 고민을 많이 하며 힘들어하는 것을 옆에서 볼 수 있었다.
나는 이러한 어려움을 우리 서비스를 통해서 극복하고 싶었다. 앞선 기수에서 어떤 방식으로 스터디를 진행했더니 스터디원들의 만족도가 어느정도 였다라고 하는 것을 기록 으로써 남기고 싶었다. 보통은 개개인의 블로그에 본인의 스터디에 대한 회고글들을 남기는데 이를 하나의 페이지로 모으고 싶은 마음이었고, 다음 우테코 크루분들에게 참고가 되었으면 하는 바램이었다.
이렇게 각자만의 이유로 우리는 "스터디 관리 홈페이지" 라는 아이디어로 의견을 좁히고 나서 1차 데모데이를 준비하기 위해 핵심기능(기능의 우선순위 고려하기), 개발 문화 구체화하기, 어떻게 구현할지 고민해보기, 팀 이름 을 고민해서 다시 만나기로 하였다.
데모데이 준비!
모든 팀원이 시간이 되는 6월 20일 다시 모여 위의 항목들에 대해서 이야기를 나누었다. 이전 회의도 3시간 정도 소요하였는데, 이 때 회의에서는 4시간 정도 걸렸던 것 같다. 다들 적극적이어서 의견도 많고, 초반이다 보니 나누어야할 이야기가 많았기 때문이다.
핵심기능
가장 먼저 우리팀의 핵심 기능을 무엇으로 할지에 대해서 서로 의견을 나누었다. 본인이 이전 회의에서 이야기하였던 점인데, "단순히 스터디를 모집한다 보다는 history를 제공한다는 데에 의미를 두자!" 에 있었다. 또 현재 Git Organization 으로는 어떤 스터디들이 있는지, 어떤 스터디가 진행중인지 한 눈에 파악하기 어렵다는 점을 개선하기 위해서 보다 가시성있는 스터디 목록 조회 및 검색 기능에 있었다.
이 외에도 스터디 성격 태그, 일정 알림, 내가 참여한 스터디 찾기(목록 보기) 등등 여러 기능들이 있었지만, 우리가 가치를 두는 기능을 우선적으로 개발하고 부가적인 기능을 덧붙여 나가는 것이 맞다라고 생각하였고, 결론적으로 우리는 스터디 목록 조회 및 검색을 1차 데모데이에서 선보이는 것으로 의견을 맞추게 되었다.
2주간 구현할 기능 명세(6/28 ~ 7/8)
- 스터디 전체 목록을 조회하면 간단하게 스터디 제목, 스터디 설명(description)을 볼 수 있다.
- 스터디 제목과 완전히 일치하게 검색하는 경우 원하는 데이터를 조회할 수 있다.
개발 문화
다음으로는 개발 문화를 구체화하였다. 우리의 개발문화는 다른 팀들과 거의 비슷하다. 내 일과 팀원의 일을 나누지 않고 함께하기!, 마감기한에 쫓겨서 개발하는게 아니라 우리가 컨트롤하기!(우리가 주체적으로 일정을 컨트롤 해보자!)와 같이 조금은 어려운 이야기도 있었고, 기본 중의 기본인 시간 약속 지키기! 딴길로 새지 않기, 1일 1 Discussion, 일정 기간에 한 번은 서로 감정회고 진행하기 등이 있었다. 이러한 여러 이야기들 중에서 우리가 가치를 두었던 것을 요약해보면 크게 3가지 이다.
- 쉬면서 일하자
- 공유하자
- 회고(기록)하자
개인적으로 개발문화에 있어서 본인이 많이 적극적이었던 점에서 스스로 만족하고 있다.
거창하거나 엄청 독특한 아이디어가 나온것은 아니지만 근거와 함께 많은 의견을 제시해보았다. 음..솔직한 회고를 한다면 90% 이상은 본인이 낸 개발문화이다. (물론 베루스, 그린론 등 다른 크루들도 마감기한 컨트롤 KPT 회고등 좋은 이야기를 많이 해주었고, 본인이 이미 많은 개발문화를 생각해 갔기 때문에 겹쳐서 그러한 것이라고 생각한다! 또 내가 제안한데에서 그치지 않고 팀원 전체가 해당 의견에 대해서 여러가지로 보충해주어서 더욱 구체적인 개발문화가 나올 수 있었다고 생각한다.)
특히 프런트가 한 일을 백엔드가, 백엔드가 한 일을 프런트가 알게 하자!와 같은 아이디어는 이전 장바구니 미션을 하면서 같은 팀이라고 하는데 백엔드와 프런트가 서로 따로 작업하는 느낌을 강하게 받아서 이러한 개발문화를 제안해볼 수 있었다. 서로 API명세만 함께 회의하고 이후에는 프런트쪽에서 어떻게 작업하고 있고, 어디까지 진행되었는지 또 백엔드가 어떻게 진행하고 어디까지 진행되었는지를 서로 공유하지 않았다. 물론 API명세를 엄청 꼼꼼히 했어서 마지막으로 서버 배포를 하고 테스트했을 때 문제없이 잘 돌아갔고, 데모도 무사히 마쳤지만 아쉬운 부분이었다. 따라서 서로 기술적인 부분에는 잘 모를 수 있어도 서로의 진행상황 정도라도 매일매일 공유했으면 하는 마음에서 제안해보았고, 우리팀의 개발문화로 채택되어 지금까지도 잘 진행되고 있다.
다음으로는 딴 길로 새지 않기이다. 회의 때는 회의 안건만 확실하게 잡고 가자는 것이고, 회의가 길어져도 서로 지치고 기존에 회의하기로 했던 안건을 모두 마치지 못하는 경험을 장바구니 때에도 그리고 모아모아 팀의 첫 회의 때에도 느껴서 제안하게되었다. 회의 내용과 밀점한 연관이 없는 내용은 따로 기록해두었다가 다음 회의 일정을 잡아서 이야기하자는 것이고 이를 위해서 회의에 대한 목표 및 세부적인 목차를 미리 준비해서 회의를 진행하자는 이야기가 나왔다. 또한 여러 의견이 나오면서 해당 안건에 대한 이야기가 길어진다고 판단하여 서로 중재해주는 역할을 한 번씩 해주자라는 이야기가 나오게 되었다.
마지막으로는 1일 1Discussion이다. 이는 곧 공유와도 연관이 있는 내용이다. 혼자 고민하기 보다는 함께 고민했으면 하는 바람에서 나온 것이고, 본인이 공부하다 생긴 의문점이나 의견(제안) 등을 자유롭게 토론했으면 해서 나온 의견이었다. 또 학습한 내용을 본인의 개인 블로그에 올려서 기록하는 것보다 Discussion에서 기록하면 서로 고민하고 공부한 내용을 자연스럽게 공유하게 될 것이라고 기대하였다. 현재는 다음과 같은 내용을 Discussion에 기록하고 있다.
모아모아
마지막으로 팀명과 함께 서로 레벨3의 목표를 정하면서 회의를 마무리하였다.
우리팀의 이름으로는 여러가지 의견이 제시되었다. 본인은 간단하게 Study With Me라는 이름을 제안하였었다. 우리 서비스가 어떤 것인지도 직관적으로 파악이 가능하다고 생각하였고, 유튜브등에서 많이 쓰이는 용어이기 때문이다.
여러가지 의견이 오가는 가운데 태태가 제시한 "모아모아"라는 팀명으로 결정하였다. 귀여운 이름이라고 생각되었고, 부르기도 쉬웠다. 또 "스터디를 모아모아" 라는 취지와도 어울린다고 생각하였다. 그리고 이렇게 모아모아가 탄생하였다.
우리는 각자 레벨3를 어떻게 보낼것인가? 에 대해서 본인들의 생각을 공유하였다. 다른 팀원들의 생각을 마음대로 공개하는 것은 안될 것 같아 본인의 생각만 기록하려고 한다.
나는 이번 팀 프로젝트를 진행하면서 기술적인 측면에 대해서 많이 배우는 것도 좋지만 앞서 정한 우리들만의 개발문화를 잘 지켜봤으면 하였다. 또 각 데모데이 별로, 혹은 전체적으로 팀 프로젝트가 끝날 때 아쉬웠던 점이나 잘했던 점을 정리해보고 싶은 생각이 있었다. 즉, 이는 꾸준한 회고를 통해서 짧은 주기로 팀 프로젝트에 대한 피드백, 생각이나 감정의 공유를 하고 싶은 것이다.
이러한 생각을 한 이유는 졸업작품과도 연관이 있다. 이 때 당시 팀장 역할로써 팀을 이끌어 갔었는데, 딱히 개발문화와 같은 내용을 이야기 안하다보니 서로 편한 방향으로 팀플을 진행하였던 것 같다. 서로 의견을 이야기하면서 근거가 없는 경우(ex. 다들 그렇게 하던데..?, 그냥..)가 빈번하였다. 발표 등 일정이 있다 보니 일정에 쫓겨서 마지막 일주일에 작업을 몰아서 하는 경향도 없지 않았다. 가장 큰 문제점은 서로의 감정이나 생각을 공유하는 시간을 가지지 않다보니 서로 사적인 감정을 공유하지 않게 되었다. 즉, 일주일에 한 번 만나는 시간에 서로 팀플에 대한 이야기만 하고 헤어지게 되었다. 프로젝트 시작과는 다른 분위기였다. 그리고 이러한 사소한 감정이나 작업한 내용에 대한 기록을 하지 않다보니 지금와서 생각해보면 어떤 부분이 아쉬웠거나 부족했는지 스스로 피드백하기가 쉽지 않다.
그래서 이번 프로젝트에서는 앞서 이야기한 여러가지 개발문화를 꼭 잘 지켜나갔으면 한다. 또한 팀 프로젝트 전체에 대한 각자의 피드백을 공유하고 생각이나 감정을 공유하는 시간을 짧은 주기와 긴 주기로 가져가보려고 한다.
모아모아 1차 데모 기간
6월 29일 (6월 28일은 레벨2에서 학습한 내용을 인터뷰하는 날이었기 때문에 별도로 팀플을 진행하지 않아 제외) 부터 7월 8일 까지 "1차 데모" 기간 동안 경험한 내용과 그 과정에서의 나의 생각, 느낀점을 기록해보려고 한다.
UI/UX 특강 (6/29, 7/1)
이틀 간 UI/UX 특강이 있었다. 첫째날에는 막연한 아이디어를 마구 뽑아내는 과정, 그 아이디어를 조금 더 구체화 시키고 그에 대해서 다른 크루들에게 평가를 받아보는 과정들을 진행해보았다. 그리고 그 이유도 들어보는 시간을 가져보았다.
공통적으로 많은 크루들의 긍정적인 반응을 이끌어내는 아이디어에 대해서 크루들은 "편안함", "상쾌함", "직관적", "신선함" 과 같은 이유로 긍정적이다 라고 답했으며, 부정적인 반응을 이끌어내는 아이디어에 대해서는 "불쾌함", "불편함" 등과 같은 감정을 느낄 것 같다라는 답을 해주었다.
즉, 각각의 아이디어에는 차이가 있더라도 그 아이디어를 통해서 느끼는 감정은 비슷했고, 긍정적인 반응을 이끌어내는 아이디어는 편안함이나 신선함 같은 감정이 동반되었다.
UI/UX 둘째날에는 각 팀의 아이디어, 즉 우리 모아모아팀의 아이디어에 대한 Ploblem(지금 현재 문제점), Solve(그래서 현재는 어떻게 해결하고 있는지), Goal(최종 목표) 를 다른 크루들과의 인터뷰를 통해서 도출해보는 시간을 가지고 또 이를 바탕으로 UX 스터디 시나리오를 뽑아보는 시간을 가졌다.
직접 크루들의 의견을 들어보면서 우리 아이디어를 어떤 방향으로 발전시킬지에 대해서 고민해볼 수 있었다. 우리 내부에서 생각하느 문제점보다 다양한 문제점을 들어볼 수 있었고, 특히 개인적으로 스터디 브랜딩에 대한 아이디어를 얻을 수 있었다고 생각한다.
우리가 4기째 진행되는 현재의 우아한테크코스를 여러 사람이 참여하고 싶어하고 함께하고 싶어하는 것 처럼, 예를 들어 "디우의 Spring Study" 가 우테코처럼 하나의 브랜드가 되어서 다른 사람들도 참여하고 싶은 스터디가 될 수 있지 않을까? 하는 아이디어 였다. 우리 모아모아의 핵심 가치가 스터디들을 모아 볼 수 있고, 또 그렇게 진행되었던 스터디에 대한 history를 제공한다는 점에서 충분히 우리 서비스가 이런 스터디 브랜딩에 도움이 될 수 있을 것 같다.
마지막으로 UX 워크샵을 통해서 배운 점은 사용자에게 직관적인 UI, 기능을 제공해야 겠다는 것이다. 처음 우리 서비스를 접한 사용자도 직관적으로 기능을 사용할 수 있도록 기능을 제공해야한다. 어떤 설명이 없이도 우리의 기능을 우리가 의도한대로 사용할 수 있게 해야한다.
몹 프로그래밍
우아한테크코스를 진행하면서 처음으로 누군가와 함께 코딩을 해보았다. 즉, 페어프로그래밍(짝코딩)을 처음 접해본 것이다. 둘이서 코딩을 하면서 같은 문제에 대해서 서로 다른 생각, 다른 시각으로 접근하는 부분 등에서 서로 많은 것을 배울 수 있었다. 특히 해당 코드에 대해 두 명 모두 바라보고 있으니 실수가 보다 적었고, 코드에 대한 책임 또한 둘 모두에게 있다는 것이 심리적으로 안정도 가져다 주었다.
하지만 이번 팀프로젝트는 프런트 2명의 크루, 백엔드 4명의 크루로 총 6명이 한 팀을 이루었다. 따라서 백엔드만 보아도 4명의 코드 스타일이나 추구하는 가치 등등 차이가 많았다. 따라서 우리는 이번 스프린트1 기간 동안에는 4명이 모두 함께 코딩하는 몹 프로그래밍을 하는 시간을 가지기로 했다.
앞서 언급한 것과 같이 4명이 모여서 하나의 코드를 작성하다보니 사소한 부분에서도 의견이 갈렸다. 예를 들어 final 선언을 왜 해야하지? 테스트 코드에서는 final을 사용하지 말까? 생성자와 파라미터에도 final 선언이 필요한가? 등 하나의 주제에 대해서도 서로 엇갈린 의견들을 주고 받았다. 크게는 테스트를 작성하는 방법, Service에 대한 테스트는 필요한가? Controller 테스트는 단위테스트여야할까? 통합 테스트여야할까? 등 여러가지 부분에서 의견이 갈렸고, 이러한 의견을 취합하는 과정이 매우 빈번하게 일어났다.
따라서 개발 속도 자체는 느려졌지만, 어떻게 보면 다른 시각에서 바라볼 수 있는 기회가 되기도 하였고, 여러가지 아이디어 그리고 내가 모르던 부분(ex. 한 번도 사용해본 적 없는 Mock 테스트, RestAssured의 또 다른 사용법 등)을 배울 수 있는 기회가 되기도 하였다. 그리고 직접 코딩을 하면서 서로의 스타일과 의견을 알아보고 맞추어 가는 과정을 스프린트1 때 함으로써 이후 코딩 컨벤션 등에 대해서 이야기를 따로 나눌 필요가 없어졌다. 이제는 2명, 2명으로 나뉘어서 하나의 이슈를 해결하게 되더라도 기존의 몹 프로그래밍으로 작업했던 내용을 기반으로 작업을 해나가면 되었다.
하지만 그에 따른 단점이 있는 것도 분명했다. 혼자할 때보다는 페어할 때 시간이 2배 정도(실은 그보다 적거나 많을 수도 있겠다.)드는 것처럼 4명이서 하다보니 페어 때보다 2배 정도(실은 그보다 적거나 많을 수도 있겠다.) 시간이 들었다. 또 우리팀의 경우 특정 시간을 정해서 드라이버를 돌아가며 하지 않았기 때문에 한 명이 드라이버를 많이하게 되고, 또 이야기를 많이하게 되는 시행착오도 겪어야 했다.
이는 시간을 정해놓고 드라이버를 정해서 드라이버가 자신의 코드(아이디어)를 설명하면서 개발을 진행하고, 남은 크루들은 드라이버가 작성한 코드에서 의견을 제시(ex. Setter를 구쳉적인 이유없이 작성하는 경우, 왜 그렇게 했는지에 대해서 질문하는 방식으로)하는 방법으로 진행해보는 것도 좋을 것 같다.
아쉬운 점
7월 7~8일, 가장중요한 데모데이와 그 전날 개인적인 사정으로 인해 나는 우리팀과 함께할 수 없었다. 그리고 이 부분이 가장 아쉬운 점이다.
실질적인 기능 개발은 이미 끝난 상태였지만, 데모데이 발표를 위한 준비는 되어있지 않은 상태였다. 우리 팀원들과 함께 스프린트1을 돌아보면서 우리가 어떤 작업을 했는지 함께 돌이켜보고, 다음 스프린트에서는 어떻게 개선할지에 대해서 이야기해볼 수 있는 시간이 되었을 것이다. 즉 어떻게 보면 스프린트1 기간을 마무리하는 시간인데, 함께하지 못한 아쉬움이 크다. 그런 와중에서도 그린론이 여러 진행 사항을 공유해주도록 노력해주어서 너무 감사하다.
이 외에도 개인적으로는 다른 팀을 참고해보았을 때, 우리팀도 역할을 돌아가면서 회의나 데일리 미팅을 진행해보면 어땠을까? 하는 생각이 든다. 회의실을 잡는 역할이라거나, 회의 진행, 회의 준비 등의 역할을 정하지 않으니 매번 하던 크루가 하는 경향이 없지 않아 있었다. 물론 시간이 지나면서 조금은 다양한 크루들이 돌아가며 진행을 해주었지만 정해서 진행해보는 것도 나쁘지 않은 경험이 될 것 같다.
또한 개인사정으로 함께하지 못한 시간이 있다보니 팀원들이 공유해줘도 몇몇 부분 공유받지 못하는 게 있어 아쉬움이 남는 것이다. 전체적인 큰 틀에서는 공유를 받을 수 있었지만, "앞으로 내부적으로는 스프린트기간을 일주일로 가져가자"와 같이 크루들 사이에서 이야기는 나왔지만 별도로 기록하지 않은 내용에 대해서는 공유받지 못해 아쉬움이 남는다. 우리 팀 모두가 조금은 사소한 내용에 대해서도 기록하려고 하는 습관을 가지면 좋을 것 같다!
마지막으로 우리가 10~18시 코어 타임을 제외하고는 서로 터치하는 일이 없다보니 조금은 조급한 마음이 든다. 몹 프로그래밍을 진행하여 진행하는 속도가 더뎠던 것도 사실이고, 6월 28일 ~ 7월 8일 이라고는 하지만 실질적으로는 7월4일 ~ 7월 6일 정도가 실제 개발 기간이었던 것을 감안하면 엄청 기능이 적은 것이라고 판단하기도 어렵지만, 조금 마음이 급해지는 것은 사실이다. 아무래도 우리의 핵심 기능(어떻게 더 잘 스터디 목록을 보여줄 수 있을까? 진행되었던 스터디(history)로 부터 가치를 제공하자.)으로 부터 부가적으로 추가할 수 있는 기능들이 많다보니 이러한 생각이 든다. 나는 우리팀의 실력을 믿는다! 조금은 더 열심히 그리고 빠르게 진행해볼 수 있지 않을까?! 스프린트2 때에는 스토리 포인트를 산출하여 우리팀의 개발 진행 속도를 측정해보고 프로젝트를 관리하면 좋을 것 같다!
잘했던 점
우선 애자일을 가장 잘 지키면서 스프린트를 진행하고 있다는 생각이 든다. 이번 우테코 레벨3의 목표는 찐한 협업과 함께 애자일을 배우는 과정이라고 생각한다. (아 물론, 레벨1,2에서 배운 내용을 우리의 프로젝트에 적용해보는 것도 당연하다.) 우리팀은 우리의 아이디어의 핵심에서 부터 기능을 덧붙여 나가는 과정으로 스프린트를 진행하고 있다. (이제 막 스프린트2에 들어갔지만..ㅎㅎ) 그런데 다른 팀을 보면 스프린트1 때 전체적인 DB 설계나 도메인 설계를 진행한 팀도 있고, 핵심 기능이 아닌 "로그인 기능"을 우선적으로 구현하고 있는 팀도 있었다. 이렇게 볼 때 우리팀에서는 가장 우선시 되는 기능(스터디 목록 조회 및 검색)을 약 3~5일 정도(실질적인 개발 시간) 되는 스프린트1 때 진행했고, 스프린트2 때에는 여기에 기능을 추가(검색시 태그를 통한 필터링, 스터디 후기 등)해 나간다는 점에서 애자일(반복적, 점진적)을 잘 지키고 있다는 생각을 한다.
앞으로 이런 애자일을 더 잘 지키기 위해서 우리 팀원 모두에게 Clean Agile(로버트 C. 마틴) 책을 읽어보길 권한다.
또한 우리 팀원들의 성향이 다들 비슷해서인지 의견 조율이 잘된다는 느낌을 받았다. 분위기도 나쁘지 않았다. 초반에는 다들 어색해서 그런지 모든 팀원이 의견을 적극적으로 내기 보다는 의견을 내는 크루들만 의견을 내는 분위기 였다는 생각이 들었지만 이후에는 다들 적극적으로 본인의 의사를 표현해주었다. 또 서로 갈리는 의견이 있을 때 서로의 근거를 잘 비교해보고 의견을 취합해 나가는 과정을 잘 했다고 생각한다.
개발 문화에 있어서도 잘 지키는 편이었다고 생각한다. (개인 개인이 우리의 문화를 더 잘 지키기 위해 노력했던 것 같다.) 특히 매일 아침 데일리 미팅에서 각자 진행한 내용을 공유함으로써 내 일과 팀원의 일을 나누지 않고 함께하기!가 잘 지켜졌다고 생각한다. 하지만 개인적으로 아쉬움 혹은 개선점이 있다면, 어떤 내용을 진행했다. 에서 그치지 않고 그 진행을 하면서 느낀 본인의 감정이나 혹은 이슈등도 조금은 더 구체적으로 공유해주면 좋겠다는 생각을 한다. 이제는(스프린트2) 몹 프로그래밍이 아닌 각 기능별로 나뉘어져서 진행을할 것이기 때문에 이런 과정이 중요하다고 생각한다.
또한 본인이 주도적으로 이끈 것 같긴 하지만 모두가 긍정적으로 KPT 회고에 참여해주고 어느정도 솔직한 감정을 공유해준 부분도 잘했던 것 같다. 아쉬운 부분이 있다면 단순히 "좋았다." 라는 감정 보다는 "왜?" 좋았었는지 구체적으로 공유해주면 좋을 것 같다는 생각이 든다.
이외에도 의견 제시할 때 근거와 함께 제시하는 부분, 1일 1Discussion 등을 적극적으로 모든 크루가 지키려고 노력한 점은 우리팀 스스로 칭찬할만 하다고 생각한다.
