Retrospective (thường gọi tắt là retro) là buổi họp định kỳ trong đó một nhóm làm việc theo Agile cùng nhìn lại cách mình đã làm việc trong một chu kỳ vừa qua — thường là một sprint dài một đến bốn tuần — để chọn ra một vài thay đổi thử nghiệm ở chu kỳ sau. Retro không bàn sản phẩm làm ra đúng hay sai yêu cầu, mà bàn cách nhóm phối hợp, ra quyết định, xử lý trở ngại.
Ý tưởng này có trong chính Tuyên ngôn Agile năm 2001, ở nguyên tắc cuối: theo định kỳ, nhóm suy ngẫm cách làm việc hiệu quả hơn rồi điều chỉnh hành vi cho phù hợp. Trong Scrum, sprint retrospective là sự kiện chính thức khép lại mỗi sprint.
Vấn đề là sau vài tháng, rất nhiều nhóm thấy retro nhàm: cùng một khuôn, cùng những lời phàn nàn, cùng những việc chốt rồi bỏ. Bài này giải thích cấu trúc chuẩn của một buổi retro và những cách giữ nó sống.
Gốc gác: từ tuyên ngôn Agile tới cuốn sách về retrospective
Trước khi Agile phổ biến, Norman Kerth đã viết cuốn Project Retrospectives (2001) về các buổi nhìn lại sau dự án phần mềm. Kerth đưa ra một câu được gọi là "chỉ thị tối cao" (Prime Directive), đại ý: dù phát hiện ra điều gì, chúng ta hiểu và thật sự tin rằng mỗi người đã làm tốt nhất có thể với những gì họ biết lúc đó, kỹ năng họ có, nguồn lực sẵn có và tình huống trước mặt. Nhiều nhóm đọc câu này ở đầu mỗi buổi retro.
Năm 2006, Esther Derby và Diana Larsen xuất bản Agile Retrospectives, chuyển buổi nhìn lại từ cuối dự án sang cuối mỗi chu kỳ ngắn và chia nó thành năm giai đoạn. Khung năm giai đoạn này đến nay vẫn là cách tổ chức retro phổ biến nhất.
Điểm khác biệt quan trọng so với buổi rút kinh nghiệm sau dự án là tần suất. Nhìn lại sau một dự án sáu tháng thì bài học đến quá muộn để cứu chính dự án đó. Nhìn lại mỗi hai tuần thì nhóm sửa được cách làm trong lúc việc còn đang chạy, và mỗi thay đổi đủ nhỏ để thử rồi bỏ nếu không hiệu quả.
Năm giai đoạn của một buổi retro
Theo khung của Derby và Larsen, một buổi retro đi qua năm bước. Với sprint hai tuần, cả buổi thường khoảng một đến một tiếng rưỡi; Scrum Guide đặt giới hạn tối đa ba giờ cho sprint một tháng.
| Giai đoạn | Mục đích | Ví dụ hoạt động |
|---|---|---|
| 1. Mở đầu | Giúp mọi người chuyển sự chú ý vào buổi họp và thấy an toàn để nói | Mỗi người nói một từ mô tả sprint vừa qua; nhắc lại mục tiêu buổi retro |
| 2. Thu thập dữ kiện | Dựng lại bức tranh chung về những gì đã xảy ra | Dòng thời gian sprint, các sự kiện đáng nhớ, số liệu công việc hoàn thành |
| 3. Tìm hiểu nguyên nhân | Hiểu vì sao các sự việc diễn ra như vậy | Gom nhóm ý kiến, hỏi "vì sao" nhiều tầng, tìm điểm chung |
| 4. Quyết định việc làm | Chọn một vài thử nghiệm cho sprint sau | Bỏ phiếu chọn ưu tiên, viết hành động cụ thể có người phụ trách |
| 5. Khép lại | Kết thúc gọn, ghi nhận đóng góp, cải tiến chính buổi retro | Mỗi người nói một điều cần giữ hoặc đổi trong cách chạy retro |
Lỗi phổ biến nhất là nhảy thẳng từ giai đoạn 2 sang giai đoạn 4: liệt kê vấn đề rồi lập tức đề xuất giải pháp. Bỏ qua bước tìm nguyên nhân thì giải pháp thường chỉ chữa triệu chứng, và sprint sau vấn đề cũ lại xuất hiện dưới hình dạng khác.
Các khuôn retro hay dùng và mỗi khuôn hợp với lúc nào
Start – Stop – Continue. Nên bắt đầu làm gì, nên thôi làm gì, nên tiếp tục gì. Đơn giản, hợp cho nhóm mới làm retro, nhưng dễ nhàm vì ý kiến lặp lại.
Mad – Sad – Glad. Điều gì khiến bạn bực, buồn, vui trong sprint. Khuôn này đưa cảm xúc lên bàn, hợp khi nhóm vừa trải qua giai đoạn căng thẳng và cần nói ra trước khi bàn giải pháp.
4L: Liked – Learned – Lacked – Longed for. Điều thích, điều học được, điều thiếu, điều mong muốn. Cân bằng giữa tích cực và vấn đề, hợp cho nhìn lại sau một bản phát hành.
Thuyền buồm. Gió đẩy thuyền (điều giúp nhóm), mỏ neo (điều kìm lại), đá ngầm (rủi ro phía trước), hòn đảo (mục tiêu). Hình ảnh giúp nhóm nói về rủi ro mà không cần gọi tên ai.
Dòng thời gian. Vẽ trục thời gian của sprint, mỗi người đặt các sự kiện và mức năng lượng của mình lên đó. Hợp khi sprint có nhiều biến cố hoặc khi nhóm hiểu sự việc rất khác nhau.
Retro theo một chủ đề. Cả buổi chỉ bàn một vấn đề đã lặp lại nhiều lần, ví dụ việc ước lượng hay phối hợp với nhóm khác. Hợp khi những retro chung chung không còn ra được gì mới.
Vì sao retro thành thủ tục, và cách gỡ từng nguyên nhân
Khi người ta nói "retro chẳng để làm gì", nguyên nhân gần như luôn nằm ở một trong những điểm sau:
- Hành động không được làm. Đây là nguyên nhân số một. Gỡ bằng cách mở mỗi buổi retro bằng việc nhìn lại hành động lần trước: đã làm chưa, có tác dụng không. Đưa hành động retro vào chính danh sách việc của sprint, không để ở một tài liệu riêng.
- Luôn một khuôn. Cùng ba cột mỗi hai tuần thì sau vài lần ai cũng biết mình sẽ viết gì. Đổi khuôn theo tình hình nhóm, hoặc luân phiên người điều phối để mỗi người mang một cách làm mới.
- Vấn đề nằm ngoài tầm tay nhóm. Nhóm phàn nàn mãi về một quy trình do bộ phận khác quyết định. Tách rõ việc nhóm tự làm được và việc cần chuyển lên trên; với loại sau, chốt ai mang lên, mang lên ai, khi nào.
- Không ai dám nói thật. Khi có cấp quản lý ngồi trong phòng hoặc khi lời phát biểu từng bị dùng để đánh giá cá nhân, retro chỉ còn những câu an toàn. Cân nhắc cho viết ẩn danh ở giai đoạn thu thập ý kiến.
- Bàn quá nhiều chuyện. Mười vấn đề trong một giờ thì mỗi vấn đề được sáu phút. Bỏ phiếu chọn một hai vấn đề để đào sâu, phần còn lại ghi nhận và để sau.
Người điều phối retro làm gì, và ai nên làm
Trong Scrum, người hay điều phối retro là Scrum Master, nhưng không bắt buộc. Nhiều nhóm luân phiên mỗi sprint một người, vừa để chia việc vừa để ai cũng hiểu cảm giác đứng ở vị trí giữ nhịp. Điều cần tránh là để trưởng nhóm kỹ thuật hoặc quản lý trực tiếp điều phối thường xuyên, vì lời họ có sức nặng khiến người khác ngại phản bác.
Việc của người điều phối là chuẩn bị khuôn phù hợp, giữ thời gian, đảm bảo mọi người đều được nói, và kéo nhóm từ than phiền sang hành động. Họ không đưa kết luận, không bênh bên nào. Khi một người chiếm sân, người điều phối mời người khác; khi buổi họp sa vào đổ lỗi, họ đưa câu hỏi trở lại tình huống: "điều gì trong cách nhóm làm việc khiến chuyện này dễ xảy ra?".
Một kỹ năng hay bị đánh giá thấp là chịu được khoảng lặng. Sau khi đặt câu hỏi, người điều phối mới vào nghề thường vội lấp chỗ trống bằng ý của mình. Đợi thêm mười giây thường là lúc người ít nói nhất trong phòng lên tiếng.
Một buổi retro sáu mươi phút mẫu
Ví dụ giả định cho một nhóm bảy người vừa xong sprint hai tuần có nhiều lỗi phát sinh sau khi phát hành:
- 5 phút — mở đầu: người điều phối đọc lại Prime Directive, mỗi người nói một từ về sprint. Xem lại ba hành động của retro trước và tình trạng của chúng.
- 15 phút — dòng thời gian: mỗi người dán các sự kiện quan trọng lên trục thời gian hai tuần, đánh dấu chỗ mình thấy căng nhất.
- 15 phút — tìm nguyên nhân: nhóm gom các sự kiện liên quan đến lỗi phát hành, hỏi vì sao vài tầng. Phát hiện ví dụ: phần kiểm thử dồn hết vào hai ngày cuối.
- 15 phút — quyết định: bỏ phiếu chọn một thay đổi chính, ví dụ mỗi tính năng phải có người thứ hai kiểm trước khi chuyển trạng thái xong. Ghi người theo dõi và cách biết nó có tác dụng.
- 10 phút — khép lại: mỗi người nói một điều về buổi retro hôm nay nên giữ hoặc đổi. Người điều phối gửi bản ghi ngắn cho nhóm trong ngày.
Để ý rằng buổi này chốt một thay đổi chính, không phải năm. Một thay đổi được làm thật và đo được tác dụng có giá trị hơn nhiều thay đổi chỉ nằm trên giấy, và nó cho nhóm bằng chứng rằng retro dẫn tới điều gì đó.
Retro cho nhóm không làm phần mềm
Retro sinh ra trong giới phần mềm nhưng cấu trúc của nó không có gì riêng của phần mềm. Một nhóm chăm sóc khách hàng có thể nhìn lại mỗi hai tuần về những loại yêu cầu bị xử lý chậm; một nhóm nội dung có thể nhìn lại quy trình duyệt bài; một tổ bộ môn trong trường học có thể nhìn lại cách phối hợp ra đề và chấm bài sau mỗi đợt kiểm tra.
Khi đưa retro ra ngoài phần mềm, vài thứ cần đổi. Nhịp: nhóm không có sprint thì chọn nhịp theo chu kỳ tự nhiên của công việc — cuối tháng, cuối đợt, cuối học kỳ. Từ ngữ: bỏ thuật ngữ như sprint, backlog, thay bằng cách gọi quen thuộc của nhóm, để không ai thấy mình đang bị ép theo một phong trào. Dữ kiện: nhóm phần mềm có sẵn số liệu công việc hoàn thành, nhóm khác cần chủ động gom vài con số đơn giản trước buổi họp, ví dụ số yêu cầu tồn hay số lần phải làm lại.
Điều giữ nguyên là tinh thần: nhìn vào cách nhóm làm việc chứ không vào năng lực từng người, chọn ít thay đổi và làm thật, rồi quay lại kiểm vào lần sau. Một buổi nhìn lại bốn mươi lăm phút mỗi tháng theo đúng năm giai đoạn đã đủ khác biệt so với cuộc họp giao ban thông thường.
Câu hỏi thường gặp
Retro và sprint review khác nhau thế nào?
Sprint review nhìn vào sản phẩm: nhóm trình bày phần việc đã làm với các bên liên quan và nhận góp ý về sản phẩm. Retrospective nhìn vào cách làm việc: chỉ nhóm với nhau bàn về phối hợp, quy trình và công cụ. Gộp hai buổi làm một thường khiến phần nhìn lại cách làm bị lấn mất.
Quản lý có nên ngồi dự retro không?
Tuỳ mức tin cậy trong nhóm. Nếu quản lý là người đánh giá thành tích của các thành viên, sự có mặt của họ dễ khiến buổi retro dè dặt. Nhiều nhóm chọn cách để quản lý vắng mặt và chỉ nhận lại những vấn đề nhóm cần hỗ trợ từ bên trên.
Nhóm làm từ xa thì chạy retro thế nào?
Dùng bảng trắng chung trên mạng, cho mọi người viết ý cùng lúc trong vài phút rồi mới thảo luận, và yêu cầu bật hình nếu nhóm thấy thoải mái. Buổi trực tuyến nên ngắn hơn và có quãng nghỉ, vì sự chú ý qua màn hình giảm nhanh hơn ngồi chung phòng.
Có cần làm retro nếu nhóm không theo Scrum không?
Không cần gọi là retro, nhưng nhịp nhìn lại đều đặn có ích cho mọi nhóm, kể cả nhóm kinh doanh hay vận hành. Một buổi bốn mươi lăm phút mỗi hai tuần hoặc mỗi tháng, theo đúng năm giai đoạn, là đủ để nhóm có thói quen tự sửa cách làm.
Làm sao biết retro của nhóm có hiệu quả?
Nhìn vào hai dấu hiệu: các hành động chốt ra có được làm và có tạo khác biệt không, và các vấn đề cũ có thôi lặp lại không. Nếu sau vài tháng nhóm vẫn nêu đúng những vấn đề ấy, buổi retro đang dừng ở mức than phiền.
Nên làm gì khi retro lộ ra mâu thuẫn giữa hai người?
Không giải quyết mâu thuẫn cá nhân giữa buổi họp chung. Người điều phối ghi nhận rằng có vấn đề phối hợp, đưa câu chuyện về mức quy trình, rồi sau buổi họp gặp riêng từng người hoặc nhờ trưởng nhóm hỗ trợ cuộc nói chuyện riêng giữa hai bên.