genneral/sys-analysis-design
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
51506aabc7f2e0946078c5ec1cbe594597ade36c
sys-analysis-design/.claude/skills/ba-4-delivery-support/SKILL.md
Canhchimlac 51506aabc7 update skill and docs
2026-09-22 13:46:36 +07:00

15 KiB
Raw Blame History

name, description
name description
ba-4-delivery-support Giai đoạn 4 của quy trình BA — đồng hành cùng team trong lúc phát triển. Dùng để trả lời câu hỏi làm rõ của dev/QA (clarification log), quản lý change request có quy trình đánh giá tác động, review test case của QA xem có phủ đủ AC không, chuẩn bị và điều hành UAT, phân loại defect và change request. Kích hoạt khi người dùng nói "dev hỏi về spec", "trả lời câu hỏi của dev", "khách đòi thay đổi", "change request", "CR", "review test case", "chuẩn bị UAT", "kịch bản UAT", "phân loại bug hay CR", "grooming". Output vào ba-output/<PROJECT>/04-delivery/ và phải qua Gate G4 (UAT pass) trước khi go-live.

GĐ4 · DELIVERY SUPPORT — Đồng hành phát triển

Mục tiêu: giữ cho spec và sản phẩm không lệch nhau trong lúc code đang chạy.

Đây là giai đoạn chiếm nhiều thời gian thực tế nhất của BA, nhưng ít được ghi nhận nhất — vì phần lớn công việc là trả lời câu hỏi, và câu trả lời không được ghi lại thì mất luôn.

Output: QLOG · CR · TCREVIEW · UAT trong ba-output/<PROJECT>/04-delivery/

Bốn nguyên tắc bất di bất dịch

  1. Không bịa yêu cầu — dev hỏi mà spec không nói ⇒ đi hỏi PO, không tự trả lời.
  2. Không quyết định thay PO — mọi CR có ảnh hưởng scope/chi phí do PO quyết.
  3. Mọi phát biểu truy vết được — mỗi câu trả lời trong QLOG phải chỉ về BR/AC/DEC.
  4. Không ghi đè tài liệu đã qua gate — SRS đã Baselined chỉ sửa qua CR-nnn.

🔴 Nguyên tắc riêng của giai đoạn này: mọi câu trả lời cho dev phải đi vào tài liệu. Trả lời miệng hoặc qua chat rồi để đó là cách chắc chắn nhất khiến ba tháng sau không ai biết vì sao hệ thống hành xử như vậy — kể cả chính bạn.

🔴 Mọi sơ đồ theo chuẩn Archify (W13, ../ba-lifecycle/references/diagram-rules.md): spec JSON diagrams/<ARTIFACT>_<slug>.<type>.json (quality_profile: showcase, validate 0 lỗi) + mermaid có marker <!-- archify: <type> · <spec> --> (hoặc mermaid-only cho ERD/use case/2×2) + bảng đi kèm. Một đường chính, ≤ 12 node, nhãn cạnh là điều kiện/giao thức, không màu. Không có Bash ⇒ ghi humanInputNeeded "chạy archify validate/deliver + diagram-check", không tự nhận đã validate. Cây phân loại Defect/CR/Spec gap (CR §0) → workflow.

Bước 0 — Chốt việc cần làm rồi dừng lại

Chưa được ghi file. Xác định loại việc trước, vì bốn loại có quy trình khác hẳn nhau:

Loại việc Dấu hiệu Chạy phần nào
Câu hỏi làm rõ Dev/QA hỏi spec nói gì Phần A
Yêu cầu thay đổi Ai đó muốn khác với spec đã chốt Phần B
Review test case QA gửi test case cần đối chiếu AC Phần C
UAT Sắp nghiệm thu Phần D

Rồi làm bốn việc, dừng chờ trả lời:

  1. Profile — đọc 00-index/PROFILE_<PROJECT>.md. Nó quyết định hình dạng của UAT (Phần D) và mức chặt của việc đóng defect: PRODUCT = ml-model ⇒ UAT là chuỗi offline → shadow → thí điểm, không phải pass/fail · RIGOR = light ⇒ demo + checklist thay UAT chính thức · RIGOR = strict ⇒ bằng chứng phải lưu trữ được, mọi defect kể cả Low đều phải có ticket.
  2. Input dùng được — bảng File | Vai trò | Version | Status. Bắt buộc tìm SRS của US liên quan và QLOG hiện có.
  3. Phân loại sơ bộ — với mỗi mục người dùng đưa vào, đoán loại và nói rõ căn cứ.
  4. Hỏi xác nhận phân loại — vì phân loại sai giữa câu hỏi và thay đổi là lỗi tốn kém nhất ở giai đoạn này (xem §Phần B).

Ví dụ phân loại thật ở nhiều domain: examples.md.

Bỏ qua khi lệnh có go.

PHẦN A — Trả lời câu hỏi làm rõ

Dùng templates/clarification-log.md.

A1. Phân loại câu hỏi

Loại Ai trả lời được Thời hạn mục tiêu
Spec đã nói rõ, người hỏi chưa đọc thấy BA — trích dẫn đích danh mục nào Trong ngày
Spec nói mơ hồ, hiểu được hai cách BA — làm rõ và sửa spec 1 ngày
Spec không nói PO/Tech Lead — BA đi hỏi 2 ngày
Spec nói sai PO — thành CR 2 ngày

🔴 Ba loại sau đều phải sửa tài liệu. Chỉ loại đầu tiên là trả lời xong là hết việc. Trả lời cho dev mà không sửa spec nghĩa là người tiếp theo đọc spec sẽ hỏi lại đúng câu đó.

A2. Trả lời

Mỗi câu trả lời trong QLOG phải có:

  • Trích dẫn nguồn — mục nào của tài liệu nào, hoặc ai quyết định và ngày nào
  • Câu trả lời dứt khoát — không "có thể", không "tuỳ"
  • Hành động kèm theo — sửa mục nào của tài liệu nào, hay không cần sửa (ghi rõ)

Không trả lời được ngay ⇒ ghi OQ, nêu người phải trả lời và hạn, và nói với dev phương án tạm để không bị chặn (kèm cảnh báo là tạm).

A3. Đóng vòng lặp

Sau khi trả lời:

  1. Sửa tài liệu (nếu thuộc loại 2/3/4)
  2. Tăng version + ghi Change Log
  3. Báo cho những người đã đọc bản cũ — dev khác, QA. Sửa spec âm thầm còn tệ hơn không sửa
  4. Cập nhật RTM nếu AC/BR thay đổi

PHẦN B — Quản lý Change Request

Dùng templates/change-request.md.

B1. Phân biệt Defect và Change Request

🔴 Đây là phân loại tốn kém nhất khi làm sai, và nó bị làm sai thường xuyên vì hai bên đều có động cơ: dev muốn gọi là CR (không phải lỗi của mình), khách muốn gọi là defect (không phải trả thêm tiền).

Phép thử duy nhất, áp dụng máy móc:

Sản phẩm có làm đúng như tài liệu đã ký (SRS Baselined) không?
  ├── KHÔNG  → DEFECT (bug). Dev sửa, không tính thêm chi phí.
  └── CÓ     → Tài liệu có nói về tình huống này không?
                ├── CÓ, và khách muốn khác đi  → CHANGE REQUEST
                └── KHÔNG nói gì               → SPEC GAP → xem B2

Spec gap — tài liệu im lặng về tình huống đó — là vùng xám thật sự, và trách nhiệm thuộc về BA. Xử lý thẳng thắn: ghi nhận là thiếu sót của đặc tả, đánh giá tác động như một CR, nhưng nêu rõ nguyên nhân gốc trong BENEFIT ở GĐ5 để lần sau đặc tả kỹ hơn chỗ đó. Đừng đẩy sang khách như một CR bình thường, cũng đừng nhận là bug của dev.

B2. Quy trình xử lý CR — 6 bước, không bỏ bước

# Bước BA làm gì Không được làm
1 Ghi nhận Ghi nguyên văn yêu cầu, ai đề xuất, ngày Diễn giải lại theo ý mình
2 Làm rõ Hỏi cho tới khi hiểu vấn đề gốc, không dừng ở giải pháp họ đề xuất Nhận đúng câu chữ rồi đi làm
3 Đánh giá tác động Rà 6 trục như IMPACT ở GĐ2 + ước lượng cùng dev Ước lượng một mình
4 Trình phương án ≥2 phương án kèm chi phí/rủi ro + khuyến nghị của BA Chỉ trình một phương án
5 PO quyết Ghi DEC-nn: chấp nhận / hoãn / từ chối + lý do Tự quyết vì "rõ ràng là nên làm"
6 Thực thi Sửa tài liệu, tăng version, cập nhật RTM, báo team Sửa code trước, sửa tài liệu sau

🔴 Bước 2 là bước cứu được nhiều tiền nhất. Thứ khách yêu cầu thường là giải pháp họ nghĩ ra; hỏi "để làm gì?" cho tới khi ra vấn đề gốc, rồi mới định giá. Câu hỏi ở đây là câu hỏi của GĐ1, dùng lại ở GĐ4. Ba ca thật, cả ba đều ra phương án rẻ hơn: examples.md.

B3. CR đến vào lúc nào cũng phải qua quy trình

Áp lực thường gặp: "cái này nhỏ thôi, làm luôn đi cho nhanh". Trả lời: mọi thay đổi đều được ghi nhận, việc ghi nhận mất 5 phút. Thay đổi không ghi nhận sẽ:

  • Không vào test case ⇒ QA không test ⇒ lỗi lọt ra thật
  • Không vào tài liệu ⇒ người sau đọc spec thấy khác sản phẩm
  • Không vào ước lượng ⇒ trễ tiến độ mà không ai giải thích được vì sao

PHẦN C — Review test case

Dùng templates/testcase-review.md.

BA không viết test case — QA viết. BA đối chiếu xem test case có phủ đúng AC không.

C1. Bốn phép đối chiếu

# Phép đối chiếu Phát hiện
1 Mỗi AC → có ≥1 test case AC bị bỏ sót khi test
2 Mỗi test case → truy về được một AC/BR Test thừa, hoặc AC chưa viết
3 Mỗi BR → có test case kiểm tra cả ca vi phạm Rule chỉ được test ở luồng đúng
4 Mỗi dòng bảng dữ liệu biên → có test case Bug ở giá trị biên, chỗ hay lỗi nhất

C2. Bốn nhóm hay thiếu trong test case

Rà đích danh, đây là chỗ test case hay hụt:

  • Phân quyền: có test gọi thẳng API với token sai quyền không, hay chỉ test giao diện?
  • Lỗi hệ thống: có test timeout/5xx và kiểm tra dữ liệu đã nhập được giữ nguyên không?
  • Đồng thời: hai người sửa cùng một bản ghi thì sao?
  • Dữ liệu cũ: có test với bản ghi tạo trước khi có tính năng này không?

C3. Kết quả review

Không sửa test case của QA. Ghi nhận xét vào TCREVIEW với ba mức: 🔴 thiếu phủ AC (phải bổ sung) · 🟠 nên bổ sung · 💬 góp ý. Rồi thống nhất với QA, không áp đặt.

PHẦN D — UAT

Dùng templates/uat-plan.md.

🔴 Hình dạng của UAT đổi theo PRODUCT. Bảng dưới đây viết cho screen; ba loại khác nghiệm thu bằng cách khác — chi tiết ở đầu file biến thể PART 2 tương ứng:

PRODUCT Nghiệm thu bằng
screen Người dùng thao tác theo kịch bản công việc (bảng D1 bên dưới)
api-service Team tiêu thụ tích hợp thử trên sandbox, ký xác nhận hợp đồng
data-pipeline Chạy song song, đối soát số liệu với nguồn/hệ thống cũ ≥ 1 chu kỳ
batch-job Chạy song song với cách cũ, thử ngắt giữa chừng rồi chạy lại
ml-model offline → shadow → thí điểm → mở rộng; bỏ shadow là rủi ro lớn nhất

D1. Chuẩn bị — làm trước ngày UAT ít nhất một tuần

Việc Chi tiết Hay hỏng ở đâu
Kịch bản Theo luồng công việc thật, không theo màn hình Kịch bản viết theo màn hình thì người dùng không nhận ra công việc của mình
Dữ liệu Dữ liệu giống thật, đủ ca biên và ca ngoại lệ Dữ liệu quá sạch ⇒ UAT pass, thật thì lỗi
Môi trường Ai có tài khoản gì, quyền gì, truy cập từ đâu Ngày UAT mới phát hiện chưa cấp tài khoản
Người tham gia Đúng người sẽ dùng thật, không phải người đại diện Người đại diện pass, người dùng thật từ chối
Tiêu chí pass Thoả thuận trước, bằng văn bản Không thoả thuận trước ⇒ tranh cãi lúc kết luận

🔴 Tiêu chí pass phải chốt trước khi bắt đầu UAT. Ví dụ: 100% kịch bản mức Must pass · không còn defect Critical/High · defect Medium có kế hoạch xử lý. Chốt sau khi đã thấy kết quả thì không còn là tiêu chí nữa.

D2. Trong lúc UAT

BA làm người quan sát và ghi chép, không làm người hướng dẫn thao tác. Người dùng loay hoay ở đâu là thông tin quý — đừng cứu họ quá sớm, hãy ghi lại.

Mỗi phát hiện ghi ngay: kịch bản nào · thao tác gì · mong đợi gì · thực tế gì · ảnh chụp · phân loại sơ bộ (defect / CR / hiểu nhầm cách dùng).

Loại thứ ba — hiểu nhầm cách dùng — thường bị ghi thành defect. Nó là tín hiệu về đào tạo hoặc về thiết kế chưa rõ, và cần được ghi riêng để xử lý ở GĐ5.

D3. Sau UAT

Tổng hợp: số kịch bản pass/fail · defect theo mức · CR phát sinh · quyết định go/no-go.

Defect được "chấp nhận tạm" phải có ticket theo dõi và hạn xử lý. Không có ticket thì nó biến mất, và quay lại sau sáu tháng dưới dạng khiếu nại của người dùng.

Trước khi kết thúc

Tuỳ phần đã chạy, in tương ứng:

Mọi lần chạy: danh sách tài liệu đã sửa kèm version mới, và ai cần được báo.

Phần A: bảng QLOG — câu hỏi mở, quá hạn (>2 ngày) đánh dấu 🔴.

Phần B: bảng CR — trạng thái, tác động, ai đang chờ quyết. CR chờ >5 ngày ⇒ 🔴.

Phần C: bảng phủ AC → test case, ô trống đánh dấu 🔴.

Phần D: bảng tự chấm Gate G4 dạng ☐/✅ + kết luận go/no-go.

Bẫy thường gặp

Trả lời dev qua chat rồi thôi. Câu trả lời không vào tài liệu là câu trả lời sẽ mất. Ba tháng sau không ai biết vì sao hệ thống hành xử như vậy — kể cả bạn.

Nhận CR "nhỏ" không qua quy trình. Không có CR nhỏ, chỉ có CR chưa được đánh giá tác động. Ghi nhận mất 5 phút, bỏ qua tốn hơn nhiều.

Tự quyết CR vì "rõ ràng là nên làm". Vi phạm nguyên tắc 2. Kể cả khi bạn đúng, PO vẫn phải biết vì họ chịu trách nhiệm về scope và chi phí.

Sửa spec mà không báo ai. Dev đang code theo bản cũ. Sửa âm thầm còn tệ hơn không sửa.

Cứu người dùng quá sớm trong UAT. Chỗ họ loay hoay là dữ liệu quan trọng nhất của buổi UAT. Ghi lại trước, hướng dẫn sau.

UAT với dữ liệu quá sạch. Dữ liệu thật có bản ghi thiếu trường, trùng, sai định dạng, tạo từ năm ngoái. Không đưa những thứ đó vào UAT thì UAT không chứng minh được gì.

Coi "không ai phản đối" là nghiệm thu. Nghiệm thu phải có chữ ký và tiêu chí đã thoả thuận trước.