Agile & Scrum

Tuyên ngôn Agile (Agile Manifesto, 2001) không phủ nhận vế bên phải, mà nói rằng vế bên trái được coi trọng hơn:

Scrum xây trên nền tảng quy trình thực nghiệm (empirical process control): ra quyết định dựa trên những gì quan sát được, qua 3 trụ cột:

• Minh bạch (transparency) — mọi người nhìn thấy cùng một thực tế: tiến độ, công việc, định nghĩa hoàn thành. Không minh bạch thì thanh tra vô nghĩa.
• Thanh tra (inspection) — thường xuyên kiểm tra artifact và tiến độ so với mục tiêu để sớm phát hiện sai lệch.
• Thích nghi (adaptation) — khi phát hiện lệch hướng, điều chỉnh ngay (sản phẩm hoặc cách làm), không chờ đến cuối dự án.

Năm giá trị Scrum nâng đỡ ba trụ cột này: Cam kết, Tập trung, Cởi mở, Tôn trọng, Can đảm (Commitment, Focus, Openness, Respect, Courage).

Scrum chỉ định nghĩa một nhóm (Scrum Team) gồm ba trách nhiệm, không có thứ bậc sếp–lính bên trong:

Mọi sự kiện đều có hộp thời gian (time-box) cố định, tạo nhịp đều và giảm họp hành ngoài kế hoạch. Thời lượng dưới đây tính cho sprint chuẩn 1 tháng (co giãn theo độ dài sprint):

Backlog Refinement (chải chuốt backlog) là hoạt động liên tục, không phải sự kiện chính thức — giúp các hạng mục đầu backlog luôn rõ ràng và đủ nhỏ để chọn vào sprint.

Definition of Done (DoD) là bộ tiêu chí chất lượng chung cho mọi hạng mục: ví dụ đã code xong, có unit test, qua code review, qua kiểm thử, cập nhật tài liệu, deploy được lên môi trường staging. Một việc chỉ "Done" khi thỏa toàn bộ DoD — nhờ đó "xong" có cùng một nghĩa với cả nhóm, đảm bảo minh bạch.

Definition of Ready (DoR) là tiêu chí để một hạng mục đủ rõ để đưa vào sprint: đã có mô tả, acceptance criteria, ước lượng, không phụ thuộc chặn. DoR canh đầu vào, DoD canh đầu ra. DoR là thông lệ tốt (không nằm trong Scrum Guide); tránh dùng nó như cổng quan liêu cứng nhắc.

User Story mô tả một nhu cầu nhỏ, có giá trị, theo góc nhìn người dùng, theo công thức kinh điển:

# mẫu user story
Là <vai trò>, tôi muốn <mục tiêu> để <lợi ích>.

# ví dụ
Là khách mua hàng, tôi muốn lưu giỏ hàng giữa các lần đăng nhập
để không phải chọn lại sản phẩm.

Một story tốt thỏa tiêu chí INVEST:

Mỗi story đi kèm acceptance criteria (tiêu chí chấp nhận) — các điều kiện cụ thể để coi là làm đúng, thường viết theo dạng Given / When / Then. Kích cỡ tương đối của story được biểu thị bằng story point (thường dùng dãy Fibonacci 1, 2, 3, 5, 8...) thay vì giờ — sẽ đi sâu ở Bài 4.

Kanban là phương pháp dòng chảy liên tục (continuous flow): không chia sprint, việc được kéo qua quy trình khi có năng lực. Bốn thực hành cốt lõi:

• Trực quan hóa luồng bằng bảng Kanban với các cột trạng thái, ví dụ To Do → Doing → Done.
• Giới hạn WIP (work-in-progress) — đặt trần số việc đồng thời ở mỗi cột để tránh ôm đồm, buộc nhóm làm xong rồi mới nhận việc mới, từ đó tối ưu flow.
• Cơ chế kéo (pull) — chỉ kéo việc mới vào khi có chỗ trống, thay vì đẩy (push) việc xuống nhóm.
• Đo & cải tiến flow qua lead time (từ lúc yêu cầu xuất hiện đến lúc giao xong) và cycle time (từ lúc bắt tay làm đến lúc xong).

So sánh nhanh Scrum và Kanban:

Khi một sản phẩm cần nhiều nhóm cùng làm, có vài khung điều phối phổ biến: