Đối với BA, sau khi lấy được requirement từ stakeholder, việc quan trọng tiếp theo chính là ghi nhận các requirement đó thành 1 tài liệu để giao tiếp với stakeholder và team development.

Có nhiều cách thức để làm việc đó và trong bài viết này tôi sẽ nói về User story 1 trong những cách thức được ưa chuộng nhất đối với các dự án Agile ngày nay.

User story là gì?

Đó không phải là 1 tính năng, user story là 1 đơn vị nhỏ nhất của nhu cầu được nêu ra với góc nhìn của người dùng. Diễn đạt 1 cách đơn giản kết quả đầu ra mà 1 người dùng cụ thể mong muốn để thỏa mãn 1 nhu cầu nào đó.

User story không xoay quanh 1 tính năng, 1 giao diện hay 1 luồng business. Để thỏa mãn 1 User story có thể cần sự kết hợp của nhiều tính năng, nhiều màn hình, nhưng cũng có thể chỉ là 1 phần nhỏ được tách ra từ 1 luồng chính.

Cốt lõi của user story chính là việc đặt người dùng làm trung tâm của mọi thứ. Người dùng cần gì từ hệ thống chứ không phải là hệ thống có thể cung cấp được gì cho người dùng. Đó cũng chính là thứ mà các nguyên tắc Agile luôn hướng tới – User first

1 tập hợp gồm nhiều user story được gọi là epic. Thật ra một epic cũng có thể xem như là 1 user story, nhưng khác biệt ở chỗ mức độ bao quát của epic cao hơn và phức tạp hơn, cho nên cần phải break down ra thành những user story nhỏ để dễ dàng thực hiện.

Một todo list (danh sách task) có thể giữ cho team tập trung vào các đầu việc cần phải hoàn thành, còn 1 bộ user story sẽ định hướng team tập trung giải quyết các vấn đề của người dùng thực tế. Sau khi hoàn thành 1 user story, đó chính là thỏa mãn 1 nhu cầu của user, chứ không phải là ghép thêm 1 mảnh ghép để tạo thành hệ thống.

Cấu trúc của 1 user story

1 user story gồm 2 phần chính

• Mở bài: Tóm tắt user story
• Thân bài: Chi tiết user story

Mở bài

Phần mở bài của user story thường được phát biểu dưới dạng một câu ngắn gọn theo cú pháp dưới đây:

Là <loại user>, tôi muốn <nhu cầu>, để <lý do>.

Ví dụ:

• Là thủ quỹ, tôi muốn ghi lại 1 khoản chi tiêu trong nhóm để có thể tính toán thu chi sau này.
• Là trưởng nhóm, tôi muốn xem báo cáo chi tiêu của nhóm trong 1 tuần vừa qua.

Chỉ bằng 1 câu ngắn gọn, đã có thể dễ dàng hình dung được nhu cầu này một cách rõ ràng:

• Loại user: Ai? Chúng ta giải quyết vấn đề này cho ai? Cần phải đặt bản thân vào vị trí của người này, người này là ai và họ có vai trò gì. BA cần đồng cảm sâu sắc cách họ nghĩ và cách họ cảm nhận, từ đó hiểu rõ ngữ cảnh của yêu cầu.
• Nhu cầu: Làm gì? Mô tả cái mà user kỳ vọng, kết quả cuối cùng mà user muốn đạt được.
• Lý do: Tại sao? Nhìn thấy rõ đâu business problem nào sẽ giải quyết được sau khi hoàn thành story này. Kỳ vọng này của user có khớp với bức tranh toàn cảnh dự án hay không?

Thân bài

Phần thân bài của user story được gọi là Acceptance Criteria – những điều kiện để được gọi là hoàn thành.

Một user story hoàn thành nghĩa là output phải đáp ứng đủ các điều kiện mà acceptance criteria đề ra.

Ví dụ:

Là người tìm việc, tôi muốn lọc danh sách công việc trong một khu vực nhất định.

Thì acceptance criteria cho user story này có thể là:

• Hệ thống hiển thị danh sách các khu vực gồm: Hồ Chí Minh, Hà Nội, Khác.
• User chỉ được chọn 1 khu vực để lọc
• Hệ thống trả ra danh sách công việc còn hiệu lực thuộc khu vực user đã chọn
• Hệ thống phân trang các kết quả trả ra, 10 kết quả/trang
• …

Việc liệt kê ra các acceptance criteria là cơ sở để triển khai xây dựng các tính năng và phục vụ việc test sau này. Việc định nghĩa kết quả càng rõ thì sẽ càng dễ dàng trong quá trình phát triển sau này. Hãy nhớ viết các acceptance criteria một cách rõ ràng mạch lạc.

Bạn có thể thấy, acceptance criteria chính là những rule, logic để hoàn thiện hơn cho user story đơn giản được mô tả ở mở bài. Đây chính là 1 input quan trọng để team phát triển và testing

Bên cạnh acceptance criteria, đôi lúc những user story phức tạp đòi hỏi phải có sự hỗ trợ của sơ đồ workflow, mockup để dễ hình dung được hơn cách mà user và hệ thống tương tác với nhau để cho ra output như mong muốn.

Nếu user story quá lớn và phức tạp để có thể xong trong 1 sprint, hãy cân nhắc chia ra thành nhiều user story nhỏ hơn với những output cụ thể hơn:

1 user story tốt cần:

• Bám sát nhu cầu thực tế của user
• Định nghĩa được rõ ràng kết quả muốn đạt được.
• Dễ dàng có thể test được
• Dễ dàng để ước lượng thời gian thực hiện

Lưu ý

User story là một công cụ hữu hiệu để có thể đào sâu vào chi tiết của các tính năng. Việc viết user story cho thật tốt sẽ mất rất nhiều thời gian và nỗ lực. Đôi khi, quá tập trung vào chi tiết cũng có thể khiến bạn mất đi cái nhìn toàn cảnh của dự án. Cho nên, hãy cân bằng giữa tư duy chi tiết và tư duy tổng quát. Nhìn rộng hơn để thấy được bức tranh lớn hơn. Từ đó biết được đâu là chỗ cần đầu tư nhiều thời gian và sáng tạo.