Đội phát triển mới có thể hoàn thiện phần mềm nếu họ xác định được phần đang hoạt động, có quyền truy cập hợp lệ vào những gì cần thiết và đưa ra được cách khả thi để hoàn thành một công việc quan trọng. Hãy bắt đầu bằng một đánh giá có phạm vi nhỏ. Một màn hình trông đã hoàn chỉnh vẫn có thể chưa lưu được kết quả. Có bản sao mã nguồn cũng chưa chắc có đủ hướng dẫn và dịch vụ để chạy phần mềm.
Nếu nhân viên đã dùng phiên bản đang vận hành, hãy thống nhất ai sẽ duy trì phiên bản đó trong khi đánh giá. Duy trì hoạt động trước mắt và có thay thế hệ thống về sau hay không là hai quyết định riêng.
Bạn có thể bàn giao gì cho đội phát triển mới?
Hãy lấy đúng phiên bản mã nguồn được dùng hoặc kiểm thử gần nhất, cùng hướng dẫn và các thành phần cần thiết để tạo bản chạy. Xác định ai quản lý tài khoản dùng để triển khai phần mềm và kết nối dịch vụ khác, hồ sơ nghiệp vụ và bản sao lưu ở đâu, và thỏa thuận cho phép bạn chia sẻ hoặc sửa đổi những gì. Quyền truy cập kho mã nguồn không tự xác nhận các quyền đó.
Kiểm tra từng vấn đề riêng. Đội mới có thể chạy một bản sao nhưng không có quyền cập nhật hệ thống đang hoạt động. Hoặc họ vào được tài khoản máy chủ nhưng không thể tạo lại phần mềm từ những gì được bàn giao. Nếu cần chuyển hồ sơ, hãy kiểm tra riêng bằng cách xuất thử dữ liệu và xác nhận hệ thống tiếp theo dùng được.
Nên yêu cầu đội tiếp quản trình diễn điều gì?
Chọn một công việc có ý nghĩa với doanh nghiệp. Giả sử bộ phận điều phối dịch vụ dùng một công cụ còn dang dở: nhân viên đã gửi được yêu cầu, nhưng chưa ai chứng minh quản lý có thể duyệt và xem lại quyết định về sau. Hãy yêu cầu đội mới tạo bản chạy từ một phiên bản xác định và thử quy trình đó trong môi trường riêng đã được cho phép. Dùng hồ sơ giả lập, tắt thông báo, thanh toán và các thao tác thực tế khác. Không dùng hệ thống đang vận hành để thử.
Quan sát yêu cầu đi được đến đâu rồi ghi lại điểm dừng. Nếu quản lý duyệt được nhưng quyết định biến mất khi mở lại yêu cầu, đội đã có một vấn đề cụ thể để tìm hiểu. Nếu thiếu thành phần cần thiết khiến phần mềm chưa khởi động được, hãy ghi rõ quy trình chưa được chứng minh và đang thiếu gì. Hai tình huống này dẫn đến các bước tiếp theo khác nhau.
Tạo được bản chạy cho thấy đội có thể dựng phiên bản đó trong điều kiện thử nghiệm. Điều này chưa chứng minh toàn hệ thống an toàn hoặc dễ bảo trì, đội có quyền triển khai hay đã sẵn sàng vận hành thực tế. Phần trình bày của Google về chuyển giao trách nhiệm vận hành minh họa quyết định riêng này: việc đánh giá xem xét các thành phần phụ thuộc và mức độ sẵn sàng, đồng thời bổ sung đào tạo và cải tiến khi cần.
Nên làm tiếp, sửa một phần hay thay thế?
So sánh mọi phương án theo cùng một công việc và công sức cần để duy trì kết quả về sau. Hướng dẫn mua sắm của Chính phủ Anh đưa ra ví dụ về cách so sánh điều chỉnh hệ thống sẵn có với phát triển mới dựa trên nhu cầu, chi phí và năng lực vận hành.
Phát triển tiếp
Đội có thể dựng một phiên bản xác định, quy trình hiện có chạy được trong môi trường thử nghiệm và có thể bổ sung bước còn thiếu mà không thay đổi cách các phần khác hoạt động.
Sửa một phần
Quy trình chính dùng được, nhưng một phần như triển khai hoặc kết nối với dịch vụ khác cần được sửa trong phạm vi rõ ràng. Hỏi đội sẽ kiểm thử bản sửa thế nào trước khi tiếp tục dùng phần đó.
Thay thế
Các phương án giữ phần mềm hiện tại không thể đáp ứng một yêu cầu thiết yếu ở mức chi phí hoặc rủi ro chấp nhận được. Trước khi chuyển đổi, hãy lập kế hoạch chuyển hồ sơ và công việc đang xử lý.
Nếu thay thế là lựa chọn phù hợp, hãy quyết định riêng cách duy trì công việc hiện tại. Vận hành cả hai hệ thống trong một thời gian là một phương án chuyển tiếp, đi kèm chi phí riêng và cần phân công trách nhiệm quản lý hồ sơ.
Bản đánh giá cần ghi rõ những gì?
Yêu cầu một bản ghi ngắn để cùng những người dùng phần mềm xem lại. Bản ghi nêu những gì đã được trình diễn, phần nào thất bại hoặc chưa thể thử, còn thiếu quyền truy cập hay sự cho phép nào, và điều gì có thể làm gián đoạn công việc hiện tại. Với mỗi phương án khả thi, hãy ghi rõ bước kế tiếp, ai cần thực hiện và điều bạn sẽ kiểm tra trước khi duyệt thêm công việc.
Với công cụ xử lý yêu cầu trong ví dụ, bước tiếp theo có thể là tìm nguyên nhân khiến kết quả duyệt biến mất, rồi trình diễn trong hệ thống thử nghiệm rằng quản lý có thể quay lại và xem quyết định đã lưu. Nếu bạn đang so sánh các đội có thể làm phần việc này, hãy xem những điều cần hỏi trước khi chọn đội phát triển phần mềm theo yêu cầu.
Câu hỏi về việc tiếp quản phần mềm đang dang dở
Chỉ có mã nguồn đã đủ chưa?
Mã nguồn là điểm bắt đầu để đội mới kiểm tra phần mềm. Hãy xác định đúng phiên bản, xem bạn có thể cấp quyền truy cập hợp lệ vào các thành phần cần thiết không, và kiểm tra đội có thể dựng phần mềm rồi thử một công việc quan trọng ngoài hệ thống đang vận hành không.
Khi nào chỉ cần sửa một phần?
Cân nhắc phương án này khi quy trình chính hoạt động và đội có thể khoanh vùng rồi kiểm thử bản sửa. Hãy hỏi bản sửa còn để lại vấn đề gì và ai sẽ bảo trì phần đó về sau.
Tôi nên nhận được gì sau khi đánh giá?
Một bản ghi ngắn về phần đã chạy được khi thử, phần chưa được xác minh, những gì còn thiếu và yêu cầu của mỗi phương án. Ghi rõ ai duy trì phiên bản đang vận hành, nếu có và bước bạn sẽ phê duyệt tiếp theo.