Quy trình phát triển phần mềm Agile Scrum: sprint nào giao gì

Quy trình phát triển phần mềm Agile Scrum chia công việc thành các vòng ngắn, mỗi vòng tạo ra một phần sản phẩm dùng được và có thể nghiệm thu. Giá trị của Scrum nằm ở chỗ mỗi sprint giao một nhát cắt hoàn chỉnh, không nằm ở việc chia nhỏ công việc kỹ thuật.

Tóm tắt nhanh

• Scrum có bốn artefact chính: product backlog, sprint backlog, increment và Definition of Done. Thiếu Definition of Done, sprint không có điểm kết thúc.
• Câu hỏi đúng cho mỗi sprint là "người dùng làm được việc gì mới", không phải "đã xong tầng nào".
• Cách chia việc hiệu quả là nhát cắt dọc: một chức năng xuyên từ giao diện đến dữ liệu, thay vì một tầng kỹ thuật nằm ngang.
• Scrum không phù hợp cho mọi dự án. Với phạm vi cố định và hợp đồng chốt trước, cách tiếp cận tuần tự thường phù hợp hơn.

Scrum không có nghĩa là không có kế hoạch

Hiểu nhầm phổ biến nhất về Scrum là làm việc không cần kế hoạch, chỉ cần họp mỗi ngày. Thực tế ngược lại: Scrum yêu cầu kế hoạch chi tiết hơn, nhưng kế hoạch được làm ở hai tầng.

Tầng thứ nhất là tầm nhìn dài hạn — sản phẩm này giải quyết vấn đề gì, cho ai, theo thứ tự ưu tiên nào. Tầng này ít thay đổi và thường sống trong product backlog.

Tầng thứ hai là kế hoạch ngắn hạn — sprint này làm gì, xong nghĩa là gì, ai làm phần nào. Tầng này thay đổi liên tục và được làm lại ở mỗi vòng.

Vấn đề xảy ra khi một tổ chức chỉ có tầng thứ hai. Khi đó, mỗi sprint đều bận rộn nhưng sau nhiều vòng vẫn không có sản phẩm dùng được, vì không ai trả lời câu hỏi tầng thứ nhất. Ngược lại, tổ chức chỉ có tầng thứ nhất sẽ có bản kế hoạch đẹp và không có gì chạy.

Bốn artefact và người sở hữu

Trong bốn artefact này, Definition of Done là thứ hay bị bỏ nhất và cũng là thứ gây tranh chấp nhiều nhất. Nếu không có định nghĩa chung, một hạng mục có thể được gọi là xong khi đã viết mã, hoặc xong khi đã kiểm thử, hoặc xong khi đã có tài liệu. Ba cách hiểu này tạo ra ba mức chi phí khác nhau và ba cuộc tranh luận khác nhau ở cuối dự án.

Năm cuộc họp, ba quyết định

Scrum có năm cuộc họp quen thuộc: lập kế hoạch sprint, họp hằng ngày, làm rõ backlog, đánh giá sprint và cải tiến quy trình. Nhưng chỉ ba cuộc họp tạo ra quyết định có ảnh hưởng đến sản phẩm.

Lập kế hoạch sprint: chọn việc bằng tiêu chí, không bằng cảm giác

Một buổi lập kế hoạch tốt trả lời bốn câu: sprint này giao phần nào dùng được; xong nghĩa là gì; việc nào phụ thuộc việc nào; rủi ro nào có thể làm hỏng sprint.

Cách chọn việc nên dựa trên ba tiêu chí: giá trị với người dùng, mức độ rõ của yêu cầu, và mức độ độc lập với phần chưa làm. Một hạng mục có giá trị cao nhưng phụ thuộc ba phần chưa tồn tại thường là lựa chọn tồi cho sprint hiện tại, dù nó quan trọng.

Sai sót hay gặp là chọn việc theo tầng kỹ thuật: sprint này làm cơ sở dữ liệu, sprint sau làm giao diện. Cách chia này khiến không sprint nào có gì để trình diễn, và do đó không sprint nào có phản hồi thật từ người dùng.

Họp hằng ngày: phát hiện chướng ngại, không phải báo cáo

Cuộc họp ngắn hằng ngày chỉ có giá trị khi nó làm nổi lên chướng ngại. Ba câu hỏi quen thuộc — đã làm gì, sẽ làm gì, có gì cản trở — chỉ hữu ích khi câu thứ ba được trả lời thật.

Dấu hiệu cuộc họp đang vô dụng: câu thứ ba luôn là "không có gì"; cuộc họp kéo dài vì tranh luận kỹ thuật; và không ai ghi lại chướng ngại để xử lý sau cuộc họp.

Đánh giá sprint: đầu ra là phản hồi đã ghi nhận

Buổi đánh giá sprint không phải buổi báo cáo tiến độ. Đầu ra của nó là phản hồi từ người dùng hoặc người đại diện, được ghi thành hạng mục cụ thể trong backlog.

Nếu buổi đánh giá kết thúc mà không có hạng mục mới nào được thêm, sửa hoặc loại bỏ, thì buổi đó chưa tạo ra giá trị. Có hai khả năng: phần trình diễn không đủ cụ thể để người dùng phản hồi, hoặc người dự không có thẩm quyền phản hồi.

Cải tiến quy trình: một thay đổi mỗi vòng

Buổi cải tiến chỉ có giá trị khi kết thúc bằng một thay đổi cụ thể, có người chịu trách nhiệm và có cách kiểm tra ở vòng sau. Một danh sách mười điều cần cải thiện thường dẫn đến không điều nào được làm.

Sprint nào giao gì: chia theo nhát cắt dọc

Nhát cắt dọc là cách chia một chức năng xuyên qua mọi tầng cần thiết — giao diện, xử lý, dữ liệu, quyền — để người dùng thực hiện được một việc trọn vẹn. Đây là đơn vị chia việc phù hợp với Scrum.

Ví dụ với hệ thống quản lý đơn hàng:

Cách chia này có ba lợi ích. Thứ nhất, sau mỗi sprint đều có thứ để trình diễn, nên phản hồi đến sớm. Thứ hai, rủi ro kỹ thuật lộ ra sớm, vì mỗi nhát cắt đều chạm vào toàn bộ đường đi của dữ liệu. Thứ ba, nếu dự án dừng giữa đường, tổ chức vẫn có phần chạy được thay vì một tập tài liệu và một nửa cơ sở dữ liệu.

Điều cần lưu ý: nhát cắt dọc không có nghĩa là làm ẩu phần nền. Nó có nghĩa là phần nền được làm vừa đủ cho nhát cắt hiện tại, và được cải thiện ở các vòng sau khi có dữ liệu thật.

Mẫu Definition of Done

Một Definition of Done dùng được nên có từ sáu đến tám điều, áp dụng cho mọi hạng mục, không thay đổi theo từng sprint. Ví dụ:

1. Mã đã được rà soát bởi một người khác trong đội.
2. Chức năng chạy được trên môi trường kiểm thử, không chỉ trên máy người viết.
3. Kịch bản kiểm thử của hạng mục đã chạy và đạt.
4. Không còn lỗi mức nghiêm trọng hoặc cao chưa đóng.
5. Dữ liệu kiểm thử đã có, đủ để người khác chạy lại.
6. Phân quyền đã được kiểm tra với ít nhất hai vai trò.
7. Tài liệu ngắn đã cập nhật: cách dùng, cách cấu hình, hoặc ghi chú kỹ thuật liên quan.
8. Hạng mục đã được trình diễn cho người đại diện nghiệp vụ.

Hai điều cuối là hai điều hay bị bỏ. Điều 7 khiến tài liệu không bị dồn đến cuối dự án, khi ký ức đã mờ. Điều 8 khiến phản hồi đến trong vòng, thay vì chờ đến buổi đánh giá.

Cách viết yêu cầu cho sprint

Yêu cầu trong Scrum thường được viết dưới dạng câu chuyện người dùng kèm tiêu chí chấp nhận. Vấn đề là nhiều câu chuyện được viết đúng hình thức nhưng không kiểm chứng được.

Nguyên tắc: một câu chuyện người dùng phải trả lời được ba câu — ai, muốn gì, để làm gì — và tiêu chí chấp nhận phải trả lời câu thứ tư — đo bằng gì để kết luận đạt.

Khi yêu cầu phức tạp, cần tài liệu đặc tả riêng thay vì chỉ câu chuyện. Cách viết tài liệu đó được trình bày trong tài liệu đặc tả yêu cầu phần mềm.

Đo lường trong Scrum

Ba chỉ số hay được dùng là biểu đồ burndown, tốc độ hoàn thành trung bình mỗi vòng, và số hạng mục hoàn thành. Cả ba đều có giới hạn.

Biểu đồ burndown cho biết công việc còn lại, nhưng không cho biết công việc còn lại có giá trị hay không. Một sprint có thể cháy hết biểu đồ bằng cách làm những hạng mục ít giá trị.

Tốc độ hoàn thành trung bình chỉ có ý nghĩa trong nội bộ một đội, để dự báo vòng sau. Dùng nó để so sánh giữa các đội là sai, vì cách chia hạng mục và tiêu chí hoàn thành khác nhau.

Chỉ số có giá trị nhất với khách hàng không nằm trong ba chỉ số trên. Đó là số nhát cắt đã được người dùng thật sử dụng. Một hệ thống có nhiều hạng mục hoàn thành nhưng không ai dùng là hệ thống đang đi sai hướng, và chỉ số này phát hiện điều đó sớm.

Khi Scrum không phù hợp

Scrum phù hợp khi yêu cầu còn bất định, khi người dùng có thể phản hồi thường xuyên, và khi phạm vi có thể điều chỉnh theo giá trị. Ba điều kiện này không phải lúc nào cũng có.

Scrum không phù hợp khi phạm vi đã được chốt bởi hợp đồng hoặc hồ sơ thầu và không thể thay đổi; khi người dùng không thể tham gia trong suốt quá trình; hoặc khi sản phẩm phải tuân thủ một bộ tiêu chuẩn cố định cần thẩm định một lần trước khi triển khai.

Trong những trường hợp đó, cách tiếp cận tuần tự thường phù hợp hơn, và được trình bày trong quy trình phát triển phần mềm Waterfall. Cũng cần nói rõ: không có phương pháp nào đúng cho mọi dự án, và việc chọn phương pháp là quyết định quản trị, không phải quyết định kỹ thuật.

Bức tranh tổng thể của sáu giai đoạn, cùng cách chúng nằm trong bốn chặng bàn giao, được trình bày trong quy trình phát triển phần mềm là gì.

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

Một sprint nên dài bao lâu?

Độ dài sprint phụ thuộc khả năng phản hồi của khách hàng và mức độ bất định của yêu cầu. Nguyên tắc chọn: sprint phải đủ dài để tạo ra một nhát cắt dùng được, và đủ ngắn để phản hồi vẫn còn kịp điều chỉnh hướng. Nếu khách hàng chỉ họp được mỗi tháng một lần, sprint dài hơn sẽ tránh lãng phí phần đã làm sai hướng.

Scrum có cần tài liệu đặc tả không?

Cần, nhưng độ dày khác nhau. Với sản phẩm nhiều bất định, tài liệu đặc tả có thể được thay bằng backlog chi tiết kèm tiêu chí chấp nhận cho từng hạng mục. Với hợp đồng, hồ sơ thầu hoặc hệ thống có yêu cầu tuân thủ, tài liệu đặc tả riêng vẫn cần, vì đó là căn cứ nghiệm thu và đối chiếu phạm vi.

Làm sao xử lý khi khách hàng muốn thêm việc giữa sprint?

Ghi nhận vào product backlog, sắp lại thứ tự ưu tiên, và quyết định ở buổi lập kế hoạch vòng sau. Chỉ thay đổi sprint đang chạy khi việc mới có tính cấp bách thật và có thỏa thuận bằng văn bản về việc bỏ hạng mục nào để bù. Thay đổi liên tục giữa sprint khiến sprint không bao giờ kết thúc, và Definition of Done mất ý nghĩa.

Sprint review khác gì nghiệm thu?

Sprint review là buổi trình diễn để lấy phản hồi, không tạo ra hiệu lực nghiệm thu. Nghiệm thu là hành vi pháp lý, được ghi bằng biên bản, theo điều khoản hợp đồng. Trong nhiều dự án, hai việc này được gộp ở các mốc thanh toán, nhưng cần phân biệt rõ để tránh nhầm lẫn giữa "đã xem và góp ý" với "đã chấp nhận".

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

Cập nhật tháng 10/2026. Nội dung phản ánh cách WinSell tổ chức công việc trong bốn chặng bàn giao — Khám phá, Đặc tả, Xây dựng, Bàn giao và đo lường — khi áp dụng nhịp lặp ngắn. Các nội dung về nghiệm thu, sở hữu sản phẩm và nghĩa vụ thuế được đối chiếu theo Bộ luật Dân sự 91/2015/QH13 và thuế GTGT của phần mềm là bao nhiêu.

Bài viết mang tính tham khảo, không phải tư vấn pháp lý hay tư vấn thuế. Vui lòng đối chiếu văn bản gốc và tham khảo ý kiến chuyên gia.

WinSell xây dựng phần mềm theo yêu cầu, chia nhát cắt theo giá trị và nghiệm thu theo mốc — xem dịch vụ của WinSell. Báo giá sau khi chốt phạm vi.