App Rescue & Rebuild: Bao gồm những gì

Đây là gì

Hợp đồng kết hợp việc đánh giá codebase và tình trạng sản phẩm với một kế hoạch có kiểm soát để ổn định, sửa chữa, xây dựng lại một phần hoặc xây dựng lại toàn bộ khi phù hợp. Đánh giá ban đầu có thể xem xét cấu trúc ứng dụng hiện có, các bản build hiện tại, phụ thuộc, quyền truy cập môi trường, lỗi đã biết, quy trình phát hành, tài liệu và các luồng người dùng mà sản phẩm cần hỗ trợ. Ranh giới đánh giá cụ thể được xác nhận khi đã hiểu rõ quyền truy cập và tài liệu hiện có. Các phát hiện được dùng để phân biệt giữa những vấn đề có thể sửa trong nền tảng hiện tại và những vấn đề khiến việc tiếp tục làm việc trở nên kém hiệu quả hoặc không an toàn để lập kế hoạch nếu không có một thay đổi lớn hơn. Một hợp đồng rescue mang lại cho bạn cái nhìn dựa trên bằng chứng về việc ứng dụng có thể được khôi phục, phát hành và trở nên dễ bảo trì hay không, và bằng cách nào. Nó tạo ra cơ sở dựa trên bằng chứng để chọn hướng triển khai tiếp theo và, khi có thể thống nhất một phạm vi thực tế, thực hiện công việc ổn định hoặc xây dựng lại đã thống nhất.

Dành cho ai

App Rescue & Rebuild phù hợp với các đội ngũ:

• Có một ứng dụng hoặc bản build sản phẩm dang dở đã đổi người phụ trách, bị đình trệ hoặc trở nên khó tiến triển
• Đang gặp lỗi lặp lại, bản phát hành dễ vỡ, vấn đề phụ thuộc hoặc trách nhiệm không rõ ràng quanh một ứng dụng hiện có
• Cần quyết định nên giữ lại các phần đang hoạt động, sửa chữa các khu vực cụ thể, xây dựng lại một số luồng được chọn hay lập kế hoạch cho một nền tảng mới
• Muốn có một hướng đi có kỷ luật hơn thay vì tiếp tục bổ sung tính năng mà không hiểu tình trạng kỹ thuật và sản phẩm hiện tại

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

Một đánh giá rescue giúp làm rõ:

• Những gì có thể quan sát được trong codebase, các bản build, môi trường, phụ thuộc và luồng sản phẩm hiện tại, và ở đâu còn thiếu bằng chứng
• Những lỗi hoặc rủi ro phát hành nào là vấn đề cục bộ, và những cái nào cho thấy vấn đề rộng hơn về kiến trúc, trách nhiệm hoặc triển khai
• Các phương án giữ lại, sửa chữa, xây dựng lại một phần và xây dựng lại toàn bộ khác nhau thế nào về phạm vi, rủi ro, phụ thuộc và thời điểm ra quyết định
• Quyền truy cập, quyết định sản phẩm, nhà cung cấp bên ngoài và các bước xác thực nào cần có trước khi có thể xác nhận một phạm vi triển khai đáng tin cậy

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

• Đánh giá ban đầu về codebase hiện có đã thống nhất, tình trạng build, phụ thuộc, môi trường, tài liệu và bối cảnh sản phẩm
• Phân loại thực tế các mẫu lỗi đã quan sát, mối lo ngại về kiến trúc, tình trạng phụ thuộc và rủi ro phát hành hoặc triển khai
• Bản đánh giá bằng ngôn ngữ dễ hiểu, tách biệt các sự kiện đã quan sát, giả định, ràng buộc và các khu vực cần thêm quyền truy cập hoặc điều tra
• Khuyến nghị về hướng đi thực tế nhất tiếp theo: giữ lại, sửa chữa có mục tiêu, xây dựng lại một phần, hoặc xây dựng lại toàn bộ với phạm vi riêng
• Công việc ổn định hoặc triển khai chỉ khi có thể thống nhất một phạm vi khả thi, ranh giới truy cập và cách nghiệm thu sau đánh giá
• Bản tóm tắt bàn giao hoặc quyết định ghi lại các ưu tiên hiện tại, câu hỏi về trách nhiệm và các bước tiếp theo đã thống nhất

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

• Lời hứa rằng mọi phần của codebase hiện có đều có thể được giữ lại, sửa chữa hoặc phát hành trước khi đánh giá hoàn tất
• Bảo đảm rằng mọi lỗi, nợ kỹ thuật, mối lo ngại bảo mật, vấn đề phụ thuộc hoặc rủi ro phát hành sẽ được tìm ra hoặc loại bỏ
• Gỡ lỗi không giới hạn, công việc tính năng không hạn chế hoặc bảo trì không có điểm kết thúc ngoài một phạm vi triển khai được thống nhất riêng
• Tự động khôi phục thông tin xác thực, kho mã nguồn, tài khoản nhà cung cấp, dịch vụ bên thứ ba hoặc tài liệu không có sẵn và không được cung cấp cho hợp đồng
• Ứng phó sự cố khẩn cấp, bảo đảm phê duyệt của cửa hàng ứng dụng, hoặc công việc rộng về backend, tuân thủ hay hạ tầng, trừ khi có phạm vi riêng

Khi nào nên chọn

Hãy chọn App Rescue & Rebuild khi quyết định then chốt không còn là xây dựng cái gì, mà là những gì có thể được mang tiếp một cách an toàn và hợp lý từ công việc đã có. Hình thức này hữu ích khi một agency hoặc nhà phát triển trước đó đã bàn giao một dự án chưa hoàn chỉnh, khi các bản phát hành không đáng tin cậy, khi codebase trở nên khó thay đổi, hoặc khi đội ngũ sản phẩm đã mất niềm tin vào kế hoạch hiện tại. Nó cũng hữu ích trước khi cam kết thêm ngân sách cho một bản build đã có dấu hiệu căng thẳng về phụ thuộc hoặc kiến trúc. Với một ý tưởng sản phẩm mới đơn giản chưa có ứng dụng nào, một hợp đồng MVP hoặc discovery thường là hướng đi rõ ràng hơn. Hướng rescue hiệu quả nhất khi doanh nghiệp có thể cung cấp các kho mã nguồn hiện có, thông tin truy cập, bối cảnh sản phẩm và một người ra quyết định có thể giải quyết các ưu tiên sau đánh giá ban đầu.

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

Chúng tôi bắt đầu từ bằng chứng hiện có thay vì các giả định về sản phẩm hiện tại. Giai đoạn đầu ghi lại quyền truy cập nào đang có, những gì có thể chạy hoặc kiểm tra, những phụ thuộc nào có vẻ đang hoạt động, các bản phát hành hiện được xử lý ra sao và những luồng người dùng nào quan trọng nhất. Sau đó, chúng tôi tách các câu hỏi ổn định trước mắt khỏi các quyết định xây dựng lại dài hạn. Giữ lại một thành phần có nghĩa là nó có đủ giá trị và khả năng bảo trì để giữ trong một ranh giới xác định. Sửa chữa có nghĩa là xử lý một vấn đề có giới hạn, còn nền tảng rộng hơn được đánh giá riêng theo đúng thực trạng của nó. Xây dựng lại một phần thay thế các luồng hoặc tầng được chọn trong khi giữ lại các phần đang hoạt động đã thống nhất. Xây dựng lại toàn bộ được cân nhắc khi nền tảng hiện có không mang lại cơ sở thực tế cho sự tiến triển có kiểm soát. Phạm vi triển khai được xác nhận khi đánh giá đã cung cấp đủ bằng chứng để làm điều đó một cách có trách nhiệm. Khi có giai đoạn ổn định hoặc xây dựng lại tiếp theo, tiêu chí nghiệm thu, phụ thuộc và ranh giới phát hành được thống nhất bằng văn bản. Kết quả là một hướng ra quyết định rõ ràng hơn, dựa trên bằng chứng.

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

Bài viết liên quan