init git
This commit is contained in:
Leonard-ThindPad-P50
159
.claude/skills/ba-lifecycle/SKILL.md
Normal file
159
.claude/skills/ba-lifecycle/SKILL.md
Normal file
@@ -0,0 +1,159 @@
|
||||
---
|
||||
name: ba-lifecycle
|
||||
description: Điều phối công việc BA — khai báo project profile (loại sản phẩm × nền cũ/mới × mức nghiêm ngặt), xác định dự án đang ở giai đoạn nào, artifact nào đã có, gate nào đang chặn, và skill nào nên chạy tiếp. Dùng khi người dùng nói "bắt đầu làm BA", "tôi đang ở đâu", "quy trình BA thế nào", "cần làm gì tiếp", "review toàn bộ tài liệu BA", "dự án này thuộc loại nào", hoặc khi họ mô tả một việc BA mà chưa rõ thuộc giai đoạn nào. Cũng dùng để khởi tạo cấu trúc thư mục ba-output và file PROFILE cho một dự án mới.
|
||||
---
|
||||
|
||||
# BA Lifecycle — Router điều phối
|
||||
|
||||
Skill này **không tự viết artifact nghiệp vụ**. Việc của nó: đọc hiện trạng, chấm gate,
|
||||
rồi chỉ đúng skill giai đoạn để chạy. Viết tài liệu là việc của `ba-1..5`.
|
||||
|
||||
## Bốn nguyên tắc bất di bất dịch
|
||||
|
||||
Áp dụng cho skill này và mọi skill `ba-*` khác. Khi một quy tắc chặn bạn, **dừng và hỏi**,
|
||||
đừng lách.
|
||||
|
||||
1. **Không bịa yêu cầu.** Thiếu thông tin ⇒ ghi `OQ-nnn`, không điền giá trị "hợp lý".
|
||||
2. **Không quyết định thay PO.** Ưu tiên/scope/trade-off nghiệp vụ ⇒ trình phương án kèm
|
||||
khuyến nghị, để PO chốt.
|
||||
3. **Mọi phát biểu phải truy vết được** về một `RQ`/`BR`/`DEC`/câu trả lời của stakeholder.
|
||||
Không nguồn ⇒ là giả định ⇒ phải ghi `ASM-nn`.
|
||||
4. **Không ghi đè tài liệu đã qua gate.** Chỉ sửa qua `CR-nnn` kèm Change Log.
|
||||
|
||||
## Bước 0 — Chốt input rồi dừng lại
|
||||
|
||||
**Chưa được ghi file.** Làm năm việc rồi **dừng chờ người dùng trả lời**:
|
||||
|
||||
1. **Project và phạm vi** — tên project, phạm vi đang hỏi (cả module hay một US).
|
||||
2. **Profile** — đọc `00-index/PROFILE_<PROJECT>.md`. Chưa có ⇒ **suy ra ba trục
|
||||
`PRODUCT · LIFECYCLE · RIGOR` từ tài liệu hiện có, nêu rõ là suy đoán kèm lý do**, rồi
|
||||
hỏi xác nhận. Chưa xác nhận thì mọi phép chấm gate ở Bước 2 dùng mặc định `standard` —
|
||||
**nói rõ điều đó**, đừng chấm im lặng.
|
||||
3. **Thư mục output** — xác nhận `ba-output/<PROJECT>/`. Nếu đã tồn tại thư mục BA khác
|
||||
trong repo (`.docs/output/`, `docs/ba/`…), nêu ra và hỏi dùng cái nào. **Không tự tạo
|
||||
cấu trúc song song với cái đã có.**
|
||||
4. **Input đã tìm thấy** — bảng `File | Vai trò | Giai đoạn | Ngày sửa`.
|
||||
5. **Hỏi xác nhận** bốn điểm trên.
|
||||
|
||||
Bỏ qua bước dừng khi lệnh có chữ `go` / `chạy luôn`.
|
||||
|
||||
## Quy tắc bắt buộc đã nạp
|
||||
|
||||
Đọc trước khi làm bất cứ việc gì:
|
||||
|
||||
- `references/domain-profiles.md` — ba trục `PRODUCT × LIFECYCLE × RIGOR` và hệ quả
|
||||
- `references/workflow.md` — định nghĩa 5 gate, tiêu chí pass theo từng mức, người duyệt
|
||||
- `references/artifact-map.md` — artifact nào thuộc giai đoạn nào, tên file, version
|
||||
- `references/writing-rules.md` — 13 quy tắc viết tài liệu BA
|
||||
|
||||
## Thực hiện
|
||||
|
||||
### Bước 1 — Quét hiện trạng
|
||||
|
||||
```bash
|
||||
find ba-output/<PROJECT> -name "*.md" -newermt "1970-01-01" | sort
|
||||
```
|
||||
|
||||
Với mỗi file tìm được, đọc **header** (Version · Date · Status · Author) — không đọc
|
||||
toàn văn ở bước này. Phân loại theo `references/artifact-map.md`.
|
||||
|
||||
Không tìm thấy gì ⇒ project chưa khởi tạo, nhảy tới Bước 4 (khởi tạo).
|
||||
|
||||
### Bước 2 — Chấm từng gate
|
||||
|
||||
Với mỗi gate G1→G5, chấm theo checklist trong `references/workflow.md` §2, **đã điều chỉnh
|
||||
theo `RIGOR`** trong profile: `light` áp checklist trừ bảng "Bớt ở light", `strict` cộng
|
||||
bảng "Thêm ở strict". Ghi mức đang chấm ngay đầu bảng pipeline.
|
||||
|
||||
Chấm **thật**: mở artifact và kiểm tra mục bắt buộc có nội dung hay chỉ là khung rỗng. Một
|
||||
file tồn tại nhưng các mục còn `TBD` ⇒ **chưa đạt**, không được đánh ✅.
|
||||
|
||||
**Tiêu chí phụ thuộc `PRODUCT`**: dòng "bảng field" và "wireframe" của G3 chỉ áp cho
|
||||
`PRODUCT = screen`. Loại khác dùng tiêu chí ghi ở đầu file
|
||||
`ba-3-specification/templates/srs-part2/<loại>.md`.
|
||||
|
||||
Ba trạng thái, không có trạng thái thứ tư:
|
||||
|
||||
| Ký hiệu | Nghĩa |
|
||||
|---|---|
|
||||
| ✅ | Đủ artifact, đủ nội dung, **đã có chữ ký duyệt ghi trong header** |
|
||||
| 🟠 | Có artifact nhưng thiếu nội dung hoặc chưa duyệt — nêu đích danh thiếu gì |
|
||||
| ☐ | Chưa bắt đầu |
|
||||
|
||||
### Bước 3 — Tìm cái đang chặn
|
||||
|
||||
Gate thấp nhất chưa ✅ chính là chỗ đang đứng. Liệt kê:
|
||||
|
||||
- **Blocker cứng** — artifact thiếu, gate chưa duyệt
|
||||
- **Blocker mềm** — `OQ-nnn` chưa trả lời, `CR-nnn` chưa quyết, `RISK-nn` chưa có phương án
|
||||
|
||||
Quét open question tồn đọng trên toàn bộ artifact:
|
||||
|
||||
```bash
|
||||
grep -rn "OQ-[0-9]\|TBD\|TODO\|❓" ba-output/<PROJECT> | head -50
|
||||
```
|
||||
|
||||
`OQ` quá 5 ngày làm việc chưa trả lời ⇒ đánh dấu **quá hạn** và nêu tên người phải trả lời.
|
||||
|
||||
### Bước 4 — Khởi tạo project mới (chỉ khi Bước 1 không thấy gì)
|
||||
|
||||
Tạo cấu trúc rỗng và **hai** file:
|
||||
|
||||
1. `00-index/PROFILE_<PROJECT>.md` — theo mẫu `references/domain-profiles.md` §0, với ba
|
||||
trục đã được người dùng xác nhận ở Bước 0, kèm cột "Hệ quả đã áp dụng".
|
||||
2. `00-index/INDEX_<PROJECT>.md` — theo mẫu `references/artifact-map.md` §4.
|
||||
|
||||
Không tạo file rỗng cho các giai đoạn sau — file rỗng làm hỏng phép chấm gate ở Bước 2.
|
||||
|
||||
```
|
||||
ba-output/<PROJECT>/{00-index,01-discovery,02-analysis,03-specification,04-delivery,05-post-release}
|
||||
```
|
||||
|
||||
### Bước 5 — Báo cáo và chỉ đường
|
||||
|
||||
In đúng bốn phần sau, không thêm:
|
||||
|
||||
**① Bảng pipeline** — mở đầu bằng một dòng profile, để người đọc biết đang chấm theo chuẩn nào:
|
||||
|
||||
```
|
||||
Profile: screen · brownfield · standard (từ PROFILE_<PROJECT>.md)
|
||||
```
|
||||
|
||||
Profile là suy đoán chưa xác nhận ⇒ ghi `(suy đoán — chưa xác nhận)`.
|
||||
|
||||
| Gate | Giai đoạn | Artifact | Trạng thái | Thiếu gì |
|
||||
|---|---|---|---|---|
|
||||
|
||||
**② Đang đứng ở đâu** — một câu. Ví dụ: *"US059 đã qua G2, SRS đang draft v0.3, chặn ở
|
||||
G3 vì thiếu bảng mã lỗi và 3 OQ chưa trả lời."*
|
||||
|
||||
**③ Việc tiếp theo** — tối đa 3 việc, mỗi việc kèm skill để chạy:
|
||||
|
||||
```
|
||||
1. Trả lời OQ-012, OQ-013 (chờ PO) → /ba-4-delivery-support US059
|
||||
2. Bổ sung bảng mã lỗi vào SRS §1.A.4 → /ba-3-specification US059
|
||||
3. Chạy kiểm tra coverage trước khi trình G3 → /ba-traceability US059
|
||||
```
|
||||
|
||||
**④ Cảnh báo** — OQ quá hạn, artifact lệch version, US có trong backlog nhưng chưa có SRS,
|
||||
SRS tham chiếu `BR` không tồn tại, **artifact khai profile khác với `PROFILE_<PROJECT>.md`**.
|
||||
Không có gì thì ghi "Không có".
|
||||
|
||||
🔴 Cảnh báo riêng cần chủ động nêu: project khai `RIGOR = light` nhưng đã có người dùng thật
|
||||
ngoài nhóm làm ⇒ đề xuất **nâng lên `standard` và chạy bù** G1–G3 (`references/workflow.md`
|
||||
§2 — G5). POC mang theo mọi thiếu sót của nó vào sản phẩm thật là chuyện xảy ra thường xuyên.
|
||||
|
||||
## Bẫy thường gặp
|
||||
|
||||
**Đừng suy ra trạng thái từ tên file.** `SRS_US059_v1.0.md` tồn tại không có nghĩa G3 đã
|
||||
qua — phải mở ra xem `Status` trong header và checklist gate.
|
||||
|
||||
**Đừng gộp nhiều project vào một lần chạy.** Mỗi lần chạy đúng một `<PROJECT>`. Người dùng
|
||||
hỏi về nhiều module ⇒ chạy lần lượt, báo cáo riêng.
|
||||
|
||||
**Đừng nhảy cóc gate.** Người dùng đòi viết SRS khi G2 chưa xong ⇒ nói rõ rủi ro (SRS sẽ
|
||||
phải viết lại khi backlog đổi), nêu phần nào của G2 còn thiếu, **rồi vẫn làm nếu họ khẳng
|
||||
định lại** — và ghi ngoại lệ đó vào Open Questions của SRS.
|
||||
|
||||
**Đừng tự sửa artifact.** Thấy lỗi trong SRS ⇒ báo cáo ở phần ④, không sửa. Sửa là việc
|
||||
của skill giai đoạn tương ứng.
|
||||
Reference in New Issue
Block a user