Nguyên tắc 3: Iterative Improvement

Spec không cần hoàn hảo ngày đầu. Nó cần tốt lên sau mỗi vòng.

Spec là tài liệu sống. Điều nguy hiểm không phải là spec phải sửa, mà là code thay đổi liên tục còn spec thì đứng yên.

Tình huống

UC-042 (đặt hàng QR): vòng đầu chỉ có Main Flow + 2 Exception rõ nhất, đủ để AI viết code, test pass, demo. Rồi thực tế dạy thêm:

• Vòng 2: user mất mạng lúc thanh toán → đơn xử lý duplicate → thêm AC về idempotency.
• Vòng 3: kế toán phát hiện hủy đơn đã thanh toán cần ghi sổ ngược → thêm exception + flow refund.

Không có nghĩa vòng đầu thất bại - team đang học domain qua thực tế.

Cách áp dụng

• Time-box buổi viết spec đầu tiên: một use case vừa phải chỉ cần 1-2 giờ cho vòng đầu.
• Mỗi spec có ## History:

  ## History
  - v1: initial
  - v2: added AC-4 for idempotency after UAT
  - v3: clarified refund flow for paid orders

• AC cũ không còn đúng thì đánh dấu deprecated thay vì xóa - lịch sử đó giúp người mới hiểu vì sao rule hiện tại tồn tại.

EM đừng chỉ hỏi “spec đã đầy đủ chưa?“. Hãy hỏi “sau mỗi sprint, spec có học được gì mới không?”

Liên quan

• Sáu nguyên tắc Spec-Driven - nguyên tắc số 3
• SDD không phải Waterfall - vì sao SDD vẫn là vòng lặp
• Spec hiện tại và Spec thay đổi - cơ chế giữ quy trình mềm