Định nghĩa hoàn thành (DoD)là danh sách các yêu cầu mà một user story phải tuân thủ để đội ngũ có thể gọi nó là hoàn thành. Trong khiTiêu chí chấp nhậncủa một User Story bao gồm một tập hợp các kịch bản kiểm tra cần được đáp ứng để xác nhận rằng phần mềm hoạt động như mong đợi.
Sự khác biệt giữa hai điều này làDoD là chung cho tất cả các User Stories trong khi Tiêu chí chấp nhận áp dụng cho một User Story cụ thể. Tiêu chí chấp nhận của mỗi User Story sẽ khác nhau dựa trên các yêu cầu của User Story đó.
Nói cách khác,Cả DoD và Tiêu chí chấp nhận đều phải được đáp ứng để hoàn thành User Story.Sản phẩm gia tăng không được coi là hoàn thành, trừ khi cả hai danh sách này đều hoàn thành. Do đó, chúng ta cần xác định hai khía cạnh của Định nghĩa hoàn thành (DOD) – Tiêu chí hoàn thành và Tiêu chí chấp nhận:
Định nghĩa hoàn thành
Định nghĩa hoàn thành được cấu trúc dưới dạng danh sách các mục, mỗi mục được sử dụng để xác thực một Câu chuyện hoặc PBI, nhằm đảm bảo rằngĐội ngũ phát triểnđồng ý về chất lượng công việc mà họ đang cố gắng sản xuất. Nó phục vụ như một danh sách kiểm tra được sử dụng để kiểm tramỗi Danh sách sản phẩmMục (hay còn gọi là PBI) hoặc User Story để hoàn chỉnh. Các mục trong định nghĩa “Hoàn thành” được dự định áp dụng cho tất cả các mục trong Danh sách sản phẩm, không chỉ cho mộtUser Story. Nó có thể được tóm tắt như sau:
- Thuật ngữ này áp dụng nhiều hơn cho sản phẩm gia tăng như một tổng thể
- Trong hầu hết các trường hợp, thuật ngữ này ngụ ý rằng sản phẩm gia tăng làcó thể giao hàng
- Thuật ngữ này được định nghĩa trong Hướng dẫn Scrum
- Được sử dụng như một cách để giao tiếp giữa các thành viên trong đội
- Chất lượng phần mềm tổng thể
- Sản phẩm gia tăng có thể giao hàng hay không
Mục tiêu của Định nghĩa hoàn thành
- Xây dựng sự hiểu biết chung trong đội về Chất lượng và Tính hoàn chỉnh
- Sử dụng như một danh sách kiểm tra mà các User Stories (hoặc PBIs) được kiểm tra
- Đảm bảo sản phẩm gia tăng được giao vào cuốiSprintcó chất lượng cao và chất lượng được hiểu rõ bởi tất cả những người liên quan.
Ví dụ — Định nghĩa hoàn thành
Ví dụ, trong ngành công nghiệp phần mềm, các đội có thể cần đặt ra một số câu hỏi sau đây để đưa ra DoD của họ:
- Mã đã được xem xét bởi đồng nghiệp chưa?
- Mã đã hoàn thành chưa?
- Mã đã được xem xét chưa?
- Mã đã được kiểm tra chưa?
- Các bài kiểm tra đơn vị đã vượt qua chưa?
- Các bài kiểm tra chức năng đã vượt qua chưa?
- Các bài kiểm tra chấp nhận đã hoàn thành chưa?
- Chủ sở hữu sản phẩmđã xem xét và chấp nhận chưa?
Tiêu chí chấp nhận
User stories là một trong những tài liệu phát triển chínhtài liệuchoPhát triển Agile, nhưng Scrum không yêu cầu rõ ràng việc sử dụng User Stories hoặc Acceptance Criteria. Nếu một mục trong danh sách sản phẩm được coi là quá lớn để đưa vào một sprint, nó thường sẽ được chia nhỏ thành user story và sau đó thành một tập hợp các nhiệm vụ như được thể hiện trong Hình:
User Stories bao gồm Acceptance Criteria, do đó chúng ta thường thấy định nghĩa hoàn thành và tiêu chí chấp nhận cùng tồn tại trong quy trình phát triển scrum của chúng ta. User story cung cấp bối cảnh về chức năng mà đội ngũ nên cung cấp. Tiêu chí chấp nhận cung cấp hướng dẫn về chi tiết của chức năng đó và cách mà khách hàng sẽ chấp nhận chúng. Cả hai cùng nhau cung cấp toàn bộ sản phẩm giao hàng.
Một số tiêu chí chấp nhận sẽ được phát hiện trong các sự kiện tinh chỉnh danh sách tồn đọng đang diễn ra trước khi Sprint bắt đầu, và những tiêu chí khác sẽ được phát hiện ngay sau Lập kế hoạch Sprint khi ngồi lại để có một cuộc trò chuyện về user story trong một nhóm nhỏ. Vì vậy, Acceptance Criteria là những thuộc tính độc nhất cho User Story hoặc Mục trong Danh sách Sản phẩm.
- Thuật ngữ này áp dụng cho một PBI/Story cá nhân
- Tiêu chí chấp nhận là khác nhau cho mỗi PBI/Story
- Thuật ngữ không được định nghĩa trong Hướng dẫn Scrum
- Được sử dụng như một cách để thông báo cho tất cả những người liên quan rằng các yêu cầu cho một PBI/story cụ thể đã được đáp ứng
- Còn gọi là các bài kiểm tra chấp nhận, Điều kiện thỏa mãn, trong một số trường hợp là “Trường hợp kiểm tra,” v.v.
Mục tiêu của Tiêu chí chấp nhận
- Làm rõ những gì đội ngũ nên xây dựng trước khi họ bắt đầu làm việc
- Đảm bảo mọi người có sự hiểu biết chung về vấn đề
- Giúp các thành viên trong đội biết khi nào câu chuyện đã hoàn thành
- Giúp xác minh câu chuyện thông qua các bài kiểm tra tự động.
Ví dụ — Tiêu chí chấp nhận
- Người dùng không thể gửi một biểu mẫu mà không hoàn thành tất cả các trường bắt buộc
- Thông tin từ biểu mẫu được lưu trữ trong cơ sở dữ liệu đăng ký
- Thanh toán có thể được thực hiện qua thẻ tín dụng
- Một email xác nhận được gửi đến người dùng sau khi gửi biểu mẫu
Ví dụ về User Story với Tiêu chí chấp nhận
Hình dưới đây cho thấy một ví dụ về tiêu chí chấp nhận của một user story.
Tài liệu tham khảo
This post is also available in Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, 简体中文 and 繁體中文.