Menu
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Đang tải...

Chủ đề 9 · Traceability & Quản lý Thay đổi Yêu cầu — Tự động hóa Traceability bằng AI-Agent

AI cho BA — Toàn tập (10 chủ đề) Bài 70/80

Bài 6 — Tự động hóa Traceability bằng AI-Agent

Từ "chat thủ công" lên "agent tự chạy"

Đến đây bạn đã dùng AI kiểu hội thoại: copy-paste vào, đọc kết quả ra. Bước tiến tiếp theo là agent — AI được nối với công cụ (Jira, Confluence, Google Sheet, kho test) để tự lấy dữ liệu, tự đối chiếu, tự cảnh báo theo lịch, không cần bạn dán tay. Mục tiêu không phải "AI làm hết", mà là giảm việc lặp để bạn tập trung vào phán đoán.

Agent traceability làm được gì

  • Định kỳ đọc yêu cầu mới và test mới → cập nhật RTM nháp.
  • Tự phát hiện: REQ mới chưa có test, test mới không gắn REQ, CR chưa chạy impact.
  • Gửi cảnh báo (Slack/Telegram/email) danh sách lỗ hổng cần BA xử lý.
  • Soạn sẵn phiếu impact nháp khi có CR mới, chờ BA duyệt.

Ví dụ cụ thể: mô tả "vai trò" cho agent (system prompt)

Dù bạn dùng nền tảng nào (Copilot Studio, một workflow tự dựng, hay agent nội bộ), phần cốt lõi là bản mô tả vai trò + ràng buộc an toàn:

VAI TRÒ: Bạn là Traceability Agent hỗ trợ BA.
NGUỒN DỮ LIỆU (chỉ đọc): danh sách yêu cầu (Jira epic X), test case (thư mục Y), 
RTM hiện tại (Google Sheet Z).

NHIỆM VỤ mỗi lần chạy:

  • Lấy REQ và TC mới/đã đổi kể từ lần chạy trước.
  • Đề xuất mapping REQ<->TC theo ngữ nghĩa (KHÔNG ghi đè RTM, chỉ đề xuất).
  • Liệt kê: REQ chưa có TC, TC mồ côi, CR chưa có phiếu impact.
  • Xuất báo cáo markdown ngắn + gửi kênh #ba-traceability.
RÀNG BUỘC BẮT BUỘC:
  • KHÔNG tự ý sửa RTM/Jira; mọi thay đổi phải chờ BA bấm duyệt.
  • Nếu độ tin cậy < 'Cao', đánh dấu [CẦN BA XEM].
  • KHÔNG bịa ID; nếu thiếu dữ liệu, báo "thiếu nguồn" thay vì suy đoán.
  • KHÔNG gửi nội dung chứa dữ liệu khách hàng ra ngoài kênh nội bộ.
  • Ghi log mọi đề xuất kèm lý do để BA truy vết.

Các bước dựng agent tối giản (không cần code)

  • Bắt đầu bằng agent chỉ đọc + chỉ cảnh báo (read-only). Tuyệt đối chưa cho ghi.
  • Kết nối 1 nguồn trước (ví dụ chỉ Google Sheet RTM + 1 file test), mở rộng sau.
  • Đặt lịch chạy nhẹ (cuối ngày/cuối sprint), không realtime để dễ kiểm soát.
  • Cho agent gửi báo cáo vào 1 kênh riêng, BA duyệt thủ công vài tuần.
  • Khi đã tin, mới cân nhắc cho agent tạo bản nháp (draft) — vẫn cần người duyệt.
  • Định kỳ kiểm tra "sai số": lấy mẫu 10 đề xuất, đếm đúng/sai để theo dõi chất lượng.

Template "Agent Safety Card" (tái dùng)

[TRACEABILITY AGENT — SAFETY CARD]
Quyền truy cập: [ ] Read-only  [ ] Draft (chờ duyệt)  [ ] KHÔNG có quyền ghi trực tiếp
Nguồn kết nối: ____ (liệt kê, ai phê duyệt)
Tần suất chạy: ____
Kênh cảnh báo: ____
Ngưỡng "cần BA xem": độ tin cậy < Cao
Cấm tuyệt đối: sửa RTM/ticket không qua duyệt; gửi PII ra ngoài; bịa ID
Cơ chế log & truy vết: ____
Người chịu trách nhiệm (owner): ____
Đánh giá sai số định kỳ: mỗi ____ tuần, mẫu ____ đề xuất

Sai lầm thường gặp

  • Cho agent quyền ghi quá sớm. Agent tự sửa RTM/Jira khi còn ảo giác = phá dữ liệu hàng loạt, khó lần ngược. Luôn bắt đầu read-only, nâng quyền dần.
  • Không có log. Nếu agent đề xuất sai mà không lưu lý do, bạn không thể audit. Bắt buộc ghi log mọi đề xuất.
  • Rò rỉ dữ liệu quy mô lớn. Agent nối vào nhiều nguồn → nếu gửi báo cáo nhầm kênh/ra ngoài, hậu quả gấp bội so với chat lẻ. Khóa phạm vi kênh, cấm PII.
  • Phụ thuộc quá mức, bỏ giám sát. "Agent chạy tự động rồi" nên không ai đọc báo cáo → sai tích tụ âm thầm. Duy trì đánh giá sai số định kỳ.
  • Ảo giác được khuếch đại. Một lỗi mapping lặp lại mỗi lần chạy. Giữ người duyệt ở khâu áp dụng thay đổi.
> Agent là trợ lý cần cù, không phải người quyết định. Tự động hóa phần lặp lại, giữ nguyên quyền phán quyết cho BA — đó là ranh giới an toàn.