Kiểm tra: Ma trận CRUD cho mọi đối tượng

Vì sao chủ đề quan trọng

User story được viết theo hành trình của người dùng, nên nó mạnh ở phần người dùng làm gì nhưng yếu ở phần dữ liệu sống ra sao. Story map của Căng tin số rất có thể có "Sinh viên xem thực đơn hôm nay" và "Sinh viên đặt cơm trước". Nhưng ai tạo ra thực đơn đó? Ai sửa khi một món hết lúc 12:30? Một đơn đặt trước bị bỏ quên thì ai dọn nó?

Ma trận CRUD trả lời những câu đó một cách cơ học. CRUD là viết tắt của bốn thao tác cơ bản trên dữ liệu: tạo (Create), đọc (Read), sửa (Update), xoá (Delete). Với nghiệp vụ, "xoá" thường nên hiểu là lưu trữ hoặc huỷ, vì tiền và đơn hàng gần như không bao giờ bị xoá thật.

Bài này nhận vào danh sách đối tượng cốt lõi và vòng đời của chúng (khóa Hiểu nghiệp vụ trước khi xây), cộng với backlog từ khóa Từ journey tới user story. Đầu ra là trang CRUD trong tệp kiểm tra, mỗi ô có một người làm hoặc một câu hỏi mở.

Bức tranh lớn

Quy trình rất đơn giản, và sức mạnh nằm ở chỗ nó không cho bạn bỏ qua ô nào:

flowchart TD
    A[Liệt kê bảy đối tượng cốt lõi] --> B[Kẻ bốn cột Tạo Đọc Sửa Xoá]
    B --> C[Điền vai trò làm thao tác đó]
    C --> D{Ô có story tương ứng?}
    D -->|Có| E[Ghi mã story vào ô]
    D -->|Không| F[Ghi câu hỏi mở và người cần hỏi]
    F --> G[Đưa câu hỏi vào buổi gặp stakeholder]
    E --> H[Sang ô tiếp theo]
    G --> H

Quy tắc vàng của bài: mọi ô trống là một câu hỏi. Ô trống không có nghĩa "không cần", mà có nghĩa "chưa ai nghĩ tới". Có thể câu trả lời đúng là "không ai được xoá", nhưng câu trả lời đó phải là một quyết định được ghi lại, không phải một sự im lặng.

Bảy đối tượng của Căng tin số là: Thực đơn ngày, Món, Đơn đặt trước, Khung giờ nhận, Thanh toán, Phiếu suất hỗ trợ, Phản hồi. Ba đối tượng đầu tiên cần làm kỹ nhất là Thực đơn ngày, Đơn đặt trước và Phiếu suất hỗ trợ, vì chúng gắn với tiền, với quy tắc và với nhóm sinh viên dễ tổn thương.

Ví dụ chi tiết

Dưới đây là ma trận đầy đủ cho ba đối tượng. Cột "Câu hỏi mở" là sản phẩm thật của bài, không phải phần phụ.

Từ ba đối tượng, ma trận sinh ra mười hai câu hỏi. Trong đó có ít nhất năm câu là tính năng hoàn toàn vắng mặt trong backlog điển hình: đánh dấu hết món, sửa đơn, đặt suất nhóm, cấp và thu hồi phiếu hỗ trợ, màn hình cho bếp.

Bốn đối tượng còn lại làm nhanh hơn, nhưng vẫn sinh ra câu hỏi đáng giá:

Món: ai tạo món mới và ghi thành phần dị ứng theo P3? ai sửa món đã hết? ai ngừng bán một món?
Khung giờ nhận: ai đặt số suất tối đa mỗi khung? sửa khung khi lớp tan muộn được không?
Thanh toán: ai sửa giao dịch chuyển khoản treo? ai xem báo cáo đối soát theo P7?
Phản hồi: sinh viên gửi, căng tin đọc theo P9; ai trả lời? ai xoá phản hồi xúc phạm?

Câu "ai sửa món đã hết" nghe giống câu về Thực đơn ngày, nhưng thật ra là hai việc khác nhau. Món là danh mục lâu dài, ví dụ trứng chiên hay một món mặn quen thuộc. Thực đơn ngày là việc chọn món nào bán hôm nay ở quầy nào. Khi một món mặn hết lúc 12:30, như Quốc Bảo vẫn gặp, cái cần sửa là trạng thái của món trong thực đơn hôm nay, không phải bản thân món. Ma trận giúp bạn tách hai việc này, và tách đúng thì lập trình viên mới thiết kế dữ liệu đúng.

Câu "ai xoá phản hồi" cũng thú vị. Nếu không ai được xoá, một phản hồi xúc phạm nhân viên sẽ nằm mãi. Nếu Anh Tuấn được xoá, căng tin có thể xoá luôn những phàn nàn bất lợi, và Chị Lan, người đang nhận khoảng 25 email phàn nàn mỗi tháng, mất nguồn thông tin. Đây là câu hỏi quyền lực, không phải câu hỏi kỹ thuật, nên phải đưa lên Chị Lan và Anh Tuấn cùng quyết.

Thao tác "Sửa" của Đơn đặt trước nên đọc cùng vòng đời của nó:

stateDiagram-v2
    Moi : Mới đặt
    DaTra : Đã thanh toán
    DangNau : Bếp đang chuẩn bị
    SanSang : Sẵn sàng lấy
    DaNhan : Đã nhận
    QuaHan : Quá hạn, bán cho hàng
    DaHuy : Đã huỷ
    Moi --> DaTra
    DaTra --> DangNau
    DaTra --> DaHuy
    DangNau --> SanSang
    SanSang --> DaNhan
    SanSang --> QuaHan

Đặt ma trận cạnh sơ đồ, bạn thấy ngay: "Sửa" chỉ hợp lý ở trạng thái Mới đặt hoặc Đã thanh toán, trước khi bếp nấu. Từ Bếp đang chuẩn bị trở đi, sửa đơn là sửa một suất cơm đã nằm trong khay.

Lộ trình từng bước

• Mở trang CRUD trong tệp kiểm tra. Mỗi đối tượng là một dòng, hoặc bốn dòng nếu bạn tách theo thao tác như bảng trên.
• Với mỗi ô, điền vai trò thực hiện. Dùng đúng sáu vai trò của case, không viết "người dùng" chung chung.
• Ghi quy tắc hoặc bằng chứng liên quan: mã R, mã P, hoặc câu trích nguyên văn.
• Tra backlog: có story nào phủ ô này không? Có thì ghi mã story. Không thì ô đó thành câu hỏi mở.
• Viết câu hỏi mở thành câu hỏi thật, có tên người cần hỏi. "Ai thu hồi phiếu?" kém hơn "Chị Lan: sinh viên hết học bổng giữa kỳ thì ai báo cho hệ thống?".
• Đối chiếu thao tác Sửa và Xoá với vòng đời: thao tác đó được phép ở trạng thái nào?
• Gom câu hỏi theo người cần hỏi, để mỗi buổi gặp stakeholder giải quyết một loạt.

Thói quen & kỷ luật

Cần luyện tập

Drill một: Làm trọn ma trận CRUD cho đối tượng Khung giờ nhận. Gợi ý: nhớ rằng có lớp tan 11:30 và vào lại 12:45, và quầy cơm bán khoảng 600 suất mỗi trưa. Ai quyết định mỗi khung nhận tối đa bao nhiêu đơn?

Drill hai: Với đối tượng Thanh toán, viết ba câu hỏi mở cho ô Sửa, mỗi câu gắn với một trong P5, P7 và R6.

Drill ba: Lấy một ứng dụng bạn dùng hằng ngày, chẳng hạn ứng dụng đặt đồ ăn. Chọn đối tượng "đánh giá". Ai tạo, ai đọc, ai sửa, ai xoá? Ứng dụng đó trả lời câu "ai xoá đánh giá xấu" như thế nào?

Checklist hành động tuần này

• [ ] Điền đủ ma trận CRUD cho bảy đối tượng
• [ ] Đánh dấu mọi ô "Chưa ai" và viết câu hỏi tương ứng
• [ ] Đối chiếu thao tác Sửa và Xoá của Đơn đặt trước với vòng đời
• [ ] Gom câu hỏi theo Chị Lan, Anh Tuấn, Cô Hạnh
• [ ] Thêm story mới cho những ô đã có câu trả lời rõ

Chỉ số cho cách làm

Các con số dưới đây đo cách nhóm làm bước này, không đo app có thành công hay không. Câu hỏi app có hiệu quả không, và làm gì tiếp, là việc của khóa Đo lường thành công.

Dấu hiệu bạn đã thành thạo

• Bạn phân biệt được Món với Thực đơn ngày, và giải thích vì sao sự phân biệt đó ảnh hưởng tới thiết kế dữ liệu.
• Bạn không bao giờ chấp nhận một đối tượng chỉ có thao tác Tạo và Đọc.
• Bạn nhận ra câu hỏi "ai được xoá" thường là câu hỏi về quyền lực và trách nhiệm.
• Ma trận của bạn khiến stakeholder nói "à, cái này chưa ai nghĩ tới".

Cạm bẫy thường gặp

Chốt lại

Ma trận CRUD buộc bạn nhìn từng đối tượng qua bốn thao tác và hỏi ai làm. Mỗi ô trống là một câu hỏi, không phải một khoảng trống được phép. Với Căng tin số, ba đối tượng đã sinh ra mười hai câu hỏi và ít nhất năm tính năng vắng mặt. Ma trận nhìn theo dữ liệu; bài 3 nhìn theo con người, với ma trận vai trò và hành động.