Từ ý tưởng đến release

Sáu chặng

1. THU THẬP  →  2. LÀM RÕ  →  3. QUYẾT ĐỊNH  →  4. HIỆN THỰC  →  5. KIỂM SOÁT  →  6. PHÁT HÀNH
   ai cũng      chủ sản        chủ sản           lập trình        review +          rollback
   đề xuất      phẩm + kỹ      phẩm chốt         viên             test + CI     được
                thuật          ưu tiên

Mỗi chặng có điều kiện vào và điều kiện ra. Việc chưa đủ điều kiện ra thì không sang chặng sau, kể cả khi người ta sốt ruột. Nhảy cóc một chặng luôn rẻ hơn ở thời điểm nhảy và đắt hơn nhiều ở thời điểm phát hiện.

Chặng 1 — Thu thập

Ai làm: bất kỳ ai. Dev, test, kinh doanh, người dùng.

Mọi ý tưởng, lỗi, phàn nàn đều vào một chỗ duy nhất. Không nhận yêu cầu qua tin nhắn riêng, không nhận qua lời nói lúc uống cà phê. Ai nói miệng thì trả lời: "anh mở giúp em một mục trên bảng", và không làm cho tới khi có.

Nghe cứng nhắc, nhưng đây là cách duy nhất để cuối tuần nhìn lại biết được đội đã từ chối gì và nhận gì. Yêu cầu không ghi lại thì không quản lý được.

Điều kiện ra: có tiêu đề, có người đề xuất, có mô tả vấn đề (không phải mô tả giải pháp).

Chặng 2 — Làm rõ

Ai làm: chủ sản phẩm cùng chủ kỹ thuật, trong buổi chuẩn bị hạng mục hằng tuần.

Câu hỏi phải trả lời xong ở chặng này:

Vấn đề thật sự là gì? Ai đang đau? Đau cỡ nào?
Không làm thì sao?
Có cách nào rẻ hơn mà giải quyết được 80% không?
Thuộc module nào? Có chạm ranh giới module khác không?
Acceptance criteria là gì — làm sao biết là xong?

Điều kiện ra: hạng mục đạt Definition of Ready. Chưa đạt thì quay về chặng 1, không được đẩy sang chặng 3.

Chặng 3 — Quyết định ưu tiên

Ai làm: chủ sản phẩm chốt, chủ kỹ thuật nói về sức chứa.

Ở đây trả lời đúng một câu: việc này có vào sprint tới không, và nếu vào thì đổi lấy việc gì đi ra. Sức chứa của đội là hữu hạn; thêm vào mà không lấy ra chỉ là cách trì hoãn có tổ chức.

Cách xếp thứ tự: xem Ưu tiên công việc.

Điều kiện ra: hạng mục nằm trong sprint, có người nhận, có ước lượng.

Chặng 4 — Hiện thực

Ai làm: lập trình viên nhận việc.

Việc dev phải làm ở chặng này được liệt kê đầy đủ trong Điều bắt buộc với lập trình viên. Tóm tắt:

Tách branch từ branch main, đặt tên theo quy ước.
Chia thành các lô nhỏ, mỗi lô đẩy lên trong ngày.
Tự test trước khi mở pull request.
Cập nhật tài liệu nếu thay đổi hành vi công khai.

Điều kiện ra: pull request mở, quality gate tự động xanh, tự rà theo danh sách kiểm tra.

Chặng 5 — Kiểm soát

Ai làm: người review, tester, máy.

Ba lớp chạy song song, không thay thế nhau:

Lớp	Kiểm cái gì	Chặn được gì
Máy	Định dạng, lỗi tĩnh, test tự động, coverage, kích thước gói	Lỗi lặp lại, lỗi cẩu thả
Review	Ý định, thiết kế, khả năng đọc, rủi ro ngầm	Lỗi tư duy, nợ kỹ thuật mới
Test	Luồng người dùng thật trên máy thật	Lỗi tích hợp, trải nghiệm kỳ quặc

Điều kiện ra: đạt đủ Definition of Done.

Chặng 6 — Release

Ai làm: người phụ trách bản release.

Không phải cứ merge vào branch main là tới tay người dùng. Thay đổi nằm sau feature flag, bật dần theo tỷ lệ, có số liệu theo dõi, có đường rollback.

Điều kiện ra: đã bật 100%, số liệu ổn định qua 48 giờ, cờ được dọn khỏi code.

Việc gấp thì sao

Có hai loại gấp, xử lý khác nhau:

Loại	Ví dụ	Cách xử lý
Sự cố đang diễn ra	App crash hàng loạt, không chốt được đơn	Bỏ qua chặng 1–3, vào thẳng quy trình xử lý sự cố. Vẫn phải review và test.
Sếp muốn gấp	Khách lớn hỏi, đối thủ vừa ra tính năng	Vào chặng 2 với độ ưu tiên cao. Vẫn phải đổi lấy việc khác đi ra.

Ranh giới này phải giữ chặt. Nếu loại thứ hai cũng được nhảy cóc như loại thứ nhất, sau vài tháng mọi việc đều gấp và quy trình chỉ còn trên giấy.

Dấu hiệu quy trình đang bị lách

Có code trên branch main mà không tìm thấy hạng mục tương ứng.
Hạng mục chuyển thẳng từ "mới" sang "đang làm" mà chưa từng qua buổi chuẩn bị.
Pull request được merge với quality gate màu đỏ, kèm lời hứa "sửa sau".
Acceptance criteria bị sửa sau khi code đã viết xong.

Thấy dấu hiệu nào thì nêu ngay trong buổi cải tiến gần nhất. Lách quy trình không phải lỗi cá nhân — thường là dấu hiệu quy trình đang cản trở thật, cần sửa quy trình.