Trong môi trường nhanh chóng của Scrum, khoảng cách giữa những gì các bên liên quan hình dung và những gì các nhà phát triển xây dựng thường dẫn đến việc phải làm lại tốn kém. Sự mơ hồ là kẻ thù của hiệu quả. Khi yêu cầu không rõ ràng, đội ngũ phải đoán mò, và việc đoán mò dẫn đến sai sót. Tiêu chí chấp nhận (AC) đóng vai trò như hợp đồng quyết định giữa giá trị kinh doanh và triển khai kỹ thuật. Chúng không chỉ là gợi ý đơn thuần; chúng là ranh giới của chất lượng.
Viết các tiêu chí chấp nhận hiệu quả đòi hỏi sự chính xác, sự hợp tác và hiểu biết sâu sắc về câu chuyện người dùng. Hướng dẫn này chi tiết các khía cạnh kỹ thuật trong việc xây dựng các tiêu chí làm rõ kỳ vọng, giảm thiểu sự mơ hồ và đảm bảo rằng mỗi bước tiến được giao đều thực sự có giá trị. Chúng ta sẽ khám phá các thành phần cấu trúc của các tiêu chí chất lượng cao, các quy trình hợp tác xung quanh chúng, và những sai lầm phổ biến làm suy yếu toàn bộ khung Scrum.
📉 Tại sao sự mơ hồ lại tốn kém tiền bạc
Việc phải làm lại trong phát triển không đơn thuần chỉ là sửa lỗi; nó làm chậm tốc độ và ảnh hưởng đến tinh thần đội ngũ. Khi một nhà phát triển xây dựng một tính năng dựa trên sự hiểu biết chưa đầy đủ, việc kiểm tra tiếp theo sẽ tiết lộ khoảng trống. Việc sửa chữa đòi hỏi phải quên đi công việc trước đó và triển khai lại logic đúng. Chu kỳ này tiêu tốn thời gian mà có thể đã dùng để phát triển các tính năng mới.
Hãy xem xét các yếu tố sau đây góp phần gây ra việc phải làm lại:
- Kỳ vọng không đồng bộ: Người chủ sản phẩm hình dung một quy trình cụ thể, nhưng mô tả lại thiếu chi tiết.
- Các trường hợp biên bị bỏ qua:Đường đi thuận lợi được xác định, nhưng xử lý lỗi và điều kiện biên lại bị bỏ qua.
- Các giới hạn kỹ thuật chưa được biết đến:Các tiêu chí không tính đến giới hạn hiệu suất hoặc yêu cầu bảo mật.
- Bối cảnh thay đổi:Không có các tiêu chí rõ ràng, việc mở rộng phạm vi phát triển xảy ra một cách vô hình trong quá trình phát triển.
Bằng cách đầu tư thời gian ngay từ đầu cho các tiêu chí rõ ràng, các đội ngũ giảm thiểu khả năng xảy ra những vấn đề này. Mục tiêu là dịch chuyển nỗ lực sang giai đoạn đầu vòng đời, nơi mà việc thay đổi sẽ rẻ hơn và có tác động lớn hơn.
🏗️ Giải phẫu của một tiêu chí chấp nhận chất lượng cao
Không phải mọi tiêu chí chấp nhận nào cũng bằng nhau. Một số quá rộng, cho phép diễn giải. Một số khác quá cụ thể, buộc đội ngũ phải tuân theo một cách triển khai duy nhất, có thể không phải là tối ưu. Điểm cân bằng nằm ở việc xác định điều gìhệ thống phải làm, mà không bắt buộc phải làm theo cách nàocách nàonó phải được xây dựng.
Các tiêu chí chất lượng cao nên có:
- Rõ ràng:Viết bằng ngôn ngữ đơn giản mà mọi người trong đội đều hiểu.
- Có thể kiểm thử:Phải có cách để xác minh điều kiện đã được đáp ứng.
- Đầy đủ:Bao quát tất cả các tình huống, kể cả các đường đi tiêu cực.
- Không mơ hồ:Sử dụng các con số và thuật ngữ cụ thể thay vì các tính từ chủ quan.
Dưới đây là một so sánh giữa các tiêu chí kém và mạnh để minh họa sự khác biệt.
| ❌ Tiêu chí mơ hồ | ✅ Tiêu chí chính xác |
|---|---|
| Hệ thống cần phải nhanh. | Trang tải trong dưới 2 giây trên kết nối 4G tiêu chuẩn. |
| Người dùng có thể tải lên tệp tin. | Người dùng có thể tải lên tệp tin lên đến 10MB định dạng PDF hoặc JPG. |
| Chức năng tìm kiếm hoạt động tốt. | Tìm kiếm trả về kết quả trong vòng 500ms và xử lý lỗi chính tả thông qua khớp mờ. |
| Đảm bảo dữ liệu được bảo mật. | Mật khẩu được băm bằng bcrypt trước khi lưu trữ. |
🔍 Kỹ thuật để đạt độ chính xác
Để đạt được sự rõ ràng cần thiết nhằm ngăn ngừa công việc phải làm lại, các đội cần áp dụng các kỹ thuật viết có cấu trúc. Những phương pháp này buộc người viết phải suy nghĩ kỹ lưỡng về logic trước khi viết mã.
1. Định dạng Given-When-Then
Thường được gọi là cú pháp Gherkin, định dạng này cấu trúc các tiêu chí thành ba phần riêng biệt:
- Cho rằng:Bối cảnh hoặc trạng thái ban đầu của hệ thống.
- Khi:Hành động hoặc sự kiện xảy ra.
- Thì:Kết quả hoặc kết quả có thể quan sát được.
Cấu trúc này mạnh mẽ vì nó trực tiếp tương ứng với kiểm thử tự động. Nếu bạn có thể viết tiêu chí theo định dạng này, bạn thường có thể viết ngay lập tức trường hợp kiểm thử. Ví dụ:
Cho rằngngười dùng đang ở trang đăng nhập,
Khihọ nhập địa chỉ email và mật khẩu hợp lệ,
Thìhọ được chuyển hướng đến bảng điều khiển.
Ngược lại, một tình huống tiêu cực sẽ như sau:
Cho rằng người dùng đang ở trang đăng nhập,
Khi họ nhập mật khẩu sai,
Thì họ thấy thông báo lỗi và vẫn ở lại trang đăng nhập.
2. Quy tắc kinh doanh và giới hạn
Các tiêu chí chấp nhận thường cần mã hóa các quy tắc kinh doanh cụ thể. Đây là những giới hạn không thể thương lượng do tổ chức hoặc yêu cầu pháp lý đặt ra. Hãy rõ ràng về những giới hạn này.
- Giới hạn tài chính:Giao dịch không được vượt quá 10.000 đô la mà không có sự phê duyệt của quản lý.
- Tuân thủ:Dữ liệu người dùng phải được lưu giữ trong 7 năm theo quy định địa phương.
- Khả năng:Hệ thống phải hỗ trợ 1.000 người dùng đồng thời.
3. Các trường hợp biên và xử lý lỗi
Hầu hết công việc sửa lại xảy ra khi hệ thống hoạt động ngoài mong đợi. Các nhà phát triển thường tập trung vào đường đi suôn sẻ. Các tiêu chí phải rõ ràng nêu bật điều gì xảy ra khi mọi thứ không như mong đợi.
- Điều gì xảy ra nếu kết nối internet bị ngắt trong quá trình gửi?
- Điều gì xảy ra nếu truy vấn cơ sở dữ liệu hết thời gian?
- Điều gì xảy ra nếu trường nhập liệu nhận các ký tự đặc biệt?
🤝 Hợp tác và nhóm Ba Người Bạn
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ừ ba vai trò then chốt tham gia vào việc cung cấp giá trị: Người sở hữu sản phẩm, Nhà phát triển và Người kiểm thử. Cách làm này thường được gọi là buổi họp ‘Ba Người Bạn’.
Trong buổi họp hợp tác này, đội sẽ xem xét câu chuyện người dùng và cùng nhau soạn thảo các tiêu chí. Mỗi góc nhìn đều mang lại chiều sâu cần thiết:
- Người sở hữu sản phẩm:Đảm bảo các tiêu chí phản ánh giá trị kinh doanh và nhu cầu người dùng.
- Nhà phát triển:Xác định tính khả thi về kỹ thuật và tác động tiềm tàng đến kiến trúc.
- Người kiểm thử:Tập trung vào các trường hợp biên, bảo mật và cách kiểm chứng các tiêu chí.
Sự hợp tác này ngăn chặn cái bẫy phổ biến khi người sở hữu sản phẩm viết các tiêu chí không thể thực hiện về mặt kỹ thuật, hoặc nhà phát triển viết các tiêu chí bỏ sót mục đích kinh doanh. Nó xây dựng sự hiểu biết chung trước khi viết bất kỳ dòng mã nào.
🔄 Tiêu chí chấp nhận so với Định nghĩa Hoàn thành
Rất phổ biến khi nhầm lẫn Tiêu chí chấp nhận với Định nghĩa Hoàn thành (DoD). Mặc dù chúng có liên quan, nhưng chúng phục vụ các mục đích khác nhau. Hiểu rõ sự khác biệt này là điều cần thiết cho việc lập kế hoạch chính xác.
- Tiêu chí chấp nhận: Đặc biệt đối với một câu chuyện người dùng duy nhất. Nó xác định điều gì làm chotính nănghoàn thiện và có giá trị đối với người dùng.
- Tiêu chuẩn hoàn thành:Áp dụng chotất cảcâu chuyện người dùng. Nó xác định các tiêu chuẩn chất lượng cho toàn bộ tăng trưởng (ví dụ: mã được kiểm tra, bài kiểm tra đơn vị vượt qua, triển khai lên môi trường thử nghiệm).
Nếu tiêu chuẩn hoàn thành không được đáp ứng, câu chuyện không được coi là hoàn thành, bất kể tiêu chí chấp nhận có được đáp ứng hay không. Nếu tiêu chí chấp nhận không được đáp ứng, câu chuyện không có giá trị, ngay cả khi tiêu chuẩn hoàn thành đã được đáp ứng.
🚫 Những sai lầm phổ biến cần tránh
Ngay cả các đội có kinh nghiệm cũng rơi vào những cái bẫy làm giảm chất lượng tiêu chí của họ. Nhận thức về những sai lầm này là bước đầu tiên để giảm thiểu rủi ro.
1. Sử dụng ngôn ngữ chủ quan
Những từ như “dễ dàng”, “nhanh”, “trực quan” hoặc “bền bỉ” là mang tính chủ quan. Điều mà một người cho là trực quan có thể là điều khiến người khác bối rối. Hãy thay thế chúng bằng các tiêu chuẩn có thể đo lường được.
- ❌ Giao diện phải trực quan.
- ✅ Người dùng có thể hoàn thành quy trình thanh toán trong ba lần nhấp chuột.
2. Tập trung vào chi tiết triển khai
Tiêu chí chấp nhận nên mô tả hành vi, chứ không phải triển khai. Nếu bạn chỉ định công nghệ, bạn sẽ giới hạn khả năng lựa chọn giải pháp tốt nhất của nhà phát triển.
- ❌ Hệ thống phải sử dụng menu thả xuống để chọn lựa.
- ✅ Người dùng phải chọn một tùy chọn từ danh sách năm mục.
3. Bỏ qua các yêu cầu phi chức năng
Hiệu suất, bảo mật và khả năng truy cập thường bị bỏ quên cho đến cuối chu kỳ phát triển. Hãy bao gồm chúng vào tiêu chí nếu chúng quan trọng đối với câu chuyện người dùng.
- ✅ Thư viện hình ảnh phải hỗ trợ điều hướng bằng bàn phím.
- ✅ Thời gian phản hồi của API không được vượt quá 200ms.
4. Gánh quá nhiều yêu cầu trong một câu chuyện duy nhất
Nếu một câu chuyện người dùng yêu cầu quá nhiều tiêu chí chấp nhận phức tạp, có khả năng nó quá lớn. Hãy chia nhỏ thành các câu chuyện nhỏ hơn. Những câu chuyện lớn khó ước lượng hơn, khó kiểm thử hơn và khó tích hợp hơn.
📊 Đo lường thành công
Làm sao bạn biết tiêu chí chấp nhận của bạn đang hoạt động hiệu quả? Bạn cần các chỉ số phản ánh chất lượng và hiệu quả. Theo dõi các chỉ số này theo thời gian:
- Tỷ lệ từ chối: Có bao nhiêu câu chuyện bị từ chối trong buổi đánh giá chu kỳ phát triển do thiếu tiêu chí?
- Tỷ lệ sửa chữa lại: Phần nào của sprint đã được dành để sửa các vấn đề mà lẽ ra đã được phát hiện bởi các tiêu chí?
- Phạm vi kiểm thử:Các tiêu chí chấp nhận có tương ứng trực tiếp với các bài kiểm thử tự động không?
- Tốc độ của đội:Liệu đội có di chuyển nhanh hơn khi các tiêu chí trở nên rõ ràng không?
Xem xét các chỉ số này trong buổi tổng kết. Nếu công việc tái thực hiện cao, hãy phân tích các tiêu chí đã thất bại. Đội có bỏ sót một trường hợp đặc biệt không? Ngôn ngữ có mơ hồ không? Sử dụng dữ liệu này để tinh chỉnh quy trình.
🛠️ Tinh chỉnh quy trình theo thời gian
Viết các tiêu chí chấp nhận là một kỹ năng được cải thiện qua thực hành. Không đội nào làm đúng hoàn hảo ngay lần đầu tiên. Cần có sự cải tiến liên tục.
- Xem xét các câu chuyện trước đây:Hãy xem các câu chuyện từ các sprint trước. Những câu chuyện nào gây nhầm lẫn? Viết lại tiêu chí cho các câu chuyện tương tự trong danh sách công việc hiện tại.
- Tiêu chuẩn hóa mẫu:Tạo một mẫu chung cho các loại câu chuyện phổ biến (ví dụ: đăng nhập, tìm kiếm, bảng điều khiển). Điều này đảm bảo tính nhất quán.
- Đào tạo đội ngũ:Đảm bảo tất cả thành viên đội hiểu cách viết và xem xét các tiêu chí. Tổ chức các buổi workshop nếu cần thiết.
- Khuyến khích đặt câu hỏi:Thúc đẩy văn hóa nơi việc đặt câu hỏi “Điều này có nghĩa là gì?” được khuyến khích, chứ không bị ngăn cản.
❓ Câu hỏi thường gặp
Câu hỏi: Tiêu chí chấp nhận có thể thay đổi trong quá trình phát triển không?
Trả lời: Có, nhưng điều đó nên xảy ra hiếm khi. Nếu tiêu chí thay đổi đáng kể, câu chuyện có thể cần được đánh giá lại hoặc chia nhỏ. Thảo luận ngay lập tức về bất kỳ thay đổi nào với đội để tránh lãng phí công sức.
Câu hỏi: Ai chịu trách nhiệm viết các tiêu chí?
Trả lời: Lý tưởng nhất là Product Owner viết bản nháp đầu tiên, nhưng toàn đội cùng hợp tác để hoàn thiện chúng. Đội chịu trách nhiệm phiên bản cuối cùng vì chính họ là người xây dựng và kiểm thử.
Câu hỏi: Một câu chuyện nên có bao nhiêu tiêu chí?
Trả lời: Không có con số cố định. Nó phụ thuộc vào độ phức tạp. Thông thường, từ 3 đến 7 tiêu chí cung cấp đủ chi tiết mà không gây quá tải. Nếu bạn có nhiều hơn, hãy cân nhắc chia nhỏ câu chuyện.
Câu hỏi: Điều gì xảy ra nếu một tiêu chí không thể kiểm thử?
Trả lời: Nếu không thể kiểm thử, thì không thể xác minh được. Bạn phải viết lại để trở nên quan sát được. Nếu bạn không thể đo lường nó, bạn sẽ không biết liệu nó đã hoàn thành hay chưa.
Câu hỏi: Điều này có áp dụng cho các dự án không phải phần mềm không?
Trả lời: Các nguyên tắc này áp dụng cho mọi dự án yêu cầu yêu cầu rõ ràng. Ngôn ngữ có thể thay đổi, nhưng nhu cầu về các điều kiện có thể kiểm thử và không mơ hồ vẫn tồn tại.
🚀 Tiến bước về phía trước
Thực hiện một cách tiếp cận nghiêm ngặt đối với các tiêu chí chấp nhận là một hành trình. Nó đòi hỏi kỷ luật và cam kết về sự rõ ràng. Bằng cách xác định rõ ranh giới công việc, các đội có thể tập trung vào thực thi thay vì làm rõ. Sự thay đổi này giảm thiểu xung đột, cải thiện chất lượng và mang lại giá trị nhanh hơn.
Bắt đầu bằng cách xem xét danh sách công việc sprint tiếp theo của bạn. Chọn một câu chuyện người dùng và viết lại các tiêu chí chấp nhận của nó bằng các kỹ thuật được nêu ở trên. Thử nghiệm quy trình mới. Đo lường sự khác biệt. Theo thời gian, sự giảm thiểu công việc tái thực hiện sẽ trở nên rõ ràng, và đội sẽ hoạt động với sự tự tin và nhịp độ cao hơn.
Hãy nhớ, mục tiêu không phải là sự hoàn hảo, mà là sự cải tiến liên tục. Mỗi câu chuyện là một cơ hội để tinh chỉnh cách bạn định nghĩa giá trị. Hãy duy trì sự tập trung vào người dùng, duy trì ngôn ngữ chính xác, và duy trì sự hợp tác cởi mở.