+4

KPT (KEEP - PROBLEM - TRY) là gì ?

Trả là hôm trước đang trainning android thì có một anh trainner có hỏi về KPT, lúc đầu mình cũng chẳng biết nó là cái gì cứ tưởng anh ấy nói đến cái Khu-PanTry của công ty. Tìm hiểu mãi và sự gơi ý của anh ấy mình mới biết nó là Keep-Problem-Try ( Giữ-Vấn đề-Thử).

Hình như cũng có một bài trên viblo có nói về KPT nhưng mình xin phép hệ thống lại và một phần là làm mình dễ nhớ hơn.

KPT là gì ?

Keep - Problem - Try là một phương pháp review/retrospective được sử dụng phổ biến tại nhật, KPT được sử dụng cho một nhóm hoặc một tổ chức, các dự án IT (được sử dụng nhiều trong mô hình agile khi kết thúc mỗi sprint) hoặc cũng có thể là phi IT.

   K - viết tắt của Keep: giữ, cũng có thể tiếp tục trong tương lai.
   P - viết tắt của Problem: Bởi vì vấn đề = vấn đề, ngăn chặn nó.
   T - viết tắc của Try: thử = tương lai, muốn thử nó .

Tìm hiểu kỹ K,P,T

  • Keep - Đây là những ưu điểm, những tác động tích cực vào team giúp team hoàn thiện công việc tốt hơn, được khách hàng khen ngợi hoặc đơn giản là giúp mọi người làm việc thoải mái hơn.
  • Problem - Đi ngược lại với keep chính là problem, đây là những vấn đề nhức nhối có tác động tiêu cực, gây ảnh hưởng tới chất lượng công việc.
  • Try - Theo nó giống như việc thử lại, khắc phục những problem.

Cách tiến hành thực hiện KPT

  • Chia Bảng thành 3 phần bảng trắng lần lượt là Keep,Problem, Try:

090717_kimoto_02.gif

  • phát cho mỗi thành viên người vài tờ ticky note (nên dùng 3 màu ticky note khác nhau lần lượt là Keep,Problem,Try) + 1 chiếc bút dùng để viết các Keep, Problem, Try.
  • dành cho tất cả các thành viên trong nhóm 5 -10 phút để tự viết những gì mà muốn thực hiện ở sprint sau, những vẫn đề.
  • sau khi các thành viên đã viết xong lần lượt lên dán những tờ ticky note ở phần bảng tương ứng và mọi người cùng thảo luận để đưa ra, nếu nó là tốt thì cho vào Keep,nếu xuất hiện những vẫn đề ta cho vào Problem,Khi đã hoàn thành cuộc thảo luận với Keep và Problem, chúng ta tiếp tục thảo luận về Try. Thứ nhất những Problem cần được cải thiện,những gì bạn sẽ làm tiếp theo sẽ được đưa vào Try.
  • Cuối cùng Người điều hành sẽ tóm tắt và dán lên bảng hoặc đọc cho các thành viên.

Kết Luận

KPT là một phương pháp rất dễ dàng triển khai và không tốn kém chi phí mặt khác nó cũng giúp các thành viên trong nhóm đưa ra được nhưng ý kiến của mình.

Các Biến thể khác của KPT

Ngoài KPT, có nhiều phương pháp thực hiện retrospective khác như

  1. Happy/Sad (những gì làm team “sướng” và “buồn”, đây là template khá đơn giản và dễ áp dụng)

  2. Mad, Glad, Sad

  3. Good Point/Bad Point/Improvement (Điểm tốt, điểm xấu, điểm cần cải tiến)

  4. Phân loại: What did we do well?/What should we have done better? (viết rõ bằng bằng plain English cho dễ hiểu).

Vì mới là New Developer nên mình vẫn chưa được thực hành và mới chỉ có qua sự tìm hiểu và lý thuyết xuông nên có gì không đúng xin phép mọi người bỏ qua cho ạ.

tài liệu tham khảo: http://qiita.com/numa08/items/2fbcbf91012c7dd49ab5#kptの手法 http://bashalog.c-brains.jp/09/07/17-201738.php http://labs.septeni-technology.jp/offshore/doi-dieu-ve-kpt-keep-problem-try/ http://www.itmedia.co.jp/im/articles/0905/19/news143.html


All rights reserved

Viblo
Hãy đăng ký một tài khoản Viblo để nhận được nhiều bài viết thú vị hơn.
Đăng kí