App Launch Readiness: Bao gồm những gì

Đây là gì

Hợp đồng rà soát ranh giới ra mắt đã thống nhất: phiên bản ứng dụng, nền tảng mục tiêu, các hành trình người dùng chính, các dịch vụ liên quan và trách nhiệm phát hành. Tùy theo phạm vi, nó có thể bao gồm hành vi xác thực và phiên, quyền truy cập, giả định về lưu trữ cục bộ và xử lý dữ liệu, các luồng API, luồng thanh toán nếu có, cấu hình, ghi log, báo cáo crash, nội dung quyền riêng tư và nội dung trên cửa hàng ứng dụng, và danh mục kiểm tra phát hành. Mục tiêu là phân biệt một đợt rà soát sẵn sàng ra mắt thực tế với một đợt kiểm thử xâm nhập đầy đủ. Rà soát sẵn sàng xem xét các điều kiện phát hành đã thống nhất và các rủi ro vận hành hoặc sản phẩm phổ biến; kiểm thử đối kháng trên diện rộng thuộc một phạm vi kiểm thử xâm nhập riêng. Các phát hiện được sắp xếp để đội ngũ thấy được điều gì cần chú ý trước bản phát hành đã lên kế hoạch, điều gì cần người phụ trách, và điều gì cần một hợp đồng kỹ thuật hoặc bảo mật có phạm vi riêng. Tùy theo gói dịch vụ, hợp đồng cũng có thể bao gồm phát triển ứng dụng và triển khai UI/UX trong phạm vi đã thống nhất, với các điểm rà soát liên quan đến bảo mật trong quá trình phát triển.

Dành cho ai

App Launch Readiness phù hợp với các đội ngũ:

• Có một ứng dụng di động sắp đến lần phát hành đầu tiên, bản cập nhật lớn hoặc đợt triển khai ra thị trường và muốn có một đợt rà soát cuối cùng có kỷ luật hơn
• Cần thống nhất trách nhiệm sản phẩm, kỹ thuật, vận hành và phát hành xung quanh cùng một ranh giới ra mắt
• Có xác thực, API, thanh toán, quyền truy cập, công cụ bên thứ ba hoặc tài liệu cửa hàng ứng dụng cần được xem xét kỹ một cách thực tế trước khi ra mắt
• Muốn sắp xếp ưu tiên cho các khoảng trống về mức độ sẵn sàng đã quan sát được với một bức tranh chính xác, dựa trên bằng chứng về rủi ro phát hành

Giúp làm rõ điều gì

Một đợt rà soát sẵn sàng ra mắt giúp làm rõ:

• Những luồng người dùng quan trọng và phụ thuộc phát hành nào nên được xác thực trước quyết định ra mắt đã thống nhất
• Liệu xác thực, phiên, quyền truy cập, hành vi API, lưu trữ, thanh toán và cấu hình có người phụ trách rõ ràng và các bước kiểm tra thực tế hay không
• Việc ghi log, báo cáo crash, tín hiệu hỗ trợ, nội dung quyền riêng tư và tài liệu nộp lên cửa hàng ứng dụng nào cần được xác nhận hoặc cải thiện
• Những quan sát nào là quyết định ra mắt cần đưa ra ngay, những cái nào có thể lên kế hoạch sau phát hành, và những cái nào cần một phạm vi riêng

Những gì được bao gồm

• Xác nhận bằng văn bản về ranh giới phát hành, nền tảng, môi trường, các luồng chính và bằng chứng hiện có
• Rà soát các yếu tố đã thống nhất về xác thực, phiên, quyền truy cập, lưu trữ, API, cấu hình và luồng thanh toán khi có liên quan
• Rà soát thực tế các hạng mục trong danh mục kiểm tra phát hành, ghi log, báo cáo crash, tín hiệu vận hành, nội dung quyền riêng tư/cửa hàng và chuẩn bị nộp ứng dụng
• Xác thực trước khi ra mắt các hành trình quan trọng đã thống nhất và hồ sơ được sắp xếp ưu tiên về các câu hỏi sẵn sàng đã quan sát
• Ghi chú về khắc phục và trách nhiệm bằng ngôn ngữ dễ hiểu, phân biệt các yếu tố chặn phát hành với công việc tiếp theo
• Buổi trao đổi bàn giao về các quyết định phát hành, ràng buộc còn lại và các hành động thực tế tiếp theo cho đội ngũ phụ trách

Những gì không được bao gồm

• Kiểm thử xâm nhập đầy đủ, ứng phó sự cố trực tiếp, vận hành ra mắt suốt ngày đêm hoặc lời hứa xác định mọi lỗ hổng
• Bảo đảm về hoạt động không lỗi, khả dụng không gián đoạn, mức độ người dùng chấp nhận, thời điểm ra mắt hoặc việc loại bỏ mọi rủi ro bảo mật hay triển khai
• Việc được Apple App Store hoặc Google Play phê duyệt; hỗ trợ nộp ứng dụng có thể nằm trong phạm vi, nhưng việc phê duyệt vẫn do nền tảng quyết định
• Công việc rộng về backend, hạ tầng, tuân thủ, pháp lý, khả năng tiếp cận hoặc chứng nhận thanh toán, trừ khi có phạm vi riêng
• Giám sát liên tục, quản lý phát hành khẩn cấp hoặc sửa lỗi không giới hạn sau ra mắt khi hợp đồng đã thống nhất kết thúc

Khi nào nên chọn

Hãy chọn App Launch Readiness khi sản phẩm đã đủ gần thời điểm phát hành để đội ngũ có thể nêu rõ phiên bản, người dùng mục tiêu, các hành trình cốt lõi và người phụ trách phát hành, nhưng muốn có một bước kiểm tra cuối cùng có kiểm soát hơn trước khi tiến hành. Hình thức này hữu ích trước lần ra mắt công khai đầu tiên, một bản cập nhật quan trọng, một đợt phát hành ở thị trường mới hoặc một thay đổi đối với xác thực, thanh toán hay các luồng quan trọng khác. Nó cũng hữu ích khi nhiều đội ngũ hoặc nhà cung cấp đã đóng góp vào sản phẩm và quy trình phát hành không còn một bức tranh rõ ràng duy nhất về mức độ sẵn sàng. Nó ít phù hợp hơn khi phạm vi sản phẩm vẫn thay đổi hằng ngày hoặc luồng người dùng chính chưa được quyết định. Trong trường hợp đó, định nghĩa sản phẩm hoặc một hợp đồng MVP có thể là điểm xuất phát tốt hơn. Đợt rà soát sẵn sàng hiệu quả nhất khi quyền truy cập, tài khoản kiểm thử, tài liệu cửa hàng ứng dụng và người ra quyết định đều sẵn có trong khung thời gian rà soát đã thống nhất.

Phương pháp của chúng tôi

Chúng tôi bắt đầu bằng việc ghi nhận bằng văn bản bản phát hành dự kiến, các phụ thuộc đã biết và ranh giới rà soát. Công việc tập trung vào những gì một quyết định ra mắt có trách nhiệm cần cân nhắc: liệu các luồng quan trọng đã thống nhất có thể được kiểm tra, liệu các thiết lập và tích hợp thiết yếu có người phụ trách rõ ràng, liệu các tín hiệu vận hành có sẵn, và liệu tài liệu cửa hàng ứng dụng và quyền riêng tư có khớp với bản phát hành hay không. Một bước kiểm tra đạt yêu cầu được ghi nhận đúng với những gì nó cho thấy: bằng chứng về các điều kiện đã thống nhất tại thời điểm đó. Chúng tôi ghi lại các vấn đề đã quan sát kèm bối cảnh và giúp đội ngũ sắp xếp ưu tiên điều gì nên xử lý trước khi ra mắt, điều gì có thể chấp nhận với một người phụ trách rõ ràng, và điều gì nên chuyển sang một phạm vi chuyên sâu riêng. Khi công việc khắc phục được thống nhất, nó được xác nhận như một bước riêng, được xác định rõ ràng. Khi bàn giao, đội ngũ nhận được một hồ sơ phát hành thực tế, chính xác, hỗ trợ việc ra quyết định.

Câu hỏi thường gặp

Bài viết liên quan