회고 & KPT

회고(Retrospective)

팀이 정해진 기간동안 해왔던 일들에 대해 돌아보면서 문제점이나 잘한 점을 찾아내어 다음작업에도 좋은 점은 계승하고, 아쉬웠던 점들은 다른 방식을 시도해 끊임없이 개선을 추구

스프린터의 종료 시점에 아래에 4가지 항목을 정리한다.

• Liked (좋았던 것)
• Learned (배운 것)
• Lacked (부족한 것)
• Longed for (원하는 것)

4L 회고 템플릿 및 회고 가이드
https://miro.com/ko/templates/4-ls-retrospective/

https://www.atlassian.com/ko/software/confluence/templates/4-ls-retrospective

회고 작성

KPT

작업(TASK)가 아닌 다른 차원의 문제 상황의 해결을 위한 회고인 경우

• 논의하려는 문제 상황

  표준화 회의를 1달에 1번 진행할 때 지난 개발 건 리뷰와 함께 업무 분석된 내용을 검토하다 보니 회의가 길어져 이에 대한 해결안 논의

• Keep: 유지해도 좋을 것

  • AS-IS, TO-BE 분석 후 개발은 실제 그대로 진행되는 것이 아니므로 변경내용에 대해서
    리뷰하는 시간은 반드시 필요하다.
  • 요구사항을 명확히 이해하고 잘못된 방향으로 진행되는 것을 막고 커뮤니케이션 오류를
    줄일 수 있다는 관점에서는 긍정적이고 유지 필요

• Problem: 해결해야 하는, 없애야 하는 문제점

  • 1달에 1번 진행하고 다른 변경사항을 모두 검토하는 바람에 회의가 길어지고 집중하기 어려움
  • 준비하는 과정에서 어렵고 힘든 점을 알 수 없고, 미팅 자체의 목적 외에 해당 프로세스의
    개선해야 하는 방향에 대한 고찰이 부족하다.

• Try: 문제를 해결하기 위해서 해볼 수 있는 것들

  • 표준화 회의의 횟수를 늘린다.
  • 개발 리뷰와 표준화 업무 미팅을 분리한다.
  • 개발 리뷰와 동시에 개발자의 회고를 진행한다.