Sprint Retrospective trong phát triển: bản chất, mục tiêu và phương pháp thực hiện
Sprint Retrospective — một cuộc họp thường xuyên của nhóm phát triển được tổ chức vào cuối mỗi sprint để phân tích giai đoạn đã qua và tìm kiếm cải tiến. Khác với daily meeting và sprint review, retrospective tập trung vào quy trình và tương tác, chứ không phải vào sản phẩm. Theo Scrum Guide, 2020, retrospective là một trong năm sự kiện bắt buộc của Scrum và đóng vai trò là cơ chế chính để cải tiến liên tục của nhóm.
Những điểm chính
- Retrospective — cuộc họp nhóm sau sprint để phân tích quy trình và tìm kiếm cải tiến.
- Mục tiêu chính — xác định những gì hoạt động tốt và những gì cần thay đổi trong sprint tiếp theo.
- Các định dạng chính — Start-Stop-Continue, Sailboat, 4L và Mad-Sad-Glad.
- Nguyên tắc chính — retrospective phải kết thúc bằng các action item cụ thể, không chỉ là thảo luận.
- Sai lầm điển hình — các vấn đề lặp lại mà không có thay đổi thực sự, khi retro trở thành hình thức.
Sprint Retrospective là gì?
Sprint Retrospective — một cuộc họp có cấu trúc của nhóm Scrum được tổ chức sau khi kết thúc sprint và trước khi lập kế hoạch cho sprint tiếp theo. Người tham gia thảo luận về sprint đã qua, chia sẻ quan sát và cùng nhau xác định những thay đổi cần thực hiện trong công việc.
Nguồn gốc của thực hành
Thuật ngữ retrospective đến từ các thực hành cải tiến liên tục được mô tả trong văn hóa DevOps và phương pháp Lean. Trong Scrum, retrospective trở thành sự kiện bắt buộc với sự ra đời của Scrum Guide vào năm 2010. Vào năm 2020, bản cập nhật Scrum Guide đã chuyển trọng tâm từ “kiểm tra và thích ứng” sang “tập trung vào chất lượng và hiệu quả”, củng cố vai trò của retrospective.
Sự khác biệt so với các nghi lễ Scrum khác
Sprint Review tập trung vào sản phẩm và phản hồi từ các bên liên quan, trong khi retrospective tập trung vào quy trình của nhóm. Daily Scrum là sự đồng bộ hàng ngày, retrospective phân tích toàn bộ sprint. Retrospective là nghi lễ duy nhất mà nhóm nói hoàn toàn về bản thân mình, không có áp lực từ khách hàng hay product owner.
Mục tiêu của Sprint Retrospective
Sprint Retrospective có một số mục tiêu chính, mỗi mục tiêu đều quan trọng cho sự phát triển lành mạnh của nhóm và quy trình phát triển.
Suy ngẫm của nhóm
Suy ngẫm cho phép nhóm hiểu về sprint đã qua: điều gì đã thành công, điều gì sai sót và những bài học nào có thể rút ra. Quá trình này ngăn ngừa việc lặp lại những sai lầm tương tự, hình thành văn hóa cởi mở và dạy các nhà phát triển chịu trách nhiệm về quy trình, không chỉ về mã.
Cải tiến có thể đo lường
Mỗi retrospective nên tạo ra các action item cụ thể — nhiệm vụ cho sprint tiếp theo. Ví dụ: “thêm code review cho tất cả pull request” hoặc “giảm daily meeting xuống 10 phút”. Action item được ghi lại trong backlog và theo dõi ở retro tiếp theo. Nếu action item không được thực hiện, retrospective sẽ mất ý nghĩa.
Ngăn ngừa kiệt sức
Các retrospective thường xuyên giúp xác định vấn đề trước khi chúng dẫn đến kiệt sức. Làm thêm giờ, xung đột trong nhóm, yêu cầu không rõ ràng — tất cả điều này được nêu ra tại retro và giải quyết trước khi đạt đến khối lượng tới hạn.
Các định dạng Retrospective
Có hơn 50 định dạng retrospective, mỗi định dạng phù hợp với các tình huống và thành phần nhóm khác nhau. Việc chọn định dạng phụ thuộc vào độ trưởng thành của nhóm, vấn đề hiện tại và thời gian có sẵn.
| Định dạng | Mô tả | Khi nào sử dụng |
|---|---|---|
| Start-Stop-Continue | Nhóm chia ý tưởng thành ba cột: bắt đầu, dừng lại, tiếp tục | Retro đầu tiên hoặc sau khủng hoảng |
| Sailboat | Ẩn dụ trực quan: gió (giúp đỡ), neo (làm chậm), đá (rủi ro) | Nhóm mệt mỏi với các mẫu |
| 4L (Liked-Learned-Lacked-Longed For) | Bốn danh mục: thích, học được, thiếu, mong muốn | Phân tích sprint chuyên sâu |
| Mad-Sad-Glad | Định dạng cảm xúc: tức giận, buồn, vui | Có căng thẳng cảm xúc |
Start-Stop-Continue
Start-Stop-Continue — định dạng đơn giản và phổ biến nhất. Nhóm viết ý tưởng lên giấy ghi chú và phân phối vào ba cột. Start — thực hành mới, Stop — thói quen xấu, Continue — những gì hiệu quả. Định dạng này rất phù hợp cho nhóm mới và retrospective nhanh 30 phút.
Sailboat / 4L
Sailboat sử dụng ẩn dụ con tàu: gió đẩy về phía trước, neo làm chậm lại, đá — rủi ro tương lai. 4L — định dạng sâu hơn, nơi nhóm phân tích từng khía cạnh qua bốn lăng kính. Cả hai định dạng đều cần nhiều thời gian hơn (60-90 phút) nhưng cung cấp bức tranh đầy đủ hơn về trạng thái của nhóm.
Chọn định dạng theo tình huống
Cho retro hàng tuần, các định dạng nhẹ phù hợp: Start-Stop-Continue hoặc Mad-Sad-Glad. Cho sprint kéo dài 2-4 tuần, nên sử dụng Sailboat hoặc 4L. Nếu có xung đột trong nhóm, tốt hơn nên bắt đầu với Mad-Sad-Glad để giải tỏa cảm xúc, sau đó chuyển sang thảo luận mang tính xây dựng.
Cách thực hiện Retrospective: kế hoạch từng bước
Thực hiện retrospective đòi hỏi cấu trúc và sự điều phối. Scrum Master hoặc người điều phối được chỉ định dẫn dắt cuộc họp từng bước để đảm bảo mỗi người tham gia đều được lắng nghe.
Chuẩn bị
24 giờ trước retro, người điều phối thu thập dữ liệu: số liệu sprint (vận tốc, số lượng lỗi, nhiệm vụ đã hoàn thành), tâm trạng nhóm qua khảo sát ẩn danh. Bảng retro được chuẩn bị trước — vật lý (giấy ghi chú, bút đánh dấu) hoặc kỹ thuật số (Miro, Mural, Retrium).
Thu thập dữ liệu
Ở giai đoạn này, mỗi người tham gia viết quan sát của mình lên giấy ghi chú (thường 5-10 phút trong im lặng). Các danh mục phụ thuộc vào định dạng đã chọn. Quy tắc quan trọng: không chỉ trích ghi chú của người khác trong giai đoạn thu thập — trước tiên tất cả ý tưởng được ghi lại, sau đó thảo luận.
Bỏ phiếu và ưu tiên
Sau khi thu thập, nhóm nhóm các ghi chú theo chủ đề và bỏ phiếu cho những ghi chú quan trọng nhất. Mỗi người tham gia nhận được 3-5 phiếu bầu (đánh dấu bằng dấu chấm trên ghi chú). Các chủ đề có nhiều phiếu nhất sẽ được đưa vào thảo luận. Cơ chế này ngăn chặn một giọng nói lấn át những người khác.
Kế hoạch hành động
Giai đoạn cuối cùng — xây dựng action item. Mỗi action item nên theo SMART: cụ thể, có thể đo lường, có thể đạt được, phù hợp và có thời hạn. Người chịu trách nhiệm được chỉ định công khai, thời hạn được ấn định. Action item được thêm vào backlog và kiểm tra tại retrospective tiếp theo.
Những sai lầm điển hình khi thực hiện Retro
Ngay cả những nhóm có kinh nghiệm cũng mắc sai lầm trong retrospective biến một thực hành hữu ích thành hình thức rỗng tuếch. Biết những sai lầm này giúp tránh chúng.
Thiếu action item
Sai lầm phổ biến nhất — thảo luận không có kết quả. Nhóm đã nói chuyện, xác định vấn đề, nhưng không ghi lại bất kỳ action item nào. Retrospective như vậy không dẫn đến thay đổi, và trong cuộc họp tiếp theo, những vấn đề tương tự lại được thảo luận. Giải pháp: dành 10 phút cuối cùng của retro cho kế hoạch hành động.
Biến thành phàn nàn
Khi retrospective biến thành buổi phàn nàn mà không có đề xuất mang tính xây dựng, tinh thần nhóm giảm sút. Người điều phối nên hướng cuộc thảo luận từ vấn đề sang giải pháp. Kỹ thuật: sau mỗi vấn đề, hãy hỏi “Chúng ta có thể làm gì về điều này?”.
Một người thống trị
Nếu một nhà phát triển nói 80% thời gian, những người khác khép lại và ngừng chia sẻ ý tưởng. Giải pháp: sử dụng thu thập ý tưởng im lặng (mỗi người tự viết), lượt theo thứ tự, hẹn giờ phát biểu. Khảo sát ẩn danh trước retro cũng giúp thu thập ý kiến của những người tham gia ít nói.
Bỏ qua retrospective
Bỏ qua retro vì bận rộn hoặc “không có thời gian” là một xu hướng nguy hiểm. Nếu nhóm bỏ qua một retro, việc bỏ qua lần thứ hai trở nên dễ dàng hơn. Theo thời gian, vấn đề tích tụ và các sprint trở nên kém hiệu quả hơn. Retrospective là một phần của sprint cũng như phát triển và kiểm thử.
Câu hỏi thường gặp
Bao lâu nên tổ chức retrospective một lần?
Retrospective được tổ chức sau mỗi sprint, bất kể độ dài của nó. Cho sprint dài 1-2 tuần, 30-60 phút là đủ. Nếu sprint ngắn (một tuần), có thể sử dụng định dạng nhẹ Start-Stop-Continue. Không nên bỏ qua retrospective — đây là cơ chế chính để cải tiến liên tục của nhóm.
Ai nên tham gia retrospective?
Toàn bộ nhóm Scrum tham gia: nhà phát triển, Scrum Master và Product Owner. Product Owner có thể tham gia với tư cách thành viên, nhưng ý kiến của họ không nên chi phối. Nếu có chuyên gia bên ngoài (nhà thiết kế, nhà phân tích) tham gia sprint, cũng nên mời họ. Nguyên tắc chính: tất cả những người đã làm việc trong sprint đều có quyền phát biểu tại retro.
Phải làm gì nếu nhóm không muốn tham gia retro?
Không muốn tham gia là triệu chứng của những vấn đề sâu xa hơn: thiếu tin tưởng vào quản lý, sợ bị trừng phạt hoặc kiệt sức. Hãy bắt đầu bằng khảo sát ẩn danh để hiểu nguyên nhân. Chuyển sang định dạng vui nhộn hơn (Sailboat, Mad-Sad-Glad). Giảm thời gian xuống 15-20 phút. Cho thấy giá trị: bắt đầu với những thay đổi nhỏ mà nhóm có thể thấy và đánh giá cao.
Có thể tổ chức retrospective từ xa không?
Có, retrospective từ xa được thực hiện hiệu quả qua bảng kỹ thuật số (Miro, Mural, Retrium, Google Jamboard). Sử dụng đồng hồ hẹn giờ cho các giai đoạn đồng bộ, bật video là bắt buộc cho tất cả người tham gia. Retrospective không đồng bộ cũng hoạt động: nhóm điền vào bảng trong ngày, sau đó dành 30 phút thảo luận kết quả. Retro từ xa đòi hỏi sự điều phối rõ ràng hơn.
Làm thế nào để retrospective hiệu quả hơn?
Hiệu quả của retro được cải thiện qua: luân phiên người điều phối (để không quen với một phong cách), thay đổi định dạng sau mỗi 3-4 sprint, tập trung vào action item, theo dõi nhiệm vụ đã hoàn thành ở retro tiếp theo. Sử dụng số liệu: vận tốc, số lượng lỗi, tâm trạng nhóm. Chỉ số chính của hiệu quả là những thay đổi mà nhóm thực sự đã thực hiện sau retro.
Tổng kết
- Retrospective — cuộc họp nhóm sau sprint để phân tích quy trình, không phải sản phẩm.
- Mục tiêu chính — xác định cải tiến qua suy ngẫm, bỏ phiếu và kế hoạch hành động.
- Các định dạng chính — Start-Stop-Continue, Sailboat, 4L, Mad-Sad-Glad. Lựa chọn phụ thuộc vào độ trưởng thành của nhóm.
- Kế hoạch từng bước — chuẩn bị, thu thập dữ liệu, nhóm lại, bỏ phiếu, action item với người chịu trách nhiệm.
- Sai lầm điển hình — thiếu action item, phàn nàn không giải pháp, một người thống trị, bỏ qua retro.
- Action item — kết quả chính của retro. Không có chúng, retrospective mất ý nghĩa.
- Tần suất — sau mỗi sprint. Định dạng từ xa hoạt động với sự điều phối tốt.
Chúng tôi sẽ phát triển ứng dụng di động chìa khóa trao tay
IT Sectr tạo các ứng dụng iOS và Android cho các công ty khởi nghiệp và doanh nghiệp từ năm 2017. Chúng tôi sẽ tư vấn và đề xuất giải pháp tốt nhất cho bạn.
Đọc thêm