[본캠프] - 팀 프로젝트 <태어난 김에 보스까지> KPT 회고

시행 일자 및 시간

2025년 1월 17일 12시 ~ 14시 30분

참여 인원

6인

주현진, 김동현, 최지한, 심홍기, 김건우, 김도훈

 

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

---

1. 프로젝트 진행 시 모든 인원이 참가해서 구현을 진행한 것
   • [주현진, 김동현, 심홍기, 김건우, 최지한]
   • 각 역할 분담을 통해 성공적으로 구현하여 책임감 성취
   • 다른 개발자들의 관점을 확인 할 수 있었다.
2. 프로젝트 목표를 정하고, 그에 맞게 구현을 진행한 점
   • [김동현,최지한]
   • 컨텐츠 업데이트를 고려한 개발 시 목표를 설정하여 개발 시간에 맞는 코드 확장성에 대한 고민(추가 기능)을 줄여줌
   • 제시받은 UML 클래스 다이어그램을 바탕으로 진행하여 방향성을 명확하게 파악할 수 있었다.
3. Git, Notion을 통한 자신의 계획 및 달성 목표를 기록한 점
   • [김동현,김건우]
   • 개발기간동안 매일 성취감을 얻을 수 있었다.
   • 협업 시 자신이 담당한 시퀀스를 이미지화를 통해 원활한 소통능력을 나타낼 수 있었다.
4. 개발 시 자신의 부족했던 부분을 협업을 통해 프로젝트의 완성도가 높아졌다.
   • [김도훈]
   • 협업 및 소통의 중요성을 다시한번 리마인드 할 수 있는 기회.
   • 다른 인원의 코드를 파악하며 코드리뷰 실력 향상 및 관점이 넓어졌다.
5. 방어코드 작성 및 메모리 관리
   • [김건우]
   • 예외발생시에 대한 방어코드 및 메모리관리를 철저하게 하여 프로그램 내적으로 완성도가 높았다.
   • 오류가 발생할 수 있는 부분에 대해 디버깅을 통한 참조메모리,값,콜스택을 확인하며 트러블 슈팅을 할 수 있는 방법에 대한 학습기회 제공

Problem - 불편하게 느끼는 부분

---

1. 추가 기능에 대한 욕심을 내지 않았던 것
   • [주현진]
2. PPT 제작 시 관점 오류
   • [주현진,김건우]
   • PM의 역할으로써 클라이언트에게 발표한다고 하는 경우 좋은 예시의 PPT
   • 이번 첫 프로젝트의 발표는 개발자들에게 발표하기 때문에 사용한 기술 및 예외처리 방법을 중점으로 해야했다.
3. 코드 리팩토링을 수행하지 않은 것
   • [주현진]
   • UML 클래스 다이어그램을 기반으로 만드는것을 목표로 하여 최대한 프로토타입에서 변형되지 않도록 프로젝트 제작
4. 기획 부분을 명확하게 하지 않은 것
   • [주현진]
5. 프로젝트 구조 설계를 명확하게 하지 않은 것
   • [주현진,김건우]
   • 소통을 통한 구조 설계를 명확하게 하지 않아 이번 프로젝트의 초기 목표였던 객체지향언어 원칙 및 특징이 흐려졌다 생각함
6. 프로젝트 진행 중 팀장님의 과도한 업무 부담
   • [심홍기, 김건우,최지한]
   • 시작은 팀 프로젝트였지만, 개인 프로젝트로 변경된 것 같은 느낌
   • 혼자서 너무 고생하시면서, 협업이 맞나 하는 의문감
   • 맡은 역할과 추가구현에 대한 역할 조금 더 분리하고 코드리뷰를 통한 가이드라인을 제시해 섬세한 역할 분담이 필요하다고 느낌
   • Branch 병합 단계에서 한분에게 너무 의존했다고 느낌
7. 소통의 부재로 인한 개발 실수
   • [심홍기,김도훈,김건우,최지한]
   • 서로 자신에게 소통하는게 아니면 개발에 집중해서 프로젝트 진행 과정에서 실수가 생겼다.
   • 계획 단계에서 소통이 부족하여 개발 시 의견이 취합되지 않았다.
8. 프로젝트 진행 중 오류,고민했던 부분을 문서화 하지 않은것
   • [김동현]
   • 리마인드를 위해 발생했던 오류들을 기록해두면 좋았다고 생각함
9. 최신화한 UML 클래스 다이어그램을 작성하지 않은 것
   • [김동현]
   • UML 클래스 다이어그램을 정확하게 이해하지 못해서 아쉬웠음
10. Commit 시 [Comment] 코드 컨벤션 사용하지 않음
    • [김건우]
    • 부재중 상태와 같이 즉각 대응을 하지 못할 때 해당 코드에 대한 의문점을 해결하지 못함
    • 다른 개발자들에게 해당 기술을 사용한 이유를 빠르게 설명 할 수 있음

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

---

1. 추가 기능에 대한 욕심을 내지 않았던 것
   • 소프트웨어 개발방법론을 적용하여 프로젝트 일정 관리, 추가적인 여유 개발시간을 가질 수 있게하기
   • 목표치를 완성했기에 Problem이라 생각하지 않는다. 모두의 역량을 파악한 상태가 아니었기에 Problem이 아니다.
   • 구현 방향이 목표치에 대한 완성도이며, 타 조는 콘텐츠 확장성이 목표치였다. 완성도(Quality)를 높였기 때문에 Problem이 아니다.
2. PPT 제작 시 관점 오류
   • 발표 자료의 청자를 고려하여 작성한다.
   • 클라이언트 : 게임 플레이, 개발 환경(호환성)
   • 개발자 : 사용한 기술 및 구현 코드 첨부, 개발 관점의 코드 첨부
3. 코드 리팩토링을 수행하지 않은 것
   • 구체적인 계획을 설계하기. (코드 리팩토링을 계획에 넣고, 수행하기)
4. 기획 부분을 명확하게 하지 않은 것
   • 설계 시 Chat Gpt와 같은 AI를 통한 검증해보기
   • 각자 맡은 영역을 시퀀스 다이어그램을 그려 이미지화 할 수 있게 하기
5. 프로젝트 구조 설계를 명확하게 하지 않은 것
   • 구조에 대한 검증을 진행하고, 타당하지 않으면 수정 할 것
   • 객체지향 언어의 특징을 반영한 구조를 작성할 것
6. 프로젝트 진행 중 팀장님의 과도한 업무 부담
   • 역할 분담을 조금 더 세분화하여 분배
   • 기획 시 구현해야 하는 부분에 대해 세부적으로 구상을 한 후 역할을 분배
7. 소통의 부재로 인한 개발 실수
   • Pull Request시 A가 작성한 코드를 B가 리뷰하고, B가 작성한 코드를 C가 리뷰하는 방식으로 진행
   • 구현을 담당한 사람과 리뷰어가 동시에 코드리뷰 진행
8. 프로젝트 진행 중 오류,고민했던 부분을 문서화 하지 않은것
   • 이슈 발생 시 바로 해결하는 것이 아닌 Notion과 Git Issue에 등록하여 문서화 하기
   • 이를 통해 동일한 오류 발생 시 빠른 해결을 할 수 있어 개발 속도를 높일 수 있다.
9. 최신화한 UML 클래스 다이어그램을 작성하지 않은 것
   • UML 수정이 필요하다고 판단 시 그에 대한 UML 최신화 및 공유
   • 의사소통을 통한 변경점 피드백 받기
10. Commit 시 [Comment] 코드 컨벤션 사용하지 않음
    • 개발 시 문서화 습관화 하기
    • 커밋 규칙을 구체적으로 정하기.

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

---

1. 프로젝트 진행 시 모든 인원이 참가해서 구현을 진행한 것
   • [주현진, 김동현, 심홍기, 김건우, 최지한]
   • 각 역할 분담을 통해 성공적으로 구현하여 책임감 성취
   • 다른 개발자들의 관점을 확인 할 수 있었다.
2. 프로젝트 목표를 정하고, 그에 맞게 구현을 진행한 점
   • [김동현,최지한]
   • 컨텐츠 업데이트를 고려한 개발 시 목표를 설정하여 개발 시간에 맞는 코드 확장성에 대한 고민(추가 기능)을 줄여줌
   • 제시받은 UML 클래스 다이어그램을 바탕으로 진행하여 방향성을 명확하게 파악할 수 있었다.
3. Git, Notion을 통한 자신의 계획 및 달성 목표를 기록한 점
   • [김동현,김건우]
   • 개발기간동안 매일 성취감을 얻을 수 있었다.
   • 협업 시 자신이 담당한 시퀀스를 이미지화를 통해 원활한 소통능력을 나타낼 수 있었다.
4. 개발 시 자신의 부족했던 부분을 협업을 통해 프로젝트의 완성도가 높아졌다.
   • [김도훈]
   • 협업 및 소통의 중요성을 다시한번 리마인드 할 수 있는 기회.
   • 다른 인원의 코드를 파악하며 코드리뷰 실력 향상 및 관점이 넓어졌다.
5. 방어코드 작성 및 메모리 관리
   • [김건우]
   • 예외발생시에 대한 방어코드 및 메모리관리를 철저하게 하여 프로그램 내적으로 완성도가 높았다.
   • 오류가 발생할 수 있는 부분에 대해 디버깅을 통한 참조메모리,값,콜스택을 확인하며 트러블 슈팅을 할 수 있는 방법에 대한 학습기회 제공

Problem - 불편하게 느끼는 부분

---

1. 추가 기능에 대한 욕심을 내지 않았던 것
   • [주현진]
2. PPT 제작 시 관점 오류
   • [주현진,김건우]
   • PM의 역할으로써 클라이언트에게 발표한다고 하는 경우 좋은 예시의 PPT
   • 이번 첫 프로젝트의 발표는 개발자들에게 발표하기 때문에 사용한 기술 및 예외처리 방법을 중점으로 해야했다.
3. 코드 리팩토링을 수행하지 않은 것
   • [주현진]
   • UML 클래스 다이어그램을 기반으로 만드는것을 목표로 하여 최대한 프로토타입에서 변형되지 않도록 프로젝트 제작
4. 기획 부분을 명확하게 하지 않은 것
   • [주현진]
5. 프로젝트 구조 설계를 명확하게 하지 않은 것
   • [주현진,김건우]
   • 소통을 통한 구조 설계를 명확하게 하지 않아 이번 프로젝트의 초기 목표였던 객체지향언어 원칙 및 특징이 흐려졌다 생각함
6. 프로젝트 진행 중 팀장님의 과도한 업무 부담
   • [심홍기, 김건우,최지한]
   • 시작은 팀 프로젝트였지만, 개인 프로젝트로 변경된 것 같은 느낌
   • 혼자서 너무 고생하시면서, 협업이 맞나 하는 의문감
   • 맡은 역할과 추가구현에 대한 역할 조금 더 분리하고 코드리뷰를 통한 가이드라인을 제시해 섬세한 역할 분담이 필요하다고 느낌
   • Branch 병합 단계에서 한분에게 너무 의존했다고 느낌
7. 소통의 부재로 인한 개발 실수
   • [심홍기,김도훈,김건우,최지한]
   • 서로 자신에게 소통하는게 아니면 개발에 집중해서 프로젝트 진행 과정에서 실수가 생겼다.
   • 계획 단계에서 소통이 부족하여 개발 시 의견이 취합되지 않았다.
8. 프로젝트 진행 중 오류,고민했던 부분을 문서화 하지 않은것
   • [김동현]
   • 리마인드를 위해 발생했던 오류들을 기록해두면 좋았다고 생각함
9. 최신화한 UML 클래스 다이어그램을 작성하지 않은 것
   • [김동현]
   • UML 클래스 다이어그램을 정확하게 이해하지 못해서 아쉬웠음
10. Commit 시 [Comment] 코드 컨벤션 사용하지 않음
    • [김건우]
    • 부재중 상태와 같이 즉각 대응을 하지 못할 때 해당 코드에 대한 의문점을 해결하지 못함
    • 다른 개발자들에게 해당 기술을 사용한 이유를 빠르게 설명 할 수 있음

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

---

1. 추가 기능에 대한 욕심을 내지 않았던 것
   • 소프트웨어 개발방법론을 적용하여 프로젝트 일정 관리, 추가적인 여유 개발시간을 가질 수 있게하기
   • 목표치를 완성했기에 Problem이라 생각하지 않는다. 모두의 역량을 파악한 상태가 아니었기에 Problem이 아니다.
   • 구현 방향이 목표치에 대한 완성도이며, 타 조는 콘텐츠 확장성이 목표치였다. 완성도(Quality)를 높였기 때문에 Problem이 아니다.
2. PPT 제작 시 관점 오류
   • 발표 자료의 청자를 고려하여 작성한다.
   • 클라이언트 : 게임 플레이, 개발 환경(호환성)
   • 개발자 : 사용한 기술 및 구현 코드 첨부, 개발 관점의 코드 첨부
3. 코드 리팩토링을 수행하지 않은 것
   • 구체적인 계획을 설계하기. (코드 리팩토링을 계획에 넣고, 수행하기)
4. 기획 부분을 명확하게 하지 않은 것
   • 설계 시 Chat Gpt와 같은 AI를 통한 검증해보기
   • 각자 맡은 영역을 시퀀스 다이어그램을 그려 이미지화 할 수 있게 하기
5. 프로젝트 구조 설계를 명확하게 하지 않은 것
   • 구조에 대한 검증을 진행하고, 타당하지 않으면 수정 할 것
   • 객체지향 언어의 특징을 반영한 구조를 작성할 것
6. 프로젝트 진행 중 팀장님의 과도한 업무 부담
   • 역할 분담을 조금 더 세분화하여 분배
   • 기획 시 구현해야 하는 부분에 대해 세부적으로 구상을 한 후 역할을 분배
7. 소통의 부재로 인한 개발 실수
   • Pull Request시 A가 작성한 코드를 B가 리뷰하고, B가 작성한 코드를 C가 리뷰하는 방식으로 진행
   • 구현을 담당한 사람과 리뷰어가 동시에 코드리뷰 진행
8. 프로젝트 진행 중 오류,고민했던 부분을 문서화 하지 않은것
   • 이슈 발생 시 바로 해결하는 것이 아닌 Notion과 Git Issue에 등록하여 문서화 하기
   • 이를 통해 동일한 오류 발생 시 빠른 해결을 할 수 있어 개발 속도를 높일 수 있다.
9. 최신화한 UML 클래스 다이어그램을 작성하지 않은 것
   • UML 수정이 필요하다고 판단 시 그에 대한 UML 최신화 및 공유
   • 의사소통을 통한 변경점 피드백 받기
10. Commit 시 [Comment] 코드 컨벤션 사용하지 않음
    • 개발 시 문서화 습관화 하기
    • 커밋 규칙을 구체적으로 정하기.