Login

Sprint retrospective: bốn định dạng giúp nhóm thực sự cải tiến

  • author-image

    Nguyễn Đình Cường

  • blog-tag
  • blog-comment 0 comment
  • created-date 09 Nov, 2026
blog-thumbnail

Cuối mỗi sprint, nhiều nhóm bỏ qua buổi retrospective vì 'bận quá'. Nhưng đó lại chính là nơi nhóm tự làm cho cách làm việc của mình tốt lên. Nếu retro của bạn nhàm chán hoặc chỉ cho ra những lời than vãn, hãy thử các định dạng dưới đây.

Retrospective để làm gì?

Retrospective là buổi họp để nhóm nhìn lại sprint vừa qua về con người, tương tác, quy trình và công cụ, rồi chọn một số cải tiến cụ thể để thực hiện trong sprint kế tiếp. Điểm mấu chốt: kết quả không phải là một danh sách than phiền mà là hành động.

Nguyên tắc nền tảng: an toàn tâm lý

Retro chỉ có ích khi mọi người dám nói thật. Vì vậy:

  • Tập trung vào quy trình và hệ thống, không đổ lỗi cho cá nhân.
  • Giữ nội dung trong nhóm, không báo cáo ai nói gì cho bên ngoài.
  • Người quản lý nên cân nhắc việc có mặt hay không, vì sự hiện diện của cấp trên đôi khi khiến mọi người dè dặt.
  • Mọi người đều có cơ hội phát biểu, không để một hai người nói hết.

Cấu trúc năm bước

  1. Mở đầu (5 phút): nhắc mục đích, quy tắc, và có thể một câu hỏi nhẹ nhàng làm quen.
  2. Thu thập dữ liệu: mọi người viết ý kiến lên giấy ghi chú, ghi dữ kiện như thay đổi, sự cố, sự kiện trong sprint.
  3. Tìm hiểu nguyên nhân: nhóm các ý giống nhau, bình chọn chủ đề quan trọng nhất, hỏi 'vì sao' để đến gốc rễ.
  4. Quyết định hành động: chọn một đến ba cải tiến, mỗi cái có người chịu trách nhiệm và cách đo kết quả.
  5. Kết thúc: tóm tắt cam kết, thu phản hồi nhanh về chính buổi retro.

Bốn định dạng thường dùng

1. Start - Stop - Continue

Chia bảng thành ba cột: Nên bắt đầu làm, Nên dừng làm, Nên tiếp tục làm. Đơn giản, dễ hiểu, rất phù hợp cho nhóm mới làm quen.

2. Mad - Sad - Glad

Cột cho điều khiến bạn bực bội, điều khiến bạn buồn và điều khiến bạn vui. Định dạng này khai thác cảm xúc, hữu ích khi nhóm đang căng thẳng hoặc thiếu gắn kết.

3. 4Ls: Liked, Learned, Lacked, Longed for

Điều được yêu thích, điều đã học được, điều còn thiếu và điều mong muốn. Thích hợp để rút bài học sau một dự án hay giai đoạn dài.

4. Thuyền buồm (Sailboat)

Vẽ con thuyền: gió là thứ đẩy nhóm tiến lên, neo là thứ kéo lại, đá ngầm là rủi ro phía trước, đích đến là mục tiêu. Hình ảnh giúp nhóm nói về rủi ro một cách nhẹ nhàng, tạo không khí thoải mái hơn.

Hãy luân phiên các định dạng để tránh nhàm chán, nhưng đừng đổi liên tục đến mức nhóm không kịp quen.

Viết hành động cải tiến tốt

So sánh hai cách ghi:

  • Yếu: 'Giao tiếp tốt hơn.'
  • Tốt: 'Từ sprint sau, mọi pull request phải được review trong vòng một ngày làm việc; Lan theo dõi và báo lại ở retro tới.'

Một hành động tốt cụ thể, có người phụ trách, có thời hạn và kiểm chứng được. Đừng chọn quá nhiều: hai ba hành động làm được còn hơn mười hành động bị quên.

Theo dõi hành động từ retro trước

Đầu mỗi buổi retro, hãy xem lại các hành động của lần trước: cái nào đã làm, kết quả ra sao, cái nào chưa làm vì sao. Nếu không theo dõi, nhóm sẽ nhanh chóng mất niềm tin rằng retro có ích.

Lỗi thường gặp

  1. Biến retro thành buổi than phiền không có kết luận.
  2. Cùng một vấn đề xuất hiện qua nhiều sprint mà không ai xử lý.
  3. Một người chiếm hết thời gian phát biểu.
  4. Chỉ nói về điều xấu, quên ghi nhận điều tốt.
  5. Cải tiến phụ thuộc vào bên ngoài nhóm mà không có ai đứng ra đề đạt lên.

Kết luận

Retrospective là cơ chế cải tiến tích hợp sẵn của nhóm. Hãy giữ an toàn tâm lý, thử các định dạng khác nhau và luôn kết thúc bằng hành động cụ thể. Chỉ một cải tiến nhỏ mỗi sprint cũng tạo ra khác biệt lớn sau vài tháng.

Nếu bạn muốn tìm hiểu kỹ hơn cách điều hành nhóm phần mềm, hãy tham khảo các khóa học tại codebem.com.

author_photo
Nguyễn Đình Cường

0 comment