Nói ngắn gọn User story là một bản tóm tắt nhu cầu người dùng.

Thông thường, US do khách hàng, hoặc đại diện của khách hàng, người thực sự hiểu nghiệp vụ và nắm bắt được chính xác yêu cầu của mình đối với nhóm phát triển.

Với những nhóm dùng bảng vật lý thì US được viết trên các thẻ nhỏ hoặc trên các miếng giấy dán. Nhóm có thể dán các thẻ này lên bảng như những hạng mục của Product Backlog.

Cấu trúc của một User Story (US):
Là <người dùng cụ thể \ vai trò> , tôi muốn <làm gì đó> để <phục vụ mục đích nào đó>.

Ví dụ 1: Là người chơi tham gia thi cử trong game Chắn Sân Đình, tôi muốn thay đổi cước địa ù để giống với ngoài đời.

--> Trong ví dụ này, người chăm sóc khách hàng sẽ đại diện cho khách hàng đã truyền tải thông tin đến đội phát triển điều họ muốn: thay đổi cước địa ù nhằm mục đích khiến cho game giống ngoài đời thật.
Tuy nhiên nếu hiểu rộng hơn thì khách hàng không chỉ là khách hàng sử dụng sản phẩm của mình, khách hàng ở đây có thể là những bộ phận khác của công ty yêu cầu 1 tính năng thực hiện công việc cho mình.
Ví dụ 2: Là một người chăm sóc khách hàng, tôi muốn có được tool đo lường chỉ số vương gia phục vụ mục đích chăm sóc khách hàng VIP.

--> Trong ví dụ này, US cho thấy rất rõ ràng tính năng cần phát triển là có được tool đo lường chỉ số của vương gia. Người yêu cầu tính năng này chính là thành viên của đội chăm sóc khách hàng và phục vụ mục đích từ chỉ số có được sẽ có chính sách chăm sóc khách hàng VIP. Với cách viết đơn giản mà đầy đủ như vậy, thành viên nhóm phát triển dễ dàng nắm bắt được yêu cầu của “khách hàng”, nghiệp vụ cũng như mục đích của việc làm ra chức năng nào đó, tức giá trị đích thực của tính năng cần làm. Hơn thế, cách viết đơn giản trên một tấm thẻ nhỏ dễ dàng truyền tay để đọc, sẽ giúp nhóm nhanh chóng đi đến thống nhất cách hiểu với khách hàng, tạo điều kiện để phát triển đúng cái khách hàng mong muốn.

Không chỉ phục vụ cho việc thể hiện chính xác nhu cầu của người dùng, US còn là công cụ để triển khai việc kiểm thử chấp nhận (acceptance test). Khi đó, US có thể thêm điều kiện kiểm thử chấp nhận.

Ví dụ 3: Là một người chắm sóc khách hàng, tôi muốn có được tool đo lường chỉ số vương gia phục vụ mục đích chăm sóc khách hàng VIP. Tool này giúp tôi đo được số người chơi trên vương gia, thời gian chơi của họ, đã bao lâu rồi họ không còn chơi nữa.

Với cách viết như thế này, khách hàng hoặc bất cứ thành viên nào của nhóm phát triển có thể kiểm tra được tool này có thỏa mãn được yêu cầu của khách hàng hay không? Tuy nhiên cách này cũng có điểm hạn chế là khiến cho US dài dòng. Vậy nếu không áp dụng cách viết này thì ta có thể mô tả những yêu cầu này ngay mặt sau của tấm thẻ để viết yêu cầu nghiệp vụ hay điều kiện kiểm thử.

Khi viết một US thì như thế nào là hoàn thành và US mang lại lợi ích gì?

* Khi viết US cần phải mô tả đặc điểm mấu chốt của tính năng, phải khi nào đảm bảo được các điểm này được thỏa mãn thì US mới được gọi là hoàn thành.

* US giúp team hiểu được lợi ích của tính năng mà mình, khi triển khai và thực hiện xong sẽ đem lại cho người dùng cuối cùng, thay vì làm thế nào để làm ra nó. Và đây cũng là tiền đề mấu chốt để bạn đưa ra bàn luận: “có nên làm tính năng này hay không?” hay “Nên làm tính năng này như thế nào?” sau này.


Kết luận:

Để hiểu sâu về US phải dành nhiều thời gian nghiên cứu nó, thực tế mỗi sản phẩm sẽ khác nhau đặc biệt như những game Sân Đình. Chúng ta phải dành nhiều thời gian tìm hiểu sản phẩm mới có thể có kinh nghiệm và kiến thức về nó.

Nên tham gia vào các cuộc họp trước khi lên kế hoạch 1 cách tích cực, thường xuyên tham gia những buổi training công ty, nói chuyện với những người giỏi về vấn đề này, hơn hết là phải tự nghiên cứu. Nếu nỗ lực càng nhiều, kiến thức nhận được càng nhiều và càng phát triển bản thân.

Dù bất cứ ai trong team thì điều quan trọng là phải hướng về US. Chỉ khi đó thì sự thành công đối với khách hàng mới có thể đạt được.

Tác giả: Ngô Như Ân