Bắt đầu từ giá trị cần kiểm chứng
Nguyên tắc Agile ưu tiên bàn giao sớm, liên tục phần mềm có giá trị và xem phần mềm hoạt động được là thước đo chính của tiến độ. Vì vậy, ranh giới giai đoạn nên bám theo một năng lực nghiệp vụ có thể chạy và đánh giá, thay vì chia riêng thành cơ sở dữ liệu, giao diện và API. [1]
Gợi ý: trước mỗi giai đoạn, doanh nghiệp có thể ghi rõ vấn đề cần giải quyết, nhóm người dùng, luồng tối thiểu và dấu hiệu cho thấy kết quả đủ hữu ích để tiếp tục. Những tính năng chưa phục vụ giả định đang kiểm chứng nên được đưa vào danh sách xem xét sau, tránh làm giai đoạn đầu phình to.
Tạo lát cắt sử dụng được
Một giai đoạn nên bao phủ đủ thành phần để người dùng hoàn thành một luồng ngắn từ đầu đến cuối. Lát cắt như vậy giúp phát hiện sớm điểm chưa thống nhất giữa nghiệp vụ, giao diện, dữ liệu và tích hợp. Nhóm dự án cũng có sản phẩm cụ thể để lấy phản hồi, thay vì chỉ đánh giá từng bộ phận kỹ thuật riêng lẻ.
Ví dụ: với hệ thống mua hàng, giai đoạn đầu có thể cho phép một phòng ban tạo đề nghị, người có thẩm quyền phê duyệt và các bên xem trạng thái. So sánh nhà cung cấp, kiểm soát ngân sách nâng cao và báo cáo tổng hợp được xem xét sau. Đây là ví dụ thiết kế phạm vi, không phải công thức áp dụng cho mọi doanh nghiệp.
Đặt cổng quyết định giữa các giai đoạn
Gợi ý: kết thúc mỗi giai đoạn bằng việc xem phần mềm chạy trên luồng đã thống nhất, rà soát phản hồi và quyết định tiếp tục, điều chỉnh, tạm dừng hoặc bỏ một hạng mục. Căn cứ có thể gồm kết quả kiểm thử, khả năng hoàn thành tác vụ, vấn đề vận hành còn mở, mức sẵn sàng của dữ liệu và chi phí dự kiến cho chặng tiếp theo.
Agile chấp nhận yêu cầu thay đổi trong quá trình phát triển, nhưng điều đó không có nghĩa mọi yêu cầu mới đều phải đưa ngay vào giai đoạn đang thực hiện. Gợi ý là ghi nhận thay đổi, đánh giá ảnh hưởng đến mục tiêu và rủi ro, rồi xác định thay đổi thuộc giai đoạn hiện tại hay được ưu tiên cho giai đoạn kế tiếp. [1]
Tích hợp bảo mật vào từng chặng
NIST cho biết nhiều mô hình vòng đời phát triển chưa mô tả bảo mật đủ chi tiết, nên các thực hành phát triển phần mềm an toàn cần được tích hợp vào từng cách triển khai SDLC. SSDF là cơ sở để tổ chức lựa chọn hoạt động theo yêu cầu kinh doanh, mức chấp nhận rủi ro và nguồn lực, không phải một danh sách cố định áp dụng giống nhau cho mọi dự án. [2]
Gợi ý: ở mỗi giai đoạn, chọn hoạt động bảo mật phù hợp với phần chức năng sắp bàn giao, chẳng hạn rà soát phân quyền khi thêm vai trò hoặc kiểm tra xử lý dữ liệu khi bổ sung tích hợp. Phạm vi nên cân nhắc rủi ro, chi phí, tính khả thi và khả năng tự động hóa. Những hoạt động này giúp giảm rủi ro, không bảo đảm an toàn tuyệt đối. [2]
Giữ nhịp phối hợp và cải tiến
Gợi ý: doanh nghiệp nên chỉ định người có quyền làm rõ nghiệp vụ, xác nhận ưu tiên và phản hồi trên phiên bản đang chạy. Nhóm phát triển cũng cần nêu sớm các phụ thuộc về dữ liệu, tích hợp và hạ tầng. Chu kỳ ngắn ít có giá trị nếu câu hỏi quan trọng bị treo hoặc quyết định chỉ được đưa ra khi giai đoạn đã kết thúc.
Sau mỗi giai đoạn, nhóm có thể chọn một vài điều chỉnh cụ thể cho chặng kế tiếp, như làm rõ tiêu chí nghiệm thu sớm hơn, chuẩn bị dữ liệu trước hoặc tự động hóa bước kiểm tra lặp lại. Lịch thực hiện cũng nên dành chỗ cho sửa lỗi, cải thiện thiết kế và xử lý rủi ro kỹ thuật, thay vì chỉ nối tiếp tính năng mới.