내일배움캠프 5일차. KPT 회고

Keep + problem 작성 5분

Keep은 현재 만족하고 있는 부분(Good), 계속해서 이어갔으면 하는 부분(Keep)을 자유롭게 작성한다. Problem은 불편(or 불만)하게 느끼는 부분, 개선이 필요하다고 생각되는 부분, 잠재적인 문제를 작성한다. 진행자 본인도 해당 시간 동안 똑같이 작성한다. (타임 타이머는 누구라도 고개를 들면 확인할 수 있도록 하는게 중요하다)

Keep

김노을

• 공부 기간이 짧았음에도 다들 빠른 성장을 한 것 같다.원활한 소통, 배려
• 맡은 역할에 대한 책임감.
• 새로운 컨텐츠의 수용
• 본인의 기술에 대한 연구
• 감정적이지 않은 피드백
• 개인간 꾸준한 구글링
• 황민도처음 하는 만큼 코딩을 어려워하는 부분에 대해 서로 이해와 배려를 잘함
• 서로의 의견과 질문을 소홀이 생각하지 않고 같이 고민함
• 소통, 질문, 검색을 다양한 경로와 질문 방식을 변경해가며 서로에게 공유 

황민도

• 소통, 질문, 검색을 다양한 경로와 질문 방식을 변경해가며 서로에게 공유
• 처음 하는 만큼 코딩을 어려워하는 부분에 대해 서로 이해와 배려를 잘함
• 서로의 의견과 질문을 소홀이 생각하지 않고 같이 고민함

 이준성

• 팀원들의 도움으로 혼자서는 구현하기 어려운 코드들을 완성할 수 있었다.(GOOD)
• 각자 맡은 분야를 소홀히 하지 않는다.(GOOD)
• 미래에 다른 팀원을 만나도 함께 도와가며 작업을 하는 것.(KEEP)

전수원

• 각자의 역할 분담
• 주기적인 회의
• 질문과 응답

이주언

• 팀프로젝트 진행에 있어서 서로서로 코드리뷰가 잘 되었다고 생각함.
• 각자가 짠 로직을 설명하고 서로 이해하는 과정이 좋았음.
• 그래서 단기간에 성장할 수 있었다고 생각함.
• 막히는 부분이 있다면 적극적으로 공유해서 해결하려고 하는 팀워크가 좋았음
• 모두가 하차하지 않고 완주해서 뿌듯함

Problem

김노을

• 개발 규칙의 부재 (변수명, 주석 달기 등)
• 전반적인 개발 지식 및 깃허브 사용 능력 부족

황민도

• 해결을 위한 경로 검색 및 과정

 이준성

• 아직 만난지 얼마되지않아 조금 어색함
• 아직 서로 공부기간이 길지 않다보니, 작업 도중 생각하지 못했던 오류(함수충돌)들이 생겨 조금 더 공부할 필요가 있다고 생각합니다.

전수원

• 주기적인 회의가 조금 더 많았으면 더 좋았다고 생각된다. → 조금 더 빨리 문제점이나 프로젝트 진도가 더 빠르게 진행되었을것 같다고 생각된다.
• 자신의 문제내용을 해결 방식이랑 어떻게 해결하였는지 공유했었으면 좋았다고 생각된다.

이주언

• 깃허브를 이용해서 코드 공유를 할때 충돌 나는 부분이 많아 그 충돌을 해결하는데 많은 시간이 걸린 것 같아서 아쉬움.
• 아무래도 처음 쓰는 툴이다보니 어색한 점이 있어서 그런것 같은데 더 원활하게 코드를 공유하는 방법을 고민해야봐야 할 것 같음.

---

Keep, Problem 공유 (10분)

---

Try 작성 (7분)

Try는 다음 KPT(회고)에서 판별이 가능한 것으로 할 것.
자신의 행동으로 컨트롤 가능한 것으로 할 것.
KPT가 끝나자마자 실행 가능한 것을 제안할 것.

 

Try

김노을

• 개발 규칙의 부재 (변수명, 주석 달기 등)
• 오후 회의에는 마주한 오류와 개발 과정들 공유하기
• 코드 컨벤션을 한 가지 채택하여 팀원이 일정한 코드 스타일을 따를 수 있도록 하기.

황민도

• 모르는 부분을 감추지 않고 좀 더 많은 질문을 통해 섬세한 프로젝트 진행에 집중
• 문제 발생 시 어느 정도 검색 과정이나 해결 과정을 메모장에 저장해두고 공유
• 주석이나 ID 코드 규칙을 소통하여 정하고 프로젝트를 실행

 이준성

• 개발 규칙의 부재 (변수명, 주석 달기 등)

깃 허브를 통해서 서로의 작업물을 병합하는 것이다보니, class나 id의 이름이 뒤죽박죽 섞여 있기에, 사전에 A쪽 코드의 id나 class는 A-main 처럼 미리 사전에 협의를 통해 더 깔끔하고 원만한 작업이 될 것 같음

• 자신의 문제내용을 해결 방식이랑 어떻게 해결하였는지 공유했었으면 좋았다고 생각된다.

코드를 작성하다 생긴 문제점이 발생할 시, 따로 메모를 해두어 그날 회의 시간에 이런 문제를 발견하여 이런 해결법을 작성해 보았고 해결or미해결 인 상태다 라는것을 공유하여, 비슷한 오류를 경험한 사람에게 도움을 받을 수 있고, 앞으로 이런 오류를 발견했을때를 대비한 공부도 될 수 있는 것 같다.

 

전수원

• 규칙적인 변수명
• 간단한 코딩 주석달기
• 하루(2~3번) 주기적인 간단한 회의 (2~30분) → 분담 업무중 어려운점이나 현재 상황 브리핑
• 문제점을 해결한 방식 공유 (조금 자세히)

이주언

• 개발 규칙 정의 - 명명 규칙이나 주석 등등 팀 내에서 개발할 때 동일하게 맞추고 가야할 것 들을 정하는 과정이 있으면 좋을 것 같음
• 깃허브 사용법 숙지
• 회의시간 정하기 - 주기적인 회의 시간을 정해서 중간 상황 보고를 빠르게 할 필요성이 있는 것 같음

---

Try 공유 (8분)

---

Try & Action 선정 (15분)

1. 코드 컨벤션을 정해두기.
2. 저녁 회의에서는 개발 과정과 오류에 대해 설명과 피드백 (자세하게)
3. 하루 3번 현재 상황 브리핑 (20~30분, 팀원 전체, 간단하게)
4. 협업 툴 숙지 + 활용

 

참고: https://www.designsori.com/zero/1157702

디자인소리 - 프로덕트 매니저의 애자일 회고 방법론 - KPT 실전편