Quy trình phát triển phần mềm linh hoạt: chọn nhịp giao hàng

Quy trình phát triển phần mềm linh hoạt không có nghĩa là không có nhịp. Nhịp giao hàng là khoảng thời gian cố định để hoàn thành một phần việc đủ nhỏ và lấy phản hồi. Chọn nhịp dựa trên ba tham số: độ lớn lô, năng lực rà soát và rủi ro phát hành.

Tóm tắt nhanh

• Nhịp cố định tạo ra điểm phản hồi; không có nhịp thì phản hồi chỉ đến khi có sự cố.
• Nhịp ngắn không tự động tốt hơn; nhịp quá ngắn làm tăng chi phí phối hợp và giảm thời gian làm việc thật.
• Ba tham số quyết định nhịp: độ lớn lô, số người rà soát được, và mức rủi ro khi phát hành.
• Số vòng trước thời hạn là phép chia, không phải cảm nhận.
• Definition of Done là thứ giữ cho nhịp ngắn không tạo ra nợ kỹ thuật.

"Linh hoạt" không có nghĩa là không có nhịp

Có hai cách hiểu sai thường gặp về làm việc linh hoạt. Cách thứ nhất là cho rằng linh hoạt nghĩa là không cần kế hoạch, ai làm đến đâu thì làm. Cách thứ hai là cho rằng linh hoạt nghĩa là phải họp mỗi ngày và giao hàng mỗi tuần.

Cả hai đều bỏ qua chức năng chính của nhịp: tạo ra điểm dừng để học. Một nhịp tốt trả lời ba câu hỏi vào cùng một thời điểm mỗi vòng. Phần việc nào đã xong theo tiêu chí đã thoả thuận. Phần việc nào chưa xong và vì sao. Vòng sau nên điều chỉnh gì.

Không có nhịp, ba câu hỏi này chỉ được trả lời khi có sự cố, và khi đó chi phí sửa đã cao hơn nhiều. Nhịp không phải nghi thức quản lý; nó là cơ chế giảm chi phí phát hiện sai.

Năm lựa chọn nhịp và khi nào dùng

Không có nhịp nào phù hợp mọi dự án. Tiêu chí chọn là khả năng tạo ra một phần việc thật sự hoàn chỉnh trong một vòng. Nếu một vòng không tạo ra được phần việc chạy được, nhịp đang quá ngắn so với độ lớn công việc. Nếu một vòng tạo ra phần việc quá lớn đến mức không ai rà hết, nhịp đang quá dài.

Bài toán chọn nhịp theo thời hạn

Giả sử dự án còn 11 tuần làm việc và cần ít nhất 4 điểm phản hồi từ người dùng trước khi phát hành.

Với nhịp một tuần, số vòng là 11, số điểm phản hồi nhiều hơn mức tối thiểu. Nhưng mỗi vòng chỉ có 5 ngày làm việc; nếu mất 1 ngày cho họp và 1 ngày cho việc chuẩn bị bản dựng, thời gian làm việc thật còn 3 ngày.

Với nhịp hai tuần, số vòng là 5, vẫn vượt mức tối thiểu 4. Mỗi vòng có 10 ngày, chi phí phối hợp khoảng 2 ngày, thời gian làm việc thật 8 ngày.

Với nhịp ba tuần, số vòng là 3, thiếu một điểm phản hồi so với yêu cầu. Muốn đủ 4 điểm, phải thêm một buổi rà giữa vòng, tức là quay lại gần nhịp hai tuần nhưng không có lợi thế của nhịp hai tuần.

Phép tính này cho thấy hai điều. Thứ nhất, số vòng là phép chia thời gian còn lại cho độ dài nhịp, không phải cảm nhận. Thứ hai, nhịp ngắn hơn không luôn tạo ra nhiều giá trị hơn, vì chi phí phối hợp tăng theo số vòng.

Cần thêm một ràng buộc: năng lực rà soát. Nếu người dùng đại diện chỉ có thể dành 2 giờ mỗi tuần, nhịp một tuần sẽ tạo ra 2 giờ rà cho mỗi vòng, còn nhịp hai tuần tạo ra 4 giờ. Với phần việc phức tạp, 2 giờ thường không đủ để phát hiện vấn đề nghiệp vụ.

Ba tham số quyết định nhịp

Độ lớn lô. Lô là tập phần việc được hoàn thành trong một vòng. Lô lớn làm tăng rủi ro vì phải chờ lâu mới biết đúng sai; lô nhỏ làm tăng chi phí vì nhiều lần bàn giao. Cách xác định độ lớn hợp lý là chọn lô mà một người dùng đại diện có thể rà trong một buổi.

Năng lực rà soát. Đây là tham số hay bị bỏ qua nhất. Nhịp chỉ có giá trị nếu có người thật sự rà và phản hồi. Nếu không ai rà, nhịp chỉ là lịch họp nội bộ và phản hồi vẫn đến muộn.

Rủi ro phát hành. Phần mềm có ảnh hưởng đến tiền, dữ liệu khách hàng hoặc quy trình pháp lý cần nhịp ngắn hơn ở giai đoạn đầu để phát hiện sai sớm. Khi rủi ro đã giảm, có thể giãn nhịp để giảm chi phí phối hợp.

Ba tham số này thường xung đột, nên cách xử lý là cố định nhịp một quãng, rồi rà lại bằng dữ liệu.

Nhịp họp tối thiểu

Bốn hoạt động này là mức tối thiểu. Điều quan trọng là sản phẩm để lại: một buổi rà kết quả không có danh sách điều chỉnh là buổi trình diễn, không phải buổi rà.

Khi nào nên giảm nhịp thay vì tăng

Có những giai đoạn nên giãn nhịp thay vì rút ngắn. Ba dấu hiệu sau là đủ để xem xét.

Phần việc liên tục bị cắt giữa vòng. Nếu vòng nào cũng phải bỏ dở phần việc để kịp mốc, nhịp đang ngắn hơn độ lớn công việc. Giãn nhịp giúp hoàn thành trọn phần việc, đổi lại ít điểm phản hồi hơn.

Rà soát không có người tham gia. Nếu buổi rà thường xuyên bị huỷ hoặc chỉ có đội kỹ thuật, vấn đề không phải nhịp mà là cam kết của người dùng. Giãn nhịp có thể giúp gom đủ người, nhưng cần đi kèm thoả thuận về thời gian tham gia.

Chi phí phối hợp lớn hơn thời gian làm việc. Nếu mỗi vòng mất hơn một phần ba thời gian cho họp và chuẩn bị, nhịp đang quá ngắn so với quy mô đội.

Ngược lại, có ba dấu hiệu nên rút ngắn nhịp: lỗi nghiệp vụ được phát hiện muộn, phạm vi thay đổi liên tục mà không ai quyết, và thời gian từ lúc viết xong đến lúc có phản hồi quá dài so với tốc độ thay đổi của nghiệp vụ.

Definition of Done: mẫu bảy mục

Nhịp ngắn chỉ có lợi khi phần việc hoàn thành thật sự hoàn thành. Một Definition of Done dùng được thường có bảy mục.

1. Mã đã được rà bởi người khác, không phải người viết.
2. Có kiểm thử tự động cho luồng chính và các trường hợp biên đã xác định.
3. Đã chạy trên môi trường thử với dữ liệu mẫu.
4. Đã kiểm tra quyền truy cập và dữ liệu hiển thị theo đúng vai trò.
5. Đã có ghi chú thay đổi cho người vận hành.
6. Đã xác nhận với người dùng đại diện hoặc người phụ trách nghiệp vụ.
7. Không còn việc tạm bợ chưa được ghi nhận thành công việc riêng.

Mục thứ bảy là mục quan trọng nhất và hay bị bỏ nhất. Mọi việc tạm bợ không được ghi nhận sẽ trở thành nợ kỹ thuật không ai theo dõi. Cách xử lý đơn giản là mỗi lần chấp nhận tạm bợ, tạo ngay một công việc riêng với mức ưu tiên và người chịu trách nhiệm.

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

Nên chọn nhịp một tuần hay hai tuần?

Phần lớn dự án phần mềm nghiệp vụ phù hợp với nhịp hai tuần, vì đủ thời gian tạo ra phần việc hoàn chỉnh và đủ thời gian để người dùng rà. Nhịp một tuần phù hợp khi đội nhỏ, phần việc tách được thành phần nhỏ, và người dùng phản hồi nhanh. Cách quyết định thực tế là thử một nhịp trong bốn vòng, đo số phần việc hoàn thành đúng tiêu chí và số lỗi phát hiện muộn, rồi điều chỉnh.

Có bắt buộc phải họp cập nhật hằng ngày không?

Không bắt buộc, nhưng cần một cơ chế phát hiện vướng mắc trong vòng 24 giờ. Với đội cùng múi giờ, một buổi ngắn 10 đến 15 phút là cách rẻ nhất. Với đội khác múi giờ, có thể thay bằng cập nhật bằng văn bản trong kênh chung, miễn là có người chịu trách nhiệm đọc và phản hồi.

Nhịp có cần cố định mãi không?

Không. Nhịp nên được rà lại theo giai đoạn, ví dụ sau mỗi ba tháng hoặc khi cơ cấu đội thay đổi. Điều cần tránh là đổi nhịp liên tục, vì mỗi lần đổi làm mất khả năng so sánh dữ liệu giữa các vòng. Cách làm hợp lý là cố định trong một quãng đủ dài để có dữ liệu, rồi điều chỉnh một lần.

Làm sao xử lý khi người dùng không tham gia rà soát?

Cần đưa cam kết tham gia vào thoả thuận ngay từ đầu, kèm tên vai trò và thời gian dành cho mỗi vòng. Nếu vẫn thiếu người, cách xử lý là gom việc rà vào một buổi dài hơn mỗi hai vòng, và ghi nhận rủi ro phát hiện muộn như một rủi ro dự án. Không nên tiếp tục nhịp ngắn mà không có người rà, vì như vậy chỉ tạo ra cảm giác đang lặp lại.

Cập nhật và kiểm chứng

Cập nhật tháng 11/2026, rà theo hai văn bản sau khi soạn phần thoả thuận nghiệm thu:

• Luật Thương mại số 36/2005/QH11 — vanban.chinhphu.vn
• Bộ luật Dân sự số 91/2015/QH13 — vanban.chinhphu.vn

Đây không phải tư vấn pháp lý hay tư vấn thuế. Nhịp phù hợp phụ thuộc vào đội, sản phẩm và người dùng cụ thể; nội dung bài viết là khung tham chiếu, không phải quy định bắt buộc.

Bài viết liên quan: tài liệu đặc tả yêu cầu phần mềm, mẫu tài liệu đặc tả yêu cầu phần mềm, quy trình phát triển phần mềm là gì và thuế GTGT của phần mềm là bao nhiêu.

Nếu bạn cần một nhịp giao hàng có tiêu chí hoàn thành rõ thay vì các mốc hình thức, WinSell xây dựng phần mềm theo yêu cầu theo bốn giai đoạn Khám phá, Đặc tả, Xây dựng, Bàn giao và đo lường — xem dịch vụ của WinSell. Báo giá sau khi chốt phạm vi.