Tin tức công nghệ

1. GIỚI THIỆU 

Chương này giúp sinh viên hiểu cách thu thập và mô tả yêu cầu người dùng thông qua User Story, một công cụ quan trọng trong quy trình phát triển phần mềm theo Agile/Scrum. Việc nắm rõ cách viết, phân tích và tổ chức User Story sẽ giúp nhóm phát triển xây dựng Product Backlog chất lượng, rõ ràng và dễ triển khai trong từng Sprint.

2. KHÁI NIỆM USER STORY

User Story là mô tả ngắn gọn về một chức năng dưới góc nhìn của người dùng. Được viết dưới dạng:

Là một [loại người dùng], tôi muốn [chức năng] để [mục tiêu]

Ví dụ: Là một sinh viên, tôi muốn có thể đăng ký môn học trực tuyến để tiết kiệm thời gian.

• Đặc điểm:
  • Ngắn gọn, tập trung vào giá trị người dùng
  • Không mô tả chi tiết kỹ thuật
  • Có thể thay đổi, mở rộng linh hoạt
  • VAI TRÒ CỦA USER STORY TRONG SCRUM
• Là thành phần chính của Product Backlog
• Được sử dụng trong các buổi Sprint Planning để chia thành các task
• Là cơ sở để kiểm thử chấp nhận (Acceptance Test)
  1. CẤU TRÚC CHUẨN CỦA MỘT USER STORY

1. Câu mô tả (User Goal)

Là một… tôi muốn… để…

2. Tiêu chí chấp nhận (Acceptance Criteria)
   • Điều kiện để chức năng được xem là hoàn thành
   • Mỗi User Story nên có từ 2–5 tiêu chí rõ ràng
3. Ước lượng (Estimation)
   • Thường được đánh giá theo điểm (story points)
   • Dùng cho lập kế hoạch Sprint

3. QUY TẮC INVEST CHO USER STORY TỐT

Mỗi User Story nên tuân theo nguyên tắc INVEST:

4. PHÂN TÍCH YÊU CẦU TỪ GÓC NHÌN NGƯỜI DÙNG

Các bước:

1. Xác định vai trò người dùng (persona)
   • Ví dụ: sinh viên, giảng viên, nhân viên thư viện
2. Xác định mục tiêu người dùng
   • Họ cần gì? Vì sao?

2. Viết câu chuyện người dùng
   • Sử dụng mẫu: Là một..., tôi muốn..., để...

3. Phỏng vấn – khảo sát – quan sát
   • Thu thập yêu cầu từ thực tế
   • VÍ DỤ VIẾT USER STORY THEO TỪNG VAI TRÒ

5. VIẾT TIÊU CHÍ CHẤP NHẬN (ACCEPTANCE CRITERIA)

Ví dụ:

User Story:

Là một sinh viên, tôi muốn thay đổi mật khẩu để bảo mật tài khoản.

Tiêu chí chấp nhận:

1. Người dùng có thể nhập mật khẩu cũ và mới.
2. Mật khẩu mới phải dài ít nhất 8 ký tự.
3. Thông báo lỗi nếu mật khẩu cũ sai.
4. Hiển thị thông báo thành công sau khi đổi mật khẩu.
   1. ƯỚC LƯỢNG ĐỘ LỚN USER STORY

Các nhóm thường sử dụng:

• Planning Poker
• Story Point: đo độ phức tạp tương đối (không theo giờ)
• Các giá trị phổ biến: 1, 2, 3, 5, 8, 13, 21 (Fibonacci)

Lưu ý: Không nên chia User Story quá nhỏ ngay từ đầu, chỉ chia khi đưa vào Sprint.

6. SAI LẦM PHỔ BIẾN KHI VIẾT USER STORY

• Viết quá dài, giống mô tả kỹ thuật
• Không nêu rõ mục tiêu người dùng
• Không có tiêu chí chấp nhận
• Viết theo góc nhìn lập trình viên, không phải người dùng
• Gộp quá nhiều chức năng vào 1 story

7. PHÂN BIỆT USER STORY, USE CASE VÀ TASK

8. CÔNG CỤ HỖ TRỢ VIẾT USER STORY

• Trello
• Jira
• Notion
• Google Sheets + Template
• Miro: sơ đồ hóa yêu cầu người dùng

9. HƯỚNG DẪN VIẾT USER STORY THEO NHÓM

1. Lập danh sách các vai trò người dùng
2. Mỗi thành viên viết 2–3 User Story cho từng vai trò
3. Gộp nhóm, loại trùng lặp
4. Đưa vào bảng Product Backlog
5. Bổ sung tiêu chí chấp nhận, ước lượng

10. CÂU HỎI ÔN TẬP

1. Mô tả cấu trúc chuẩn của một User Story.
2. INVEST là gì? Nêu ý nghĩa từng chữ.
3. Phân biệt User Story và Task?
4. Acceptance Criteria dùng để làm gì?
5. Tại sao không nên viết User Story quá kỹ thuật?

11. BÀI TẬP THỰC HÀNH

Bài tập 1: Viết 3 User Story cho hệ thống điểm danh sinh viên bằng mã QR.

Bài tập 2: Phân tích một User Story sai và viết lại theo chuẩn INVEST.

Bài tập 3: Làm việc nhóm: Viết 5 User Story cho đề tài "App hỗ trợ sinh viên thuê trọ".

12. TÀI LIỆU THAM KHẢO

1. User Story Mapping, Jeff Patton
2. The Art of Agile Development, James Shore
3. Scrum Guide, Ken Schwaber & Jeff Sutherland
4. Agile Alliance – www.agilealliance.org