Chọn phạm vi MVP nhưng không bỏ các bảo vệ cần thiết

Sản phẩm khả dụng tối thiểu, thường gọi là MVP, là sản phẩm giới hạn để kiểm tra một nhận định quan trọng. Từ tối thiểu dễ dẫn đến thương lượng sai hướng: mọi kiểm soát đều thành tùy chọn vì nhóm muốn bản phát hành nhỏ hơn. Hãy xác định thử nghiệm trước, rồi làm rõ những bảo vệ cần có để thử nghiệm cụ thể ấy vận hành có trách nhiệm.

Tách phạm vi học hỏi khỏi điều kiện vận hành

Viết nhận định mà thử nghiệm phải kiểm tra và bằng chứng cần để đánh giá. Thử nghiệm tiếp nhận nhà cung cấp có thể kiểm tra việc nhân viên thu thập đủ thông tin mà không gọi lại. Nó không cần mọi báo cáo hay mọi nhóm nhà cung cấp.

Hướng dẫn khám phá của GOV.UK yêu cầu hiểu ràng buộc và ưu tiên giả định rủi ro.[1] Dùng sự phân biệt đó khi thu hẹp phạm vi. Chức năng xuất dữ liệu tiện lợi và quy tắc ngăn truy cập trái phép không thể đánh đổi ngang nhau chỉ vì cả hai đều cần phát triển.

Đặt mức kiểm soát tối thiểu cho quy trình đã chọn

Liệt kê người tham gia, dữ liệu, hành động được phép và lỗi có thể xảy ra trong phạm vi thử nghiệm. OWASP khuyến nghị quyền tối thiểu, mặc định từ chối và kiểm tra quyền trên mọi yêu cầu.[6] Chuyển các nguyên tắc thành kiểm tra cụ thể thay vì một mục bảo mật chung chung.

Thống nhất cách người vận hành phát hiện sai sót, sửa bản ghi và xử lý phụ thuộc không hoạt động. Cơ chế cần thiết tùy vào hậu quả khi lỗi xảy ra. Quy trình khôi phục thủ công có giám sát có thể phù hợp với thử nghiệm nhỏ, nhưng chỉ khi có người thực sự làm được.

Ví dụ giả định: sổ theo dõi thiết bị dùng chung

Một nhóm quản lý cơ sở giả định muốn thử ghi nhận việc mượn thiết bị bằng công cụ số. Nhóm bỏ nhắc tự động và chuyển thiết bị giữa nhiều địa điểm khỏi phạm vi đầu tiên. Nhóm giữ kiểm tra người được ghi nhận trả thiết bị và cách sửa lượt mượn ghi nhầm.

Thử nghiệm chỉ gồm một địa điểm và nhân viên được chỉ định. Nếu sổ số không hoạt động, nhân viên dùng bản ghi tạm đã thống nhất rồi đối soát trước khi dùng lại bình thường. Các lựa chọn minh họa cách kiểm soát phạm vi. Chúng không chứng minh một triển khai cụ thể an toàn hay đáng tin cậy.

Danh sách kiểm tra khi cắt phạm vi

Đánh giá mỗi đề xuất bỏ tính năng theo thử nghiệm thực tế, không theo nền tảng tương lai tưởng tượng. Ghi ai chấp nhận giới hạn vận hành còn lại.

• Nêu câu hỏi cần kiểm tra và nhóm người dùng đủ điều kiện.
• Tách tiện ích tùy chọn khỏi kiểm soát bảo vệ quy trình đã chọn.
• Kiểm tra cả hành động được phép và bị cấm cho từng vai trò.
• Phân công trách nhiệm sửa lỗi, hỗ trợ và vận hành tạm.
• Ghi trường hợp loại trừ và điều kiện phải tạm dừng thử nghiệm.

Phân biệt chất lượng với số lượng tính năng

Scrum Guide định nghĩa Definition of Done là trạng thái chất lượng bắt buộc của một phần tăng trưởng sản phẩm, gọi là Increment.[5] Với nhóm dùng Scrum, cắt tính năng không biến công việc chưa hoàn tất thành Increment dùng được. Cách triển khai khác cũng cần kiểm tra chấp nhận rõ ràng.

Thử nghiệm nhỏ giới hạn điều nhóm học được về quy mô, tích hợp và việc sử dụng không có giám sát. Nêu giới hạn ấy trong báo cáo quyết định. Chỉ mở rộng khi bằng chứng hỗ trợ ranh giới tiếp theo, thay vì xem buổi trình diễn ban đầu là quyền triển khai không hạn chế.