Viết tài liệu trong Agile

VIẾT TÀI LIỆU TRONG AGILE

• Agile là không cần tài liệu (Document)?
• Không có document thì làm sao người mới đến có thể hiểu hệ thống?
• Không có document làm sao bảo trì và vận hành hệ thống về sau?
• Không có tài liệu làm sao biết làm sai hay đúng?
• Viết tài liệu đến đâu là đủ?

Có rất nhiều tranh cãi hay hiểu lầm với việc viết tài liệu trong môi trường Agile. Trong bài viết này mình muốn cung cấp thêm thông tin làm rõ như sau:

Trước hết hãy bắt đầu với giá trị số 2 trong bảng tuyên ngôn Agile: “Working software over comprehensive documentation”:

• Thứ khách hàng muốn là sản phẩm, không phải tài liệu. Chúng ta viết tài liệu là để làm sản phẩm. Ví dụ một dự án mà mất đi 40%-60% thời gian cho việc viết tài liệu thì thật quá lãng phí!
• Môi trường Agile có nhiều thay đổi, bỏ ra một tháng viết tài liệu: Yêu cầu, thiết kế… với hàng trăm trang, đến khi có thay đổi chúng ta mất bao nhiêu thời gian vì vứt bỏ, cập nhật nó?
• Viết tài liệu quá sớm, sau 5-7 tháng mới làm thì những thông tin trong não của chúng ta – cơ sở để viết ra tài liệu bị bay hơi – dẫn đến sai sót hay mất thời gian phục hồi.
• Việc thiết lập functional team dẫn đến nhu cầu giao tiếp giữa các teams, tự nhiên phát sinh nhu cầu quá lớn về tài liệu – công cụ cho việc giao tiếp và thông tin giữa các team.
• Như vậy, nếu có chiến lược nào đó giúp giảm 50%-70% số tài liệu mà vẫn có sản phẩm chất lượng thì thật hoàn hảo phải không?

​

CHIẾN LƯỢC – Giúp Agile tối thiểu về tài liệu:

1. Tổ chức cross-functional team thay vì functional team: Mục tiêu và kế hoạch chi tiết Agile ngắn trong vài tuần (để có thể nhớ), kết hợp khả năng colocation và F-2-F của KH trực tiếp với team (Direct) làm thông tin đi trực tiếp từ người (não) đến người (não) mà không cần qua trung gian – tài liệu.
2. Tài liệu chết -> tài liệu sống: Thay vì đầu tư thời gian cho những tài liệu như thiết kế chi tiết kỹ thuật, thiết kế chức năng… hãy biến chúng thành tài liệu sống, tài liệu dùng được, chạy được: Tuân thủ coding standard, comment trực triếp trên code, viết và comment rõ cho test cases… khi đọc code hay test (automation) chúng ta sẽ hiểu thông tin sản phẩm.
3. Just- In-Time (JIT): Agile chỉ viết tài liệu khi thực sự cần – Sprint tới team cần yêu cầu chi tiết để phát triển US số 1 (Progressive elaboration). Thì Sprint này mới cần chuẩn chỉnh về tài liệu. Điều này giúp loại bỏ tối đa lãng phí dẫn đến từ các nhu cầu thay đổi trong quá trình phát triển sản phẩm.
4.  Barely Sufficient: Giữ tài liệu ở mức tối thiểu, thực sự cần thiết cho quá trình phát triển. Không thừa mà cũng không thiếu! Thừa gây lãng phí thời gian, thiếu gây rủi ro hay ảnh hưởng xấu đến tiến trình phát triển. Tài liệu tối thiểu như yêu cầu, tiêu chí nghiệm thu từ khách hàng (Fearure, user story)… Tài liệu ưu tiên góc nhìn tổng quát, hạn chế quá chi tiết khi có thể. Ví dụ tổng thể kiến trúc, luồng nghiệp vụ, luồng phát triển…
5. Bớt Formal document: Đầu tư một tài liệu dùng lâu dài như là đầu tư cho một sản phẩm, nó tốn rất nhiều thời gian và tiền bạc để tạo ra, duy trì, cập nhật…. vậy nên hãy ưu tiên informal document như hình vẽ trên bảng, hình ảnh, wiki…
6. Agile Team ► Product Team ổn định và lâu dài với sản phẩm chứ không phải Project Team sớm lập, chiều giải tán!