중간 회고

중간 회고

개발 방식 회고

서로 관련 있는 페이지를 분리하고, 팀 내에서 두 팀으로 나누어 작업하는 방식은 어땠나요?

서로의 코드를 파악하기 위해 PR 만으로 충분했는지, 더 보완했으면 하는 점이나 좋았던 점이 있다면 무엇인지 회고해봅시다.

---

민재

👍🏻  기능 분리 PR 리뷰

기능개발을 페이지별로 구별해서 각자 전담하고 비슷한 페이지끼리 묶어서 팀을 나누어서 작업을 하였다. 추가로 필요한 페이지나 기능이 필요할 때에는 비슷한 페이지나 기능을 개발했거나 하고있는 팀원이 전담함으로써 이미 해본 기능과 비슷하기 때문에 이해도가 높아서 금방 개발할 수 있었고 시간을 많이 단축할 수 있었다. PR 리뷰도 연관된 페이지나 기능을 개발중인 팀원에게 받음으로써 확실하게 리뷰를 받아서 문제없이 머지할 수 있었다.

👎🏻 기능 분리

비슷한 페이지만 개발하게 되는 부분이 조금 아쉬움이 있다. 개발시간은 단축할 수 있었지만 한 사람이 비슷한 페이지 전체를 개발하다보면 구조와 코드가 비슷한것을 알 수 있다. 프로젝트를 업무적인 측면에서 본다면 빠르게 개발할 수 있었지만 학습적인 면에서 본다면 성향이 다른 페이지도 개발해보았으면 좋은 경험이 되었을 거 같고 시야를 넓게 볼 수 있고 전체적인 프로젝트의 프로세스도 잘 파악할 수 있었을 것 같다.

혜성

👍🏻 개발 방식 선정 과정

우리 팀의 개발 방식은 체계적이고 계획적이기 보다는 실전적이었다고 생각한다. 세부적인 개발 방식, 계획들은 개발이 진행되는 와중에 대부분 결정되었다. 나는 우리 같이 경험이 많지 않은 주니어 개발자들에게 이 방식이 아주 적합했다고 생각한다. 완벽하고 체계적인 계획을 세우는 건 불가능에 가깝다. 오랜 시간을 들여 계획을 세웠다고 해도 분명 실천하기 쉽지 않은 내용이었을 것이다. 따라서 직접 부딪혀가며 필요성을 느낄 때 협의 하에 개발 방식을 정한 점이 좋았다. PR 리뷰 PR 리뷰를 해서 정말 다행이라고 생각한다. 영역을 나누어 개발하다 보니 서러 어떤 코드를 만들고 있는지, 어느 정도의 퀄리티를 유지하고 있는지 확인 할 수 있는 유일한 장치였다. PR리뷰를 통해 컨벤션을 지키고 통일성을 부여할 수 있었다. 이런 장치가 몇 가지 더 있었다면 더 좋았을 것 같다.

👎🏻 기능 분리 사실 기능 분리는 내가 제안했지만 속 시원하게 효과적인 방식이었다고 말하기는 힘들다고 느낀다. 서로 작업하는 영역이 분명하게 분리되어 기술적으로는 좋았지만, 학습하는 입장에서 효과적이었나? 의구심이 조금 든다.

나연

👍🏻

팀 분리 테마 별로 팀을 나누어서 진행했다. 팀을 이루어 진행하니 소통할 때 서로 이미 어느 정도 코드를 이해하고 있었기 때문에 논의가 쉬웠고 결정도 빠르게 이루어졌다.

PR 리뷰

PR 리뷰를 통해 놓치고 있었던 코드 컨벤션을 체크할 수 있었다. 정해 놓은 PR 규칙(구현 내용과 PR 포인트 작성) 덕분에 PR한 코드를 확인할 때 많은 도움이 되었다.

개발

프로젝트의 목표 중 기능 구현이 최우선순위라는 점에서 팀원 모두가 개발을 빨리 시작한 것은 목표를 달성하는 데 좋은 영향을 준 것 같다.

👎🏻

PR과 코드 리뷰 다른 팀의 코드를 파악하는 것은 코드 리뷰를 하지 않으면 파악하기 어려웠던 것 같다. 페이지 하나 또는 기능이 완전히 구현될 때는 전체 팀 리뷰를 받아도 좋을 것 같다. 팀끼리 고민했던 내용(구현 전 고민했던 내용들)은 문서화 하면 좋을 것 같다. 문서화하면 다른 팀의 팀원들과도 다양한 구현 방식과 방법들에 대해 공유할 수 있을 것 같다.

수연

👍🏻 기능 분리 PR 리뷰 컴포넌트 설명서

현재 우리 팀은 팀 내부에서 두 팀으로 나눠 각자 페이지 별로 기능 구현을 담당하고 있다. 어느 한명이 지나치게 늘어지거나 막중한 책임감을 안지 않도록 기능을 적절히 분배한 것 같다는 생각이 든다. 다만 이렇게 기능을 나눌 시, 다른 팀의 코드가 어떻게 구현되어 있는지 모른다는 문제점이 있었다. 이런 문제점은 PR 리뷰와 컴포넌트 설명서를 작성함으로써 보완하기로 했다.

나는 PR 리뷰를 할 때마다 컴포넌트 설명서를 작성했는데, 확실히 이 방법이 많은 도움이 된 것 같다. 추후 다른 사람들에게도 공유할 수 있고 무엇보다 코드의 흐름을 이해하는 능력을 많이 기를 수 있었다.

👎🏻 기능 전담

한 사람이 페이지 하나를 전담하게 되고, 기능이 큰 경우만 둘 정도의 인원을 배치하다 보니 비슷한 구현을 반복하는 형태가 된 것 같다. 물론 비슷한 기능을 작성하게 되면 코드의 이해도가 높으니 더 빠르게 코드를 작성할 수 있지만, 새로운 기능을 구현할 수 있는 기회는 많이 없었을지도 모른다. 또, 한 사람이 페이지를 전담하다 보니 하나의 구조에 꽂히면 그 방식을 밀고 나가게 되는 문제점도 있는 것 같다.

시간이 부족했기 때문에 기능 구현에 초점을 두었지만, 더 좋은 코드를 만들 수 있는 방법이 있지 않았을까 하는 아쉬움이 든다.

창기

👍🏻 기능 분리 브랜치 머지 룰셋 적용

초기 유저 스토리를 논의하고 디자인을 만들 때 특정 기능을 담당하는 페이지가 여럿 나올 것임을 확인했고, 이에 페이지 계열을 2개로 나누어 2개 팀에 각각 할당하고, 그 팀 내에서 페이지를 하나씩 담당하는 식의 개발 Task 할당을 제안했다. 예상대로 하나의 페이지를 1명이 담당하게 되어 개발 속도 면에서 장점을 가져갈 수 있었고, 페이지에 대한 이해를 바탕으로 팀 내에서 특정 페이지에 대한 질의 또한 막힘없이 응답하는 모습을 확인할 수 있었다.

브랜치에 변경 사항을 만들 때, 단순 push와 일명 PR이라고 불리는 Pull Request를 Merge하는 방식으로 할 수 있었는데, main 브랜치에 대한 무분별한 변경을 지양하고, 팀원 간 각자의 개발 영역에 대해 설명하고 이해하는 기회를 만들 수 있지 않을까? 해서 필수적인 PR을 통한 변경과, Merge를 위한 필수적인 팀 내 2명 이상의 승인(Approve) 강제화를 브랜치 합병 규칙(Branch Merge Ruleset)을 통해 적용하였다. 기대한 만큼의 효용이 있었다고 생각한다.

👎🏻 PR 리뷰

아무래도 브랜치 머지 룰셋의 적용으로 인해 사소하지만(코드의 양은 상대적으로 적지만) 필요한 변경에 대해서는 리뷰어들이 PR 리뷰를 하기 애매한 상황이 펼쳐졌고, 리뷰는 다른 사람이 작성한 코드를 이해하는 과정이다보니 시간과 에너지가 많이 소요되었다. 이 때문에 개발 Task에 대해 우선순위가 밀려 리뷰가 지연되거나, 간단한 코멘트 정도의 리뷰로 마무리되는 경우를 보게 된 것 같다. 첫번째 문제에 대한 대안으로 리뷰어들의 리뷰 Deadline을 간이로 설정하였지만 그닥 지켜지지 않았던 것 같고, 두번째 문제는 현실적으로 해결하기 어려운 문제로 생각하고있다.

협업 방식 회고

NIRVANA 협업 방식은 어땠었나요?

스프린트로 매주 일정을 공유하고, 스크럼을 통해 어떤 점들을 관리할 수 있었는지 회고해봅시다.

---

민재

👍🏻 스크럼 백로그

스크럼을 통해서 팀원들이 어떤 작업을 할 지 파악할 수 있었고 자신의 작업도 정리해두기 때문에 자신이 해야 할 작업에 집중할 수 있었다. 백로그와 칸반보드를 작성했기 때문에 시각적으로 팀원들이 어떤 작업을 예정중인지, 진행중인지 언제 완료할 것인지 일정들을 쉽게 추적할 수 있었고 개발중인 과정과 현재 상황을 한눈에 쉽게 파악할 수 있었다. 슬랙으로 비동기 커뮤니케이션을 하며 개인이 개발에 몰입할 수 있는 시간을 확보 할 수 있었다.

👎🏻 스크럼 백로그

팀 스크럼, 백로그, 칸반보드 등을 활용해서 서로의 일정을 파악하며 일정을 관리하였는데 이들이 같은 목표와 목적을 가지고 있다고 생각하는데 여러 페이지로 나누어져 있다보니 어디에 작성을 해야할지 애매한 경우도 있었고 중복되는 내용도 있었다. 이들을 하나의 페이지에서 관리하거나 실제 협업에서 자주 사용되는 지라같은 툴을 사용해서 관리 했었으면 더 좋았을 것 같다고 생각한다.

혜성

👍🏻

멘토님에게 피드백을 받은 이후 브랜치를 적절히 나누고 PR리뷰 기능을 중점적으로 사용한 것이 협업에 큰 도움이 되었다.

칸반 보드를 도입한 이후로 프로젝트 진행 방식이 명확해졌다.

👎🏻 스프린트 별로 목표를 수립했지만 스프린트가 시작할 때 스프린트 목표를 작성하다 보니 결국 그 주의 할 일을 정리해 놓은 표 정도의 기능에서 그친 것 같다. 프로젝트를 시작함과 동시에 어떤 스프린트에 어떤 기능을 완성할 지 대략적으로 나마 계획을 미리 세워야 했을 거 같다.

여러가지 팀 규칙을 정했는데 중복되는 느낌을 받는 규칙들이 몇가지 존재했다. PR리뷰 설명과 칸반 보드 설명, 백로그와 칸반보드가 그랬다. 사실 이는 우리가 필요성을 느낄 때마다 규칙을 만들다 보니 어쩔 수 없는 현상인 것 같다. 이것도 필요한 것 같고 저것도 필요한 것 같아서 만들어보니 결국 같은 문제를 해결하기 위한 것이었던 것이다.

스크럼이 때로 길어지기도 했는데 우리가 만든 칸반 보드를 중심으로 서로 의견을 나누면 더 효율적인 스크럼이 되었을 것 같다.

나연

👍🏻

칸반보드사용과 스크럼 ****

칸반 보드를 통해 실시간 팀원들의 진행 사항을 확인할 수 있었고 스크럼을 통해 팀원들의 작업 사항 들을 쉽게 확인할 수 있었다. 스크럼을 할 때 논의 사항 칸이 있어서 미리 작성할 수 있어 잊지 않고 스크럼 시간에 공유할 수 있었다.

👎🏻

기능과 페이지별 Man/day

처음부터 페이지와 기능에 대해서 세부적으로 MAN/DAY를 지정하지 않아서 아쉬웠다. 그래서 지정하기 전에는 모든 페이지를 기한에 맞춰서 구현될 수 있을까라는 불안감을 가지며 개발을 한 것 같다. 지금은 지정이 모두 된 상태이다.

수연

👍🏻 규칙 백로그

결론부터 말하자면 꽤 성공적이고 효율적인 협업 방식을 구축했다고 생각한다. 팀 규칙을 자세하게 짜놓았기도 했고, 혼자서 고민하지 않도록 공유하는 문화가 잘 자리잡은 덕이 크다고 생각한다. 효율적으로 회의를 진행하기 위해 슬랙 알람을 사용하고, 비동기적 커뮤니케이션을 적절히 활용했다.

스크럼과 스프린트, 백로그 등이 현재 팀원들이 어떻게 일정을 진행하고 있는지 아는 데 큰 몫을 했다. 특히 백로그 형태로 일정을 쉽게 관리하고, 계획을 세우기 좋았다. 다음 팀 프로젝트에서 기능 분배 방식은 달라질지도 모르지만, 탄탄한 규칙과 좋은 팀 문화를 만들었기 때문에 어떤 규칙을 덧대도 괜찮았다고 생각하기에 이 점만큼은 계속 이어나가고 싶다.

👎🏻 기능 설명 계획

개발 진행 사항을 세세히 알 수 없는 만큼 컴포넌트 설명서라는 우리 팀만의 문화를 잘 활용해주었으면 하는 마음이 있었는데, 참여율이 높지 않은 것 같아 아쉬웠다.

스프린트와 백로그를 조금 늦게 시작한 점도 아쉬웠다. 중간에 팀 규칙이야 얼마든지 추가될 수 있지만, 개발 계획을 처음부터 어느 정도 세우고 출발했다면 더 효율적일 수 있지 않았을까, 하고 생각한다.

창기

👍🏻 스크럼 칸반보드

우리 팀은 팀 프로젝트를 시작하기 전에도 데일리 스크럼을 하고 있었고, 다가온 팀 프로젝트는 정말 개발을 위한 스크럼 적용을 시도해보기 참 좋은 기회였다. 그래서 팀 프로젝트 스크럼을 위한 템플릿을 만들어 모든 팀원이 해당 템플릿에 그날에 개발할 것, 개발 현황, 어려운 점 등을 공유했다. 회의를 통해 해당 템플릿에 작성한 내용을 구두로 설명(부연 설명)하였으며, 덕분에 모든 팀원들이 개발을 진행함에 있어 숙지해야 할 부분을 숙지하고 개발을 시작할 수 있었다고 생각한다.

멘토님과의 커피챗을 통해 중간에 도입한 칸반 보드 또한 소통의 효율을 높일 수 있었다고 생각한다. 칸반 보드는 팀원들이 현재 개발을 시작한 Task, 리뷰를 기다리는 Task, 아직 시작하지 않은 Task를 카드 형식으로 한 눈에 파악할 수 있도록 돕는 좋은 도구였다고 생각한다.

👎🏻 백로그

여기서 백로그는 SW 개발의 전체적인 과정에 있어 현황을 파악하고, 진척 상황을 파악하고, Task에 대한 세부 사항 또한 파악할 수 있는 프로덕트 백로그(Product Backlog)인데, 우리 팀은 이 문서를 만들었으나 결국 활용하지 못했다. 문서 제작자는 필자였는데, 엑셀 형식의 딱딱한 디자인 때문이었던지, 이 문서를 도입해야하는 이유를 잘 설명하지 못했던지, 이 문서가 잘 활용되지 못한 책임은 필자에게 있다고 생각한다.

팀 단위 회고

팀에 대해 느꼈던 점을 서술해주세요.

---

민재

👍🏻 팀 분위기

개인이 맡은 업무를 책임감있게 개발하고 궁금한 점을 자유롭게 물어볼 수 있는 팀의 분위기가 좋았다. 모르는 것이 많았고 이런 것 까지 물어봐도 되나 싶은 질문도 친절하게 잘 알려줘서 고마운 마음이 많이 들었다. 또한 자신과 다른 관점이나 생각을 긍정적으로 수용하면서 더 좋은 결과물을 낼 수 있었다고 생각한다.

👎🏻 개인적인 아쉬움

팀 보다는 개인적인 아쉬움으로는 내가 맡은 페이지를 잘 구현할 수 있을까 못하면 팀에게 피해를 주지 않을까 하는 불안감에 급하게 개발만 했던 점이 아쉽다. 코드 품질과 팀에서 정한 컨벤션도 몇가지 놓친 부분이 있어서 개발하고 난 이후에 팀원들의 도움으로 컨벤션을 맞춰가게 되었다. 조금 더 여유를 가지고 코드의 구조와 재사용성을 생각해보면서 개발했으면 더 좋았을 거 같다.

혜성

👍🏻

내가 생각하는 우리 팀의 가장 큰 장점은 소통이 잘 된다는 점이다. 그 탁월함은 모두가 소통에 열려있는 자세였다는 곳에 있다. 모르는 것에 대해서는 적절한 질문을 통해 답변을 받거나 또는 함께 고민했고, 문제 사항에 대해서는 즉각적으로 인지 시켜주는 팀 문화가 자리 잡았던 것 같다. 그래서 프로젝를 진행하면서 소통 면에서는 답답함이나 어려움을 느낀 적이 없었다.

그리고 열심히 하는 팀에 속해서 좋았다.

👎🏻

우리 팀은 너무 착하다! 프로젝트를 진행하다 보면 분명 서로 마음에 들지 않는 부분도 있을 것이고, 코드 퀄리티 같은 기술적인 면, 또는 기술 선택에 있어서 논쟁적인 태도를 가져야 할 순간들이 있었을 것이다. 그런데 우리 팀은 너무 착했다! 조금 더 자신감을 가지고 각자 본인만의 의견을 적극적으로 피력하면 프로젝트에 자체에 대한 관심도도 올라가고, 우리가 만드는 것에 대한 당위성이 생기며 설득력도 생기지 않을까 생각한다. 정리하자면 조금 더 건방지고 나빠져도 좋을 것 같다.

나연

👍🏻

팀원 모두가 책임감을 가지고 자신이 맡은 기능에 대해 열심히 개발에 임했다. 비동기 소통을 할 때는 빠르게 답을 해주거나 반응을 해줘서 비동기임에도 불구하고 원할하게 소통을 할 수 있었다. 프로젝트 진행 중 문서 작업을 해야 할 일이 종종 있었는데 모두가 적극적으로 작성해주었다.

👎🏻

개발을 너무 빨리 시작했나 싶기도 하다. 개발 중 필수 기능이 추가되거나, UI 변경이 이루어지기도 했는데, 개발하기 전에 페이지마다 어떻게 구현할지 함께 정리하고 생각을 나누는 시간이 있었다면 놓친 부분이 없는지 체크가 가능했을 것 같고 학습적인 측면에서도 자신이 구현하는 페이지가 아니지만 같이 고민해봄으로써 배울 것들이 있었을 것 같다.

중간 중간에 규칙들이 정해질 때가 있었는데 개발 전에 규칙을 좀 더 세부적으로 정하지 못한 아쉬움이 있다.

수연

👍🏻 의견수용

개인이 지나치게 늘어지거나, 막중한 부담감을 갖는 일 없이 적절히 기능을 분배해서 프로젝트를 잘 진행하고 있다. 토론이 필요하면 토론을 하고, 자문을 구하고 싶은 경우 자유롭게 구한다. 이 과정에서 눈치를 본 적이 없다는 게 좋은 팀이라는 것을 증명해준다고 생각한다.

의견이 나오면 적극적으로 수용할 줄 알고, 또 필요할 땐 자신의 의견을 내세울 줄 아는 팀원들이다. 의사결정을 빠르게 내리기 때문에 프로젝트도 빠르게 진행되었다. 각자 맡은 일에 충실하면서도, 다른 사람들을 도와주는 것을 마다하지 않기 때문에 효율적인 작업이 가능한 팀이라고 생각한다.

👎🏻 기록

다들 개발을 너무 열심히 해서(…) 스크럼 시간 전에 스크럼에 관한 내용을 기록하는 일에 소홀해진 것 같다. 이에 따라 스크럼 시간이 길어지고, 얘기할 내용을 뒤늦게 찾는 경우도 있어서 개발하다가 어려운 상황을 만나면 기록해놓는 것을 습관화해주었으면 한다.

창기

👍🏻 팀 분위기

우리 팀은 분위기 하나는 정말 좋았던 것 같다. 공과 사가 분리되어 개발할 땐 개발에 집중, 사담을 나눌 때는 사담에 경청하는 그런 분위기를 필자는 매우 좋아했던 것 같다. 사담이 지나치면 분명히 문제로 작용하지만, 적당하다면 긍정적이고 적극적인 소통 분위기 형성에 크게 일조한다는 말을 꼭 하고 싶다. 너무 공적인 분위기에 개발과 관련된 이야기만 한다면 분명 소통의 명분 자체는 튼튼하겠지만, 소통의 총량 자체가 줄어들어 삭막한 분위기가 만들어졌을 것 같다고 생각한다.

개인 단위 회고

팀원에 대해 느꼈던 점을 서술해주세요.

---

민재

• 혜성 기능을 개발할 때 정해놓은 기능말고도 더 추가할 부분을 능동적으로 의견을 제시하고 기능이 단순히 작동한다는 것만으로는 만족하지 않고 코드품질과 컴포넌트 분리와 컨벤션을 신경쓰는 부분이 인상깊었다. 일단 작동하는 기능을 빠르게 만드려고 했던 나와는 다르게 생각이 깊고 프로젝트를 넓은 시야로 보는 부분을 배우고 싶다고 느꼈다.
• 나연 소통과 공유를 잘한다고 같다고 느꼈다. 배운 내용을 혼자 아는 것이 아닌 팀원과 적극적으로 공유함으로써 팀과 같이 성장하고자 하고 도와주고 싶어하는 마음이 느껴졌다. 궁금한 점이나 의견을 적극적으로 제시하고 PR리뷰도 적극적으로 하는 부분이 인상깊었다.
• 수연 팀원들이 편하게 사용할 수 있게 단순히 한 페이지만을 위한 컴포넌트가 아닌 여러 컴포넌트에서 사용할 수 있게 재사용 가능한 공통 컴포넌트를 만들어 주어서 개발 시간이 많이 단축되었다. 또한 개발외에도 디자인과 문서화를 굉장히 빠르면서도 완성도 있게 작성하는 것을 보고 많이 놀랐고 개발을 포함해서 여러가지를 다 잘하는 분이라고 느꼈다.
• 창기 팀장으로서 책임감도 있고 중압감도 있었을 것이라고 생각하는데 힘든내색하지 않고 잘 이끌어 주어서 고마운 마음이 든다. 팀원 한명한명에게 신경써준다는게 느껴졌고 팀장으로서 여러 업무들이 겹쳤을텐데도 자신이 맡은 개발업무도 성실히 하고 있는게 대단하다고 느껴진다.

혜성

• 민재 강남까지 왕복 10시간 거리를 오가면서도 한반도 피곤한 티를 낸다거나 프로젝트에 지장을 주지 않은 점이 감사하고 대단하다고 생각한다. 맡은 부분을 묵묵히 수행하고, 능동적으로 다음 할 일을 찾으려는 모습이 돋보였다.
• 혜성 (셀프리뷰) 잘 모르는 것 같은데 건방지게 이런 저런 의견을 과감하게 피력하는 모습이 대견했다. 멘토님과의 커피챗 시간을 백분 활용하기 위해 유의미하다고 느끼는 질문을 많이 했고, 노트북 앞에 엉덩이 붙이고 있는 시간이 참 긴 것 같다. 잘했다.

다만 귀찮은 일을 하지 않으려는 모습이 보인다. 하고 싶은 것만 하려는 경향이 있다. 그리고 비효율을 참 싫어하지만 나서서 근본적인 문제를 해결하기 보다는 소시민적 반항에 그치는 모습이 아쉽다.

• 나연 가장 소통이 잘 된다고 느끼고, 소통에 적극적이고 열려있는 자세를 가진 팀원 중 한명이었다. 자신이 아는 부분에 대해서는 잘 파악하고 있다고 느껴진다. 그리고 본인이 잘 모르는 것에 대해서는 혼자만의 궁금점으로 남겨두지 않고 질문하려고 하는 모습이 진정성있게 느껴졌다. 그리고 같이 다양한 의견을 적극적으로 말해줘서 고마웠다. 왜? 라는 근본적인 이유에 대한 궁금증을 꾸준히 가지는 것 같다!b 기술적인 부분에서도 배울 점이 많은 동료였다.
• 수연 우리 팀에서 가장 헌신적인 팀원 중 한명이었다! 노션 기록부터 디자인까지 귀찮고 고된 작업들을 불만 한번 표현하지 않고 웃는 모습으로 일관하며 묵묵히 수행한 점들이 멋있었다. PR리뷰를 정성스럽게 남겨준 모습도 인상깊었다. 특유의 꼼꼼한 성격 덕분에 안전벨트도 없이 악셀만 밟던 우리 팀에 안정성을 부여해 주었다고 느껴진다.
• 창기 팀장으로써 프로젝트 전반적인 일정에 대해 계속 고민하고 독려해 주었다. 팀원들의 의견을 적극적으로 수용해줘서 고마움을 많이 느낀다.

나연

• 민재

자신이 맡은 일을 정한 시간에 맞춰 수행한다. 하루에 자신이 구현할 수 있는 정도를 정확하게 알고 있는 것 같다. 또한 기능 구현을 제일 빠르게 하는 팀원이다. 구현하다가 생기는 고민이나 코드에 대해 더 적극적으로 의견을 내도 좋을 것 같다.

• 수연

문서화에 대한 중요성을 알게 해줬다. 개발만 잘하면 된다라는 생각을 깨부셔준다. 문서화를 잘 못하는 나에게 매우 자극이 되는 팀원이다. 또한 수연님이 가진 따뜻한 마음씨가 우리 팀 분위기를 평화롭게 해준다. 개발 또한 잘한다. 공통 컴포넌트를 개발할 때 확장성을 잘 고려해서 만들며 코드 컨벤션과 상수화를 적극 활용해서 클린 코드의 모범이 되고 있다. 코드 리뷰도 꼼꼼히 해주셔서 개발하다 놓치는 부분들을 잡아주신다

• 혜성

어떻게 구현해야 최적의 코드가 될지 끊임없이 고민하고 시도하는 것 같다. (특히 시도를 잘 하는 것 같다) 개발할 때 가장 중요한 왜? 라는 질문을 자주 하고, 고민들을 팀원들에게 공유해주어서 함께 해결하는 과정에서 많이 배우게 된다. 또, 이런 점은 학습에 있어서 팀원들에게 좋은 자극제가 되고 있다. 그리고 코드를 왜 이렇게 작성했는지에 대해 명확한 근거를 가지고 있다.

• 나연

가끔 질문을 무지성으로 할 때가 있다. 스스로 좀 더 생각을 해보고 찾아본 뒤에 질문을 해야겠다. 그리고 의견을 내세울 때 너무 차갑게 말해서 팀원들이 받아들일 때 불편했을까 좀 걱정이 된다. 조금 더 부드럽게 의견을 전달해야겠다. 문서화를 잘해야겠다(노션을 적극 활용하겠다)

• 창기

팀장으로서 솔선수범하고 있어서 팀장을 보며 나도 열심히 해야겠다는 생각이 든다. 팀원들을 위해 배려를 많이 하고 있는 것 같다. 팀장으로서 프로젝트 중 공식적으로 해야 할 일들에 대해서 빠르게 공유해주고 진행한다. 백로그와 같이 실제 사용하는 문서들을 공유하고 적극 활용할 수 있도록 도와준다.

수연

• 민재

  디자인을 UI 로 그대로 구현함에 있어 사소한 것 하나도 놓치지 않고 구현한 것이 인상깊었다. 세심하고 완벽함을 추구하는 것이 사용자 편의성을 늘리는데 중요한 요소라고 생각하지만, 실제로 디자인을 완벽하게 구현하기 위해 노력하는 사람은 별로 없다고 생각했는데 특유의 세심한 성격이 결과물에 그대로 드러난다.

• 혜성

  기술을 도입하고 적용해봄에 있어 거리낌이 없는 팀원이다. 자신이 해야할 일을 주도적으로 정하고, 팀 프로젝트에 쏟는 관심이 누구보다도 많다. 좋은 코드를 만들기 위해 끊임없이 노력하기 때문에 클린 코드에 대한 규칙을 세울 때 많은 도움이 되었다.

• 나연

  팀 규칙을 처음 정할 때 많은 도움을 준 팀원이고, 현재까지도 문제가 생기면 가장 빨리 공유해주는 팀원이다. 덕분에 팀 내에서 문제 공유를 원활하게 할 수 있었던 것 같다. 혜성님과 더불어 니르바나 라는 프로젝트에 많은 관심을 갖고, 좋은 프로젝트를 만들기 위해 어떻게 할 수 있을지 끊임없이 고민하는 팀원이다.

• 창기

  팀 프로젝트의 역할을 적극적으로 맡으려고 하는 팀원이다. 구현하기 번거로운 작업이라고 해도 본인이 먼저 나서서 역할을 도맡고는 한다. 팀장으로서의 책임감도 뛰어나고, 팀 내 분위기를 좋게 끌어올려주기 때문에 팀원들의 화합을 도모하는 데 많은 역할을 해주었다.

창기

• 수연 우리 팀의 디자이너, 우리 팀의 테크니컬 라이터, 우리 팀의 빛과 소금… 긍정적이고 활발한 소통이 일어나도록 항상 팀원의 관심사, 안부에 관한 화두를 던져 화기애애한 대화 분위기를 만든다. 개발 실력 또한 뛰어나서 필자에게 기술적인 도움을 주거나 했을 때 참 의지가 되는 팀원이구나…하고 생각했다.
• 민재 프로젝트에서 중요도가 매우 높은 사용자의 인증 / 인가 와 관련된 부분을 주로 개발하였고, 속한 개발 팀 내에서도 활발하고 적극적인 질의 / 리뷰 활동을 통해 빠른 개발을 이끌어내는 데 일조하고 있는 팀원이다. 스스로 idle하다고 생각하면 팀에 더 기여할 것이 없는지 생각하고, 찾아내어 기꺼이 Task를 수행한다.
• 혜성 우리 팀의 테크니컬 리더, 깨알 웃음 담당을 맡고 있는 팀원이라고 할 수 있다. 팀 프로젝트에서 활용되는 기술 스택에 대해 높은 이해를 갖고 있어 전반적인 개발 과정을 주도하며 많은 개발 Task들을 빠르게 수행하고 있다. 학술적인 궁금증도 갖고 있어 멘토님과의 커피챗 때 기술과 관련된 질의를 토대로 팀원들에게 새로운 기술적인 시각을 제공하기도 한다.
• 나연 우리 팀의 높은 능률을 만드는 다양한 컨벤션과 깔끔한 프로젝트 구조, 수연님과 더불어 활발하고 적극적인 소통 문화를 만드는 데 크게 기여하고, 프로젝트에서 활용하고 있는 Tech Stack에 대한 높은 이해를 기반으로 빠르게 여러 UI를 만들고, 다른 팀원에게 기술적인 조언도 아끼지 않으며 혜성님 못지 않은 높은 학술적인 관심 또한 갖고 있는 올라운더 팀원이라고 할 수 있다.