Tìm hiểu Epic, User Story, mối quan hệ giữa hai loại công việc và cách chúng hỗ trợ quản lý phạm vi sản phẩm.
Nội dung chính
1. Vì sao yêu cầu cần được chia nhỏ?
Trong dự án phần mềm, một nhu cầu lớn thường không thể hoàn thành trong một lần phát triển.
Nhóm Agile cần chia nhu cầu đó thành các phần nhỏ hơn để dễ phân tích, ước lượng, phát triển,
kiểm thử và phát hành.
Hai khái niệm thường được sử dụng để tổ chức yêu cầu là:
- Epic: một mục tiêu hoặc nhóm chức năng lớn.
- User Story: một nhu cầu cụ thể mang lại giá trị cho người dùng.
Việc chia nhỏ đúng giúp nhóm nhìn rõ phạm vi, giảm rủi ro và tạo điều kiện để QA chuẩn bị kiểm thử sớm.
2. Epic là gì?
Epic là một nhóm công việc lớn, thường bao gồm nhiều User Story có liên quan.
Một Epic có thể kéo dài qua nhiều Sprint và không nhất thiết hoàn thành trong một Sprint duy nhất.
Epic thường được dùng để đại diện cho:
- Một chức năng lớn của sản phẩm.
- Một mục tiêu nghiệp vụ quan trọng.
- Một nhóm trải nghiệm hoàn chỉnh của người dùng.
- Một phạm vi cần chia thành nhiều phần nhỏ để triển khai.
Ví dụ trong dự án Credit Card Banking
Một số Epic có thể gồm:
- Quản lý đăng nhập và bảo mật.
- Quản lý tài khoản thẻ tín dụng.
- Thanh toán dư nợ thẻ.
- Quản lý thông tin cá nhân.
- Thông báo và cảnh báo giao dịch.
Epic Thanh toán dư nợ thẻ vẫn còn quá lớn để Developer và QA xử lý trực tiếp.
Epic này cần được chia thành nhiều User Story nhỏ hơn.
3. User Story là gì?
User Story mô tả một nhu cầu cụ thể từ góc nhìn của người sử dụng hoặc một bên liên quan.
Nó tập trung vào giá trị cần đạt được thay vì mô tả chi tiết cách lập trình.
Cấu trúc thường dùng:
Là một [đối tượng người dùng],
tôi muốn [nhu cầu hoặc hành động],
để [giá trị hoặc lợi ích nhận được].
Phiên bản tiếng Anh thường gặp:
As a [user role],
I want [goal],
so that [business value].
Ví dụ
Là một chủ thẻ tín dụng, tôi muốn xem số tiền cần thanh toán,
để tôi có thể thanh toán đúng hạn và tránh phí trễ hạn.
User Story trên đã thể hiện ba thành phần:
- Người dùng: chủ thẻ tín dụng.
- Nhu cầu: xem số tiền cần thanh toán.
- Giá trị: thanh toán đúng hạn và tránh phí trễ hạn.
Epic được chia thành các User Story cụ thể; Acceptance Criteria giúp QA xác định điều kiện cần kiểm thử cho từng User Story.4. Mối quan hệ giữa Epic và User Story
Một Epic thường chứa nhiều User Story. Các User Story cùng đóng góp vào mục tiêu lớn của Epic.
| Epic |
User Story minh họa |
| Thanh toán dư nợ thẻ |
Xem số tiền cần thanh toán |
| Xem ngày đến hạn |
| Chọn số tiền thanh toán |
| Xác nhận giao dịch thanh toán |
Nhờ cấu trúc này, nhóm có thể triển khai từng User Story theo thứ tự ưu tiên,
thay vì phải chờ hoàn thành toàn bộ Epic.
5. Epic và User Story khác nhau như thế nào?
| Tiêu chí |
Epic |
User Story |
| Phạm vi |
Lớn |
Nhỏ và cụ thể hơn |
| Thời gian thực hiện |
Có thể qua nhiều Sprint |
Thường nên hoàn thành trong một Sprint |
| Mức độ chi tiết |
Tổng quát |
Đủ rõ để phân tích và thực hiện |
| Mục đích |
Nhóm các chức năng liên quan |
Mô tả giá trị cụ thể cho người dùng |
| Kiểm thử |
Định hướng phạm vi lớn |
Là đơn vị QA thường phân tích trực tiếp |
6. Một User Story tốt cần có gì?
Cấu trúc câu chỉ là điểm bắt đầu. Một User Story tốt còn phải đủ rõ để nhóm có thể thảo luận,
ước lượng, phát triển và kiểm thử.
Có thể tham khảo nguyên tắc INVEST:
- Independent: hạn chế phụ thuộc không cần thiết.
- Negotiable: có thể trao đổi và làm rõ.
- Valuable: mang lại giá trị.
- Estimable: có thể ước lượng.
- Small: đủ nhỏ để hoàn thành trong Sprint.
- Testable: có thể kiểm tra được.
Đối với QA, yếu tố Testable đặc biệt quan trọng.
Nếu không thể xác định cách chứng minh User Story đã hoàn thành, yêu cầu vẫn chưa đủ rõ.
7. Acceptance Criteria có vai trò gì?
User Story mô tả nhu cầu và giá trị, còn Acceptance Criteria mô tả các điều kiện cần đáp ứng
để User Story được chấp nhận.
Ví dụ User Story
Là một chủ thẻ, tôi muốn xem số tiền thanh toán tối thiểu,
để tôi biết số tiền ít nhất phải thanh toán trong kỳ.
Acceptance Criteria minh họa
- Hệ thống hiển thị số tiền thanh toán tối thiểu của kỳ hiện tại.
- Số tiền được hiển thị đúng định dạng tiền tệ.
- Thông tin chỉ xuất hiện khi người dùng đăng nhập thành công.
- Nếu chưa có sao kê, hệ thống hiển thị thông báo phù hợp.
- Dữ liệu phải khớp với thông tin trong hệ thống backend.
Acceptance Criteria là căn cứ quan trọng để QA xây dựng Test Scenario và Test Case.
8. Vai trò của QA khi đọc Epic
Khi xem một Epic, QA nên tìm hiểu:
- Mục tiêu nghiệp vụ của Epic là gì?
- Những nhóm người dùng nào bị ảnh hưởng?
- Epic bao gồm những luồng nghiệp vụ chính nào?
- Có phụ thuộc vào hệ thống hoặc Epic khác không?
- Những rủi ro chất lượng lớn nhất là gì?
- Cần kiểm thử tích hợp hoặc end-to-end ở đâu?
Epic giúp QA hình dung bức tranh tổng thể, nhưng chưa đủ chi tiết để viết toàn bộ Test Case.
QA vẫn cần phân tích từng User Story.
9. Vai trò của QA khi đọc User Story
QA nên kiểm tra các nội dung sau:
- Người dùng hoặc vai trò đã được xác định rõ chưa?
- Nhu cầu có cụ thể không?
- Giá trị nghiệp vụ có hợp lý không?
- Acceptance Criteria có đầy đủ không?
- Có trường hợp ngoại lệ hoặc lỗi chưa được đề cập không?
- Có dữ liệu đầu vào và điều kiện tiền đề nào không?
- User Story có phụ thuộc vào chức năng khác không?
- Có thể hoàn thành và kiểm thử trong một Sprint không?
10. Ví dụ phân tích User Story của QA
User Story
Là một khách hàng, tôi muốn đăng nhập vào ứng dụng,
để tôi có thể xem thông tin thẻ tín dụng của mình.
QA có thể đặt thêm các câu hỏi:
- Người dùng đăng nhập bằng email, số điện thoại hay username?
- Mật khẩu có yêu cầu độ dài và ký tự đặc biệt không?
- Sai mật khẩu bao nhiêu lần thì tài khoản bị khóa?
- Tài khoản bị khóa có thể mở lại bằng cách nào?
- Phiên đăng nhập tồn tại trong bao lâu?
- Người dùng có được đăng nhập đồng thời trên nhiều thiết bị không?
- Thông báo lỗi có làm lộ việc tài khoản tồn tại hay không?
- Có xác thực hai bước không?
Những câu hỏi này giúp nhóm bổ sung yêu cầu trước khi Developer bắt đầu làm,
giảm nguy cơ phát hiện thiếu sót quá muộn.
11. Các lỗi thường gặp khi viết User Story
Chỉ mô tả chức năng, không có giá trị
Tạo màn hình xem số dư.
Câu này chưa nói rõ người dùng là ai và tại sao họ cần chức năng đó.
User Story quá lớn
Là khách hàng, tôi muốn quản lý toàn bộ thẻ tín dụng của mình.
Nội dung này có thể bao gồm xem số dư, thanh toán, lịch sử giao dịch, khóa thẻ,
đổi hạn mức và nhiều chức năng khác. Nó nên được xem là Epic hoặc cần tiếp tục chia nhỏ.
Không thể kiểm thử
Hệ thống phải thân thiện và hoạt động tốt.
Các từ như “thân thiện”, “nhanh” hoặc “tốt” cần được chuyển thành tiêu chí có thể đo lường hoặc xác minh.
Viết theo giải pháp kỹ thuật
Tạo stored procedure để lấy dữ liệu giao dịch.
Đây có thể là Technical Task, không phải User Story thể hiện giá trị người dùng.
12. Bài thực hành
Với Epic Quản lý đăng nhập và bảo mật, hãy viết ít nhất năm User Story.
Ví dụ:
- Đăng nhập bằng username và mật khẩu.
- Yêu cầu đặt lại mật khẩu.
- Nhận mã xác thực.
- Khóa tài khoản khi đăng nhập sai nhiều lần.
- Đăng xuất khỏi ứng dụng.
Với mỗi User Story, hãy xác định:
- Đối tượng người dùng.
- Nhu cầu.
- Giá trị nhận được.
- Ít nhất ba Acceptance Criteria.
- Một trường hợp lỗi hoặc ngoại lệ.