Trong bối cảnh phát triển linh hoạt, sự rõ ràng là đồng tiền của thành công. Khi một đội bắt đầu làm việc trên một tính năng mới, nền tảng nằm ở Câu chuyện Người dùng. Tuy nhiên, một Câu chuyện Người dùng chỉ là một chỗ trống cho một cuộc trò chuyện. Để biến cuộc trò chuyện đó thành một sản phẩm hoạt động, hai tài liệu quan trọng là cần thiết: Tiêu chí Chấp nhận và Định nghĩa Hoàn thành. Những khái niệm này đóng vai trò như các rào chắn đảm bảo chất lượng, sự đồng thuận và tính dự đoán được.
Nhiều đội làm việc gặp khó khăn trong việc phân biệt hai khái niệm này. Đôi khi chúng bị coi là một thứ, dẫn đến sự nhầm lẫn trong quá trình kiểm thử hoặc triển khai. Vào những lúc khác, chúng bị bỏ qua hoàn toàn, dẫn đến mở rộng phạm vi công việc hoặc các tính năng chưa hoàn thiện lọt vào sản xuất. Hướng dẫn này khám phá về cơ chế, mục đích và cách triển khai của Tiêu chí Chấp nhận và Định nghĩa Hoàn thành để giúp đội của bạn liên tục mang lại giá trị.
Câu chuyện Người dùng là gì? 📝
Trước khi phân tích các thành phần của một câu chuyện, điều quan trọng là phải nhớ rõ Câu chuyện Người dùng thực sự là gì. Trong các khung phát triển linh hoạt, Câu chuyện Người dùng là một mô tả ngắn gọn, đơn giản về một tính năng được kể từ góc nhìn của người mong muốn có khả năng mới. Nó thường tuân theo định dạng:
- Là một [loại người dùng],
- Tôi muốn [mục tiêu nào đó],
- Để rằng [một lợi ích nào đó].
Định dạng này tập trung vào giá trịgiá trị được cung cấp cho người dùng, thay vì việc triển khai kỹ thuật. Tuy nhiên, định dạng này một mình là chưa đủ để dẫn dắt phát triển. Nó không xác định rõ ranh giới công việc hay các tiêu chuẩn cần đạt được để hoàn thành. Đây chính là lúc Tiêu chí Chấp nhận và Định nghĩa Hoàn thành phát huy vai trò.
Tiêu chí Chấp nhận (AC): Các Điều kiện Hoàn thành ✅
Tiêu chí Chấp nhận là một tập hợp các điều kiện mà một Câu chuyện Người dùng phải đáp ứng để được coi là hoàn thành từ góc nhìn của người sở hữu sản phẩm. Chúng xác định ranh giới của câu chuyện và cung cấp sự hiểu rõ về hình dạng sản phẩm cuối cùng cần đạt được.
Mục đích của Tiêu chí Chấp nhận
Tiêu chí Chấp nhận đóng nhiều vai trò khác nhau trong vòng đời phát triển:
- Làm rõ: Chúng loại bỏ sự mơ hồ. Nếu một lập trình viên hỏi: “Nút bấm khi di chuột nên chuyển sang màu xanh hay màu xanh dương?”, thì Tiêu chí Chấp nhận phải trả lời điều đó.
- Kiểm thử: Chúng đóng vai trò như các trường hợp kiểm thử. Các kỹ sư QA sử dụng những điều kiện này để xác minh tính năng.
- Sự đồng thuận: Chúng đảm bảo người sở hữu sản phẩm và đội phát triển đồng thuận về việc gì được coi là “hoàn thành” đối với câu chuyện cụ thể này.
Đặc điểm của Tiêu chí Chấp nhận tốt
Tiêu chí Chấp nhận hiệu quả phải cụ thể, đo lường được và không mơ hồ. Tránh dùng những từ ngữ mơ hồ như “dễ sử dụng” hay “nhanh” mà không định nghĩa các chỉ số đo lường. Thay vào đó, hãy nêu rõ các hành vi cụ thể.
- Nguyên tử: Mỗi tiêu chí nên giải quyết một yêu cầu duy nhất.
- Có thể kiểm thử: Phải có thể xác minh tiêu chí đó bằng kết quả đạt hoặc không đạt.
- Độc lập:Tiêu chí không được phụ thuộc vào các câu chuyện bên ngoài để được xác nhận.
- Liên quan:Tập trung vào giá trị người dùng, chứ không phải cấu trúc mã nội bộ.
Ví dụ về tiêu chí chấp nhận
Hãy xem xét một câu chuyện về việc thêm tính năng “Quên mật khẩu”. Dưới đây là cách tiêu chí chấp nhận có thể trông như thế nào:
- Giả sử người dùng đang ở trang đăng nhập,
Khi họ nhấp vào liên kết “Quên mật khẩu”,
Thì họ sẽ được chuyển hướng đến trang khôi phục mật khẩu. - Giả sử người dùng nhập một địa chỉ email hợp lệ,
Khi họ gửi biểu mẫu,
Thì một thông báo xác nhận sẽ được hiển thị. - Giả sử người dùng nhập một địa chỉ email không hợp lệ,
Khi họ gửi biểu mẫu,
Thì một thông báo lỗi sẽ cho biết định dạng email không đúng.
Những ví dụ này tuân theo cấu trúc Given/When/Thencấu trúc (thường liên quan đến cú pháp Gherkin), giúp tăng tính rõ ràng và phù hợp với các khung kiểm thử tự động.
Tiêu chuẩn hoàn thành (DoD): Cổng chất lượng 🚧
Trong khi Tiêu chí chấp nhận là cụ thể cho một câu chuyện người dùng duy nhất, thì Tiêu chuẩn hoàn thành là một tiêu chuẩn toàn cầu được áp dụng chotất cảcông việc trong một sprint hoặc bản phát hành. Nó đại diện cho danh sách kiểm tra các yêu cầu cần được đáp ứng để bất kỳ phần công việc nào được coi là có thể phát hành.
Mục đích của Tiêu chuẩn hoàn thành
DoD hoạt động như một cổng chất lượng. Nó đảm bảo rằng nợ kỹ thuật không tích tụ và sản phẩm luôn ở trạng thái có thể phát hành. Nếu một câu chuyện đáp ứng Tiêu chí chấp nhận nhưng không đáp ứng Tiêu chuẩn hoàn thành, thì nó không thể được đánh dấu là hoàn thành.
Các thành phần phổ biến trong Tiêu chuẩn hoàn thành bao gồm:
- Xem xét mã nguồn:Mọi mã nguồn phải được xem xét bởi ít nhất một đồng nghiệp.
- Kiểm thử đơn vị:Các kiểm thử tự động phải vượt qua với độ bao phủ 100% cho logic mới.
- Tài liệu: Tài liệu API hoặc hướng dẫn người dùng đã được cập nhật.
- Hiệu suất: Tính năng đáp ứng các yêu cầu thời gian tải tối thiểu.
- Khả năng truy cập: Tính năng tuân thủ các hướng dẫn WCAG.
- Bảo mật: Không có lỗ hổng nào được phát hiện.
Tại sao Definition of Done (DoD) lại quan trọng
Không có Definition of Done, các đội thường rơi vào cái bẫy ‘về mặt kỹ thuật đã xong nhưng thực tế chưa sẵn sàng’. Một tính năng có thể hoạt động đúng như mong đợi theo các tiêu chí chấp nhận, nhưng có thể đã làm hỏng một phần khác của hệ thống, thiếu tài liệu đầy đủ hoặc tạo ra các rủi ro bảo mật. DoD ngăn chặn điều này bằng cách đảm bảo một mức độ chất lượng cơ bản trên toàn bộ danh sách công việc.
Tiêu chí chấp nhận so với Definition of Done: Những điểm khác biệt chính 🆚
Sự nhầm lẫn thường xảy ra vì cả hai khái niệm đều liên quan đến ‘sự hoàn chỉnh’. Tuy nhiên, phạm vi và quyền sở hữu của chúng khác biệt rõ rệt. Hiểu rõ sự khác biệt này giúp ngăn ngừa sự bất đồng giữa các nhà phát triển, kiểm thử và người sở hữu sản phẩm.
| Tính năng | Tiêu chí chấp nhận | Định nghĩa về hoàn thành |
|---|---|---|
| Phạm vi | Cụ thể cho một User Story duy nhất | Toàn cục cho toàn bộ đội nhóm hoặc dự án |
| Quyền sở hữu | Người sở hữu sản phẩm và đội phát triển | Toàn bộ đội phát triển |
| Tính linh hoạt | Thay đổi theo từng câu chuyện dựa trên yêu cầu | Ổn định, mặc dù có thể được cập nhật theo thời gian |
| Mục đích | Xác định các yêu cầu chức năng | Xác định tiêu chuẩn chất lượng và phi chức năng |
| Xác minh | Kiểm thử chức năng dựa trên nhu cầu người dùng | Xác minh kỹ thuật và quy trình |
Hãy nghĩ đến Tiêu chí chấp nhận như điểm đến cho một chuyến đi cụ thể, trong khi Định nghĩa về hoàn thành là danh sách kiểm tra an toàn cần thiết cho mọi phương tiện tham gia giao thông.
Làm thế nào để viết các tiêu chí chấp nhận hiệu quả 📝
Viết các tiêu chí chấp nhận là một nỗ lực hợp tác. Nó không nên được thực hiện riêng lẻ bởi người sở hữu sản phẩm. Cách tốt nhất là áp dụng khái niệm “Ba người bạn”, trong đó người sở hữu sản phẩm, một nhà phát triển và một người kiểm thử hợp tác ngay từ đầu quá trình tinh chỉnh.
Bước 1: Xác định mục tiêu người dùng
Bắt đầu bằng cách nêu lại lợi ích cốt lõi. Người dùng đang giải quyết vấn đề gì? Điều này đảm bảo các tiêu chí luôn tập trung vào trải nghiệm người dùng thay vì chi tiết kỹ thuật.
Bước 2: Xác định các tình huống tích cực và tiêu cực
Đừng chỉ viết đường đi thuận lợi. Hãy cân nhắc những gì xảy ra khi mọi thứ đi sai.
- Đường đi thuận lợi: Người dùng thực hiện hành động đúng như mong đợi.
- Trường hợp biên: Điều gì xảy ra với các ký tự đặc biệt, dữ liệu thiếu hoặc kết nối chậm?
- Đường đi tiêu cực: Hệ thống xử lý đầu vào không hợp lệ một cách trơn tru như thế nào?
Bước 3: Sử dụng ngôn ngữ rõ ràng
Tránh dùng thuật ngữ chuyên môn nếu có thể. Nếu cần dùng các thuật ngữ kỹ thuật, hãy đảm bảo chúng được định nghĩa rõ ràng. Sử dụng thể bị động. Ví dụ, “Hệ thống phải xác thực…” thì ít rõ ràng hơn “Người dùng nhận được thông báo lỗi…”.
Bước 4: Ưu tiên
Nếu một câu chuyện lớn, hãy chia nhỏ nó. Các tiêu chí chấp nhận cần phải đạt được trong một sprint. Nếu các tiêu chí ngụ ý công việc không thể hoàn thành trong sprint, câu chuyện cần được chia tách.
Làm thế nào để xây dựng một Định nghĩa Hoàn thành vững chắc 🛠️
Định nghĩa Hoàn thành không phải là một tài liệu tĩnh. Nó thay đổi theo sự trưởng thành của đội và sự thay đổi công nghệ. Nó cần được hiển thị rõ ràng cho mọi người, thường được treo trên bảng vật lý hoặc bảng kỹ thuật số.
Bước 1: Tham khảo ý kiến đội ngũ
DoD thuộc về đội ngũ thực hiện công việc. Các nhà phát triển, người kiểm thử và nhà thiết kế nên đóng góp vào danh sách này. Nếu một nhà phát triển thêm một yêu cầu, họ có khả năng tuân thủ yêu cầu đó cao hơn.
Bước 2: Phân loại yêu cầu
Sắp xếp các mục DoD vào các nhóm hợp lý để danh sách kiểm tra trở nên dễ quản lý hơn.
- Chất lượng mã nguồn: Kiểm tra linting đạt, không có cảnh báo, đánh giá đồng nghiệp đã hoàn thành.
- Kiểm thử: Các bài kiểm thử đơn vị đã được viết, kiểm thử tích hợp đã đạt, kiểm thử thủ công đã được xác minh.
- Triển khai: Đã triển khai lên môi trường thử nghiệm, kiểm thử khói đã đạt.
- Tài liệu: Tài liệu Readme đã cập nhật, tài liệu API đã đồng bộ.
Bước 3: Đặt nó thành điểm dừng cứng
Nếu một câu chuyện không đáp ứng được DoD, thì không thể đóng lại. Điều này đòi hỏi sự kỷ luật. Rất dễ bị cám dỗ nói rằng, ‘Chúng ta sẽ sửa tài liệu sau,’ nhưng điều đó tạo ra nợ kỹ thuật. Câu chuyện vẫn nằm ở trạng thái ‘Đang thực hiện’ cho đến khi DoD được đáp ứng.
Bước 4: Xem xét và tinh chỉnh
Trong các buổi tổng kết, hãy hỏi đội ngũ: ‘DoD của chúng ta có phát hiện vấn đề nào không?’ hay ‘Có yêu cầu nào chúng ta thường xuyên bỏ sót không?’ Cập nhật DoD dựa trên những nhận định này.
Những sai lầm phổ biến cần tránh ⚠️
Ngay cả các đội có kinh nghiệm cũng vấp phải khi triển khai các thực hành này. Nhận thức được những điểm nguy hiểm phổ biến có thể tiết kiệm rất nhiều thời gian và sự bực bội.
1. Tiêu chí chấp nhận mơ hồ
Viết các tiêu chí như ‘Hệ thống phải an toàn’ là vô dụng. Chúng không thể kiểm thử được. Thay vào đó, hãy nêu rõ: ‘Hệ thống phải yêu cầu xác thực đa yếu tố cho các tài khoản quản trị viên.’
2. DoD như một bài kiểm tra đánh dấu hộp
Nếu đội đánh dấu hộp DoD mà không thực sự thực hiện công việc (ví dụ: bỏ qua việc kiểm tra mã nguồn), thì DoD sẽ mất ý nghĩa. DoD phải được tôn trọng, chứ không chỉ được đọc qua.
3. Làm phức tạp hóa DoD
Một DoD gồm 50 mục sẽ trở nên quá tải. Hãy tập trung vào các cửa kiểm soát chất lượng thiết yếu. Nếu một yêu cầu hiếm khi bị vi phạm, thì có thể nó chỉ là một hướng dẫn chứ không phải là một mục DoD cứng.
4. Bỏ qua các yêu cầu phi chức năng
Các đội thường tập trung mạnh vào AC (chức năng) và bỏ qua DoD (phi chức năng). Hiệu suất, bảo mật và khả năng truy cập là một phần của DoD, chứ không phải AC. Bỏ qua chúng dẫn đến các tính năng hoạt động nhưng chậm hoặc không an toàn.
5. Tạo DoD mà không có sự đồng thuận của đội
Nếu người chủ sản phẩm đặt DoD mà không có sự góp ý từ các nhà phát triển, đội có thể phản đối. DoD phải là một thỏa thuận chung.
Tích hợp vào quy trình làm việc 🔄
Tiêu chí chấp nhận và Định nghĩa Hoàn thành cần được tích hợp vào mọi giai đoạn của vòng đời phát triển, chứ không chỉ ở cuối.
Giai đoạn tinh chỉnh
Trong giai đoạn tinh chỉnh danh sách công việc, người chủ sản phẩm soạn thảo các tiêu chí chấp nhận. Đội sẽ xem xét để đảm bảo chúng có thể kiểm thử và khả thi. Các câu hỏi sẽ được đặt và trả lời ở đây, chứ không phải trong suốt sprint.
Lập kế hoạch Sprint
Khi cam kết thực hiện các câu chuyện, đội sẽ xác minh xem các tiêu chí chấp nhận có rõ ràng hay không. Nếu không, câu chuyện sẽ chưa sẵn sàng cho sprint.
Giai đoạn phát triển
Các nhà phát triển viết mã để đáp ứng AC. Đồng thời, họ đảm bảo tuân thủ DoD (ví dụ: viết kiểm thử, yêu cầu kiểm tra).
Giai đoạn kiểm thử
Các kỹ sư QA xác minh AC đối với tính năng đã xây dựng. Họ cũng xác minh DoD (ví dụ: kiểm tra báo cáo độ bao phủ mã nguồn, quét khả năng truy cập).
Xem xét và đóng lại
Trước khi một câu chuyện được chuyển sang trạng thái ‘Hoàn thành’, đội xác nhận cả AC và DoD đều được đáp ứng. Nếu không, nó sẽ quay lại hàng đợi.
Đo lường thành công 📊
Làm sao bạn biết được các tiêu chí chấp nhận và Định nghĩa Hoàn thành của bạn đang hoạt động hiệu quả? Hãy theo dõi các chỉ số theo thời gian.
- Tỷ lệ lỗi:Số lượng lỗi phát hiện trong môi trường sản xuất có đang giảm dần không? Một tiêu chuẩn hoàn thành (DoD) mạnh mẽ nên phát hiện các vấn đề trước khi phát hành.
- Tỷ lệ từ chối:Các câu chuyện có thường xuyên bị Product Owner từ chối không? Điều này cho thấy việc định nghĩa Tiêu chí chấp nhận (AC) chưa tốt.
- Độ ổn định tốc độ phát triển:Tốc độ phát triển của đội có duy trì ổn định không? Nếu các câu chuyện thường xuyên bị trả lại do thiếu các mục trong DoD, thì tốc độ sẽ dao động.
- Tần suất triển khai:Một DoD rõ ràng có giúp triển khai trơn tru và thường xuyên hơn không?
Câu hỏi thường gặp ❓
Dưới đây là những câu hỏi phổ biến mà các đội thường đặt ra khi triển khai các tiêu chuẩn này.
Câu hỏi: Tiêu chí chấp nhận có thể thay đổi trong suốt một sprint không?
Trả lời: Lý tưởng nhất là không. Nếu Tiêu chí chấp nhận thay đổi đáng kể, điều đó có thể cho thấy câu chuyện chưa được hiểu rõ trong quá trình tinh chỉnh. Những làm rõ nhỏ là chấp nhận được, nhưng những thay đổi phạm vi lớn nên dẫn đến việc tạo câu chuyện mới hoặc điều chỉnh phạm vi sprint.
Câu hỏi: Mỗi câu chuyện có cần một Tiêu chuẩn hoàn thành (DoD) riêng biệt không?
Trả lời: Không. DoD là chung cho toàn bộ đội. Tuy nhiên, các câu chuyện kỹ thuật cụ thể có thể có thêm yêu cầu được thêm vào danh sách kiểm tra cho mục đó, nhưng DoD cơ bản vẫn áp dụng cho tất cả.
Câu hỏi: Nếu đội không đồng thuận về DoD thì sao?
Trả lời: Tổ chức một cuộc thảo luận. Mục tiêu là đạt được sự đồng thuận. Nếu một lập trình viên kiên trì yêu cầu mà tester không đồng ý, hãy thảo luận về rủi ro. Nếu rủi ro thấp, hãy loại bỏ yêu cầu đó. Nếu rủi ro cao, hãy giữ lại.
Câu hỏi: Tiêu chí chấp nhận cần chi tiết đến mức nào?
Trả lời: Chi tiết đủ để kiểm thử được. Nếu một kỹ sư kiểm thử chất lượng (QA) có thể viết một trường hợp kiểm thử trực tiếp từ Tiêu chí chấp nhận, thì nó đã đủ chi tiết. Nếu họ cần đặt câu hỏi, thì cần chi tiết hơn.
Câu hỏi: Kiểm thử tự động có thể thay thế kiểm thử thủ công trong DoD không?
Trả lời: Phụ thuộc vào tình huống. Đối với logic quan trọng, thì có thể. Đối với trải nghiệm người dùng hoặc các yếu tố hình ảnh, kiểm tra thủ công vẫn có thể cần thiết. DoD nên phản ánh phương pháp tốt nhất cho đảm bảo chất lượng.
Suy nghĩ cuối cùng về chất lượng và sự đồng thuận 🌟
Triển khai Tiêu chí chấp nhận và Tiêu chuẩn hoàn thành không phải là về thủ tục hành chính; đó là về sự tôn trọng. Đó là sự tôn trọng đối với người dùng mong đợi một tính năng hoạt động, sự tôn trọng đối với nhà phát triển mong muốn các yêu cầu rõ ràng, và sự tôn trọng đối với Product Owner cần sự tự tin trong việc giao hàng.
Khi hai khái niệm này được sử dụng đúng cách, chúng tạo nên một ngôn ngữ chung cho đội. Chúng giảm nhu cầu họp giải thích liên tục. Chúng ngăn ngừa tích tụ nợ kỹ thuật. Và quan trọng nhất, chúng đảm bảo rằng mỗi câu chuyện hoàn thành đều mang lại giá trị thực sự cho sản phẩm.
Bắt đầu nhỏ. Xác định một DoD cơ bản. Viết các Tiêu chí chấp nhận rõ ràng cho câu chuyện tiếp theo của bạn. Xem xét lại chúng trong buổi tổng kết tiếp theo. Theo thời gian, những thói quen này sẽ trở nên tự nhiên, thấm sâu vào văn hóa của đội bạn. Kết quả là dòng chảy ổn định của phần mềm chất lượng cao, đáp ứng nhu cầu của những người sử dụng nó.