3일차 아티클
학습관리 매니저님이 정성들여 써주시는 아티클을 읽고 배운 점과 느낀 점을 정리해 보았다.
개발 팀 문화
티플 서비스 기획자 최윤아 님의 글 - 사이드 프로젝트 운영하는 법
R&R (Roles And Responsibilities)
서로의 R&R에 대해 인지하는 것이 중요하다.
이 부분에 대해서는 누구한테 물어봐야 하지? 라는 고민을 할 시간을 줄여 더 효율적으로 협업할 수 있게 된다.
커뮤니케이션 룰 - 시간 관리
활성화 시간과 비활성화 시간
팀원들과 협의 하에 일과시간을 만들고, 활성화시간내에 모인 인원끼리 소통하여 논의를 마무리하고, 비활성화시간에는 의견을 수용하지 않는다.
활성화 시간을 조정하면서 일부 팀원의 참여 여부와 상관 없이 더 빠른 결정을 내릴 수 있다.
아무도 일하지 않는 날
더 좋은 생산성을 위해서는 더 좋은 휴식도 있어야 한다.
이 말에 정말 큰 공감을 했다.
이전의 프로젝트 경험들을 돌아보면, 최선을 다해 좋은 결과를 가지려던 마음에 모두의 능력을 한계까지 이끌어내서 비효율적으로 작업을 했던것 같다.
팀원이 개인적인 일정으로 참여하지 못하게 되는것에 서로 미안함을 느끼고, 끼니를 거르고, 졸음을 참으며 문제 해결을 위해 고민과 시도를 반복하다가 결국 컨디션이 좋지 못한 상태로 다시 또 개발을 하다 실수를 하는 이어지는 일이 빈번했다.
번아웃에 빠지게 된것은 어쩌면 당연할 수 있겠다고 생각되었다. 이전의 나는 이게 최선을 다하는 것이라고 생각했다.
팀의 의사결정
완벽 추구 vs 빠른 실패
혼자 고민하기 vs 동료의 일도 같이 고민하기
각자의 소통 밝히지 않기 vs 소통 내용 투명히 밝히기프로젝트를 이어나가며
- 지켜져서 좋은 것
- 지켜지지 않지만 노력해야 하는 것
- 필요 없는 룰
세가지를 소통해나가며 규칙을 조정한다.
캠프 이전 팀플에서 처음으로 데일리 스크럼을 하며 하루의 Good & Bad를 나누어 평가해본 것과 비슷한것 같다.
그러나 팀원 모두 빠른 퇴근(?)을 바라기도 했고, 당장 구현해야 할 기능에 압박을 느끼며 그리 팀플에서 중점을 두고 이뤄지진 않았던 것 같아 아쉬운 경험이다.
어떻게 하면 이러한 구현 압박에 대해 여유를 가질 수 있을까?
이에 대한 답은 역시 최대한 많은 경험을 하고 학습을 하는것이란 생각밖에는 들지 않는다. 더 열심히 하자!
더 나은 회의 방식
스레드
팀 전체가 참여하지 않는 부분, 예를 들어 디자이너와 개발자가 앱 내 컴포넌트 배치에 대해서 이야기를 할 때 마케터나 PM은 참여할 수 없다.
이러한 구체적인 주제를 따로 떼어내서, 댓글 형태로 이어가는 집중 대화 공간인 스레드를 따로 만든다.
회의에서는 프로덕트 전체와 팀 목표에 집중할 수 있고, 관련자만 비동기적으로 깊게 논의하고 기록이 남아 나중에 다시 보거나 다른 사람이 참여하게 됐을 때도 용이하다.
자신의 업무가 아니라도 존중하고 배우기
회의가 끝나기 전 각자 분야에 대해 셰어 스피치를 한다.
각자의 시각으로 다른 팀원이 고민하고 있는 것에 도움을 줄 수도 있고, 각자의 업무를 더 자세히 알게되어 팀 결속력과 프로덕트의 이해를 높일 수 있게 된다.
그라운드 룰 정하기
다시 학습 매니저님의 글로 돌아와, 앞으로 하게 될 팀 프로젝트 주차를 대비한 새로운 마음가짐을 가지기로 한다.
이제부턴 정말 각자 살아온 삶, 스타일, 개발 방식이 다 다른 처음 만나는 사람과 진행해야 한다.
이전까지는 비교적 같은 교육과정을 겪어오며 어느정도 키워드 등이 통일된 팀원들과 의사소통을 해왔다.
그러나 이번 스파르타 교육과정에서는 이미 한 번씩 개발과 프로젝트를 경험하고 온 사람들이다.
그렇기에, 각자 스타일을 하나의 원칙으로 합의를 보는 이른바 "그라운드 룰"을 정하는 것이 더욱 중요해졌다.
그라운드 룰
소통방식
슬랙 / 디스코드 등 연락 수단, 연락 확인 시간 회의 시간과 방식
데일리 스크럼
주간 회의
회의 방식
회의록 작성 방식역할 분담과 일정 관리
누가 어떤 기능을 맡을 건지 명확하게 정하기
예상 완료 시점 공유하기팀 컨벤션
네이밍 컨벤션
카멜 / 스네이크 / 케밥
변수와 함수
클래스
상수코드 스타일
들여쓰기 간격/ 탭 사용
중괄호 같은 줄 / 다른 줄InteliJ의 코드 스타일 설정 공유하거나 Checkstyle 도구를 사용할 수 있다.
패키지 구조
컨트롤러, 서비스, 유틸함수 등의 위치코드 컨벤션
네이밍과 포맷팅보다 넓은 범위의 규칙이다.
컨트롤러 응답 반환 : ResponseEntity vs Dto vs 그외 커스텀 응답 객체
API 응딥 형식 : 성공응답, 에러 응답 형태
예외 처리 응답 방식 : HTTP코드, 커스텀 예외 클래스
예외 처리 적용 방식 : try-catch vs @ControllerAdvice
DTO 변환 위치 : 컨트롤러 vs 서비스
...Git 컨벤션
브랜치 전략
main ────────────────●───────────────●
↘ ↑ ↑
develop ───●───●───●───────┘
↑ ↑ ↑
feature feature feature
/login /pay /profile
- 각자 기능을 개발할 때는
develop에서feature브랜치를 만들어서 작업 - 작업이 끝나면
develop으로 PR을 올리고, 팀원의 리뷰를 받은 후에 머지 - 스프린트가 끝나거나 배포할 때
develop을main으로 머지
캠프 이전에는 주먹구구로 브랜치 전략을 짜서 main 브랜치 위에서 기능별로 구현하고 main으로 머지하면 바로 CI/CD 플로우로 배포가 되는 형식이었다.
아마 실제 서비스였다면 장애가 많이 일어났을 것이다.
develop 브랜치의 존재 하나로 이를 예방할 수 있게 된다는 것을 알게되었다.
커밋 메시지
Conventional Commits :
<type>: <subject>
feat: 로그인 기능 추가
fix: 회원가입 시 이메일 유효성 검사 오류 수정
refactor: 유저 서비스 로직 분리
docs: README에 설치 방법 추가
chore: ESLint 설정 변경기능 구현의 흐름과 버그가 발생하게 된 커밋을 찾기 쉬워진다.
PR 템플릿
## 작업 내용
- 로그인 API 구현
- JWT 토큰 발급 로직 추가
## 테스트 방법
1. POST /api/auth/login 호출
2. 응답으로 accessToken 확인
## 관련 이슈
- #12과거 PR 내용중에 "정말 좋은 코드네요! 굿굿굿👍"이런 식으로 작성했던 때를 반성하게 된다..😅
코드 리뷰
코드 리뷰를 할 때 - 비난이 아니라 제안의 형태로 피드백을 주기
피드백을 받았을 때 - 방어적으로 반응하지 말고, 왜 그런 피드백을 줬는지 이해하려고 노력하기사실 이 부분은 자신있다!
예전부터 프로젝트를 진행하면서 개발보드나 코드를 캡처해 공유하며 문제해결 방법을 의논하는 것이 기능 구현보다 즐거웠다.
적어두고 보니 컨벤션으로 정할 것이 정말 많다. 솔직히 말해 이런것들을 정하는 시간이 일주일정도는 필요하지 않나? 생각이 들 정도로 많다.
매니저님은 처음부터 모두 정할 필요는 없고 진행하면서 논의하고 정해도 좋고, 정한 내용을 문서로 남기는 것이 중요하다고 하셨다.
글을 쓰면서 갑자기 든 생각인데, 팀원 각자의 github 주소를 올리면 여태까지 써왔던 코드 스타일을 보고 팀 컨벤션 문서를 작성해주는 서비스가 있으면 어떨까?
트러블 관리
좋은 개발자는 참지 않아
참다보면 언젠간 터지게 되어있고, 감정은 코드에도 묻어나며 리뷰가 줄어들고 소통이 줄어들게 된다.
이 부분이 조금 불편했는데, 이렇게 하면 어떨까요?
상대방을 비난하지 말고 해결책을 통해 상황을 개선하자는 방향으로 이야기하기
팀원의 실수에 관대해지기
우린 모두 사람이니까 모두 실수할 수 있다.
실수 자체보다 그 이후의 대응이 중요하다.
예전 팀플을 생각해보면 트러블에 대해 팀원들도, 나도 참기만 했던 것 같다.
실수에 대해서 감정적으로 여기지 않고, 묵묵히 서로 해결방안을 찾기만 했다. 그러다 결국 프로젝트가 끝난 후에 팀원들의 감정이 폭발하며 한 명을 몰아세우기도 했었다.
지 않은 것 같아 미안하다. 참지 않고 해결책을 이야기했다면 그 사람의 태도가 조금은 바꼈을 것이고 다른 방식의 노력으로 팀에 도움을 줄 수 있었을 것이란 아쉬운 마음이 든다.
이를 교훈으로 삼아 앞으로의 협업은 더 잘하고싶다.
