Câu trả lời được chấp nhận
Nguyễn Thu Hà, PMP
Tuyên ngôn Agile (2001) viết rằng phần mềm chạy được được coi trọng hơn tài liệu toàn diện — và ngay cuối tuyên ngôn có câu then chốt mà nhiều người bỏ qua: các mục bên phải vẫn có giá trị, chỉ là các mục bên trái được coi trọng hơn. Tức là tuyên ngôn nói về thứ tự ưu tiên, không phải loại bỏ tài liệu.
Nguyên tắc số 6 sau tuyên ngôn còn cho biết cách truyền thông tin hiệu quả nhất trong đội là trò chuyện trực tiếp — tài liệu không nên thay thế hội thoại, nhưng hội thoại cũng không lưu lại được cho người đến sau.
Gợi ý phân loại tài liệu
| Nên giữ (và giữ cập nhật) | Có thể giảm mạnh |
|---|---|
| Quyết định kiến trúc quan trọng và lý do | Đặc tả chi tiết viết trước toàn bộ |
| Hướng dẫn vận hành, xử lý sự cố | Biên bản họp dài dòng |
| Yêu cầu pháp lý, bảo mật, kiểm toán | Báo cáo trạng thái trùng với bảng công việc |
| Hợp đồng giao diện (API) giữa các hệ thống | Tài liệu "để cho có" không ai đọc |
| Tài liệu cho người dùng cuối | Bản sao của thông tin đã có trong code/công cụ |
Giữ tài liệu không lỗi thời
- Đưa yêu cầu cập nhật tài liệu vào Definition of Done (ví dụ: "hướng dẫn vận hành được cập nhật nếu có thay đổi cấu hình").
- Ưu tiên tài liệu sống gần code: README, mô tả API sinh tự động, kiểm thử chấp nhận viết dạng dễ đọc.
- Ghi quyết định (ngắn, có ngày, có lý do) thay vì mô tả mọi thứ.
- Hỏi "ai sẽ đọc tài liệu này và để làm gì?" trước khi viết.
Trong tình huống ở câu hỏi, rủi ro mất tri thức và yêu cầu kiểm toán là hai lý do chính đáng để có tài liệu — đó chính là "giá trị của mục bên phải".
Nguồn: