Nền tảng
Nhịp làm việc
Lịch cố định của đội theo ngày, tuần, hai tuần và quý. Mỗi buổi có mục đích riêng, có đầu ra riêng, và không được biến thành buổi báo cáo tiến độ.
Nội dung bài
Vì sao cần nhịp cố định
Không có nhịp, việc điều phối rơi vào tin nhắn: ai nhớ thì hỏi, ai rảnh thì trả lời, thông tin quan trọng nằm rải rác trong các đoạn chat. Có nhịp cố định thì mọi người biết trước khi nào được hỏi, khi nào được nghe, và không cần ngắt nhau giữa lúc đang tập trung.
Nhịp cũng là cách kiểm soát rẻ nhất: đều đặn nhìn lại thì lệch nhỏ được sửa sớm, thay vì tích lại thành lệch lớn.
Bảng nhịp
| Buổi | Tần suất | Thời lượng | Ai dự | Đầu ra bắt buộc |
|---|---|---|---|---|
| Standup | Hằng ngày | 15 phút | Cả đội làm việc | Danh sách vướng mắc cần gỡ trong ngày |
| Soát backlog | Hằng ngày, sau đồng bộ | 10 phút | Chủ sản phẩm, chủ kỹ thuật | Backlog phản ánh đúng thực tế |
| Chuẩn bị hạng mục | Giữa tuần | 60 phút | Chủ sản phẩm, chủ kỹ thuật, vài dev | Hạng mục đủ điều kiện để nhận làm |
| Chốt việc sprint | Đầu sprint hai tuần | 60 phút | Cả đội | Cam kết phạm vi của sprint |
| Tổng kết sprint | Cuối sprint hai tuần | 45 phút | Cả đội + khách mời | Bản chạy được, đã trình diễn |
| Retro | Cuối sprint hai tuần | 45 phút | Cả đội | 1–3 thay đổi có người nhận |
| Soát sức khoẻ hệ thống | Hằng tuần | 30 phút | Chủ kỹ thuật, chủ module | Danh sách chỉ số xấu đi + việc sửa |
| Soát mục tiêu quý | Hằng tháng | 60 phút | Chủ sản phẩm, chủ kỹ thuật | Cập nhật tiến độ mục tiêu trên sổ tay |
| Đặt mục tiêu quý | Đầu quý | 3 giờ | Cả đội | Mục tiêu quý có số đo |
Standup hằng ngày
Ba câu, mỗi người dưới một phút:
- Hôm qua tôi đẩy được cái gì qua quality gate?
- Hôm nay tôi làm cái gì?
- Cái gì đang chặn tôi?
Đây không phải buổi báo cáo cho quản lý. Nó là buổi để đội tự phát hiện ai đang kẹt. Câu 3 là câu quan trọng nhất; hai câu đầu chỉ để dẫn tới nó. Mọi thảo luận dài hơn hai phút đều tách ra sau buổi, chỉ với người liên quan.
Dấu hiệu buổi này đang hỏng: mọi người đọc lại y nguyên thẻ trên backlog, và không ai từng nói câu "tôi đang kẹt".
Chuẩn bị hạng mục
Buổi quan trọng nhất mà các đội hay bỏ. Mục đích: biến ý tưởng mơ hồ thành hạng mục đủ điều kiện nhận làm — có mô tả, có acceptance criteria, có người biết đủ để ước lượng.
Quy tắc: hạng mục chưa qua buổi này thì không được đưa vào sprint. Đây là cách chặn hiệu quả nhất việc dev nhận một thẻ rồi ngồi đoán ý.
Tổng kết sprint
Trình diễn trên bản chạy thật, không trình chiếu, không ảnh chụp màn hình. Thứ gì không demo được trên máy thật thì coi như chưa xong.
Người xem được phép hỏi và được phép nói "cái này không đúng ý tôi". Nghe khó chịu, nhưng nghe lúc này rẻ hơn nghe từ người dùng sau khi release.
Retro
Không phải nơi than phiền. Cấu trúc cố định, xem biểu mẫu retro.
Điều bắt buộc: kết thúc buổi phải có 1 đến 3 thay đổi cụ thể, mỗi thay đổi có tên một người và một thời hạn. Buổi cải tiến không sinh ra thay đổi có chủ thì lần sau khỏi họp, vì nó chỉ đang tiêu thời gian.
Mở đầu buổi sau luôn là: các thay đổi lần trước làm tới đâu rồi?
Soát sức khoẻ hệ thống
30 phút nhìn số, không nhìn việc:
- Tỷ lệ phiên không crash tuần này so với tuần trước.
- Thời gian khởi động, thời gian phản hồi các luồng chính.
- Số lỗi mới mở, số lỗi đóng, số lỗi tồn đọng quá 30 ngày.
- Thời gian trung bình một pull request nằm chờ review.
- Tỷ lệ bản release phải rollback.
Chỉ số nào xấu đi hai tuần liên tiếp thì mở một hạng mục sửa, có người nhận. Không có ngoại lệ "để tuần sau xem lại".
Luật chung cho mọi buổi
- Buổi nào không có đầu ra bắt buộc thì buổi đó bị huỷ khỏi lịch.
- Đi trễ thì buổi vẫn bắt đầu đúng giờ.
- Không có chương trình từ trước thì không họp.
- Kết luận được ghi lại ngay trong buổi, không hẹn ghi sau.
- Ai không cần cho quyết định thì không cần dự — không dự họp không phải là bị bỏ rơi.