토이프로젝트 Kanban _ KPT 회고

Keep:

지속적인 소통, 질의응답, 토론, 문제를 포기하지 않고 해결하려는 자세,

날이 갈수록 의견을 말하기 편해졌는데, 이는 서로의 배려가 있었기에 가능한 일이었던 듯..

어려워도, 아파도 하려고 했던 그 의지,

깃 컨벤션을 통해 충돌을 최소화하는 법,

생성자나, 메서드 방식의 컨벤션(설계도의 양식의 통일화)

 

Problem:

테스트 코드 부족, 프론트엔드 구현 실패, 미약한 깃 컨벤션 적용,

코드리뷰와 머지를 한 사람만 맡다보니 하염없이 기다려야 했던 점,

issue 가 세분화 되지 않아서 충돌을 겪음,

중간의 역할분담의 부재( ex . 기본 CRUD 구현 후의 역할이 애매 했다.),

한 사람에 업무과중으로 인해 부담감과 프로젝트의 지체,

프론트를 꺼려하는 성향,

얄팍한 프론트 지식,

주말엔 쉬고 싶은 안타까운 체력

 

Try:
기능 구현은 빠르게 마치고, 테스트 코드에 집중하기,

코드리뷰는 최소 두 사람이 맡기,

issue를 생성할 때, 더욱 세분화 하기,

업무 지체의 완화를 위해 더미 데이터 생성 후 프로젝트 진행하기,

피곤해도 죽어서 잔다는 마인드로 프로젝트에 임하기,

프론트 싫어도 어느정도는 완성하기

 

---

이상은 팀 내에서 작성한 것이고 추가로 아래에 내용을 남겨봄

 

느낀점

• 알고리즘에 대한 지식의 부재가 얼마나 치명적인지 절실하게 느꼈던 한 주였다
• 그리고 아무리 백엔드라고 할지라도 프론트에 대한 지식이 조금은 있어야 한다고 말하는 이유를
  어느정도 이해한 것 같다
• 그래도 일단 백엔드적 지식을 어느정도 함양한 후 프론트를 건드려 보는 것이 낫지 않은가
  하는 것에대한 생각은 변함이 없다

 

경험

• 처음으로 발표용 PDF 파일을 생성했다
• 팀원들의 도움을 받으며 하긴 했지만, 역시 결과물이 눈에 보이니 만족도가 있었다
  하지만 시간 부족과, 플랫폼 사이트의 버퍼링으로 완전하게 만들지 못했기에 아쉬움이 좀 남는다
• 그리고 이번에 다시 느낀건,
  나는 '일'을 할 때 '실력'보다는 '사람'을 보게 된다는 것이다