App MVP Sprint là gì?

Đây là gì

Hợp đồng bắt đầu bằng việc làm rõ vấn đề mà sản phẩm cần giải quyết, ai là người dùng chính và họ cần hoàn thành điều gì trước tiên. Từ đó, công việc tập trung vào các luồng người dùng chính: một số ít hành trình giúp sản phẩm hữu ích ngay từ ngày đầu. Một phạm vi điển hình có thể bao gồm định nghĩa sản phẩm, các màn hình thiết yếu, chức năng ứng dụng đã thống nhất, giả định về dữ liệu và tích hợp, kiểm tra chất lượng và chuẩn bị phát hành thực tế. Cách tiếp cận kỹ thuật cụ thể phụ thuộc vào sản phẩm, các tài sản hiện có và nền tảng đã thống nhất. Sprint tập trung vào một bản phát hành đầu tiên mạch lạc, được xây dựng quanh các luồng cốt lõi đã thống nhất. Đây là một cách có cấu trúc để các lựa chọn ban đầu trở nên rõ ràng, kiểm thử được và có thể bàn giao. Các tính năng không hỗ trợ kết quả cốt lõi của bản phát hành đầu tiên được ghi nhận là những cân nhắc cho tương lai thay vì âm thầm bổ sung vào một phạm vi cố định.

Dành cho ai

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

• Có một ý tưởng sản phẩm hoặc vấn đề kinh doanh đã xác định nhưng cần hỗ trợ để biến nó thành một bản phát hành đầu tiên thực tế
• Muốn xác thực một hành trình khách hàng tập trung trước khi đầu tư vào lộ trình sản phẩm rộng hơn
• Cần một quy trình triển khai có trách nhiệm rõ ràng cho phạm vi sản phẩm, quyết định giao diện, phát triển và chuẩn bị phát hành
• Đang thay thế các nguyên mẫu không chính thức, bảng tính hoặc các bước thủ công bằng một trải nghiệm ứng dụng đầu tiên có thể sử dụng được

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

Một sprint MVP giúp làm rõ:

• Vấn đề người dùng và luồng chính nào mà bản phát hành đầu tiên nên giải quyết, và ý tưởng nào nên chờ
• Những giả định, phụ thuộc, nội dung, tích hợp hoặc phê duyệt của khách hàng nào cần được giải quyết trước khi công việc xây dựng có thể tiến hành
• Những tính năng nào là thiết yếu cho một bản phát hành kiểm thử được, so với các cải tiến mong muốn cho lộ trình sau này
• Việc kiểm thử, phân công trách nhiệm và chuẩn bị phát hành nào là thực tế trong phạm vi và tiến độ đã thống nhất

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

• Xác nhận phạm vi bằng văn bản mô tả mục tiêu của bản phát hành đầu tiên, nền tảng, các luồng người dùng đã thống nhất và ranh giới triển khai
• Định nghĩa sản phẩm và giao diện tập trung cho các màn hình và tương tác thiết yếu trong phạm vi
• Công việc xây dựng các tính năng MVP đã thống nhất, với các giả định và phụ thuộc được ghi nhận khi phát sinh
• Kiểm thử thực tế các luồng người dùng đã thống nhất trước khi bàn giao hoặc chuẩn bị phát hành
• Hỗ trợ sẵn sàng phát hành phù hợp với nền tảng, quyền truy cập tài khoản và trách nhiệm nộp ứng dụng đã thống nhất
• Mã nguồn, tài liệu và bản tóm tắt bàn giao xác định những gì đã được bàn giao, những gì cần ý kiến của người phụ trách và những gì thuộc về giai đoạn tương lai

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

• Danh sách tính năng không giới hạn, chỉnh sửa không hạn chế, hoặc tự động đưa vào mọi ý tưởng được thảo luận trong sprint
• Nền tảng backend phức tạp, chức năng marketplace, video thời gian thực, chương trình dữ liệu nâng cao hoặc công việc tuân thủ rộng, trừ khi có phạm vi riêng
• Bảo đảm về thời điểm ra mắt, việc được App Store hoặc Google Play phê duyệt, mức độ người dùng chấp nhận, kết quả thương mại hoặc dịch vụ bên thứ ba không gián đoạn
• Quản lý sản phẩm liên tục, bảo trì hoặc phát triển tính năng tương lai sau khi hợp đồng kết thúc, ngoài phần hỗ trợ sau ra mắt có giới hạn cho các hạng mục trong phạm vi đã bàn giao
• Công việc phụ thuộc vào nội dung, tài khoản, quyết định pháp lý, nhà cung cấp bên ngoài hoặc tích hợp chưa có sẵn hoặc chưa được xác nhận trong phạm vi

Khi nào nên chọn

Hãy chọn App MVP Sprint khi thách thức trọng tâm là quyết định phiên bản hữu ích đầu tiên nên là gì và sau đó triển khai phiên bản đó một cách có kỷ luật. Hình thức này có thể phù hợp với một đội ngũ giai đoạn đầu, một doanh nghiệp đã vững vàng đang thử nghiệm mô hình dịch vụ mới, hoặc một đội ngũ cần thay thế quy trình khách hàng thủ công bằng một hành trình ứng dụng tập trung. Sprint hiệu quả nhất khi có một người ra quyết định được chỉ định, có thể tiếp cận những người hiểu vấn đề của người dùng, và sẵn sàng giữ phiên bản đầu tiên hẹp một cách có chủ đích. Sprint ít phù hợp hơn khi định hướng sản phẩm vẫn còn rất bất định, luồng người dùng cốt lõi chưa thể mô tả, hoặc các tích hợp và phụ thuộc vận hành cần thiết chưa được biết. Trong những trường hợp đó, một giai đoạn discovery hoặc product blueprint có thể là điểm xuất phát hữu ích hơn trước khi cam kết xây dựng.

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

Chúng tôi bắt đầu bằng việc xác nhận kết quả mong muốn, người dùng chính, nền tảng và ranh giới triển khai bằng văn bản. Các cuộc trao đổi ban đầu tập trung vào hành trình cốt lõi thay vì một danh sách tính năng dài: người dùng phải làm được gì, thông tin nào là cần thiết, và điều gì giúp bản phát hành đầu tiên trở nên mạch lạc. Chúng tôi ghi lại các giả định về nội dung, tích hợp, tài khoản, trách nhiệm phê duyệt và phụ thuộc bên ngoài để chúng không trở thành rủi ro triển khai ẩn về sau. Trong quá trình xây dựng, chúng tôi giữ cho phạm vi đã thống nhất luôn rõ ràng và giải thích tác động của mọi yêu cầu mới trước khi coi nó là một phần của phạm vi. Việc kiểm thử dựa trên các luồng người dùng đã thống nhất và điều kiện phát hành thực tế. Khi bàn giao, đội ngũ nhận được cái nhìn rõ ràng về ranh giới của bản phát hành đầu tiên, công việc đã hoàn thành và các hạng mục nên chuyển sang lộ trình sau này hoặc một phạm vi riêng.

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

Bài viết liên quan