Unlimited Design & Technology

Triển khai dự án

Xây dựng Definition of Done mà cả nhóm kiểm tra được

Chuẩn chất lượng chung cần bằng chứng quan sát được, không phải lời hứa chung chung. Bài viết giúp tách nghiệm thu tính năng khỏi chất lượng sản phẩm, phân công kiểm tra và xử lý phần việc chưa hoàn tất.

UDT Insights13/07/2019
Một đồng nghiệp dùng danh sách kiểm tra bên cạnh cổng hoàn thành dẫn đến kiện hàng. Một đồng nghiệp xem bảng kẹp giấy.

Một tính năng có thể trông hoàn chỉnh trong buổi trình diễn nhưng vẫn thiếu xử lý lỗi, hướng dẫn hỗ trợ hoặc kiểm tra tích hợp. Khi đó, khách hàng mới phát hiện mỗi nhóm hiểu “xong” theo một cách. Definition of Done, tức định nghĩa hoàn tất chung, cần làm rõ bất đồng trước khi nhóm cam kết bàn giao. Hãy bắt đầu từ bằng chứng để tin rằng phần sản phẩm mới có thể sử dụng, thay vì liệt kê các hoạt động mong muốn.

Tách lời hứa của tính năng khỏi chuẩn chất lượng tối thiểu

Scrum Guide định nghĩa Definition of Done là mô tả chính thức về trạng thái của phần sản phẩm tăng thêm khi đáp ứng các yêu cầu chất lượng.[1] Hiểu đơn giản, đây là chuẩn chất lượng tối thiểu dùng chung. Tiêu chí nghiệm thu lại mô tả hành vi riêng của tính năng, chẳng hạn người duyệt có thể từ chối khoản chi kèm lý do.

Cần giữ cả hai loại hồ sơ. Tính năng có thể đúng quy tắc nghiệp vụ nhưng thiếu bài kiểm tra tích hợp bắt buộc. Ngược lại, phần mềm được kiểm thử kỹ vẫn có thể giải quyết sai vấn đề. Hãy yêu cầu nhóm trình bày riêng bằng chứng nghiệm thu nghiệp vụ và bằng chứng hoàn tất chung, cùng liên kết tới một hạng mục bàn giao.

Thay tính từ bằng kết quả kiểm tra được

Quy tắc như “đã kiểm thử đầy đủ” cho phép quá nhiều cách diễn giải. Nên viết rõ: “các kiểm tra hồi quy đã thống nhất đều đạt trên bản dựng được xác định, có đính kèm kết quả”. Xác định người thực hiện, nơi lưu bằng chứng và điều kiện không đạt. Không cần yêu cầu ảnh chụp nếu kiểm tra tự động đã tạo hồ sơ đáng tin cậy.

Dùng danh sách khởi đầu dưới đây rồi điều chỉnh theo sản phẩm, không sao chép nguyên mẫu.

  • Xác định bản dựng và môi trường mà bằng chứng bao phủ.
  • Xác nhận riêng nghiệm thu nghiệp vụ và các tình huống lỗi bắt buộc.
  • Đính kèm kết quả kiểm tra bảo mật, khả năng tiếp cận và tích hợp theo yêu cầu.
  • Cập nhật hướng dẫn hỗ trợ khi hành vi sử dụng hoặc cách phục hồi thay đổi.

Ví dụ giả định: một quy trình duyệt, hai nhóm

Trong ví dụ giả định về công cụ quản lý chi phí, một nhóm làm màn hình duyệt, nhóm kia sửa dịch vụ thông báo. Nhóm giao diện đánh dấu hoàn tất sau khi kiểm tra cục bộ. Tuy nhiên, quy tắc chung còn yêu cầu thông báo từ chối hoạt động xuyên hệ thống và có cách xử lý khi gửi thất bại. Các phép kiểm tra này làm lộ phần còn thiếu trước khi buổi trình diễn bị hiểu thành xác nhận hoàn tất.

Khi nhiều Scrum Team cùng làm một sản phẩm, hướng dẫn yêu cầu các nhóm thống nhất và tuân thủ cùng một Definition of Done.[1] Khuyến nghị ở đây là giữ một hồ sơ chuẩn tối thiểu, bổ sung kiểm tra cho thay đổi rủi ro cao. Kiểm tra bổ sung phải tăng mức bảo đảm, không được thay thế chuẩn chung.

Cải tiến quy tắc mà không che phần việc dở dang

Danh sách dài hơn không mặc nhiên tốt hơn. Việc thu thập bằng chứng thủ công quá mức có thể tốn thời gian mà không làm rõ rủi ro quan trọng. Sau sự cố thực tế, hãy xem lại quy tắc mơ hồ. Chỉ bỏ kiểm tra trùng lặp khi nhóm hiểu rõ lớp bảo vệ bị mất.

Nếu một kiểm tra bắt buộc không đạt, ghi nhận việc còn lại và điều chỉnh dự báo. Đừng đổi nghĩa của “hoàn tất” chỉ để báo cáo đẹp hơn. Hãy thử áp dụng chuẩn dự kiến cho một hạng mục sắp triển khai với cả hai nhóm. Dùng các bất đồng để làm rõ phép kiểm tra trước khi áp dụng cho toàn bộ danh sách công việc.

Tài liệu tham khảo

Trao đổi về dự án của bạn

Cùng UDT xác định nhu cầu và bước triển khai tiếp theo.

Liên hệ UDT
Zalo