← Tiểu luận

Backlog Refinement và AI: điều gì thực sự thay đổi

Phân tích thực tiễn về cách AI thay đổi Backlog Refinement: điều gì được tăng tốc, rủi ro xuất hiện ở đâu, thời gian của đội được phân bổ lại như thế nào và cần kiểm tra thủ công những gì.

33 phút đọc
TelegramBản gốc
Backlog Refinement và AI: điều gì thực sự thay đổi

Đây là bài viết đầu tiên trong loạt bài về cách AI thay đổi các cuộc họp kinh điển của đội phát triển đa chức năng. Dưới đây tôi sẽ bắt đầu với Backlog Refinement, và trong các tài liệu tiếp theo sẽ lần lượt phân tích Planning, Daily, Review, Retrospective và sau đó tổng hợp tất cả vào một bài viết tổng quan cuối cùng.

Tôi xin làm rõ ngay khung khái niệm: dưới đây tôi nói về refinement như một phiên họp định kỳ của đội và thực hành làm rõ các backlog item, chứ không nhất thiết là một sự kiện Scrum chính thức riêng biệt. Điều này quan trọng để đảm bảo độ chính xác của thuật ngữ: trong Scrum Guide 2020 (RU PDF) refinement được mô tả như một ongoing activity, chứ không phải một event độc lập. Trong bản tiếng Nga của Scrum Guide 2020, ý này được diễn đạt trực tiếp: làm rõ Product Backlog là hoạt động thường xuyên nhằm bổ sung chi tiết, thứ tự và kích thước.

Backlog Refinement là một trong những nơi đầu tiên mà AI bắt đầu mang lại lợi ích khá hữu hình cho đội. Nó giúp nhanh chóng thu thập ngữ cảnh, chuẩn bị bản nháp mô tả công việc, nhanh chóng tạo bản nháp tiêu chí nghiệm thu, tìm các trường hợp tương tự và xây dựng danh sách câu hỏi mở. Luận điểm này cũng đã được các công trình ứng dụng hơn ủng hộ: ví dụ, trong LLM-Assisted Requirements Engineering in Agile MDD đã có đánh giá riêng việc sinh tiêu chí nghiệm thu, và trong nghiên cứu tình huống công nghiệp Acceptance Test Generation with Large Language Models người dùng ghi nhận rằng các kịch bản do AI tạo giúp phát hiện những trường hợp trước đây bị bỏ sót. Nhưng chính vì vậy, ở đây đặc biệt dễ rơi vào bẫy: nhầm lẫn một bản nháp được trình bày đẹp với một nhiệm vụ thực sự rõ ràng.

Theo tôi, AI không làm đơn giản hóa refinement theo nghĩa đội giờ đây cần suy nghĩ ít hơn. Nó thay vào đó làm rẻ đi phần công việc thủ công đắt đỏ nhất xung quanh nó — tìm kiếm, tóm tắt, đóng gói và phân rã sơ bộ. Điều đó có nghĩa là giá trị của chính cuộc thảo luận của đội không biến mất mà dịch chuyển: ít thời gian hơn dành cho việc gom từ hỗn độn thành một thứ giống như nhiệm vụ, và nhiều hơn cho việc hiểu liệu có thể đưa nó vào làm việc hay không.

“AI tăng tốc không phải bản thân sự thống nhất của đội, mà là việc chuẩn bị tài liệu cho nó”

Tại sao những thay đổi lại được cảm nhận rõ nhất chính ở Backlog Refinement

Nếu nhìn vào các nghi thức và cuộc họp quen thuộc của đội trong thực hành Agile, refinement hóa ra là một trong những quy trình nhạy cảm nhất với sự xuất hiện của AI. Lý do khá đơn giản: xung quanh refinement từ trước đến nay có rất nhiều công việc trí óc thủ công mang tính lặp lại. Cần thu thập ngữ cảnh phân tán từ tài liệu, ticket cũ, các cuộc trao đổi và ký ức của con người. Cần biến một ý tưởng kinh doanh thô thành một backlog item dễ hiểu. Cần diễn đạt vấn đề kinh doanh, kịch bản, tiêu chí nghiệm thu, ràng buộc, câu hỏi mở, phụ thuộc và các trường hợp biên có thể xảy ra.

Chính vào lớp công việc này AI xâm nhập đặc biệt tốt. Điều này cũng phù hợp với cách người ta thảo luận hiện nay về việc ứng dụng LLM trong requirements engineering: các mô hình mạnh về tóm tắt, cấu trúc hóa sơ bộ yêu cầu, sinh bản nháp và hỗ trợ chuẩn bị phân tích, nhưng yếu hơn ở những nơi cần độ chính xác miền nghiệp vụ, khả năng truy vết và trách nhiệm đối với quyết định cuối cùng. Theo nghĩa đó, refinement thực sự trở thành một trong những quy trình đầu tiên mà lợi ích của AI được cảm nhận nhanh chóng, còn giới hạn độ tin cậy của nó — gần như ngay lập tức. Điều này được viết rõ trong bài tổng quan Challenges in applying large language models to requirements engineering tasks, trong bài tổng quan hệ thống mới Large Language Models (LLMs) for Requirements Engineering (RE): A Systematic Literature Review, và trong công trình ứng dụng hơn LLM-Assisted Requirements Engineering in Agile MDD.

Đội phân tích backlog item với sự hỗ trợ của AI và các artifact Agile
AI tăng tốc tốt việc chuẩn bị cho refinement, nhưng không thay thế việc kiểm tra tập thể về ý nghĩa.

Refinement trông như thế nào trước AI

Nói đơn giản, trước AI, refinement rất thường là quá trình lắp ghép hiểu biết thủ công. Vào backlog không phải một nhiệm vụ đã sẵn sàng, mà đúng hơn là một ý định kinh doanh: cải thiện onboarding, thêm nhắc nhở, cung cấp cho quản lý một báo cáo mới, giảm số lượng yêu cầu quá hạn. Sau đó Product Owner, chuyên viên phân tích hoặc một ai đó trong nhóm lead bắt đầu thủ công thu thập ngữ cảnh: lục lại các yêu cầu cũ của khách hàng, các tính năng tương tự, ràng buộc của kiến trúc hiện tại, trạng thái đang vận hành, các thông báo hiện có, UI pattern và mọi thứ khác có thể bất ngờ nổi lên ngay trong cuộc thảo luận.

Sau đó, chính người này hoặc một vài người cố gắng thủ công biến những gì đã thu thập thành bản nháp đầu tiên: phát biểu vấn đề kinh doanh, mô tả kịch bản, viết tiêu chí nghiệm thu, nêu ra các câu hỏi mở và chỉ ra những ràng buộc tiềm ẩn. Nhưng ngay cả khi bản nháp như vậy đã tồn tại, cuộc họp vẫn thường mất thời gian để đưa bối cảnh vào đầu toàn bộ đội ngũ. Chủ sản phẩm giải thích lại điều doanh nghiệp muốn, chuyên viên phân tích kể lại những gì đã tìm hiểu được, lập trình viên nêu ra các ràng buộc kiến trúc, QA lôi ra các kịch bản biên, nhà thiết kế và frontend thảo luận xem có cần một màn hình riêng không và nó sẽ nằm ở đâu.

Cùng một tình huống: không có AI và có AI

Để không dừng lại ở mức những công thức chung chung, tôi sẽ lấy một tình huống cụ thể. Sản phẩm là một nền tảng B2B LMS cho đào tạo doanh nghiệp. Các khách hàng lớn giao cho nhân viên những khóa học bắt buộc về compliance, bảo mật và các quy định nội bộ. Từ phía doanh nghiệp có yêu cầu: cần thêm email nhắc nhở tự động cho những nhân viên chưa hoàn thành khóa học bắt buộc trước hạn chót.

Thoạt nhìn, đây có vẻ là một tác vụ đơn giản về gửi email. Nhưng ngay từ những bước đầu đã rõ ràng rằng thực tế ở đây có nhiều ngã rẽ: ai được coi là chưa hoàn thành khóa học, khi nào gửi nhắc nhở, làm sao khử trùng lặp các lần gửi, khách hàng cấu hình việc này thế nào, có cần nhật ký gửi không, xử lý múi giờ ra sao, lấy ngôn ngữ email nào và có cần loại trừ người dùng đã lưu trữ và đã vô hiệu hóa không.

Ở chế độ không có AI, đội ngũ chủ yếu đi đến những câu hỏi này thông qua việc chuẩn bị thủ công kéo dài và một cuộc trao đổi đồ sộ ngay tại cuộc họp. Đầu tiên, Chủ sản phẩm nêu bối cảnh khách hàng. Sau đó chuyên viên phân tích thủ công đi qua các tài liệu nội bộ: tìm các yêu cầu tương tự cũ, xem dịch vụ thông báo, kiểm tra trạng thái hiện tại của các assignment, sự tồn tại của tác vụ lập lịch, trường cấu hình ngôn ngữ và múi giờ. Ngay ở giai đoạn này đã lộ ra những ràng buộc thực tế: hệ thống có mẫu email nhưng chỉ cho email giao dịch; múi giờ được lưu ở cấp khách hàng chứ không phải người dùng; không có nhật ký gửi; cũng không có mô hình nhắc nhở riêng trong sản phẩm.

Sau đó chuyên viên phân tích thủ công lắp ráp bản nháp đặc tả đầu tiên, nhưng nó vẫn còn non. Ví dụ, trong đó có thể chưa ghi lại các trạng thái chính xác cần gửi nhắc nhở, logic khử trùng lặp, khối lượng công việc tối thiểu cho UI, fallback theo ngôn ngữ hoặc ranh giới của phiên bản đầu tiên. Và ngay tại buổi refinement, đội ngũ hoàn thiện tác vụ ngay trong lúc trao đổi. Chính ở đó mới rõ rằng nhắc nhở chỉ cần cho các khóa học bắt buộc, rằng các trạng thái not_started và in_progress phù hợp, còn expired tốt hơn không nên đưa vào phiên bản đầu tiên, rằng nếu không có nhật ký gửi thì bộ phận hỗ trợ và đội ngũ đồng hành khách hàng sẽ nhanh chóng chìm trong câu hỏi, và nếu không có biện pháp bảo vệ riêng sẽ có trùng lặp khi tác vụ lập lịch chạy lại.

Ở chế độ có AI, chính tình huống đó lại trông khác. Chủ sản phẩm tải vào AI bản tóm tắt ngắn từ đội ngũ đồng hành khách hàng, các yêu cầu gần đây của khách hàng và yêu cầu gốc thô. AI nhanh chóng nhóm các nỗi đau của khách hàng, làm nổi bật những kỳ vọng lặp lại và giúp hình thành cách phát biểu vấn đề. Chuyên viên phân tích yêu cầu AI nêu ra mọi thứ liên quan đến luồng thông báo, trạng thái assignment, tác vụ lập lịch, cấu hình ngôn ngữ, múi giờ và các tác vụ tương tự trong Jira. Backend chạy trước qua AI mô tả kiến trúc thông báo hiện tại và yêu cầu đề xuất cách tiếp cận kỹ thuật. Frontend và nhà thiết kế nhanh chóng kiểm tra xem nên tích hợp cài đặt và lịch sử gửi ở đâu hợp lý hơn. QA nêu ra danh sách khởi đầu các trường hợp biên và rủi ro về thời gian.

Ở đây thường nảy sinh một câu hỏi tự nhiên: vậy nếu AI bỏ sót điều gì thì sao? Rốt cuộc có thể tin bản tóm tắt ngắn như vậy đến mức nào, đặc biệt khi nguồn dữ liệu lớn? Các nghiên cứu và tình huống thực tiễn ở đây cho một bức tranh khá tỉnh táo: LLM thực sự có thể tăng tốc việc tạo user story, bản nháp tiêu chí nghiệm thu và đặc tả sơ bộ, nhưng chất lượng kết quả phụ thuộc rất nhiều vào bối cảnh đầu vào, lĩnh vực và việc kiểm tra sau đó của con người. Vì vậy cũng hữu ích khi ghi nhớ những công trình ứng dụng hơn như AI-Generated User Stories: Are They Good Enough? và LLM-Assisted Requirements Engineering in Agile MDD: chúng cho thấy rõ rằng việc tạo ra một bản nháp mạnh và việc sẵn sàng cho phát triển không phải là một.

Theo kinh nghiệm làm việc với Cursor của tôi, trong các tình huống ứng dụng, tôi khá hiếm khi nghi ngờ việc liệu mô hình có khả năng tạo ra bản nháp đầu tiên cần thiết trên một tập nguồn lớn hay không. Điều quan trọng hơn nhiều là: tôi đã diễn đạt nhiệm vụ tốt đến đâu, đã đặt ra những ràng buộc nào, đã kịp thêm những câu hỏi làm rõ nào và đã tổ chức việc kiểm tra kết quả chính xác ra sao. Khi tôi có nghi ngờ, tôi không cố giải quyết nó bằng câu hỏi "tin hay không tin AI" — tôi chỉ làm rõ thêm yêu cầu, yêu cầu hiển thị riêng các nguồn, tách ra những điểm gây tranh cãi, phân tách sự kiện và giả định, hoặc tái tạo câu trả lời với một khung khác. Theo nghĩa này, làm việc với AI rất giống với coaching: kỹ năng đặt những câu hỏi chính xác, không chỉ kích hoạt việc tạo sinh mà còn hướng tư duy của mô hình đi đúng hướng, là rất hữu ích.

Tất nhiên, đây là kinh nghiệm cá nhân của tôi chứ không phải một quy tắc phổ quát. Có thể tôi sẽ viết riêng thêm một bài về niềm tin vào AI, chất lượng của các câu hỏi làm rõ và việc kiểm tra kết quả có kiểm soát. Đối với refinement, điều này đặc biệt quan trọng: cơ sở nguồn càng lớn và bản tóm tắt ngắn càng thuyết phục, thì nguy cơ nhầm lẫn giữa sự chuẩn bị mạnh mẽ với sự hiểu biết đã được kiểm chứng càng cao.

“Cơ sở nguồn càng lớn và bản tóm tắt ngắn càng thuyết phục, thì nguy cơ nhầm lẫn giữa sự chuẩn bị mạnh mẽ với sự hiểu biết đã được kiểm chứng càng cao”

Kết quả là nhóm đến buổi refinement không còn với một ý tưởng thô mà với một bản phác thảo khá mạnh: có bản nháp câu chuyện người dùng, bản nháp tiêu chí chấp nhận, các câu hỏi mở, danh sách rủi ro, cách tiếp cận kỹ thuật sơ bộ và đề xuất UI. Nhờ đó, bản thân cuộc họp trở nên ngắn hơn và có trọng tâm hơn. Nhóm không còn mất nhiều thời gian để dựng bối cảnh cơ bản mà chủ yếu thảo luận những điểm gây tranh cãi: có nên bao gồm expired, có nên làm múi giờ riêng cho từng người dùng không, có cần nhật ký gửi trong bản phát hành đầu tiên không, có nên giới hạn ở các trigger cố định không, làm thế nào để chống trùng lặp và đâu là ranh giới của phiên bản đầu tiên.

Tiến bộ của nhóm thể hiện ở đâu?

Khi nhóm mới bắt đầu sử dụng AI, nó chủ yếu hoạt động như một công cụ tạo bản nháp đầu tiên nhanh chóng. Nhưng khi trưởng thành hơn, bước hợp lý tiếp theo là ngừng chỉ làm việc với mô hình chung và bắt đầu dần chuyển vào ngữ cảnh được quản lý của nhóm những gì trước đây chỉ sống trong ký ức của con người. Đó có thể là các nguyên tắc sản phẩm, mẫu tiêu chí chấp nhận, các lý do phổ biến khiến nhiệm vụ bị từ chối tại refinement, các trường hợp biên điển hình, các ràng buộc kiến trúc, bộ câu hỏi làm rõ tiêu chuẩn, các quy định nội bộ của tổ chức, Definition of Ready và Definition of Done ở cấp tổ chức và nhóm, cũng như các ví dụ về giải pháp tốt cho những ca tương tự.

Khi đó chất lượng của bản nháp đầu tiên thực sự bắt đầu tăng lên. Không phải vì mô hình đột nhiên “tự hiểu lĩnh vực”, mà vì nhóm đã học được cách hệ thống hóa việc đưa vào đó các mẫu tư duy, ràng buộc nội bộ và quy tắc kiểm tra của chính mình. Và ở đây refinement trở thành không chỉ nơi kiểm tra nhiệm vụ mà còn là nơi nhóm dần dần huấn luyện lớp AI của riêng mình.

Điều gì thay đổi theo vai trò

Dưới đây, sẽ hữu ích nếu nhìn không chỉ các vai trò như những chức năng trừu tượng mà còn là những hành động cụ thể trong ca mô phỏng với các nhắc nhở về khóa học bắt buộc. Chính nhờ vậy, sự khác biệt giữa chế độ không có AI và có AI mới thực sự trở nên rõ rệt.

Vai trò Không có AI Có AI
Chủ sản phẩm Tự mình dựng bối cảnh khách hàng, tổng hợp yêu cầu từ nhóm hỗ trợ khách hàng, giải thích lại vấn đề kinh doanh tại cuộc họp. Chuẩn bị đầu vào đã ẩn danh, yêu cầu AI nhóm các nỗi đau của khách hàng, mang đến cuộc họp bản nháp phát biểu vấn đề và danh sách các quyết định sản phẩm gây tranh cãi.
Chuyên viên phân tích nghiệp vụ Tìm các ca tương tự, tự tay thu thập trạng thái, ràng buộc, phụ thuộc và sau đó viết lại tất cả thành bản nháp đầu tiên của đặc tả. Tổ chức yêu cầu cho AI theo các nguồn, đối chiếu bản tóm tắt ngắn với các nguồn, chỉnh sửa tiêu chí chấp nhận, ghi lại các câu hỏi mở và những gì mô hình có thể đã bỏ sót.
Lập trình viên backend Thường lần đầu hiểu sâu vấn đề ngay tại refinement, nêu ra các ràng buộc của dịch vụ thông báo và rủi ro trùng lặp ngay trong quá trình thảo luận. Trước cuộc họp nhận được bản nháp đầu tiên về các phương án kỹ thuật, kiểm tra trước việc khử trùng lặp, các tác vụ của bộ lập lịch, audit trail và ranh giới của phiên bản đầu tiên.
Lập trình viên frontend Tại cuộc họp cùng với nhà thiết kế cố gắng hiểu liệu có cần màn hình riêng không, cài đặt sẽ nằm ở đâu và điều gì thực sự thuộc UI tối thiểu. Trước cuộc họp xem bản nháp UI tích hợp do AI tạo, đánh dấu trước các điểm gây tranh cãi về cài đặt, trạng thái và ràng buộc giao diện.
Kỹ sư chất lượng / Kỹ sư QA Chủ yếu tham gia tại cuộc họp, đưa ra các kịch bản tiêu cực, xung đột trạng thái và rủi ro thời gian ngay trong cuộc trò chuyện chung. Trước cuộc họp nhận được danh sách khởi đầu các trường hợp biên, kiểm tra rằng AI không bỏ sót trùng lặp, múi giờ, các kịch bản fallback ngôn ngữ và ngoại lệ theo trạng thái người dùng.
Nhà thiết kế UX/UI Tìm hiểu nhiệm vụ trong quá trình thảo luận và ước lượng tại chỗ liệu có cần màn hình mới, khối cài đặt hay lịch sử gửi. Kiểm thử nhanh cùng với frontend nhiều phương án tiếp cận UI và đến với một đề xuất có ý nghĩa, chứ không phải từ con số không.
Scrum Master Tập hợp các thành viên, giữ thời gian, giúp không bị lạc lối trong việc dựng lại bối cảnh hỗn loạn và đưa đội ngũ trở lại cốt lõi khi cuộc thảo luận lan rộng. Dành ít thời gian hơn cho cơ chế tổ chức và căn chỉnh bối cảnh cơ bản, nhiều hơn — cho việc điều phối các quyết định gây tranh cãi, ghi nhận các câu hỏi mở và kiểm soát chất lượng thảo luận.

Ưu điểm, rủi ro và thời gian được giải phóng

Lợi ích của AI trong refinement khá rõ rệt. Bối cảnh được thu thập nhanh hơn, bản nháp nhiệm vụ xuất hiện nhanh hơn, thảo luận khởi động dễ dàng hơn và kết quả được đóng gói tốt hơn. Nhưng chính trong refinement, rủi ro của AI cũng xuất hiện rất sớm. Rủi ro rõ ràng nhất là sự rõ ràng giả tạo. AI có khả năng tạo ra các backlog item gọn gàng, trông tốt về mặt hình ảnh và cấu trúc. Vì điều này, đội ngũ dễ tự lừa mình bằng cảm giác rằng nhiệm vụ đã được hiểu, trong khi nó vẫn còn những lỗ hổng về sản phẩm và kỹ thuật.

Ở đây nên gọi tên mọi thứ đúng bản chất. Thứ nhất, đó là thiên lệch tự động hóa và sự phụ thuộc quá mức — xu hướng chấp nhận đề xuất của hệ thống quá dễ dàng và chuyển từ kiểm tra chủ động sang giám sát thụ động hơn. Trong hồ sơ NIST cho AI tạo sinh điều này được mô tả trực tiếp như sự tin tưởng quá mức vào các hệ thống AI, và trong nghiên cứu thực nghiệm Automation Bias in AI-Decision Support: Results from an Empirical Study cho thấy lợi ích cảm nhận cao của hệ thống có thể làm tăng sự đồng ý sai với các lỗi của nó, trong khi chất lượng đào tạo người dùng làm giảm khả năng xảy ra hiệu ứng như vậy. Thứ hai, đó là ảo giác của mô hình — một kết luận có vẻ hợp lý nhưng không được xác nhận bởi nguồn. Đối với refinement, điều này đặc biệt quan trọng vì AI gần như luôn hoạt động thông qua tóm tắt tài liệu, ticket và thư từ, nghĩa là rủi ro không chỉ ở “bản nháp tiêu chí chấp nhận đẹp nhưng bịa đặt”, mà còn ở sự bóp méo âm thầm bối cảnh gốc. Chính vì vậy, trong refinement AI thường sai không phải ở phong cách văn bản mà ở các sự kiện của bối cảnh — và rủi ro này được mô tả tốt trong công trình On Faithfulness and Factuality in Abstractive Summarization. Liều thuốc giải độc thực tế ở đây khá đơn giản: yêu cầu mô hình tách sự kiện khỏi giả thuyết, yêu cầu trích dẫn nguồn và xây dựng bản tóm tắt ngắn gọn sao cho có thể nhanh chóng phân rã ngược lại thành tài liệu, ticket và quyết định của đội ngũ.

Còn một tầng rủi ro nữa — dữ liệu. Trong trường hợp trên, AI làm việc với các yêu cầu của khách hàng, mô tả nội bộ hệ thống và tín hiệu người dùng. Vì vậy, đội ngũ cần thống nhất trước những gì có thể truyền cho mô hình và những gì không thể. Đối với generative AI, rủi ro không chỉ giới hạn ở prompt: dữ liệu cá nhân có thể xuất hiện ở đầu vào, đầu ra và thậm chí thông qua memorization/regurgitation của mô hình. Do đó, nếu trong công việc có dữ liệu cá nhân hoặc bối cảnh khách hàng nhạy cảm, các nguyên tắc vệ sinh dữ liệu cơ bản phải là bắt buộc: giảm thiểu khối lượng dữ liệu trong prompt, ẩn danh đầu vào khi có thể, không kéo vào mô hình bản xuất thô chưa lọc, hiểu rõ mục đích xử lý và không tin vào các tuyên bố của nhà cung cấp như «chúng tôi không xử lý dữ liệu cá nhân» hoặc «mô hình là ẩn danh» mà không có các kiểm soát tổ chức và kỹ thuật có thể kiểm chứng. Riêng biệt, nên xác định trước cơ sở pháp lý của việc xử lý, tập trường tối thiểu cần thiết, vai trò và trách nhiệm trong quy trình, và ở nơi áp dụng được — các yêu cầu về thông báo cho chủ thể dữ liệu. Nếu kịch bản bao gồm dữ liệu cá nhân và quy mô hoặc rủi ro đáng chú ý, nên đánh giá trước xem có cần DPIA hay không và ghi nhận riêng quyết định đó. Trong bối cảnh châu Âu, điều này cũng phù hợp với các nguyên tắc của GDPR Article 5, và với các khuyến nghị thực tiễn của CNIL về phát triển hệ thống AI, cũng như với hướng dẫn của EDPS về Generative AI và EDPB Opinion 28/2024.

Và ở đây nảy sinh một câu hỏi quan trọng nữa: thời gian được giải phóng của các chuyên gia đi đâu. Phương án đơn giản nhất — cố gắng nhồi thêm nhiều nhiệm vụ hơn vào đó. Trưởng thành hơn — đầu tư khoản tiết kiệm này vào chất lượng quyết định, giảm nợ kỹ thuật, phát triển các mẫu nội bộ, đào tạo, tài liệu và ít nhất là quản lý sự chú ý của đội ngũ tốt hơn. Trong bài viết tổng quan cuối cùng của loạt bài, tôi sẽ riêng nói về việc AI không chỉ thay đổi quy trình mà còn thay đổi văn hóa sử dụng thời gian của đội ngũ.

Chi phí ẩn mới không thể bỏ qua

Để cuộc trò chuyện về hiệu quả không trông quá trơn tru, cần thêm cả mặt trái: AI hiếm khi mang lại “tiết kiệm thuần” mà không có các loại công việc mới. Một phần thời gian giờ đây dành cho việc chuẩn bị dữ liệu, thiết lập quyền truy cập vào các nguồn, hỗ trợ prompt và mẫu, kiểm tra nguồn, tài liệu hóa quyết định và kiểm tra của con người. Cách nhìn này cũng phù hợp với các thực tiễn quản lý rủi ro cho generative AI: ví dụ, hồ sơ NIST cho AI tạo sinh nhấn mạnh không chỉ lợi ích của tự động hóa mà còn sự cần thiết của oversight, documentation và kiểm soát quản lý.

Đánh giá theo kịch bản về công sức cho một Backlog Refinement (theo kịch bản)

Dưới đây không phải “nhiệt độ trung bình của thị trường”, mà là mô hình kịch bản của cùng một Backlog Refinement cho cùng một nhóm bảy người: PO, BA, backend, frontend, QA, designer và Scrum Master. Đây là đánh giá cho một backlog item lớn hoặc khá mơ hồ, không phải một story nhỏ dễ hiểu. Giá trị của những con số này không nằm ở độ chính xác đến từng phút, mà ở việc so sánh cấu trúc chi phí: thời gian trước đây đã đi đâu và bây giờ nó đi đâu.

Phần tiếp theo nói cụ thể về giờ công cho một backlog item lớn — chuẩn bị, thảo luận và chỉnh sửa ngắn sau cuộc họp — chứ không phải về thời lượng của bản thân cuộc họp. Bản thân cuộc họp thường cũng được rút ngắn, nhưng một phần công việc chỉ chuyển sang chuẩn bị bất đồng bộ, các lần chạy làm rõ và kiểm tra thủ công bắt buộc.

Ghi chú về tính toán công sức: trong lịch sử, tại Scrum Guide 2017 (RU PDF) refinement cũng được mô tả như một ongoing process, và ở đó có một mốc tham chiếu rằng nó thường chiếm không quá 10% năng lực sẵn có của nhóm phát triển. Trong Scrum Guide 2020 (RU PDF) mốc tham chiếu này không còn nữa, vì vậy bảng dưới đây nên được đọc không phải như một định mức, mà như một mô hình kịch bản để so sánh hai chế độ làm việc.

Cần giải thích riêng: cột «Có AI» dưới đây đã bao gồm công việc mới cơ bản mà không có nó thì kịch bản này không hoạt động — chuẩn bị dữ liệu đầu vào, các truy vấn làm rõ, kiểm tra sơ bộ bản tóm tắt ngắn, xác minh các điểm gây tranh cãi và kiểm tra tối thiểu của con người. Tức là lợi ích cuối cùng trong bảng không phải là khoản tiết kiệm “thô” trước khi tính các chi phí mới, mà là đánh giá kịch bản thực tế hơn sau khi đã tính cơ bản các chi phí đó.

Để đánh giá này có thể tái lập, thuận tiện tính theo một sơ đồ đơn giản: TAI = Tbase × ((1 − p) + p × s) + o，trong đó Tbase — thời gian không có AI, p — tỷ lệ công việc được tăng tốc, s — hệ số tăng tốc trên phần đó, và o — công việc mới cho chuẩn bị dữ liệu, truy vấn làm rõ và kiểm tra kết quả.

Dưới đây là một ví dụ đã hiệu chỉnh đúng cho kịch bản cơ bản này. Nhiệm vụ của nó không phải chứng minh một chuẩn mực phổ quát, mà cho thấy cùng một mô hình có thể tái tạo các con số trong bảng cho một trường hợp cụ thể như thế nào. Trong một nhóm thực tế, tốt hơn nên hiệu chỉnh các tham số như vậy theo 3–5 Backlog Refinement gần nhất và sau đó có được khoảng của riêng mình. 

# Calibrated to reproduce the table (base scenario)
# T_ai = T_base * ((1 - p) + p * s) + o
roles = {
    "PO": {"T_base": 4.5, "p": 0.75, "s": 0.20, "o": 0.7},
    "BA": {"T_base": 10.0, "p": 0.70, "s": 0.20, "o": 0.6},
    "BE": {"T_base": 3.5, "p": 0.75, "s": 0.20, "o": 0.6},
    "FE": {"T_base": 3.0, "p": 0.75, "s": 0.20, "o": 0.3},
    "QA": {"T_base": 3.0, "p": 0.50, "s": 0.20, "o": 0.2},
    "UX": {"T_base": 3.0, "p": 0.50, "s": 0.20, "o": 0.2},
    "SM": {"T_base": 2.5, "p": 0.50, "s": 0.20, "o": 0.0},
}

def t_ai(x):
    return x["T_base"] * ((1 - x["p"]) + x["p"] * x["s"]) + x["o"]

total_base = sum(r["T_base"] for r in roles.values())
total_ai = sum(t_ai(r) for r in roles.values())

print("Total base:", round(total_base, 1))
print("Total AI:", round(total_ai, 1))
print("Gain:", round(total_base - total_ai, 1))

for role, x in roles.items():
    print(role, round(t_ai(x), 1))
Vai trò Không có AI Có AI (tính cả công việc mới) Điều gì thay đổi
Chủ sở hữu sản phẩm 4.5 giờ 2.5 giờ Thu thập bối cảnh khách hàng nhanh hơn, nhưng dành một phần thời gian cho việc chuẩn bị đầu vào và các truy vấn làm rõ
Chuyên viên phân tích nghiệp vụ 10 giờ 5 giờ Ít tìm kiếm và viết lại thủ công hơn, nhiều xác minh, biên tập và kiểm tra rằng AI không bỏ sót điều quan trọng hơn
Lập trình viên backend 3.5 giờ 2 giờ Nhận được phân tích kỹ thuật đầu tiên nhanh hơn, nhưng kiểm tra riêng các ràng buộc kiến trúc và rủi ro trùng lặp
Lập trình viên frontend 3 giờ 1.5 giờ Đánh giá việc tích hợp UI và cấu hình nhanh hơn, đồng thời tham gia sớm hơn vào việc kiểm tra các điểm gây tranh cãi
Kỹ sư chất lượng / Kỹ sư QA 3 giờ 2 giờ Nhận được các trường hợp biên và rủi ro thời gian sớm hơn, nhưng tham gia nhiều hơn vào việc kiểm tra các chỗ thiếu và kịch bản tiêu cực
Nhà thiết kế UX/UI 3 giờ 2 giờ Thu thập phương án UI đầu tiên nhanh hơn và loại bỏ trước các phương án giao diện thừa
Scrum Master 2.5 giờ 1.5 giờ Ít thời gian hơn cho việc căn chỉnh bối cảnh mang tính tổ chức, nhiều hơn cho việc điều phối các quyết định và ghi nhận các câu hỏi mở
Tổng cộng 29.5 giờ 16.5 giờ Lợi ích theo kịch bản — khoảng 13 giờ công cho một Backlog Refinement như vậy sau khi đã tính công việc mới cơ bản

Phạm vi kịch bản: lợi ích có thể thay đổi như thế nào

Kịch bản Không có AI Có AI Lợi ích thuần Khi nào như vậy
Thận trọng 24–28 giờ 18–21 giờ 4–10 giờ Nguồn không đầy đủ, nhiều kiểm tra thủ công, nhóm chỉ mới xây dựng các mẫu làm việc với AI.
Cơ bản 28–32 giờ 15–18 giờ 10–15 giờ Trường hợp mô phỏng trông đại khái như vậy: AI tăng tốc tốt việc chuẩn bị, nhưng công việc mới cho xác minh đã được tính đến.
Mạnh 30–36 giờ 14–17 giờ 13–19 giờ Nhóm có nguồn tốt, các mẫu lặp lại và quy tắc rõ ràng về vệ sinh dữ liệu và kiểm tra thủ công.

Công việc mới nào đã được tính trong kịch bản có AI

Bảng dưới đây không phủ định lợi ích cuối cùng từ bảng đầu tiên. Nó chỉ giải thích nhờ những hành động mới nào mà một phần thời gian tiết kiệm được quay trở lại quy trình — và tại sao ngay cả sau đó hiệu ứng thuần vẫn còn đáng kể.

Vùng công việc mới Điều gì xuất hiện với AI Tại sao cần
Chuẩn bị dữ liệu đầu vào Làm sạch, ẩn danh, trích xuất bối cảnh cần thiết Để không làm quá tải mô hình bằng rác và không kéo theo dữ liệu thừa
Truy vấn làm rõ Các lần chạy lại, làm rõ phạm vi câu trả lời, yêu cầu tách sự kiện và giả định Để không coi câu trả lời đẹp đầu tiên là hiểu biết cuối cùng
Thiết lập mẫu Prompt, mẫu đặc tả, quy tắc định dạng kết quả Để AI đưa ra bản nháp hữu ích, lặp lại được, chứ không phải văn bản ngẫu nhiên
Kiểm tra sự kiện Kiểm tra liên kết đến nguồn, thuật ngữ, trạng thái và ràng buộc Để bắt ảo giác của mô hình và sự rõ ràng giả trước cuộc họp
Ghi nhận mức độ tin cậy Xác nhận rõ những gì đã được kiểm tra thủ công và vì sao có thể tin tưởng kết quả Để nhóm không thay thế trách nhiệm bằng một bản nháp đẹp mã

Khác biệt theo từng giai đoạn

Giai đoạn Không có AI Có AI
Thu thập ngữ cảnh trước cuộc họp Tìm kiếm thủ công lâu dài qua tài liệu, ticket và ký ức của mọi người Lượt đầu qua các nguồn và bản tóm tắt ngắn được thực hiện nhanh hơn rõ rệt
Bản nháp mô tả công việc Được viết thủ công và thường còn thô Có bản phác thảo mạnh để nhóm có thể phản biện và làm rõ
Bản thân Backlog Refinement Nhiều thời gian dành cho việc thống nhất cách hiểu Trọng tâm chuyển sang các quyết định gây tranh cãi, phụ thuộc và ranh giới của phiên bản đầu tiên
Hoàn thiện sau cuộc họp Thường phải viết lại mô tả công việc gần như từ đầu Các kết luận đã được đóng gói tốt và cần ít chỉnh sửa thủ công hơn

Danh sách kiểm tra chất lượng chuẩn bị AI cho refinement

Quan trọng: Definition of Ready này là thực hành nội bộ của nhóm, không phải một phần của Scrum Guide. Ở đây nó cần thiết như một biện pháp bảo vệ chống lại sự rõ ràng giả tạo, thiếu sót và trách nhiệm mơ hồ trong chuẩn bị bằng AI.

Definition of Ready cho bản nháp AI

  • Tách biệt sự kiện và giả định: nhóm hiểu điều gì được lấy từ nguồn và điều gì do mô hình đề xuất.
  • Có liên kết hoặc chỉ dẫn rõ ràng đến nguồn cho các khẳng định chính về sản phẩm và kỹ thuật.
  • Các câu hỏi mở không bị giấu dưới văn bản gọn gàng mà được nêu rõ ràng.
  • Đã kiểm tra thuật ngữ miền, trạng thái, ràng buộc, vai trò và phụ thuộc.
  • Với mỗi khẳng định chính, mức độ chứng cứ được hiểu rõ: đó là sự kiện từ nguồn, giả thuyết đang làm việc hay giả định của mô hình.
  • Đã kiểm tra riêng các trường hợp biên, kịch bản tiêu cực và rủi ro tạm thời.
  • Rõ ràng dữ liệu nào không thể được truyền cho mô hình và những biện pháp vệ sinh dữ liệu nào đã được áp dụng.
  • Đã chỉ định người sở hữu kiểm tra theo loại khẳng định: logic nghiệp vụ, khả thi kiến trúc, khả năng kiểm thử và xử lý dữ liệu.
  • Nhóm đã đồng thuận rằng bản nháp AI là nguyên liệu để thảo luận, không phải một task gần như hoàn chỉnh.

Để danh sách kiểm tra này không quá trừu tượng, đây là cách nó sẽ trông trong trường hợp của chúng ta với email nhắc nhở:

  • AI đề xuất đưa vào các trạng thái not_started, in_progress và expired — nhóm nêu rõ rằng expired vẫn là giả thuyết, không phải quy tắc đã được xác nhận cho phiên bản đầu tiên.
  • Trong bản tóm tắt ngắn có nói rằng thông báo cần được gửi theo múi giờ của người dùng — backend đối chiếu điều này với các nguồn và xác nhận rằng trong hệ thống hiện tại múi giờ chỉ được lưu ở cấp độ client, còn việc chuyển đổi giữa các múi giờ và DST cần được kiểm tra riêng.
  • AI đã thêm lịch sử gửi như một phần “hiển nhiên” của giải pháp — Chủ sản phẩm và BA quyết định riêng xem đây là phần bắt buộc của phiên bản đầu tiên hay là cải tiến cho bản phát hành tiếp theo, vì ở đây còn có cả vấn đề kiểm toán và tải cho bộ phận hỗ trợ.
  • QA nhận được không chỉ danh sách các trường hợp biên mà là nhiệm vụ cụ thể để kiểm tra trùng lặp khi tác vụ lập lịch chạy lại, các kịch bản fallback ngôn ngữ, ngoại lệ cho người dùng archived và đã vô hiệu hóa, cùng các kịch bản tiêu cực quanh hạn chót.
  • Backend kiểm tra riêng rate limits, throttling, deliverability và cách hệ thống sẽ hành xử khi gửi lại và khi nhà cung cấp gặp lỗi.
  • PO và BA bổ sung xác thực chính sách thông báo: ai có thể nhận nhắc nhở, nơi nào cần opt-out hoặc ngoại lệ của khách hàng, và điều gì được coi là hành vi chấp nhận được cho các khóa học bắt buộc.

Với trường hợp như vậy, cũng hữu ích khi nói rõ hai điều thực tế thường xuất hiện gần giai đoạn production: deliverability nhanh chóng trở thành tải cho bộ phận hỗ trợ và nhóm đồng hành khách hàng nếu không có chẩn đoán tốt “vì sao email không đến”, còn quiet hours và cửa sổ lịch thường không phải “tùy chọn bổ sung” mà là yêu cầu doanh nghiệp của khách hàng.

Ai kiểm tra thủ công điều gì

Kiểm tra điều gì Ai sở hữu Ví dụ trong trường hợp LMS
Mục tiêu và chính sách sản phẩm PO và BA Ai và khi nào nhận nhắc nhở, ngoại lệ nào được phép, ranh giới của phiên bản đầu tiên nằm ở đâu.
Tính đúng đắn của quy tắc và trạng thái BA Trạng thái nào được coi là “chưa hoàn thành”, làm gì với expired và điều này đã được nguồn xác nhận ở đâu.
Ràng buộc kiến trúc Lập trình viên backend Khử trùng lặp, tác vụ lập lịch, tính idempotent, nhật ký kiểm toán, rate limits và hành vi khi gửi lại.
Ranh giới UI của phiên bản đầu tiên Lập trình viên frontend và nhà thiết kế UX/UI Cài đặt nằm ở đâu, có cần màn hình lịch sử riêng không và những kịch bản giao diện nào thực sự thuộc phiên bản đầu tiên.
Kịch bản tiêu cực và tạm thời Kỹ sư chất lượng / Kỹ sư QA DST, múi giờ, kịch bản fallback ngôn ngữ, ngoại lệ người dùng archived và đã vô hiệu hóa, cũng như trùng lặp khi tác vụ lập lịch chạy lại.
Điều phối quyết định và câu hỏi mở Scrum Master Điều gì đã được quyết định, điều gì còn tranh cãi và nhóm cần đưa ra thỏa hiệp có ý thức ở đâu.
Vệ sinh dữ liệu và tính cho phép của dữ liệu PO/BA và, nếu có, Security hoặc DPO Điều gì có thể truyền cho mô hình, điều gì phải được ẩn danh và những kiểm tra nào là bắt buộc trước khi chạy chuẩn bị bằng AI.

Điều tôi sẽ khuyên nhóm

  • Không coi bản nháp AI là task hoàn chỉnh chỉ vì nó trông đẹp.
  • Thống nhất rõ ràng những phần ngữ cảnh nào mà nhóm bắt buộc phải kiểm tra thủ công trước cuộc họp, và những phần nào sẽ kiểm tra ngay tại cuộc họp.
  • Dần dần chuyển các mẫu sản phẩm và quy trình của riêng mình vào lớp AI của nhóm, thay vì chỉ dùng chung một kênh chat “nguyên trạng”.
  • Không cắt giảm refinement một cách máy móc chỉ vì việc chuẩn bị đã trở nên nhanh hơn.
  • Chủ động quyết định xem thời gian được giải phóng sẽ đi đâu: vào chất lượng, đào tạo, tài liệu, nợ kỹ thuật hay việc phục hồi sự tập trung của nhóm.

Điều đặc biệt quan trọng là phải nhớ về giới hạn áp dụng của kịch bản này. Hiệu quả của AI sẽ rất khác nhau tùy thuộc vào độ chín của tài liệu, mức độ sẵn có của các nguồn nội bộ, độ phức tạp miền của sản phẩm và mức độ nhóm biết biến tri thức ngầm thành ngữ cảnh có thể lặp lại. Ở những nơi dữ liệu đầu vào yếu, AI có thể tăng tốc việc đóng gói, nhưng không nhất thiết cải thiện chất lượng quyết định.

Kết luận

Nếu thật ngắn gọn, thì hiệu quả chính của AI đối với refinement tôi sẽ diễn đạt như sau: AI tăng tốc không phải bản thân sự thống nhất của nhóm, mà là việc chuẩn bị tài liệu cho nó. Chính vì vậy refinement trở nên nhanh hơn ở đầu vào: ngữ cảnh được thu thập nhanh hơn, bản nháp xuất hiện nhanh hơn, các câu hỏi cơ bản và rủi ro được phát hiện nhanh hơn, kết quả được đóng gói nhanh hơn.

Nhưng điều đó không làm refinement tự động trở nên đơn giản hơn. Bởi vì ngay khi chi phí chuẩn bị giảm xuống, giá trị của những gì AI chưa thực sự làm tốt sẽ tăng lên: hiểu miền, cảm nhận các ràng buộc thực tế, nhận ra sự rõ ràng giả tạo, xử lý dữ liệu một cách thận trọng và giúp nhóm đưa ra những thỏa hiệp có ý thức.

Vì vậy, cách tốt nhất để nhìn nhận AI trong refinement là như sau: nó loại bỏ một phần công việc thủ công đắt đỏ xung quanh thực hành, nhưng làm cho việc kiểm tra ý nghĩa của con người trở nên quan trọng hơn. Việc tạo ra các backlog item trở nên dễ dàng hơn bao nhiêu, thì việc hiểu được item nào thực sự sẵn sàng để thảo luận và item nào chỉ trông có vẻ tốt lại càng quan trọng bấy nhiêu. Và trong các bài viết tiếp theo của loạt bài, sẽ rất thú vị khi xem sự dịch chuyển này ảnh hưởng không chỉ đến quy trình mà còn đến văn hóa sử dụng thời gian của nhóm như thế nào.

Nguồn và tài liệu tham khảo

← Tất cả tiểu luận