Viết yêu cầu cho các dự án phần mềm thường tạo ra khoảng cách giao tiếp. Các nhà phát triển nói bằng mã code. Các bên liên quan kinh doanh nói bằng giá trị. Tiêu chí chấp nhận (AC) nằm ở giữa, đóng vai trò như cây cầu nối giữa những gì cần thiết và những gì được xây dựng. Khi cây cầu này được xây dựng bằng thuật ngữ kỹ thuật, nó trở nên không ổn định. Những thành viên không chuyên không thể xác minh xem công việc có đúng hay không. Các bên liên quan mất niềm tin vào quy trình. Hướng dẫn này giải thích cách viết Tiêu chí chấp nhận mà không dùng thuật ngữ kỹ thuật, đảm bảo sự rõ ràng, hợp tác và giao hàng chất lượng.
🧩 Tiêu chí chấp nhận là gì?
Tiêu chí chấp nhận xác định các điều kiện mà một sản phẩm phần mềm phải đáp ứng để được người dùng hoặc bên liên quan chấp nhận. Chúng không phải là danh sách các tính năng, mà là định nghĩa về ranh giới. Chúng trả lời câu hỏi: “Hoàn thành nghĩa là như thế nào?”. Trong bối cảnh của một Câu chuyện Người dùng, AC cung cấp chi tiết cần thiết để đảm bảo đội phát triển hiểu rõ phạm vi.
Tiêu chí chấp nhận hiệu quả nên có:
- Rõ ràng:Không mơ hồ. Mọi người đều hiểu cùng một ý nghĩa.
- Có thể kiểm thử:Bạn có thể viết một trường hợp kiểm thử để xác minh chúng.
- Cụ thể:Chúng sử dụng các con số và trạng thái cụ thể, chứ không phải các thuật ngữ mơ hồ.
- Dễ tiếp cận:Chúng được viết bằng ngôn ngữ mà toàn bộ đội hiểu được.
🗣️ Tại sao thuật ngữ kỹ thuật lại làm hại sự hợp tác
Khi các nhà phát triển viết Tiêu chí chấp nhận, họ có xu hướng tự nhiên là mô tả chi tiết triển khai. Điều này xảy ra vì họ biết hệ thống hoạt động như thế nào. Tuy nhiên, mô tả giải pháp trước khi vấn đề được giải quyết sẽ tạo ra rủi ro. Nó làm hạn chế tính linh hoạt và gây nhầm lẫn cho những người không lập trình.
Chi phí của sự hiểu lầm
Hãy xem xét một tình huống mà một bên liên quan đọc một yêu cầu và hiểu theo một nghĩa khác với nhà phát triển. Sự khác biệt này dẫn đến công việc phải làm lại. Việc làm lại tốn thời gian và ngân sách. Nó cũng làm chậm tiến độ đưa giá trị ra thị trường. Tránh dùng thuật ngữ sẽ giảm khả năng xảy ra khoảng cách này.
- Nhà phát triển:Có thể tập trung vào các trường cơ sở dữ liệu thay vì kết quả người dùng.
- Người kiểm thử QA:Có thể không biết cách xác minh hành vi nếu không hiểu cấu trúc API.
- Chủ sở hữu kinh doanh:Có thể duyệt câu chuyện vì nghĩ nó đáp ứng nhu cầu của họ, chỉ để phát hiện ra nó không đáp ứng.
Những thuật ngữ kỹ thuật phổ biến cần tránh
Để giữ cho tiêu chí dễ tiếp cận, một số từ cần được thay thế bằng các từ ngữ đơn giản tương đương. Mục tiêu là mô tả hành vi, chứ không phải cơ chế.
- Tránh dùng:“Cập nhật bản ghi cơ sở dữ liệu.”
Dùng:“Lưu thông tin khách hàng.” - Tránh dùng: “Gọi điểm cuối API.”
Sử dụng: “Gửi yêu cầu đến máy chủ.” - Tránh: “Hiển thị thành phần.”
Sử dụng: “Hiển thị nút trên màn hình.” - Tránh: “Ném một ngoại lệ.”
Sử dụng: “Hiển thị thông báo lỗi.”
📝 Nguyên tắc của Yêu cầu Ngôn ngữ Rõ ràng
Viết mà không dùng thuật ngữ đòi hỏi sự kỷ luật. Nó yêu cầu bạn phải rời xa giải pháp kỹ thuật và tập trung vào trải nghiệm người dùng. Các nguyên tắc sau đây giúp duy trì sự tập trung này.
1. Tập trung vào Hành vi, Không phải Triển khai
Mô tả hệ thống làm gì, chứ không phải cách thức thực hiện. Hệ thống nên xử lý logic nội bộ. Người dùng quan tâm đến kết quả. Nếu hệ thống thay đổi cấu trúc cơ sở dữ liệu nội bộ, người dùng không nên nhận ra. Do đó, yêu cầu chấp nhận (AC) không nên đề cập đến cơ sở dữ liệu.
- Xấu: “Chèn một hàng vào bảng Đơn hàng.”
- Tốt: “Tạo một bản ghi đơn hàng mới trong hệ thống.”
2. Sử dụng thể chủ động
Thể bị động làm mờ ai đang làm gì. Thể chủ động làm rõ hành động. Điều này giúp tiêu chí dễ đọc và hiểu hơn.
- Xấu: “Nút phải được người dùng nhấp.”
- Tốt: “Người dùng nhấp nút.”
3. Xác định các con số cụ thể
Những từ như “nhanh”, “nhiều” hay “sớm” mang tính chủ quan. Chúng dẫn đến tranh cãi về việc gì được coi là thành công. Hãy dùng các giá trị đo lường thay vào đó.
- Xấu: “Trang web phải tải nhanh.”
- Tốt: “Trang được tải trong vòng 3 giây.”
4. Tránh những giả định
Đừng giả định người dùng biết hệ thống hoạt động như thế nào. Hãy nêu rõ các điều kiện. Nếu một bước là cần thiết để thực hiện hành động, hãy liệt kê nó như một điều kiện tiên quyết.
- Xấu: “Bạn có thể xóa tệp.”
- Tốt: “Nếu một tệp được chọn, người dùng có thể xóa nó.”
🧪 Mẫu Given-When-Then (Đơn giản hóa)
Một trong những cách hiệu quả nhất để viết các tiêu chí chấp nhận không mang tính kỹ thuật là định dạng Given-When-Then. Cấu trúc này thường liên quan đến phát triển hướng hành vi, nhưng cũng hoạt động tốt với các yêu cầu bằng ngôn ngữ đơn giản. Nó chia tình huống thành bối cảnh, hành động và kết quả.
Phân tích mẫu
- Cho trước: Trạng thái ban đầu hoặc bối cảnh. Điều gì đang xảy ra trước khi thực hiện hành động?
- Khi: Hành động được thực hiện bởi người dùng hoặc hệ thống. Điều gì kích hoạt sự thay đổi?
- Sau đó: Kết quả mong đợi. Điều gì xảy ra sau hành động?
Ví dụ tình huống: Đăng nhập
Hãy tưởng tượng một câu chuyện người dùng về việc đăng nhập vào tài khoản bảo mật. Phiên bản kỹ thuật có thể đề cập đến các mã thông session. Phiên bản ngôn ngữ đơn giản tập trung vào trải nghiệm.
- Cho trước: Người dùng đang ở trên màn hình đăng nhập.
- Khi: Người dùng nhập địa chỉ email và mật khẩu hợp lệ, sau đó nhấp vào “Đăng nhập”.
- Sau đó: Người dùng được chuyển đến trang chủ.
Cấu trúc này buộc người viết phải suy nghĩ về luồng sự kiện thay vì cấu trúc mã nguồn. Nó dễ đọc và xác minh đối với một nhà phân tích kinh doanh.
📊 So sánh phiên bản kỹ thuật với ngôn ngữ đơn giản
Xem các ví dụ song song giúp làm rõ sự khác biệt. Bảng dưới đây minh họa cách chuyển đổi các yêu cầu kỹ thuật thành ngôn ngữ tập trung vào người dùng.
| ❌ Phiên bản kỹ thuật | ✅ Phiên bản ngôn ngữ đơn giản |
|---|---|
| Khi người dùng gửi biểu mẫu, thực hiện yêu cầu POST đến /api/submit với dữ liệu JSON. | Khi người dùng nhấp vào nút “Gửi”, thông tin sẽ được gửi đến hệ thống. |
| Đảm bảo giao dịch cơ sở dữ liệu được hoàn tác nếu kết nối hết thời gian chờ. | Nếu kết nối thất bại, hệ thống sẽ không lưu dữ liệu và yêu cầu người dùng thử lại. |
| Xác thực đầu vào dựa trên mẫu regex cho địa chỉ email. | Đảm bảo địa chỉ email được định dạng đúng trước khi lưu. |
| Trả về HTTP 404 nếu ID tài nguyên không tồn tại. | Hiển thị thông báo cho biết mục được yêu cầu không thể tìm thấy. |
| Dọn dẹp các cookie phiên làm việc khi đăng xuất. | Loại bỏ trạng thái đăng nhập khi người dùng nhấp vào nút “Đăng xuất”. |
🤝 Vai trò của sự hợp tác
Viết tiêu chí chấp nhận hiếm khi là công việc đơn độc. Nó đòi hỏi sự đóng góp từ Chủ sở hữu sản phẩm, Đội phát triển và Đội đảm bảo chất lượng. Sự hợp tác đảm bảo ngôn ngữ đơn giản là chính xác và các giới hạn kỹ thuật được tôn trọng mà không cần phải nêu rõ ràng.
Chuẩn bị cho buổi thảo luận
Trước khi viết các tiêu chí cuối cùng, hãy thu thập thông tin. Hỏi các bên liên quan về kinh doanh họ cần gì. Hỏi các nhà phát triển điều gì là khả thi. Việc chuẩn bị này giúp giảm thiểu sự trao đổi qua lại sau này.
- Xem lại tài liệu hiện có: Kiểm tra xem có tính năng tương tự nào đã được xây dựng hay không.
- Xác định các trường hợp biên: Điều gì xảy ra nếu internet bị mất? Điều gì xảy ra nếu người dùng nhập sai dữ liệu?
- Đặt các giới hạn: Có giới hạn về thời gian hay yêu cầu bảo mật nào phải đáp ứng không?
Tinh chỉnh các tiêu chí
Khi bản nháp đã sẵn sàng, hãy cùng đội ngũ xem xét lại. Sử dụng các tiêu chí như điểm thảo luận, chứ không phải như hợp đồng cuối cùng. Điều này cho phép điều chỉnh dựa trên những phát hiện kỹ thuật mới.
- Làm thử: Đọc các tiêu chí thành tiếng. Liệu chúng có hợp lý với người không chuyên không?
- Đặt câu hỏi: Đặt các câu hỏi “Điều gì nếu?” để kiểm tra giới hạn.
- Kiểm thử: Hãy để người kiểm thử thử viết một trường hợp kiểm thử dựa trên các tiêu chí. Nếu họ gặp khó khăn, nghĩa là các tiêu chí quá mơ hồ.
🛠️ Xử lý các trường hợp biên mà không cần độ phức tạp
Các trường hợp biên là những tình huống hiếm khi xảy ra nhưng phải hoạt động khi chúng xảy ra. Mô tả chúng mà không dùng thuật ngữ chuyên môn có thể là thách thức. Điều quan trọng là mô tả trải nghiệm người dùng trong lúc lỗi, chứ không phải mã lỗi bản thân.
Các trường hợp biên phổ biến
- Lỗi mạng: “Nếu kết nối internet bị mất, hệ thống sẽ lưu dữ liệu cục bộ và thông báo cho người dùng.”
- Dữ liệu đầu vào không hợp lệ: “Nếu người dùng nhập chữ vào trường số điện thoại, hệ thống sẽ hiển thị lỗi và làm nổi bật trường đó.”
- Thiếu dữ liệu: “Nếu một trường bắt buộc trống, hệ thống sẽ ngăn việc lưu và yêu cầu thông tin.”
- Vấn đề quyền truy cập: “Nếu người dùng không có quyền truy cập, hệ thống sẽ ẩn nút đó.”
Bằng cách tập trung vào phản ứng hiển thị, bạn giữ cho tiêu chí luôn dễ tiếp cận. Nhà phát triển biết cách triển khai sửa lỗi ở phía sau màn hình.
📈 Đo lường thành công và chất lượng
Làm sao bạn biết tiêu chí chấp nhận của bạn có hoạt động không? Bạn đo lường chúng dựa trên chất lượng công việc được giao và hiệu quả của quy trình.
Các dấu hiệu của tiêu chí tốt
- Ít phải làm lại hơn: Đội ngũ xây dựng đúng thứ cần thiết ngay từ lần đầu tiên.
- Kiểm thử nhanh hơn: Người kiểm thử có thể xác minh câu chuyện nhanh chóng mà không cần yêu cầu làm rõ.
- Chấp thuận rõ ràng: Các bên liên quan có thể xác nhận công việc đã hoàn thành mà không gây nhầm lẫn.
- Giảm thiểu sự mơ hồ: Ít câu hỏi hơn nảy sinh trong giai đoạn phát triển.
Tiêu chuẩn hoàn thành so với tiêu chí chấp nhận
Rất quan trọng khi phân biệt giữa Tiêu chí chấp nhận và Tiêu chuẩn hoàn thành (DoD). DoD áp dụng cho mọi nhiệm vụ cụ thể, bất kể tính năng. Nó bao gồm các việc như kiểm tra mã nguồn, kiểm tra bảo mật và kiểm thử đơn vị. Tiêu chí chấp nhận là cụ thể với từng Câu chuyện người dùng.
- DoD: “Mã nguồn được kiểm tra, kiểm thử đạt, tài liệu được cập nhật.”
- AC: “Người dùng có thể lọc sản phẩm theo khoảng giá.”
Cả hai đều cần thiết cho chất lượng. DoD đảm bảo sức khỏe kỹ thuật. AC đảm bảo giá trị kinh doanh.
🚧 Những sai lầm phổ biến cần tránh
Ngay cả với những ý định tốt, các đội thường rơi vào bẫy. Nhận thức được những sai lầm phổ biến này giúp duy trì tiêu chuẩn cao.
Sai lầm 1: Quá mơ hồ
Nói rằng ‘Hệ thống phải nhanh’ là chưa đủ. Điều này khiến tranh cãi nảy sinh. Hãy định nghĩa rõ ‘nhanh’ có nghĩa là gì trong bối cảnh của bạn. Có phải dưới 1 giây? Dưới 5 giây?
Lỗi 2: Trộn lẫn Tiêu chuẩn chấp nhận với Nhiệm vụ
Đừng liệt kê các bước mà nhà phát triển cần thực hiện. Ví dụ, ‘Tạo một bảng cơ sở dữ liệu mới’ là một nhiệm vụ, chứ không phải tiêu chuẩn chấp nhận. Tiêu chuẩn là kết quả, chứ không phải phương pháp.
Lỗi 3: Bỏ qua các trường hợp tiêu cực
Chỉ viết về những gì xảy ra khi mọi thứ diễn ra suôn sẻ là chưa đầy đủ. Một bộ tiêu chí vững chắc cần bao gồm cả những gì xảy ra khi mọi thứ rắc rối. Điều này bảo vệ trải nghiệm người dùng.
Lỗi 4: Sử dụng quá nhiều điều kiện
Nếu một Bản kể người dùng có đến hai mươi Tiêu chuẩn chấp nhận, có thể nó quá lớn. Hãy thử chia nhỏ thành các bản kể nhỏ hơn. Những bản kể nhỏ hơn sẽ dễ hiểu và kiểm thử hơn.
🛡️ Đảm bảo tính khả dụng và rõ ràng
Ngôn ngữ đơn giản không chỉ là tránh dùng từ chuyên môn. Đó là làm cho nội dung trở nên dễ tiếp cận với mọi người trong nhóm. Bao gồm cả những người có phong cách học tập hoặc trình độ ngôn ngữ khác nhau.
Lời khuyên cho tính khả dụng
- Câu ngắn:Giữ câu dưới 20 từ khi có thể.
- Từ ngữ đơn giản:Sử dụng từ vựng phổ biến thay vì thuật ngữ ngành.
- Trợ giúp hình ảnh:Khi có thể, đính kèm ảnh chụp màn hình hoặc sơ đồ bố cục để làm rõ các tiêu chí.
- Thuật ngữ nhất quán:Sử dụng cùng một từ cho cùng một khái niệm trong suốt dự án.
🔄 Quy trình xem xét
Sau khi các tiêu chí được viết, chúng cần được xem xét lại. Đây không phải là một sự kiện duy nhất. Khi dự án phát triển, các tiêu chí có thể cần cập nhật. Một tài liệu sống giúp đảm bảo yêu cầu luôn chính xác.
Bảng kiểm xem xét
- Có thể kiểm thử được không?Chúng ta có thể xác minh điều này bằng một bài kiểm thử không?
- Có đầy đủ không?Có bao quát tất cả luồng người dùng không?
- Có rõ ràng không?Một thành viên mới trong nhóm có thể hiểu được không?
- Có nhất quán không?Có phù hợp với các bản kể khác trong danh sách chờ không?
🎯 Những suy nghĩ cuối cùng về yêu cầu rõ ràng
Viết các tiêu chí chấp nhận mà không dùng thuật ngữ kỹ thuật là một khoản đầu tư vào thành công của dự án. Nó giúp lấp đầy khoảng cách giữa nhu cầu kinh doanh và việc thực hiện kỹ thuật. Nó giảm thiểu sai sót, tiết kiệm thời gian và xây dựng niềm tin giữa các bên liên quan. Bằng cách tập trung vào ngôn ngữ đơn giản, kết quả rõ ràng và hành vi người dùng, các đội ngũ có thể cung cấp phần mềm chất lượng cao thực sự đáp ứng nhu cầu người dùng.
Sự nỗ lực tránh phức tạp mang lại kết quả trong giao tiếp trơn tru hơn và giao hàng nhanh hơn. Khi mọi người đều hiểu rõ mục tiêu, đội ngũ sẽ tiến bước với sự tự tin. Cách tiếp cận này dẫn đến sản phẩm tốt hơn và các đội ngũ hạnh phúc hơn.
