KPT 회고

3차 프로젝트 끝

• 원래 TIL이 계속 올라왔어야 하는데 최근 건강 이슈와 프로젝트 구현하는 동안 시간이 부족해서 TIL을 올리지 못했다 이것부터 시작해서 계속 꾸준하게 올려야겠다.

Keep

잘하고 있는 점. 계속 했으면 좋겠다 싶은 점. ex)마음 편히 질문할 수 있는 분위기가 좋다.

• 데일리 스크럼을 통한 하루 일과 계획 작성하고 팀원들에게 공유하는 것
• 개인만의 집중 코딩 시간이 존재하는 것
• 작은것도 칭찬해주고 모르는 부분을 적극적으로 해결해주려고 하는 부분 - 감사했씁니다
• 개개인의 의견을 편하게 얘기할 수 있는 밝은 팀 분위기
• 서로의 아이디어를 공유할 수 있는 시간이 있어서 좋았다
• 자신이 맡은 역할이 아니라도 여유가 있으면 도와주는 것
• git사용법을 자세히 알려주어서 도움이 많이 되었다

Problem

• 프로젝트 진행시 가이드라인을 정확히 숙지하지 않아서 중간에 혼선이 생긴 것
• 코드에서의 이름에 기준이 없어서 서로 중복되거나 읽기 힘들었다
• 처음 기획했던 기능을 전부 구현하지 못한 점이 아쉬웠다.
• 공통 UI의 기준을 명확히 잡지 않아서 초반의 디자인 갈피를 잡지 못했다.
• Git push, commit 기준 및 규칙이 명확하지 않아 기록을 보았을 때 난해했다.

Try

`problem에 해당하는 개선 방법 규칙)**구체적이고 실천적어야 한다**

• 프로젝트 시작 전 필요한 규칙 및 기준을 미리 정하고 시작하기

• 공통적으로 구현해야 하는 부분에 대해선 확실한 기준을 잡고 시작하기

• 다 같이 가이드라인 숙지하는 시간을 가지고, 체크리스트를 활용하여 step별로 과제에 접근해보았을 것이다.

  • 과제 주제에 대한 자료를 수집하는 시간을 가진다.

• 코드 컨벤션을 정한 다음 해당 코드 컨벤션을 따로 문서화한다.

  • 코드 컨벤션을 push로 확인할 경우 중복이 일어날 수 있으니 merge를 통해 중복 확인&코드 컨벤션을 확인하는 시간을 가진다.

• 기본적인 기능을 우선적으로 구현한 다음, 추가적인 기능은 2차 회의를 걸쳐서 구현 여부를 정하는 것이 좋을 거 같다.

• 와이어프레임 작성 단계에서 화면 ui를 표현 단계를 넘어서 세부적인 ui를 정하면 공통으로 구현해야하는 ui를 찾을 수 있을 거 같다.

  • 플로우차트(흐름도)를 같이 기획하면서 파악해보면 해결될 것이다.
  • 유저 스토리를 기반으로 와이어 프레임을 기획하면 우선적 기능과 해당 ui에 사용하면 좋은 widget를 정확하게 정할 수 있을 거 같다.

• 특징적인 ui를 기본값으로 가지고 그 범위 안에서 추가 기능을 구현하는 방법

• push, commit 이름 및 기준을 문서화한다.

  • 뭉쳐서 commit하는 것을 금지한다.
  • file을 새로 만들었을 때 : ‘create + ui/featere + 기능 이름’
  • ui widget을 다 배치했을 때 : complete +ui + widget 이름
  • ui widget을 다 수정했을 때 : correction + ui + widget
  • ui와 kotlin에 widget을 연결했을 때 : connect + ui + widget 이름
  • widget logic을 추가했을 때 : Add + logic + widget 이름
  • 오류가 났을 때
    • 개인적인 오류가 났지만 해결했을 때 : ‘error + 해결방법’
    • 개인적인 오류가 나서 해결을 못 했을 때 : ‘error’
    • merage하고 난 후 실행에 오류가 생겼을 때(해결) : ‘finish merge + error 이름’
    • merage하고 난 후 실행에 오류가 생겼을 때(해결 실패) : ‘error!!! + error 이름’