Lập kế hoạch Sprint có AI hỗ trợ: cách tăng tốc chuẩn bị mà không đánh mất trách nhiệm

Đây là bài viết thứ hai trong loạt bài về cách AI thay đổi các cuộc họp kinh điển của đội ngũ phát triển đa chức năng. Trong bài đầu tiên, tôi đã phân tích Backlog Refinement và đi đến kết luận chính: AI tăng tốc không phải bản thân sự thống nhất của đội ngũ, mà là việc chuẩn bị tài liệu cho nó. Giờ đây hợp lý là chuyển sang bước tiếp theo — Sprint Planning — và xem cách tăng tốc chuẩn bị cho nó mà không đánh mất trách nhiệm của đội ngũ đối với mục tiêu, khối lượng và tính thực tế của sprint.

Thoạt nhìn có vẻ rằng sau một buổi refinement tốt, planning phải gần như trở thành một thủ tục kỹ thuật. Các phần tử backlog đã được làm rõ, tiêu chí chấp nhận đã được phác thảo, rủi ro đã được ghi ra, các câu hỏi mở đã được đóng một phần, các phương án tiếp cận kỹ thuật đã được chuẩn bị. Chỉ còn việc chọn các nhiệm vụ vào sprint và phân chia chúng cho từng người.

Nhưng đó chính là cái bẫy.

Sprint Planning trong Scrum không phải là cuộc họp để phân chia nhiệm vụ. Đây là sự kiện mà ở đó đội ngũ trả lời ba câu hỏi quan trọng hơn: vì sao sprint này có giá trị, thực sự có thể làm được gì trong sprint và công việc đã chọn sẽ được thực hiện như thế nào. Và nếu nhìn AI qua lăng kính này, điều chính yếu trở nên rõ ràng: AI thực sự có thể giúp đội ngũ nhanh hơn trong việc tập hợp các phương án kế hoạch, làm nổi bật các phụ thuộc, đề xuất phân rã và chuẩn bị câu hỏi. Nhưng nó không thể nhận lấy trách nhiệm cho Sprint Goal và không thể tự nó làm cho kế hoạch trở nên thực tế.

“AI giúp tập hợp một kế hoạch trông giống như thực tế. Chỉ có đội ngũ mới làm cho nó thực tế.”

Theo tôi, chính ở đây là sự dịch chuyển chính. AI tăng tốc chuẩn bị cho Sprint Planning, nhưng không thay thế bản thân Sprint Planning như là sự thống nhất của đội ngũ về mục tiêu, khối lượng và cách thức bàn giao.

Vì sao Sprint Planning không chỉ là “thu thập nhiệm vụ vào sprint”

Trong Scrum Guide 2020, Sprint Planning được mô tả như một sự kiện khởi động sprint. Kết quả của nó được tạo ra bởi công việc chung của toàn bộ Đội ngũ phát triển.

Sprint Planning được xây dựng quanh ba chủ đề

• Vì sao sprint này có giá trị?
• Có thể làm được gì trong sprint này?
• Công việc đã chọn sẽ được thực hiện như thế nào?

Đây là một trình tự quan trọng. Trước tiên không phải danh sách nhiệm vụ, mà là giá trị. Không phải “chúng ta kịp đóng cái gì”, mà là “chúng ta muốn đạt được thay đổi nào vào cuối sprint”. Chính vì vậy Sprint Goal không phải là một dòng trang trí trong Jira và cũng không phải là một bản tóm tắt ngắn gọn đẹp đẽ của các nhiệm vụ đã chọn. Đó là mục tiêu duy nhất của sprint, tức là mục tiêu duy nhất mang lại cho đội ngũ sự tập trung và cho phép đưa ra quyết định khi trong sprint xuất hiện những dữ kiện mới.

Sprint Backlog khi đó gồm ba phần: Sprint Goal như là “vì sao”, các phần tử backlog đã chọn như là “cái gì” và kế hoạch hành động như là “như thế nào”. Và đặc biệt quan trọng là Sprint Backlog là kế hoạch do các nhà phát triển tạo ra và dành cho các nhà phát triển. Chủ sản phẩm giúp chuẩn bị thảo luận và liên kết công việc đã chọn với Product Goal, Scrum Master giúp sự kiện trở nên hữu ích và hiệu quả, nhưng kế hoạch thực hiện và trách nhiệm về tính thực tế của phần kỹ thuật vẫn nằm trong đội ngũ phát triển.

Từ đó rút ra một kết luận đơn giản nhưng rất quan trọng cho cuộc trò chuyện về AI: công cụ có thể đề xuất cách diễn đạt Sprint Goal, danh sách sơ bộ các phần tử backlog, phụ thuộc, rủi ro và phân rã. Nhưng nó không thể là người mang cam kết của đội ngũ. Nó không thể nói thay đội ngũ: “chúng tôi thực sự sẵn sàng nhận việc này”.

AI thực sự thay đổi điều gì trong planning

Tôi xin nêu ngay ranh giới của bằng chứng. Cho đến nay, cơ sở nghiên cứu mạnh mẽ đúng về AI-assisted Sprint Planning trong các đội Scrum thực tế còn ít. Có nhiều công trình hơn đáng kể về các chủ đề liên quan: requirements engineering, chất lượng user story, ước lượng công sức, sinh test, ra quyết định của con người cùng với AI và quản lý rủi ro AI. Vì vậy sẽ đúng hơn nếu nói không phải “AI lập kế hoạch sprint”, mà là “AI tăng tốc việc tập hợp bản nháp kế hoạch để thảo luận và giúp đội ngũ sớm nhìn thấy một phần các lỗ hổng”. Đây là một khác biệt quan trọng.

Trước khi AI xuất hiện, việc chuẩn bị cho Sprint Planning thường khá thủ công. Chủ sản phẩm xem trước các ưu tiên và cố gắng tập hợp khối lượng công việc sơ bộ. Chuyên viên phân tích kiểm tra xem các phần tử backlog đã sẵn sàng để thảo luận đến đâu. Các nhà phát triển nhớ lại các ràng buộc kỹ thuật và các nhiệm vụ tương tự. QA nêu lên các rủi ro kiểm thử. Scrum Master theo dõi để cuộc họp không biến thành một cuộc tranh cãi hỗn loạn về những chi tiết lẽ ra phải được làm rõ trước đó.

Với AI, lớp chuẩn bị này có thể trở nên nhanh hơn rõ rệt — với điều kiện là nhóm có ngữ cảnh đầu vào chất lượng và quy trình kiểm tra kết quả rõ ràng. Mô hình có thể giúp tạo ra một vài phương án Sprint Goal, nhóm các mục backlog quanh mục tiêu, làm nổi bật các điểm yếu trong tiêu chí nghiệm thu, đề xuất danh sách phụ thuộc, tìm các nhiệm vụ tương tự trong lịch sử, phác thảo rủi ro và chuẩn bị câu hỏi cho QA, backend, frontend và design. Nhưng đây không phải bằng chứng rằng buổi planning cuối cùng sẽ luôn nhanh hơn hoặc chính xác hơn: một phần lợi ích có thể bị mất vào việc con người kiểm tra, xác minh nguồn và sửa lỗi trong bản nháp.

Điều này đặc biệt hữu ích khi nhóm đến buổi planning sau một buổi refinement có AI hỗ trợ. Trong bài viết trước, tôi đã chỉ ra rằng AI giúp chuyển một yêu cầu thô thành một mục backlog trưởng thành hơn nhanh hơn. Nhưng giờ đây nảy sinh câu hỏi tiếp theo: nếu các mục backlog trông tốt hơn, liệu điều đó có nghĩa là kế hoạch cũng tốt hơn không?

Không nhất thiết.

AI có thể làm cho các tạo tác của planning gọn gàng hơn. Nó có thể tạo cảm giác rằng mọi thứ đã được liên kết: đây là Sprint Goal, đây là khối lượng công việc, đây là rủi ro, đây là phụ thuộc, đây là ghi chú kiểm thử. Nhưng đây chưa phải là kế hoạch. Đây là bản nháp của kế hoạch. Và giá trị của Sprint Planning chính là ở chỗ nhóm kiểm tra bản nháp này với thực tế.

AI giúp tạo nhanh hơn các phương án Sprint Goal, khối lượng công việc, phụ thuộc và rủi ro, nhưng không thay thế việc nhóm kiểm tra tính thực tế của kế hoạch.

Tiếp tục cùng ca ví dụ: B2B LMS và email nhắc nhở

Để không nói chung chung, tôi sẽ tiếp tục ca ví dụ từ bài viết đầu tiên.

Có một nền tảng B2B LMS dành 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ộ. Doanh nghiệp muố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.

Trong buổi refinement, nhóm đã làm rõ rằng nhiệm vụ này chỉ có vẻ đơn giản. Trên thực tế cần thống nhất:

• ai được coi là đáp ứng điều kiện để nhận nhắc nhở;
• chỉ lấy các khóa học bắt buộc hay không;
• những trạng thái nào cần tính đến: not_started, in_progress, expired;
• cách loại trừ archived và người dùng đã bị vô hiệu hóa;
• múi giờ được lưu ở đâu;
• cài đặt ngôn ngữ và fallback ngôn ngữ hoạt động thế nào;
• cách chống trùng lặp khi nhiệm vụ của bộ lập lịch chạy lại;
• có cần nhật ký lịch sử / nhật ký kiểm toán hay không;
• nhóm hỗ trợ khách hàng cần thấy được gì;
• khối lượng công việc tối thiểu của phiên bản đầu kết thúc ở đâu.

Sau một buổi refinement tốt, nhóm có thể đến Sprint Planning với một bản chuẩn bị đã khá vững. Ví dụ, AI đã giúp tạo bản nháp user story, tiêu chí nghiệm thu, danh sách các trường hợp biên, các phương án tiếp cận kỹ thuật và câu hỏi mở. Nhưng ở buổi planning cần đưa ra một loại quyết định khác: nhóm thực sự lấy gì vào sprint gần nhất và với mục tiêu gì.

Một Sprint Goal tồi cho ca ví dụ này có thể trông như sau:

“Làm scheduler, email nhắc nhở và nhật ký lịch sử.”

Về hình thức thì dễ hiểu, nhưng đây chỉ là danh sách các thành phần. Nó không giải thích vì sao sprint có giá trị, kết quả tối thiểu nào phải xuất hiện và những thỏa hiệp nào là chấp nhận được.

Một cách diễn đạt mạnh hơn:

“Hệ thống gửi một nhắc nhở chính xác cho nhân viên đang hoạt động có khóa học bắt buộc chưa hoàn thành trước hạn chót và lưu lại lịch sử gửi có thể kiểm chứng.”

Cách diễn đạt này tốt hơn vì trong đó đã có giá trị và ranh giới. Chúng ta không hứa một bảng điều khiển khách hàng đầy đủ. Không hứa logic nhắc nhở phức tạp. Không giải quyết ngay mọi tranh luận quanh expired. Không xây dựng phân tích mở rộng. Nhưng chúng ta hứa một kết quả có giá trị tối thiểu: nhân viên cần nhận được nhắc nhở chính xác, và nhóm có thể kiểm tra ai, khi nào và vì sao email đã được gửi.

Buổi planning sẽ trông thế nào nếu không có AI

Không có AI, cuộc họp như vậy thường bắt đầu bằng việc khôi phục ngữ cảnh. Chủ sản phẩm nhắc lại yêu cầu kinh doanh. Chuyên viên phân tích kể lại những gì đã làm rõ trong buổi refinement. Backend làm rõ dịch vụ thông báo hoạt động thế nào. Frontend hỏi có cần màn hình cài đặt hay chỉ cần logic backend là đủ. QA bắt đầu đưa ra các câu hỏi về hạn chót, múi giờ, trùng lặp và trạng thái. Nhà thiết kế cố gắng hiểu liệu trong khối lượng công việc đầu tiên có UI hay không.

Một nửa cuộc họp không dành cho việc chọn một kế hoạch thực tế, mà dành cho việc đưa tài liệu trở lại trong đầu nhóm lần nữa. Đến một lúc nào đó xuất hiện cám dỗ là cứ “lấy hết những gì quan trọng”: đáp ứng điều kiện, scheduler, mẫu email, khử trùng lặp / loại bỏ trùng lặp, nhật ký lịch sử, cài đặt ngôn ngữ fallback, múi giờ, khả năng hiển thị thông tin cho nhóm hỗ trợ khách hàng, xử lý expired, cài đặt khách hàng và thêm vài trường hợp biên nữa.

Khối lượng công việc như vậy có thể trông hợp lý ở mức độ thông thường: mọi thứ đều liên kết với nhau. Nhưng chính ở đây planning bắt đầu phình ra. Nhóm dường như đang nói về một kết quả tổng thể, nhưng thực tế lại đang tập hợp nhiều hướng không chắc chắn độc lập. Chỗ thì ngữ nghĩa sản phẩm không rõ, chỗ thì triển khai kỹ thuật, chỗ thì kiểm thử, chỗ thì UI, chỗ thì hỗ trợ.

Kết quả là đến cuối cuộc họp có thể xuất hiện một Sprint Backlog trông có vẻ đầy đủ nhưng vẫn mong manh. Nó được xây dựng trên hy vọng rằng mọi điểm tranh cãi sẽ được giải quyết trong quá trình sprint. Đôi khi điều đó xảy ra. Nhưng thường thì chính theo cách này nhóm nhận được công việc chưa hoàn thành bị chuyển sang, sự phình to khối lượng công việc một cách âm thầm và cảm giác khó chịu: “chúng ta tưởng như đã thảo luận hết rồi”.

Planning thay đổi như thế nào với AI

Với AI, chính cuộc họp đó có thể bắt đầu ở một mức độ khác.

Trước planning, AI giúp Chủ sản phẩm chuẩn bị một số phương án Sprint Goal: phiên bản đầu tiên hẹp, khối lượng công việc phía khách hàng rộng hơn, khối lượng công việc an toàn về kỹ thuật, khối lượng mở rộng đầy tham vọng. Nhà phân tích yêu cầu AI liên kết các mục trong backlog với từng phương án mục tiêu và chỉ ra những mục nào không trực tiếp hỗ trợ mục tiêu. Backend chạy qua AI mô tả kiến trúc thông báo và yêu cầu làm nổi bật các rủi ro của nhiệm vụ bộ lập lịch, khử trùng lặp và tính bất biến. Frontend và nhà thiết kế kiểm tra xem UI có cần trong sprint đầu tiên hay có thể giới hạn ở hiển thị lịch sử tối thiểu. QA yêu cầu AI chuẩn bị danh sách các kịch bản tiêu cực, kịch bản biên và kịch bản gắn với thời gian.

Nhóm đến planning không phải với trang giấy trắng, mà với một tập phương án:

• khối lượng công việc tối thiểu: các khóa học bắt buộc, not_started / in_progress, loại trừ người dùng đã lưu trữ và bị vô hiệu hóa, một lời nhắc, loại bỏ trùng lặp, nhật ký lịch sử;
• khối lượng công việc mở rộng: thêm cấu hình ngôn ngữ fallback và chính sách múi giờ cẩn thận hơn;
• khối lượng mở rộng đầy tham vọng: thêm khả năng hiển thị cho nhóm hỗ trợ khách hàng;
• ngoài phạm vi công việc: expired, các quy tắc định kỳ phức tạp, phân tích mở rộng, lịch trình riêng theo khách hàng.

Điều này tiết kiệm đáng kể công sức nhận thức. Giờ đây nhóm không dành phần lớn cuộc họp để lần đầu tiên hình thành các phương án. Nhóm thảo luận phương án nào thực tế, phương án nào hỗ trợ Sprint Goal tốt hơn và những rủi ro nào không thể để ngầm hiểu.

Nhưng chính ở đây xuất hiện một cái bẫy mới. Kế hoạch do AI tập hợp có thể trông gọn gàng đến mức nhóm sẽ bắt đầu không kiểm tra nó mà chỉnh sửa nó. Không hỏi “liệu chúng ta có thực sự làm được điều này không?”, mà chỉ cải thiện cách diễn đạt. Không tranh luận về năng lực sẵn có của nhóm, mà tin vào sự phân rã đẹp đẽ. Không kiểm tra các phụ thuộc, mà cho rằng nếu chúng đã nằm trong bảng thì nghĩa là chúng đã được tính đến.

Và khi đó AI không giúp planning. Nó chỉ làm cho một kế hoạch quá lạc quan trở nên thuyết phục hơn.

Cái bẫy chính: tính hiện thực giả tạo của kế hoạch

Trong refinement, rủi ro chính là sự rõ ràng giả tạo: nhiệm vụ trông dễ hiểu vì AI đã trình bày nó đẹp đẽ. Trong Sprint Planning, rủi ro lại khác — tính hiện thực giả tạo.

Tính hiện thực giả tạo xuất hiện khi kế hoạch trông mạch lạc, đầy đủ và logic, nhưng lại không được kiểm tra dựa trên các giới hạn thực tế của nhóm. Nó có Sprint Goal, danh sách nhiệm vụ, ước lượng, phụ thuộc và rủi ro. Nhưng không ai thực sự kiểm tra liệu năng lực sẵn có của nhóm có đủ không, có công việc chưa hoàn thành từ sprint trước không, QA có bị quá tải không, chuyên gia cần thiết có sẵn không, có thể thực sự đạt đến Definition of Done không và phần khó nhất có bị giấu dưới những từ như “tích hợp”, “thêm hỗ trợ” hay “tính đến các trường hợp biên” không.

Rủi ro này khớp tốt với một số vấn đề đã biết.

Thứ nhất — sai lệch trong lập kế hoạch. Các nhóm vốn đã có xu hướng đánh giá thấp độ phức tạp của công việc tương lai, đặc biệt khi nhìn kế hoạch “từ bên trong” và tập trung vào kịch bản mong muốn. AI có thể giúp nếu nó đưa ra dữ liệu lịch sử, các nhiệm vụ tương tự, những chậm trễ trước đây và các nguyên nhân điển hình của việc chuyển công việc chưa hoàn thành. Nhưng nó cũng có thể làm trầm trọng thêm sai lệch lập kế hoạch nếu nó tạo ra một câu chuyện trơn tru, thuyết phục: “mọi thứ trông mạch lạc, nghĩa là mọi thứ đều hiện thực”.

Thứ hai — thiên lệch tự động hóa. Khi hệ thống đề xuất một kế hoạch gọn gàng, con người dễ chuyển từ chế độ kiểm tra chủ động sang chế độ chấp thuận thụ động. Nhóm không còn chủ động tìm mâu thuẫn nữa, vì “AI đã tập hợp hết rồi”. Điều này đặc biệt nguy hiểm trong planning, nơi chất lượng quyết định không phụ thuộc vào tính đầy đủ của văn bản, mà vào sự trung thực của việc thảo luận các giới hạn.

Thứ ba — ảo giác của mô hình hoặc confabulation / bịa đặt đầy tự tin. AI có thể tự tin bịa ra một phụ thuộc không tồn tại. Hoặc tham chiếu đến một “nhiệm vụ tương tự” mà thực ra chỉ tương tự bề ngoài. Hoặc đưa ra kết luận sai về trạng thái, múi giờ, cấu hình ngôn ngữ fallback hoặc giới hạn kiến trúc. Vấn đề không phải là những lỗi như vậy luôn thô thiển. Ngược lại, những lỗi nguy hiểm nhất lại trông có vẻ hợp lý.

Thứ tư là độ chính xác giả tạo. Nếu AI đưa ra một đánh giá đẹp, một khoảng ước lượng gọn gàng hoặc một chuỗi bước tự tin, đội có thể có cảm giác chính xác. Nhưng độ chính xác của planning không sinh ra từ một bảng biểu đẹp. Các nghiên cứu về ước lượng công sức trong Agile cho thấy chất lượng ước lượng phụ thuộc vào nhiều yếu tố: kinh nghiệm của đội, kinh nghiệm trước đó, quy mô nhiệm vụ, chất lượng thông tin, thực hành ước lượng, quản lý dự án và các ảnh hưởng kinh doanh. Vì vậy, thật nguy hiểm khi viết hoặc nghĩ rằng AI “cải thiện ước lượng” tự thân. Một cách diễn đạt trung thực hơn: AI có thể giúp phát hiện thông tin bị bỏ sót, các trường hợp tương tự và những giả định không ổn định, nhưng ước lượng vẫn phải được đội kiểm chứng.

Vì vậy, việc sử dụng AI trưởng thành trong Sprint Planning bắt đầu không phải từ câu hỏi “nó đã lắp cho chúng ta kế hoạch gì?”, mà từ câu hỏi “điều gì trong kế hoạch này có thể sai, chưa đầy đủ hoặc quá trơn tru?”. Một đội giỏi không chỉ cải thiện bản nháp AI, mà còn cố tình tìm cách bác bỏ nó: kiểm tra nguồn, giả định, phụ thuộc, năng lực sẵn có của đội, Definition of Done và những chỗ mà mô hình có thể đã tự tin khái quát hóa nhiều hơn mức sự thật cho phép.

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

Chủ sản phẩm

Với AI, Chủ sản phẩm nhận được các phương án Sprint Goal và khối lượng công việc nhanh hơn. Người đó có thể yêu cầu mô hình đưa ra nhiều kịch bản: tối thiểu, an toàn, tham vọng, stretch. Có thể nhanh hơn nhìn ra mục nào trong backlog thực sự hỗ trợ mục tiêu, và mục nào chỉ đơn thuần là “cũng hữu ích”.

Nhưng trách nhiệm của Chủ sản phẩm không biến mất. Ngược lại, nó trở nên rõ ràng hơn. Nếu AI đề xuất đưa vào sprint mọi thứ trông có vẻ liên quan, Chủ sản phẩm phải giữ câu hỏi về giá trị: kết quả tối thiểu nào thực sự cần cho người dùng hoặc các bên liên quan? Điều gì có thể không làm bây giờ? Điều gì sẽ phá hỏng Sprint Goal, và điều gì chỉ là nice-to-have?

Chuyên viên phân tích nghiệp vụ

Với chuyên viên phân tích, AI hữu ích như một công cụ kiểm tra tính liên kết. Nó giúp nhanh chóng tìm ra lỗ hổng trong tiêu chí chấp nhận, mâu thuẫn giữa các mục backlog, giả định ngầm và những câu hỏi nên nêu ra tại planning.

Nhưng chuyên viên phân tích vẫn là người phân biệt một yêu cầu đẹp về hình thức với một yêu cầu đã được kiểm chứng thực tế. Trong trường hợp LMS, chính chuyên viên phân tích phải nhận ra rằng “khóa học chưa hoàn thành” không phải là một thuật ngữ hiển nhiên. Đó là các trạng thái cụ thể, ngoại lệ, hạn chót, quy tắc của khách hàng và dữ liệu trong hệ thống.

Lập trình viên backend

Backend nhận được từ AI một lượt đầu nhanh về các rủi ro kỹ thuật: nhiệm vụ của bộ lập lịch, tính idempotent, khóa khử trùng lặp, nhật ký kiểm toán, logic thử lại, tích hợp với dịch vụ thông báo. Điều này tăng tốc chuẩn bị.

Nhưng AI không biết toàn bộ kiến trúc thực tế như đội biết. Nó có thể đề xuất một sơ đồ hợp lý mà không tính đến các ràng buộc legacy, hàng đợi không ổn định, đặc thù dữ liệu hoặc các thỏa thuận giữa các dịch vụ. Vì vậy backend không nên “chấp nhận” phân rã kỹ thuật của AI. Mà phải phê phán nó.

Lập trình viên frontend

Frontend có thể kiểm tra nhanh hơn xem UI có cần trong khối lượng công việc đầu tiên không, cần hiển thị những trạng thái nào, người dùng sẽ thấy lịch sử gửi như thế nào, có cần quản lý cài đặt hay chỉ cần khả năng xem là đủ.

Nhưng planning phải trả lời trung thực: UI có thực sự cần cho Sprint Goal hay đây đã là mở rộng? Nếu mục tiêu là gửi nhắc nhở đúng cách và lưu lịch sử có thể kiểm chứng, có thể giao diện khách hàng đầy đủ không cần trong sprint đầu tiên. AI có thể giúp diễn đạt các phương án, nhưng đội phải chấp nhận thỏa hiệp.

Kỹ sư chất lượng / Kỹ sư QA

QA có lẽ được lợi từ AI nhiều hơn vẻ ngoài. Mô hình nhanh chóng tạo ra các kịch bản tiêu cực, kịch bản biên, kịch bản gắn với thời gian, kiểm tra múi giờ, fallback ngôn ngữ, người dùng archived và bị vô hiệu hóa, chạy lại nhiệm vụ của bộ lập lịch và loại bỏ trùng lặp.

Nhưng chính QA phải bảo vệ đội khỏi phạm vi kiểm thử giả tạo. Một danh sách dài các ý tưởng kiểm thử chưa có nghĩa là kế hoạch có thể kiểm thử được. Kế hoạch chỉ có thể kiểm thử được khi tiêu chí chấp nhận rõ ràng, dữ liệu sẵn có, khả năng quan sát rõ ràng, và đội hiểu cách chứng minh việc hoàn thành Definition of Done.

Nhà thiết kế UX/UI

Với AI, nhà thiết kế nhanh hơn trong việc tập hợp các phương án tiếp cận UI: cài đặt nhắc nhở, lịch sử gửi, trạng thái lỗi, gợi ý cho đội hỗ trợ khách hàng. Nhưng tại planning, nhiệm vụ của người đó không phải là mở rộng khối lượng công việc bằng những tính năng giao diện đẹp, mà là giúp tách cái cần thiết khỏi cái mong muốn.

Trong trường hợp của chúng ta, một dashboard đầy đủ có thể hữu ích, nhưng không bắt buộc cho Sprint Goal đầu tiên. Nếu designer giúp thu hẹp hành trình người dùng mà không mất giá trị, người đó làm tăng tính hiện thực của kế hoạch.

Scrum Master

Trong planning có AI hỗ trợ, Scrum Master không còn là “người tổ chức cuộc họp”, mà là người bảo vệ chất lượng cam kết của đội. Nhiệm vụ của người đó là theo dõi để bản nháp AI không tự thân trở thành thẩm quyền.

Những câu hỏi hay của Scrum Master ở đây là:

• Chúng ta có thực sự hiểu vì sao sprint này có giá trị không?
• Các lập trình viên có coi Sprint Backlog này là kế hoạch của chính họ không?
• Điều gì trong bản nháp AI chúng ta đã kiểm chứng bằng sự thật?
• Kế hoạch có vẻ quá suôn sẻ ở đâu?
• Chúng ta sẽ loại bỏ điều gì đầu tiên nếu có thông tin mới?
• Sprint Goal có bị biến thành danh sách công việc không?

So sánh: Sprint Planning không có AI và có AI

Khu vực lập kế hoạch	Không có AI	Điều gì thay đổi với AI
Sprint Goal	Được hình thành trong thảo luận trực tiếp, đôi khi sau khi đã chọn công việc	AI nhanh chóng đề xuất một số phương án mục tiêu
Lựa chọn khối lượng công việc	Nhóm thảo luận tuần tự các mục backlog và thường tranh luận về ranh giới	AI tập hợp danh sách ngắn, các phương án khối lượng công việc thay thế và đề xuất ngoài phạm vi
Năng lực sẵn có của nhóm	Được tính thủ công theo người, nghỉ phép, hỗ trợ và việc chưa hoàn thành chuyển sang	AI có thể tập hợp các tín hiệu lịch sử và ràng buộc lịch
Phụ thuộc	Nổi lên qua trí nhớ và kinh nghiệm của nhóm	AI nhanh hơn trong việc trích xuất các phụ thuộc sơ bộ từ văn bản và lịch sử
Phân rã	Các nhà phát triển tự phân rã công việc	AI đề xuất phân rã nhanh hơn và chi tiết hơn
Kiểm thử	QA thủ công nêu ra các kịch bản quan trọng	AI tạo các phương án sơ bộ cho kịch bản tiêu cực và biên
Quản lý rủi ro	Rủi ro thường được nêu ra một cách rời rạc	AI nhanh chóng tạo danh sách rủi ro và sổ đăng ký giả định
Cam kết của nhóm	Nảy sinh từ sự đồng thuận của nhóm sau thảo luận	AI tạo ra một kế hoạch được trau chuốt, dễ chấp nhận hơn
Tài liệu	Thường được viết bổ sung thủ công sau cuộc họp	AI nhanh chóng ghi lại các quyết định, giả định và hành động tiếp theo

Rủi ro mới và những gì cần kiểm tra thủ công

Khu vực lập kế hoạch	Rủi ro mới	Những gì cần kiểm tra thủ công
Sprint Goal	Sprint Goal biến thành một bản tóm tắt ngắn gọn đẹp đẽ về khối lượng công việc	Mục tiêu có chứa “tại sao” chứ không chỉ “chúng ta làm gì” không
Lựa chọn khối lượng công việc	Tính đầy đủ giả tạo và khối lượng công việc bị nén quá mức	Mỗi mục có thực sự cần thiết cho Sprint Goal không? Có thể loại bỏ điều gì đầu tiên?
Năng lực sẵn có của nhóm	Bỏ qua các yếu tố phân tâm thực tế, lỗi, hỗ trợ và cuộc họp	Đã tính đến nghỉ phép, tải hỗ trợ, việc chưa hoàn thành, cuộc họp bắt buộc và chờ phụ thuộc bên ngoài chưa
Phụ thuộc	Mô hình có thể bịa ra phụ thuộc không tồn tại hoặc bỏ sót phụ thuộc tổ chức	Tất cả phụ thuộc bên ngoài đều được con người xác nhận và có người chịu trách nhiệm
Phân rã	Nhóm thụ động chấp nhận logic phân chia của người khác	Cách phân chia phản ánh kiến trúc, rủi ro và Definition of Done của nhóm
Kiểm thử	Che phủ giả: nhiều test nhưng không phải các chế độ thất bại	Có tiêu chí chấp nhận có thể kiểm chứng, khả năng quan sát và dữ liệu cho test không
Quản lý rủi ro	Danh sách có vẻ đầy đủ và khép kín chủ đề	Rủi ro nào chưa được xác nhận bằng dữ kiện? Rủi ro nào có thể giảm ngay bây giờ?
Cam kết của nhóm	Pha loãng quyền sở hữu / trách nhiệm: “kế hoạch đã được lắp ráp xong”	Các nhà phát triển đã xác nhận rõ ràng Sprint Backlog là kế hoạch của chính họ
Tài liệu	Biên bản ghi lại không phải các thỏa thuận mà là các cách diễn đạt thuyết phục của mô hình	Tất cả quyết định then chốt, dữ kiện và câu hỏi mở đều được người tham gia xác nhận

Điều quan trọng nhất trong bảng này không phải là AI “làm planning tốt hơn”. Ý chính xác hơn: AI gần như ở mọi nơi đều tăng tốc việc lắp ráp bản nháp, danh sách, phương án thay thế và biên bản. Nhưng gần như không ở đâu nó thay thế được vòng kiểm tra cuối cùng của con người về tính xác thực, tính thực tế và quyền sở hữu / trách nhiệm.

Quản trị và vệ sinh dữ liệu: những gì không thể giao cho mô hình một cách thiếu suy nghĩ

Trong planning thường xuất hiện cám dỗ tải mọi thứ vào AI: công việc trong Jira, các luồng thảo luận trong Slack, yêu cầu của khách hàng, nhật ký hỗ trợ, các phần tài liệu, lịch của nhóm, lịch sử sự cố, trao đổi với các bên liên quan. Từ góc độ chất lượng planning điều này dễ hiểu: càng nhiều ngữ cảnh thì bản nháp càng tốt.

Nhưng từ góc độ governance điều này nguy hiểm.

Nếu nhóm sử dụng AI để chuẩn bị Sprint Planning, nhóm cần thỏa thuận trước dữ liệu nào có thể truyền cho mô hình và dữ liệu nào không, ai kiểm tra kết quả và cách ghi lại các điểm gây tranh cãi. Ở đây một cách tiếp cận governance đơn giản hoạt động tốt: chỉ định rõ các kiểm tra có trách nhiệm, tách dữ kiện khỏi giả định, ghi lại những điều chưa biết, lưu giữ các ghi đè thủ công quan trọng của nhóm lên các khuyến nghị của AI và kiểm tra nguồn cho các khẳng định then chốt. Không nên dán một cách thiếu suy nghĩ vào prompt / yêu cầu gửi mô hình:

• tên khách hàng thực tế;
• địa chỉ email của người dùng và nhân viên;
• dữ liệu sản xuất;
• chi tiết sự cố bảo mật;
• thông tin đăng nhập, token, khóa API;
• nhật ký kiểm toán đầy đủ;
• tài liệu pháp lý và điều khoản hợp đồng;
• thông tin nhân sự;
• chi tiết nhạy cảm về thương mại không cần thiết cho planning.

An toàn hơn là làm việc với ngữ cảnh được tối giản và ẩn danh hóa: thay thế định danh thực bằng các thay thế ẩn danh, sử dụng biên tập có loại bỏ dữ liệu nhạy cảm / ẩn danh hóa, truyền các mẫu lịch sử tổng hợp thay vì bản trích xuất thô, tách dữ kiện khỏi giả định và ghi lại những prompt / yêu cầu gửi mô hình và phản hồi của mô hình thực sự được dùng khi chuẩn bị planning.

Đây không phải là quan liêu. Đây là cách để không biến AI-assisted planning thành kênh rò rỉ dữ liệu và không cung cấp cho mô hình nhiều ngữ cảnh hơn mức cần thiết cho một quyết định cụ thể.

Danh sách kiểm tra: Sprint Plan do AI lắp ráp có thể được thảo luận nếu…

Danh sách kiểm tra này không phải là một tạo tác Scrum chính thức. Đây là một bộ lọc thực tiễn giúp nhóm không nhầm lẫn bản nháp AI với một kế hoạch thực sự.

Sprint Plan do AI tổng hợp có thể được thảo luận nếu:

• Sprint Goal được diễn đạt như một giá trị hoặc trạng thái thay đổi cho người dùng / bên liên quan, chứ không phải như một danh sách công việc.
• Với mỗi mục backlog được chọn, nhóm có thể giải thích nó hỗ trợ Sprint Goal như thế nào.
• Năng lực khả dụng của nhóm được tính đến không phải một cách trừu tượng, mà có tính đến nghỉ phép, hỗ trợ, sửa lỗi, chuyển giao công việc chưa hoàn thành, hội nhập nhân sự mới và các cuộc họp bắt buộc.
• Công việc chưa hoàn thành từ sprint trước được làm rõ ràng: cái gì được chuyển sang, cái gì bị hủy, cái gì cần đánh giá lại.
• Các phụ thuộc bên ngoài được nêu rõ ràng, mỗi phụ thuộc có người chịu trách nhiệm và trạng thái rõ ràng.
• Với khối lượng công việc đã chọn, nhóm thấy được con đường đến Definition of Done, chứ không chỉ đến trạng thái “mã gần như xong”.
• Kế hoạch có thể kiểm thử được: có tiêu chí chấp nhận, kịch bản tiêu cực, kịch bản biên, khả năng quan sát và dữ liệu rõ ràng để kiểm tra.
• Nhóm có thể gọi tên bằng một câu khối lượng công việc tối thiểu có giá trị của sprint.
• Nhóm hiểu trước điều gì có thể bị loại bỏ đầu tiên khỏi khối lượng công việc nếu xuất hiện thông tin mới.
• Các khẳng định thực tế quan trọng từ bản nháp AI được kiểm tra thủ công: trạng thái, phụ thuộc, dữ liệu lịch sử, ràng buộc kiến trúc, quy tắc thời hạn, bản địa hóa, khử trùng lặp.
• Một trong những người tham gia đã cố gắng bác bỏ bản nháp AI một cách có chủ đích, chứ không chỉ cải thiện nó.
• Nhóm đã xem xét riêng những chỗ kế hoạch quá trơn tru, quá chính xác hoặc đáng ngờ là “đương nhiên hiển nhiên”.
• Các nhà phát triển đã xác nhận rõ ràng rằng Sprint Backlog là kế hoạch của họ, và Sprint Goal là cam kết của nhóm cho sprint.
• Kết quả của planning được ghi lại sao cho rõ ràng: điều gì đã được quyết định, điều gì được giả định, điều gì còn chưa biết và điều gì được đưa ra ngoài khối lượng công việc.

Trong thực tế, danh sách kiểm tra này có thể được sử dụng không phải như một rào cản kiểm soát chính thức, mà như một kỷ luật tư duy ngắn gọn vào cuối planning. Đặc biệt hữu ích là hai câu hỏi: “điều gì trong bản nháp AI này có thể là không đúng?” và “chúng ta sẽ loại bỏ điều gì đầu tiên nếu thực tế hóa ra phức tạp hơn?”.

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

Thứ nhất, sử dụng AI trước Sprint Planning không phải để “nó lập kế hoạch sprint”, mà để nó chuẩn bị tài liệu cho một cuộc thảo luận tốt của con người. Hãy để nó thu thập các phương án, phụ thuộc, giả định, rủi ro, trường hợp biên, các phương án thay thế cho khối lượng công việc và các câu hỏi. Nhưng quyết định phải thuộc về nhóm.

Thứ hai, luôn tách bản nháp kế hoạch khỏi cam kết của nhóm. Bản nháp AI có thể là một bản phác thảo tuyệt vời, nhưng Sprint Backlog chỉ trở thành thật khi các Nhà phát triển hiểu nó là kế hoạch của chính họ.

Thứ ba, không chấp nhận các ước lượng do AI tạo ra như thể khách quan hơn chỉ vì chúng trông có cấu trúc. Các nghiên cứu tái lập và tổng quan về đánh giá tự động / đánh giá công sức có hỗ trợ AI cung cấp đủ cơ sở để thận trọng: một mô hình phức tạp không trở nên tốt hơn một mô hình cơ sở đơn giản chỉ vì độ phức tạp của nó. Trong ước lượng, không chỉ sai sót là nguy hiểm, mà cả sự tự tin quá mức. Tốt hơn là dùng AI để phát hiện các bất định hơn là để tạo ra ảo giác về độ chính xác.

Thứ tư, ghi rõ ràng những gì nằm ngoài khối lượng công việc. Trong các phiên planning có hỗ trợ AI tốt, giá trị thường được tạo ra không chỉ bởi những gì nhóm đã chọn, mà còn bởi những gì nhóm đã có ý thức không lấy. Trong trường hợp LMS, đó có thể là expiredmột bảng điều khiển đầy đủ của nhóm hỗ trợ khách hàng, phân đoạn phức tạp của tần suất nhắc nhở và phân tích mở rộng.

Thứ năm, chỉ định người sở hữu việc kiểm tra. Ý nghĩa nghiệp vụ do Chủ sở hữu sản phẩm kiểm tra, tính liên kết của yêu cầu — nhà phân tích, tính khả thi kiến trúc — các nhà phát triển, khả năng kiểm thử — QA, ranh giới trải nghiệm người dùng — nhà thiết kế, chất lượng thỏa thuận nhóm — Scrum Master. AI có thể chuẩn bị một bản nháp chung, nhưng không thể sở hữu việc kiểm tra.

Kết luận

Nếu trong Backlog Refinement AI giúp thu thập và định hình tài liệu cho thảo luận nhanh hơn, thì trong Sprint Planning nó giúp thu thập các phương án kế hoạch nhanh hơn. Nó có thể đề xuất Sprint Goal, nhóm các mục backlog, làm nổi bật phụ thuộc, phác thảo phân rã, chuẩn bị kịch bản kiểm thử, liệt kê giả định và thậm chí ghi lại kết quả cuộc họp một cách đẹp mắt.

Nhưng điều đó không làm cho kế hoạch trở nên thực tế.

Một Sprint Plan thực tế chỉ xuất hiện khi nhóm đã trung thực kiểm tra giá trị, khối lượng công việc, năng lực khả dụng của nhóm, phụ thuộc, Definition of Done, khả năng kiểm thử và sự sẵn sàng của chính họ để nhận việc này. AI có thể tăng tốc việc kiểm tra này, nhưng không thể thay thế nó. Nó có thể giúp thấy nhiều phương án hơn, nhưng không thể chọn cam kết của nhóm thay cho con người.

Vì vậy, hiệu ứng chính của AI trong Sprint Planning tôi sẽ diễn đạt như sau: nó giảm chi phí chuẩn bị các phương án kế hoạch, nhưng tăng giá của việc kiểm tra của con người. Càng dễ tạo ra một kế hoạch đẹp, thì càng quan trọng để hiểu liệu đó có phải là kế hoạch thực sự của nhóm hay không.

Trong một đội ngũ trưởng thành, AI không biến Sprint Planning thành việc tự động tạo Sprint Backlog. Nó biến nó thành một cuộc trò chuyện cụ thể hơn về mục tiêu, các ràng buộc và sự đánh đổi. Và đó có lẽ chính là hình thức tự động hóa hữu ích nhất: không loại bỏ con người khỏi planning, mà giải phóng sự chú ý của họ cho những quyết định mà công cụ không thể đưa ra thay họ.

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

• Scrum Guide 2020 — Sprint Planning, Sprint Goal, Sprint Backlog, các vùng trách nhiệm.
• khung quản lý rủi ro AI của NIST 1.0 — quản lý / quy định, trách nhiệm giải trình / trách nhiệm, cấu hình tương tác giữa con người và AI.
• hồ sơ NIST cho AI tạo sinh — confabulation / bịa đặt đầy tự tin, phụ thuộc quá mức, quyền riêng tư và quản lý rủi ro.
• ChatGPT as a tool for User Story Quality Evaluation — ví dụ về cơ sở bằng chứng vừa phải cho các nhiệm vụ đánh giá chất lượng câu chuyện người dùng.
• Large Language Models for Software Engineering: Survey and Open Problems — tổng quan về LLM trong phát triển phần mềm / kỹ thuật phần mềm.
• Ước lượng công sức trong phát triển phần mềm Agile: tổng quan hệ thống tài liệu — các yếu tố chất lượng của ước lượng Agile.
• Reasons and Approaches for Accurate Effort Estimations in Agile Iterative Development — chất lượng thông tin, đội ngũ, thực hành ước lượng, quản lý dự án, tác động kinh doanh.
• GPT2SP replication report — hạn chế của ước lượng AI bằng story points và so sánh với các mô hình cơ sở / đường cơ sở đơn giản.
• Hướng tới lập kế hoạch Agile lặp đi lặp lại đáng tin cậy thông qua dự báo thay đổi tài liệu hạng mục công việc — mối liên hệ giữa thay đổi tài liệu và sự mong manh của planning.
• The Planning Fallacy — công trình kinh điển về việc đánh giá thấp thời hạn.
• Automation Bias in Intelligent Time Critical Decision Support Systems — thiên lệch tự động hóa, lỗi bỏ sót và lỗi hành động.
• Generalization bias in large language model summarization — rủi ro khái quát hóa quá mức trong các bản tóm tắt do mô hình ngôn ngữ lớn tạo ra.
• OWASP Top 10 cho ứng dụng LLM — thông tin nhạy cảm, phụ thuộc quá mức, rủi ro prompt và bảo mật.