User Story Hay Use Case
Trong xu hướng chuyển dịch mạnh mẽ sang mô hình phát triển phần mềm linh hoạt (Agile/Scrum), khái niệm User Story đã trở nên cực kỳ phổ biến. Tuy nhiên, ở các dự án lớn thuộc lĩnh vực Tài chính, Ngân hàng, Bảo hiểm hay Y tế, Use Case vẫn giữ vị thế không thể thay thế.
Rất nhiều IT BA lúng túng không biết khi nào nên dùng User Story, khi nào nên dùng Use Case và làm thế nào để viết tiêu chí nghiệm thu (Acceptance Criteria) một cách chặt chẽ nhất. Bài viết này sẽ phân tích toàn diện hai kỹ thuật này.
1. Đặt Lên Bàn Cân: User Story Và Use Case
A. User Story (Mô hình Agile / Scrum)
- Bản chất: Là một đoạn mô tả ngắn gọn về tính năng dưới góc nhìn của người dùng cuối. Ý nghĩa cốt lõi của User Story là lời mời gọi cho một cuộc thảo luận (Conversation).
- Cấu trúc chuẩn (Côn thức 3C - Card, Conversation, Confirmation):
- Mẫu câu: As a [Role], I want to [Action], So that [Benefit].
- Ví dụ: As an Online Shopper, I want to filter products by price range, So that I can find items within my budget quickly.
- Ưu điểm: Nhanh, linh hoạt, dễ thay đổi, tập trung vào giá trị mang lại cho người dùng.
B. Use Case (Mô hình Waterfall / Hybrid)
- Bản chất: Là một văn bản mô tả chi tiết toàn bộ chuỗi tương tác từng bước (Step-by-step) giữa Tác viên (Actor) và Hệ thống (System) để đạt được một mục tiêu cụ thể.
- Cấu trúc chuẩn: Actor, Pre-conditions, Post-conditions, Main Flow, Alternate Flows, Exception Flows.
- Ưu điểm: Cực kỳ chi tiết, tính bao quát cao, giảm thiểu tối đa sự hiểu nhầm logic.
2. Kỹ Thuật Viết Tiêu Chí Nghiệm Thu (Acceptance Criteria - AC) Cho User Story
User Story nếu không có Acceptance Criteria (AC) sẽ trở nên vô giá trị vì Developer và Tester không có căn cứ để đánh giá xem tính năng đã hoàn thành (Definition of Done) hay chưa.
Có 2 phương pháp viết AC phổ biến nhất hiện nay:
Phương pháp 1: Scenario-based (Định dạng Given-When-Then / BDD)
- Given: Bối cảnh ban đầu của hệ thống.
- When: Hành động thực hiện của người dùng.
- Then: Kết quả kỳ vọng hệ thống trả về.
- Ví dụ:
- Given người dùng đang ở trang Giỏ hàng và có ít nhất 1 sản phẩm.
- When người dùng nhấp vào nút "Thanh toán".
- Then hệ thống chuyển hướng người dùng sang trang Nhập địa chỉ giao hàng.
Phương pháp 2: Rule-based (Liệt kê danh mục quy tắc)
- Liệt kê dạng danh sách các quy tắc bắt buộc:
- Trường Mật khẩu phải chứa ít nhất 8 ký tự, gồm chữ hoa, chữ thường và số.
- Nếu nhập sai mật khẩu quá 5 lần, tài khoản tự động bị khóa trong 15 phút.
3. Phương Pháp Ánh Xạ Với Ma Trận Truy Xuất Yêu Cầu (Requirements Traceability Matrix - RTM)
Dù sử dụng User Story hay Use Case, IT BA cũng cần xây dựng RTM (Requirements Traceability Matrix) để đảm bảo:
- Mọi yêu cầu kinh doanh ban đầu đều được hiện thực hóa thành tính năng phần mềm.
- Mọi User Story đều có các Test Case tương ứng của bộ phận QA/QC.
- Không có tính năng "thừa" (Gold Plating) được code mà không nằm trong phạm vi dự án.
4. Học Kỹ Thuật Viết Yêu Cầu Thực Chiến Cùng Chuyên Gia
Việc nắm chắc lý thuyết là chưa đủ, bạn cần luyện tập phản xạ phân tích các tình huống nghiệp vụ phức tạp. Tham gia Khóa học Phân tích nghiệp vụ phần mềm sẽ giúp bạn thực hành viết hàng chục User Story, dựng Use Case Specification và thiết lập ma trận RTM bám sát dự án thật.
Kết Luận
Một IT BA giỏi không thần thánh hóa User Story cũng không lạm dụng Use Case. Hãy linh hoạt lựa chọn công cụ phù hợp với quy mô dự án và phương pháp quản trị của doanh nghiệp để mang lại hiệu quả cao nhất.
Tags: #cole #colevn #coleblogvn #UserStory #UseCase
Link:
https://telegra.ph/User-Story-Hay-Use-Case-08-07