Giao phần mềm theo giai đoạn là cách chia dự án thành nhiều mốc nhỏ. Mỗi mốc là một phiên bản dùng được thật, được nghiệm thu rồi mới sang mốc tiếp theo. Thay vì chờ cả hệ thống xong mới thấy kết quả, bạn đưa một bản nhỏ vào hoạt động trước, rồi mở rộng dựa trên cách mọi người dùng nó.
Cách làm này giúp bạn kiểm soát rủi ro và chi phí tốt hơn, vì quyết định đầu tư được đưa ra từng bước với thông tin ngày càng đầy đủ. Bài này mô tả cách chia mốc, cách nghiệm thu và những giới hạn cần biết.
Vì sao nên giao theo giai đoạn
- Thấy kết quả sớm hơn. Người dùng dùng thật và góp ý trên sản phẩm thật, không phải trên bản vẽ.
- Hiểu sai được phát hiện sớm. Chỗ nào sai quy trình lộ ra khi còn nhỏ, sửa ít tốn kém hơn.
- Cam kết tài chính từng bước. Báo giá được đưa ra theo từng giai đoạn sau khi phân tích quy trình, bạn không phải ký một khoản lớn cho những thứ chưa rõ.
- Người dùng quen dần. Nhân viên làm quen từng phần thay vì bị đổi cả cách làm việc một lúc.
Cách chia mốc
Không có công thức chung, nhưng có vài nguyên tắc dễ áp dụng.
Chia theo quy trình, không chia theo màn hình
Mỗi giai đoạn nên hoàn tất một quy trình có ý nghĩa. Ví dụ giả định cho một công ty phân phối: giai đoạn một là nhận đơn và xuất kho, giai đoạn hai là công nợ và đối chiếu, giai đoạn ba là báo cáo và kết nối với kế toán. Mỗi giai đoạn đều đưa lại giá trị riêng.
Đặt nền móng ở giai đoạn đầu
Những thứ khó sửa về sau cần làm đúng từ đầu: cấu trúc dữ liệu, phân quyền theo vai trò, sao lưu. Phần giao diện và tính năng phụ có thể bổ sung dần.
Để phần chưa chắc ở sau
Tính năng bạn còn phân vân nên xếp vào giai đoạn sau khi đã có dữ liệu sử dụng. Lúc đó quyết định dựa trên thực tế chứ không phải phỏng đoán. Cách chọn bản đầu tiên được bàn riêng trong MVP là gì và cách chọn bản đầu tiên.
Mỗi giai đoạn phải chạy được độc lập
Sau mỗi mốc, hệ thống phải dùng được, kể cả khi các giai đoạn sau chưa làm. Nếu một giai đoạn chỉ có ý nghĩa khi giai đoạn sau xong, hãy gộp chúng lại.
Tiêu chí nghiệm thu cho từng giai đoạn
Nghiệm thu là chỗ nhiều dự án tranh cãi, vì mỗi bên hiểu "xong" một khác. Hãy thống nhất trước bằng văn bản, với từng giai đoạn:
- Danh sách chức năng được giao, mô tả bằng tình huống sử dụng cụ thể.
- Kịch bản kiểm tra: ai làm gì, kết quả mong đợi là gì. Người dùng thật tham gia kiểm tra.
- Dữ liệu thật hoặc gần thật, tránh nghiệm thu chỉ trên dữ liệu mẫu quá đẹp.
- Yêu cầu vận hành: phân quyền hoạt động đúng, có sao lưu, người dùng được hướng dẫn.
- Quy tắc xử lý lỗi: lỗi phát hiện trong giai đoạn nghiệm thu được sửa thế nào, lỗi sau đó được hỗ trợ ra sao.
Với bản cập nhật, các thay đổi đều được kiểm tra tự động trước khi lên hệ thống thật, nhằm giảm nguy cơ làm hỏng phần đã chạy tốt. Lợi ích này đặc biệt rõ khi hệ thống lớn dần qua nhiều giai đoạn.
Quản lý thay đổi giữa các giai đoạn
Khi dùng thật, chắc chắn sẽ có yêu cầu mới. Điều quan trọng là có quy ước chung:
- Yêu cầu mới được ghi vào danh sách, không chèn lung tung vào giai đoạn đang làm
- Hai bên cùng xem xét ưu tiên ở đầu mỗi giai đoạn
- Thay đổi ảnh hưởng đến phạm vi thì báo giá điều chỉnh cho giai đoạn đó, nói rõ trước khi làm
Cách này giữ cho dự án có đích đến rõ và hạn chế cảm giác phát sinh bất ngờ. Phần chi tiết tài liệu yêu cầu cho từng mốc xem tại tài liệu đặc tả yêu cầu phần mềm (SRS) cần có gì.
Bàn giao và dữ liệu
Dù chia giai đoạn hay không, bạn nên nhận mã nguồn và dữ liệu theo hợp đồng. Với cách giao nhiều mốc, hãy xác nhận từ đầu: mốc nào bàn giao gì, bạn có quyền truy cập ra sao, tài liệu hướng dẫn đi kèm là gì. Điều khoản cụ thể nên được luật sư của bạn xem xét.
Giới hạn và khi nào không phù hợp
Giao theo giai đoạn không phải lúc nào cũng tốt hơn.
- Tổng chi phí không nhất thiết thấp hơn. Cách này giúp kiểm soát và giảm rủi ro, nhưng mỗi mốc có công việc nghiệm thu và triển khai riêng. Điều bạn được là quyết định có thông tin, không phải chắc chắn rẻ hơn.
- Cần người của doanh nghiệp tham gia đều. Nếu không có ai dành thời gian dùng thử và phản hồi, các giai đoạn sẽ trôi mà không học được gì.
- Hệ thống không thể dùng một nửa. Một số nghiệp vụ buộc phải đầy đủ mới hợp lệ, khi đó khó chia.
- Có nguy cơ chắp vá. Nếu không có định hướng tổng thể từ đầu, các giai đoạn nối nhau thiếu nhất quán. Vì vậy cần một bức tranh chung dù chi tiết chỉ làm dần.
Quy trình tổng thể bao quanh các giai đoạn
Mỗi giai đoạn nhỏ vẫn đi qua các bước quen thuộc: khảo sát, thiết kế, xây dựng, kiểm thử, triển khai, vận hành. Xem mô tả từng bước ở góc nhìn khách hàng trong quy trình phát triển phần mềm theo yêu cầu từ khảo sát đến vận hành.
Bước tiếp theo
Nếu bạn muốn bắt đầu bằng một bản nhỏ và mở rộng dần, hãy gửi mô tả nhu cầu để chúng tôi cùng chia mốc. Tìm hiểu cách chúng tôi làm tại trang dịch vụ viết phần mềm theo yêu cầu, hoặc gửi yêu cầu báo giá để được phân tích quy trình trước khi báo giá theo giai đoạn.
