중간 KPT회고

공통

문서화 및 소통 관련 Try 정리

• 여러군데 혼재되어 있는 정보를 “유저스토리” 를 중심으로 일원화 및 최신화 한다. 채택

• 회의록과 이슈리포트를 FE/BE 통합하여 사용한다. 채택

• 1위계에 해당하는 자료는 접근성을 높이기 위해, 홈의 최상단 영역으로 이동한다. 채택

• 회의가 진행된 이후, 담당자를 선정하여, 해당 회의에서의 결정 내용을 ‘유저스토리, 서비스Q&A, API명세서 ,… 등의 문서’에 Update 하도록 한다.채택

• 통합 회의를 진행할 때에는 ‘젠허브’ 칸반을 다 같이 공유하며 현재 진행상황을 점검한다.채택

• 누군가 의견을 제시할 때, 관대한 찬성보다는 확실한 도입 메리트가 보장되어있는지 제안 단계에서 검토하고 의견을 나누자 채택

• 알림기능과 확인여부를 명확히 할 수 있는 슬랙 사용을 활성화 하자 채택
• notion Comment 보다는 슬랙쓰레드 토의
• 작성된 문서에 대한 피드백이 필요할 때에는, 해당 팀원을 지정하여 슬랙에 공유한다. 채택

• 개인 DM 보다는 팀 슬랙을 적극적으로 활용하여, 해당 이슈에 대한 소통이 퍼지도록 하자 채택

문서화

• 결정된 사항은 가능한 한 문서화하려고 애썼음

• 주요 사항에 대해 쉽게 접근하기 위해 문서 정리에 애썼음

• 젠허브 좋았습니다.
• why? github의 이슈들이 실제 업무와 연동되는 감각이 없었는데 , 젠허브의 깔끔한 인터페이스로 확실하게 파악할 수 있었습니다. 원래 ,github issue를 잘 사용하지 않았는데, 덕분에 어떤 방식으로 사람들이 github를 통해 협업하는지 알 수 있었습니다. 감사합니다x100

• 유저 스토리 정리된 것이 요구사항 파악에 도움 많이 됐습니다.

• 문서화 기반 소통 부족
• 문서에 근거하는 버릇을 들였으면 좋겠음
• 이를 위해선, 문서화 된 것은 다들 알고 있다는 믿음/행동이 필요 but 부족
• 문서화 기반 소통을 온전히 할 수 있는 환경인지 생각해보아야 함
• 시간이 촉박한 상황에서 단기적 변화는 어려울 수 있다.

• 노션 페이지 관리를 맡아서 했는데, 문제를 많이 느껴 여러 개선 방법을 시도했으나, 팀의 전반적인 생산성 향상에 미치기까지 부족했다는 생각.
• 서비스 Q&A, 화이트보드, ..
• 확실한 사용방법, 사용효과에 대한 충분한 설득 없이, 제안정도에 그쳤다.
• try 서비스 Q&A 결과 > 유저스토리 반영 하는 프로세스
• try 좋다는 게 확실하다면, 팀 전체적으로 활용할 수 있도록 리마인더 제공하기

• 문서를 읽고 있는가?
• 문서화가 진행되어도 제대로 읽지 않는 경우가 종종 있었음
• 기록은 많이 하지만, 다시 보지 않는다. 중요한 것만 최소한으로 기록한다면, 과연 자주 보게될까?
try ”꼭 읽어야만 하는 사용자”를 “문서 작성자”가 지정하고, 슬랙에 공유한다.
try 노션은 알림 용도로 부족하기 때문에, 슬랙을 통한 적극적인 소통하자.
• 알림에 대한 기능이 명확하고, 슬랙은 읽은 여부를 체크 가능하다.

• 문서화에 대한 룰 미비
• 어떤 문서를 어떤 목적을 위해 누가 적을 것인가에 대한 명확한 기준이 없었다.
• 노션을 동기적 소통의 용도 보다는, 결과를 기록하고 남기는 용도로 사용하자
• 회의록 제목에 날짜만 명시되어 있어서 어떤 회의내용이었는지 잘 기억이 나질 않아 모든 회의록을 뒤지면서 정보를 찾아야 했음
• try 회의를 통해 회의록이 작성되면 담당자를 지정하여, 해당 내용을 필요한 문서에 update하도록 한다.
• 협업 툴 / 공유 방식 등에 관하여 팀 전체의 alignment가 제대로 이루어지고 있지 않음
• 특정 기술 / 방식을 제안하는 경우,
• 당연히 제안자가 더 고생하고
• 더 설득해야 하는 것은 맞음
• 하지만 팀의 협업 방식이 정해졌다면, 그 방식을 제안하지 않았더라도 거기에 맞춰 가려는 책임을 져야 함
• 예시 문서를 읽었다면 소통을 하자(Tree)에 동의하지 않을 수 있고, 내 방식이 아닐 수 있음
• 하지만 회의에서 그게 결정되었다면 그 규칙을 지키는 것이 맞음: 지정된 규칙 / 기록을 준수해야 함
• 만일 애초에 지키기 어렵거나 결코 동의할 수 없는 방식이라면 적극적으로 반대했어야 함: 반대 의견을 제시하는 데 주저하지 않았으면 좋겠음
• try 의견을 누군가 제시할 때, 예상되는 의문이나 복잡도, 현재상황에서 지킬 수 있는지 등에 대한 모두의 검토 및 의견 제시하기

• 문서화 및 소통 관련 Try 정리

소통

• 필요하다면 오프라인에서 따로 만나서 작업을 하여 빠르게 피드백을 하며 수정할 수 있어서 좋았음

• 오프라인에서 작업을 진행한 날에는, 여러 사람이 자연스럽게 해당 문제에 대해 논의를 나눌 수 있어서
• 미처 생각하지 못한 포인트를 찾아낼 수 있었음
• 문제 상황에 대한 소통이 민첩하게 진행되었음

• 팀장끼리 의논하거나, 각 도메인 담당자들끼리 자체적으로 의논하는 식으로 소통을 진행해서 인원이 많음에도 큰 혼란이 이루어지지 않음

• 명확하게 책임이 할당되지 않았음에도, 스스로 나서서 책임을 지고 활동하시는 분들 덕분에 시간을 많이 절약한 것 같습니다.

• 날카로운 사람이 없어서, 솔직한 소통을 주고 받는데 어려움이 없었다.

• 혼자서 끙끙 싸매지 않고 적극적으로 소통하려고 한 것이 좋았습니다

• 소통/기록 방식에 대해서 의견을 묻거나, 주지 않아서, 현재 방식이 적합한건지, 그냥 참고 쓰는지? 이런 부분들을 알지 못했다.

• 개발할 때 백과 프론트 통합으로 테스트 할 때 로컬에서 테스트하는데 문제를 겪음

• 젠허브 에픽에 중복된 내용이 프론트,백이 나뉘어져서 에픽이 너무 많아보였음
• 해결방법 찾아봐야함

• 젠허브를 통한 ‘소통의 효율’ 얼마나 있었나 하는 의문
• try 통합회의 시, 젠허브 화면을 같이 보며 공통 스크림 실시

• 각각 개발하고 나중에 맞춰보는 방식에서, 서로 개발 방향이 달라 수정해야 할 부분이 많았음
• 작업 시 초기 설계 없이, 각자 진행 후 중간에 맞추어보았던 부분
• try 주기적으로 서로의 진행상황 공유하기

• 명확한 요구사항 전달이 제대로 되지 않는 듯한 문제가 생기는 것 같음. 이 때문에 지속적으로 여러번 소통 비용이 생김.

• 프론트, 백엔드 팀장의 역할이 모호 한 듯함. 사실상 현재는 기술적인 측면이나 관련된 소통이 각 담당자간 사이에만 공유되고 있어 팀장 선출의 의의가 떨어짐(딱히 필요 없을 수도? 라는 생각이 들음)
• 역할과 책임에 대한 부분, 공통 작업의 우선순위가 밀리고 책임이 없어지는 문제
• try 월요일에 팀장 및 역할/책임에 대한 미팅 (확실히 정하고 지켜야할 필요가 있음)
• 책임에 관하여
• 언제까지 해결해야 하는 문제 등이 있을 때 그 책임이 명확하게 부여되었으면 좋겠음
• 모두가 책임질 수 있는 상황이라, 모두가 뒤로 미루게 됨
• 다들 자기 일이 바쁘기 때문에 공통 영역에 대한 책임이 방치된다는 느낌임
• 이슈 / 현재 작업에 대한 기록 부족
• 현재 맡은 도메인에 대한 작업 기록/이슈를 남겨야, 다른 도메인 담당자도 해당 문서를 보고, 이해하고, 리뷰하고, 다음 작업을 구상하는데 도움이 될 듯하다.
• 이슈 문서화에 대한 활용도 (현재 주로 디코, 슬랙, 오프라인 만남을 통해 해결하는 케이스가 많음)

• 슬랙 활용도가 낮은 것 같음 ✅

• 다른 사람의 일정을 신경쓰느라, 방해하지 않고 싶어 질문이나 도움을 구하는 것에 대해서 주저하는 분위기?
• try 도메인 별 소통을 DM보다, 공통 팀 슬랙에서 진행해보자.
• try 가벼운 소통 늘리고, 관심 갖고 , 이야기도 하고, ,..

• pray - 백이 먼저 프론트가 먼저?
• 개발 방식으로 두 가지를 생각해 볼 수 있음
1. 백엔드가 먼저 api를 개발하고 프론트가 가져다 쓰는 방식 (graphQL) ✅
2. 프론트가 먼저 대략적인 화면 디자인 후, 필요한 데이터를 백엔드에게 요청하는 방식 (BFF)
• 개발 방식을 명확하게 지정하지 않으면 다음과 같은 일이 발생할 수 있음
• 백엔드는 프론트의 데이터 요구사항이 올때까지 개발을 진행하지 않고, 프론트는 백엔드가 api 를 만들기 전까지 개발을 진행하지 않는 상황
• try 젠허브를 통해 프론트 진행상황을 보며 백엔드에서 먼저 다음작업에 대한 API를 개발하고, 추후 맞추어본다.

• 문서화 및 소통 관련 Try 정리

프론트

• 8/8월 진행예정

• 최소 한 명의 approve가 있어야 merge 가능
• 소홀해질 수 있는 코드 리뷰를 의무화 함과 동시에 팀원과의 소통이 활발할 수 있었다.

• rebase merge 사용

• 커진 PR 단위
• 한 사람이 맡은 이슈의 크기가 커지면서 PR의 단위가 커졌다.
• PR의 단위가 커지면서 코드 리뷰에 소요되는 시간과 노력이 많아졌다.

• PR 단위를 더 작게 쪼개도록 시도해보자.

• 팀원이 리뷰하기 쉽게 잘 정리된 PR 설명을 작성해보자.

백엔드

Git PR 전략

• 적당한 PR 크기
• 이전 프로젝트 회고에서  큰 PR 단위로 코드 리뷰가 어렵다는 의견이 다수였는데, 이번에는 팀원들 모두 PR 크기가 적당해 리뷰하기 쉬웠다고 느낌
• 이슈별로 PR이 나누어지짐 → 명확한 PR 기준이 생긴 것 같아 좋았습니다

• 커밋 네이밍
• 어떤 작업에 대한 커밋인지 명확하게 알기 어려움

• Squash vs Rebase
• develop 브랜치는 rebase를 사용, release 브랜치는 squash 사용.
• rebase를 사용하는 과정에서 가끔 몇몇 commit들이 누락되는 문제
• develop 브랜치 커밋 가독성 문제. 어떤 피처에

• 브랜치 관리에 대해 한번 더 신경쓰기. 만약 계속 같은 문제가 발생한다면 squash로 통일

• 현재 develop 브랜치가 rebase가 잘 되지 않는 것 같아서 squash로 가야 할 것 같습니다.

개발 진행 과정

• 트러블 슈팅, 공통 사용 모듈에 대한 문서화
• 프로젝트를 진행하면서 각자 발생했던 문제에 대해 문서화가 잘 되었음
• 공통으로 사용되는 모듈 개발을 담당한 개발자가 문서화를 통해 해당 모듈의 사용법을 공유했음

• 작업 사이의 Blocking. 선행 작업이 완료되지 않으면 다른 작업자가 작업을 진행 못하는 상황이 발생
• 작업을 진행 못하는 개발자는 스스로 할일을 찾아야했음

• 개발 초기부터 시큐리티 dependency가 추가됨에 따라, 보안 관련 작업이 마무리되지 않으면 다른 작업을 진행할 수 없었음

• 작업 단위를 세분화하자
• 꼭 필요한 선행작업들의 우선순위를 생각하여 세분화 하고 역할을 분담하여 최대한 빠르게 개발을 완료합시다.

• 시큐리티 의존성을 개발 초기부터 추가하지 말고, 초반에는 간단한 방식(ex. Interceptor에 간단하게 구현하는 인증 로직을 도입)을 이용하다가 나중에 추가하자

Spring Profile

• github secret을 활용해서 비밀 관리를 클라우드에 의존하지 않게 된 것은 좋게 생각합니다.

• OAuth까지 들어가면서 관리가 복잡해졌습니다. security 전용 yml을 .gitignore하고 저번처럼 슬랙으로 공유하려는데, 좀 더 세련된 방법이 없을까요?

PR 커뮤니케이션 방식

• PR을 짧게 가져가서 리뷰를 적극적으로 할 수 있는 환경을 마련할 수 있어서 좋았습니다.

• 저번 프로젝트보다 PR 리뷰를 많이 할 수 있어서 좋았습니다

• 어디까지가 정상적으로 작동되고, 어디까지가 구현되지 못한 것인지 인지하지 못해서, 코드를 제대로 평가할 수 없는 상황이 있었습니다.

• PR 내용에서 기능이 어디까지 작동되어야 정상인지 간략하게 요약해주시면 편할 것 같습니다. 물론 나중에 테스트 코드 작성되기 시작하면 크게 문제될 것 없을 듯 합니다.

KPT 회고 참고 자료