Thuật ngữ
Retrospective là gì? Cách họp rút kinh nghiệm cuối sprint ra hành động
Retrospective là buổi đội tự nhìn lại cuối sprint: giữ gì, bỏ gì, thử gì. Khác Review ở đâu, khung 45 phút, ba định dạng, cách ra hành động có người phụ trách.
Khoảng 6 phút đọc
Trả lời ngắn
Định nghĩaRetrospective (họp rút kinh nghiệm, gọi tắt là retro) là buổi đội tự nhìn lại cách làm việc ở cuối mỗi sprint: điều gì tốt nên giữ, điều gì chưa tốt nên bỏ, điều gì nên thử ở sprint sau. Kết quả bắt buộc là một đến hai hành động cụ thể, có người phụ trách, được kiểm tra ở retro kế tiếp.
Retro là lý do Scrum tự tốt lên theo thời gian: không ai thiết kế được quy trình hoàn hảo từ đầu, nhưng đội chỉnh mỗi hai tuần một chút thì sau nửa năm sẽ có quy trình hợp với chính mình. Đội bỏ retro là đội đứng yên với những lỗi của sprint đầu tiên.
Retro khác Review ở đâu
Review nhìn vào sản phẩm, có khách hoặc người dùng dự, hỏi “đã làm ra đúng thứ chưa?”. Retro nhìn vào cách làm, chỉ có đội, hỏi “đã làm đúng cách chưa?”. Hai buổi liền nhau ngày cuối sprint nhưng không gộp: có khách trong phòng thì không ai nói thật về cách làm. Năm sự kiện của sprint ở Sprint là gì?.
Khung 45 phút
| Phút | Bước | Làm gì |
|---|---|---|
| 0–5 | Mở đầu | Nhắc hành động của retro trước: đã làm chưa, có tác dụng không. Nhắc quy tắc: nói về cách làm, không về người. |
| 5–10 | Dữ liệu | Nhìn số: velocity, burndown, việc dở chuyển sang, yêu cầu khách hàng trễ. Số trước, cảm nhận sau. |
| 10–25 | Thu thập | Mỗi người viết giấy hoặc gõ vào bảng theo định dạng đã chọn, im lặng 5 phút rồi đọc lên, gom nhóm. |
| 25–38 | Chọn | Bỏ phiếu chọn 1–2 vấn đề đáng sửa nhất; bàn nguyên nhân bằng cách hỏi “vì sao” vài lần. |
| 38–45 | Hành động | Mỗi vấn đề một hành động: làm gì, ai, đến khi nào, kiểm tra thế nào ở retro sau. |
Ba định dạng đơn giản, đủ dùng cả năm
Đổi định dạng vài sprint một lần cho đỡ nhàm
- Giữ, Bỏ, Thử. Đơn giản nhất, hợp đội mới. Ba cột, mỗi người ba tờ giấy.
- Vui, Buồn, Ý tưởng. Bắt đầu từ cảm xúc, hợp sprint căng thẳng hoặc sau sự cố.
- Cột buồm. Gió đẩy (điều giúp đội), mỏ neo (điều kéo đội lại), đá ngầm (rủi ro sắp tới). Hợp khi cần nhìn về phía trước.
Quy tắc vàng
Ví dụ: retro sprint 3 của đội 6 người
Ví dụ
Dữ liệu: velocity 18 so với 24 và 23 hai sprint trước; ba việc dở chuyển sang; hai việc bị chặn vì chờ API của đơn vị khác. Thu thập theo Giữ, Bỏ, Thử: mọi người khen daily đi theo bảng (giữ); ba người viết “nhận việc chưa rõ phụ thuộc” (bỏ); hai người đề xuất “hỏi lịch bàn giao ở refinement” (thử).
Hỏi vì sao ba lần: vì sao chặn, vì chờ API; vì sao không biết sớm, vì không hỏi ở refinement; vì sao không hỏi, vì chưa ai coi đó là việc của mình. Hành động: từ sprint 4, việc có phụ thuộc bên ngoài phải ghi tên đầu mối và ngày bàn giao ngay trong mô tả trước khi vào sprint; điều phối dự án kiểm ở refinement thứ Tư. Retro sprint 4 mở đầu bằng câu hỏi: đã làm chưa? Đã, và không việc nào bị chặn.
Năm lỗi hay gặp
Đội mới hay mắc
- Buổi than phiền. Nói hết 45 phút về vấn đề, không ra hành động. Chốt cứng 7 phút cuối cho hành động.
- Sếp ngồi dự. Mọi người nói điều an toàn. Retro là của đội.
- Năm hành động một lúc. Không làm được cái nào. Tối đa hai.
- Hành động không có tên người. “Đội sẽ cập nhật bảng đúng giờ hơn” không ai làm. “Hạnh nhắc ở daily, kiểm tra thứ Sáu” thì có.
- Bỏ retro vì sprint tốt. Sprint tốt là lúc dễ nhìn ra cái gì làm nên nó để giữ lại.
Retrospective trên Pentara
Dữ liệu cho phần mở đầu có sẵn: trang Chi tiết sprint hiện velocity cam kết và hoàn thành, burndown, danh sách việc dở đã chuyển sang; tab Báo cáo có việc trễ hạn, việc chưa giao và tỉ lệ đúng SLA của yêu cầu khách hàng. Đội nhìn số trước khi nói cảm nhận.
Hành động của retro ghi thành Task trong sprint kế tiếp, gắn nhãn “retro”, giao đúng người và đặt hạn; retro sau lọc theo nhãn này để kiểm tra. Lịch sử hoạt động của dự án giúp trả lời “việc này bị kéo ngược mấy lần” khi bàn nguyên nhân. Thử ngay: đăng ký gói Miễn phí, chạy một sprint theo Bắt đầu nhanh, và đừng bỏ retro đầu tiên; lịch chi tiết ở Quy trình sprint 2 tuần.
Hỏi đáp nhanh
- Retro và Review có gộp làm một được không?
- Không nên. Review có khách hoặc người dùng dự và nhìn vào sản phẩm; Retro chỉ có đội và nhìn vào cách làm. Có khách trong phòng thì không ai nói thật về cách làm. Hai buổi liền nhau ngày cuối sprint, Review trước, Retro sau.
- Retro nên dài bao lâu?
- 45 đến 60 phút cho sprint 2 tuần; 30 phút cho sprint 1 tuần. Dài hơn thường vì không chốt được hành động. Dành cứng 7 phút cuối cho hành động, dù phần bàn luận chưa xong.
- Sếp có được dự retro không?
- Chỉ khi đội mời. Retro là nơi đội nói thật về cách làm, kể cả về sự chen ngang của cấp trên; có sếp thì mọi người nói điều an toàn. Kết quả retro, tức hành động cải tiến, có thể chia sẻ với sếp; diễn biến thì không.