Tóm tắt nhanh
Retrospective, hay ふりかえり, là buổi team nhìn lại cách làm việc sau sprint để cải thiện. Trong team Nhật, tinh thần 改善 rất quan trọng: nói vấn đề không phải để đổ lỗi, mà để tìm action nhỏ giúp sprint sau tốt hơn.
Bài này giúp developer Việt Nam góp ý trong retrospective bằng tiếng Nhật một cách cụ thể, lịch sự và có tác dụng.
Retrospective là gì?
レトロスペクティブ là event cuối sprint, sau sprint review. Team thường bàn:
- Nhóm
- Tốt
- Câu hỏi
- Sprint này điều gì hiệu quả?
- Nhóm
- Chưa tốt
- Câu hỏi
- Điều gì gây lãng phí, trễ, hiểu sai?
- Nhóm
- Cải thiện
- Câu hỏi
- Sprint sau thử thay đổi gì?
- Nhóm
- Action
- Câu hỏi
- Ai làm, đến khi nào, đo bằng gì?
Điểm quan trọng là action. Nếu retrospective chỉ dừng ở "cần giao tiếp tốt hơn", sprint sau sẽ không đổi. Action nên nhỏ và cụ thể.
Kaizen trong team phát triển phần mềm
改善 nghĩa là cải thiện. Trong team Scrum Nhật, kaizen có thể là:
- Vấn đề
- Story thiếu acceptance criteria
- Action kaizen cụ thể
- Trước planning, PO thêm 受入条件 cho story lớn
- Vấn đề
- Daily quá dài
- Action kaizen cụ thể
- Discussion kỹ thuật tách sau daily
- Vấn đề
- Review bị dồn cuối sprint
- Action kaizen cụ thể
- Tạo PR nhỏ hơn, gửi review sớm hơn
- Vấn đề
- Bug lặp lại
- Action kaizen cụ thể
- Thêm checklist test trước PR
- Vấn đề
- Spec hỏi quá muộn
- Action kaizen cụ thể
- Refinement thêm mục scope/API/permission
Kaizen tốt không cần lớn. Một thay đổi nhỏ nhưng được làm đều sẽ hiệu quả hơn khẩu hiệu lớn.
Cách nói vấn đề không gây đối đầu
Tránh nói kiểu đổ lỗi cá nhân. Hãy nói theo hiện tượng, ảnh hưởng và đề xuất:
- Chưa tốt
- Aさんのレビューが遅いです。
- Tốt hơn
- レビューが後半に集中し、修正時間が不足しました。
- Chưa tốt
- 仕様がいつも悪いです。
- Tốt hơn
- 受入条件が不明なストーリーがあり、実装中に確認が必要でした。
- Chưa tốt
- Dailyが長すぎます。
- Tốt hơn
- 技術相談がdaily内で長くなったため、別枠にしたいです。
Nói theo process giúp team dễ cải thiện hơn nói theo con người.
Mẫu phát biểu retrospective
今回のスプリントでは、レビュー依頼が後半に集中しました。
そのため、修正と再レビューの時間が不足しました。
次回は、PRを小さく分けて、実装完了したものから早めにレビュー依頼を出したいです。
Nghĩa là: Sprint này request review bị dồn về cuối, nên thiếu thời gian sửa và review lại. Sprint sau, tôi muốn chia PR nhỏ hơn và gửi review sớm từ phần đã hoàn thành.
Câu tiếng Nhật nên nhớ
- 日本語
- ふりかえりを行います。
- かな
- ふりかえりをおこないます
- Nghĩa tiếng Việt
- Chúng ta sẽ retrospective.
- Dùng khi nào
- Bắt đầu
- 日本語
- 良かった点です。
- かな
- よかったてんです
- Nghĩa tiếng Việt
- Điểm tốt.
- Dùng khi nào
- Nêu positive
- 日本語
- 改善したい点です。
- かな
- かいぜんしたいてんです
- Nghĩa tiếng Việt
- Điểm muốn cải thiện.
- Dùng khi nào
- Nêu issue
- 日本語
- 次回はAを試したいです。
- かな
- じかいはAをためしたいです
- Nghĩa tiếng Việt
- Sprint sau muốn thử A.
- Dùng khi nào
- Đề xuất action
- 日本語
- アクションを決めましょう。
- かな
- あくしょんをきめましょう
- Nghĩa tiếng Việt
- Hãy quyết định action.
- Dùng khi nào
- Kết luận
- 日本語
- 誰が対応しますか。
- かな
- だれがたいおうしますか
- Nghĩa tiếng Việt
- Ai sẽ phụ trách?
- Dùng khi nào
- Chốt owner
- 日本語
- 次回確認しましょう。
- かな
- じかいかくにんしましょう
- Nghĩa tiếng Việt
- Lần sau kiểm tra lại.
- Dùng khi nào
- Theo dõi action
Checklist retrospective có giá trị
- Vấn đề được mô tả bằng hiện tượng, không đổ lỗi cá nhân?
- Có ảnh hưởng cụ thể đến sprint không?
- Action đủ nhỏ để thử trong sprint sau không?
- Có owner và thời hạn không?
- Sprint sau có kiểm tra action cũ không?
Ví dụ action tốt và action mơ hồ
Retrospective dễ thất bại khi action quá chung. Ví dụ "giao tiếp tốt hơn" nghe đúng nhưng không ai biết ngày mai cần làm gì. Action tốt nên nhìn thấy được trong sprint sau.
- Action mơ hồ
- Giao tiếp tốt hơn
- Action tốt hơn
- Mỗi ticket thiếu spec sẽ comment câu hỏi trong ngày đầu sprint
- Action mơ hồ
- Review nhanh hơn
- Action tốt hơn
- PR dưới 300 dòng, gửi review trước 15:00 nếu muốn nhận feedback trong ngày
- Action mơ hồ
- Test kỹ hơn
- Action tốt hơn
- Thêm checklist 5 case regression cho màn hình login
- Action mơ hồ
- Daily ngắn hơn
- Action tốt hơn
- Discussion kỹ thuật trên 3 phút sẽ tách sau daily
Khi nói bằng tiếng Nhật, có thể dùng mẫu “次回はAを試し、ふりかえりで効果を確認したいです”. Câu này vừa đề xuất hành động, vừa nói rõ sẽ kiểm tra hiệu quả sau.
Học tiếp trên JLPTVN
Đọc thêm daily scrum tiếng Nhật, sprint review, Hou-ren-sou. Luyện giao tiếp với progress và review.
Sau khi đọc, làm bài luyện IT và lưu câu sai ở Review để quay lại đúng điểm yếu.
FAQ
Retrospective có nên nói thẳng vấn đề không?
Có, nhưng nên nói bằng hiện tượng, dữ liệu và đề xuất. Tránh công kích cá nhân.
Action retrospective nên lớn hay nhỏ?
Nên nhỏ, cụ thể và thử được trong sprint sau. Action quá lớn dễ bị bỏ quên.
Nếu team không làm action đã chốt thì sao?
Hãy nhắc lại ở retrospective sau và hỏi lý do. Có thể action quá lớn hoặc không có owner rõ.