아웃소싱 프로젝트 KPT

 

재웅이연의 삼성 딜리버리 배달 앱 서비스 프로젝트

2024.12.03 ~ 2024.12.09

 

KPT 회고

회고를 바탕으로, 다음 스텝으로 나아가보자.

실제로 많은 회사들이 프로젝트가 종료될 때마다 회고를 진행하고, KPT회고 방법론을 아주 많이 적용한다.

공부한 것, 배운 것 보다는 "협업"을 하며 느낀 점, 앞으로 더 잘 하고 싶은 점과 관련된 이야기를 많이 나누자!

• KPT회고 방법 참고하기https://techblog.woowahan.com/2677/
• ttps://brunch.co.kr/@jinha0802/35

 

Keep - 현재 만족하고 있는 부분

• 모르는 부분에 대해 질문하고, 답변을 주고받으면서 문제를 해결 할 수 있었다. 그로인해 어려운 문제나 막히는 부분에 대해 도움을 주며 협력하는 분위기가 조성되어 좋았다.
• 의견을 조율하고 수용하는 속도가 빨라서 좋았다. 소통이 잘 된다고 느껴서 문제가 발생하였을 때 신속한 커뮤니케이션으로 해결할 수 있었다. 팀의 분위기가 딱딱하지 않고 편안한 분위기라 경직되지 않은 환경에서 프로젝트를 진행할 수 있고 질문을 하는 것도 편해서 좋았다.
• 역할 배분을 잘하여 개발 후에 모두의 코드가 합쳐지는 부분에서 깃 충돌이 나지않아서 개발하기 수월했습니다.
• 문제 해결 시, 다양한 각도에서 바라봄에 따라, 여러가지 해결방안이 제시되는 상황이 만족스러웠으며, 이에 따른 신속함 역시 만족스러웠다.

Problem - 불편하게 느끼는 부분

• 시작하기 전, 예상 시간을 개인적으로 설정했지만, 작업 과정에서 시간이 초과되면서 이후 예정된 작업들이 지연되었던게 아쉬웠다.
• 스스로 짠 코드를 다른 팀원들도 명확하게 이해할 수 있을 정도로 잘 알고 있어야 한다. “왜 이렇게 짠거죠?”하는 질문에 대답을 못해서 당황했던 적이 한두번이 아닌 것 같다. 네이밍이 통일되지 않고, 커밋 컨벤션이 일치하지 않아서 각자 개인 프로젝트를 하는 것처럼 정리가 잘 되지 않는 느낌이 들었다.
• 초기 계획을 더 자세하고 많이 준비했다면 개발 시간을 좀 더 단축하여 더많은 부분을 구현할 수 있지않았을까 하는 아쉬움이 있습니다.
• 설계 시, 도메인 별 교집합이 발생하는 곳일 미리 설계하고, 기본적인 패키지 구분과 같은 프로세스를 확실히 잡아간다면 더 나은 개발을 할 수 있을 듯 하다.

Try - Problem에 대한 해결책, 당장 실행 가능한 것

• 구현을 시작하기 전에 내가 구현해야할 부분을 명확히 정리하고, 전체적인 구조와 핵심 기능을 우선적으로 설계 및 구현한다. 그 이후 큰 틀을 완성한 후, 세부적인 사항은 단계별로 추가하며 작업을 진행한다. 또한 중간중간 팀원들에게 진행 상황을 공유하고, 피드백을 받아 모르는 부분은 즉시 논의하여 해결함으로써 작업 예정 시간을 준수할 수 있게 한다.
• 코드를 그렇게 짤 수 밖에 없던 이유를 기록해 놓거나 주석을 달아둔다. 오류가 발생한 부분에 대한 관련 테스트 코드를 추가하는 방법도 있다. 사소하게 주석을 다는 것과 네이밍(공통 메서드 포함), 커밋 컨벤션 모두 초기 세팅에 팀원과 상의해서 지정해 두고 나서 패키지와 클래스를 만들어둔 하나의 파일을 올려두고 각자 가져가서 시작하는 것이 중요하다.
• 초기 계획을 짤때 더많은 시간을 투자하여 탄탄하게 계획하는것이 중요할것 같습니다.
• 본인이 작성한 코드 및 의견에 적절한 근거를 제시하고, 이에 따른 나의 주장을 좀 더 명확히 표현한다면, 팀원들에게 쉽게 이해시킬 수 있을 듯 하다.

 

 

 

 

 

 

 

ＴＩＬ 12월 8일