Để tạo ra những user story tốt nhất

User story là gì?

User story là một câu chuyện có người dùng, hành động và kết quả. Nó thường được mô tả theo cấu trúc sau:

Là một [người dùng], Tôi muốn [làm gì đó] để tôi có thể [nhận được một kết quả nào đó]

Trong bài viết này, tôi sẽ sử dụng những ví dụ về một công ty tưởng tượng có tên là Enable Quiz. Công ty này đang xây dựng một ứng dụng giúp cho các quản lý nhân sự tìm kiếm các ứng viên dựa trên những kỹ năng cụ thể tương ứng với một bản mô tả công việc.

Ví dụ cho user story:

Là một quản lý nhân sự, tôi muốn ghép các kỹ năng của một vị trí cần tuyển với những chủ đề quiz, để tôi có thể tạo được các quiz lọc ứng viên

Các story thường được tổ chức theo mô hình top-down (từ trên xuống dưới). Sẽ có một 
epic story mô tả một câu chuyện tổng quát. Epic story này sẽ bao gồm nhiều user story, mỗi user story sẽ thực hiện một chức năng riêng biệt. Mỗi user story sẽ có nhiều test case để kiểm tra chúng

Ví dụ cho epic story:

Là một quản lý nhân sự, tôi muốn tạo ra các quiz để tôi có thể dùng khi phỏng vấn ứng viên

Những thứ cần có để xây dựng user story

Người dùng là ai?

Nếu bạn không xác định rõ người dùng sản phẩm là ai thì sẽ rất khó để xây dựng user story. Và có thể bạn sẽ gặp phải lỗi the twin anti-poles of design failure:


• Nếu bạn làm chính xác những gì người dùng yêu cầu, thì cuối cùng bạn sẽ rơi vào vòng lặp vô tận Product Death Cycle :
  1. hỏi khách hàng chức năng nào đang thiếu
  2. xây dựng những chức năng thiếu
  3. không ai sử dụng sản phẩm của bạn
  4. cuối cùng lại quay trở lại 1
• Nếu bạn cho rằng mình biết rõ người dùng muốn gì, cuối cùng thì cũng không ai sử dụng sản phẩm của bạn

Để tránh lỗi thiết kế the twin anti-poles , hãy đặt mình vào vị trí người sử dụng (persona): đặt một cái tên cụ thể cho người dùng (ví dụ như chị quản lý nhân sự Helen) và đưa ra ý tưởng về mối liên quan giữa cô ấy và phần mềm của bạn:

• Cô ấy nghĩ như thế nào về các mọi thứ vận động hàng ngày?
• Cô ấy muốn trở thành người như thế nào?
• Cô ấy nhìn thấy người khác làm những gì, và điều đó ảnh hưởng đến quan điểm của cô ấy như thế nào?
• Cô ấy cảm nhận như thế nào về công việc của mình?
• Cô ấy thực sự đang làm gì trong lĩnh vực nghiệp vụ mà phần mềm của bạn sẽ đụng chạm tới nó?

Nếu thật sự hiểu người dùng nghĩ - nhìn thấy - cảm nhận - làm những gì, bạn sẽ tìm ra được nhiều user story.

Người dùng muốn gì?

Hãy xây dựng một tình huống để mô tả cái mà người dùng muốn làm. Nó phải tương đối tổng quát để có thể tương đương với nhiều tình huống khác.

Ví dụ

• Tình huống Tìm kiếm các tài năng kỹ thuật tương đương với đọc các CV hay là gọi điện cho các ứng viên. Vì vậy mà tình huống này sẽ xây dựng được những user story tốt
• Tình huống Thuê được những tài năng kỹ thuật thì quá rộng
• Các tình huống chi tiết hơn như Người quản lý nhân sự chuẩn bị một quiz cho một vị trí cần tuyển hoặc Người quản lý nhân sự gửi những ghi chú về các ứng viên cho một nhân viên HR khác thì quá chi tiết

Để thiết kế những user story tốt hơn

User story nên có mức độ chi tiết như thế nào là đủ?

Các user story nên chi tiết, mô tả hành động cụ thể, có thể test được và gắn liền với các tình huống

Ví dụ

• User story Tôi muốn tìm kiếm các ứng viên kỹ thuật để công ty của tôi có thể thu được lợi ích tuyển dụng cao nhất thì quá rộng và không thể test được trực tiếp
• Với tình huống Tìm kiếm các tài năng kỹ thuật thì user story Là một người quản lý nhân sự, tôi muốn tìm kiếm các ứng viên kỹ thuật để tôi có thể biết được những kỹ năng của họ là cụ thể hơn, có thể test được

Để tìm kiếm được hết các user story của một epic story, bạn nên sử dụng các storyboard. Đây là một công cụ bao gồm những hình ảnh với người dùng, hành động và bối cảnh. Nó mô tả epic story theo cách của một câu truyện tranh

Ví dụ với epic story Là một quản lý nhân sự, tôi muốn tạo ra các quiz để tôi có thể dùng khi phỏng vấn ứng viên

Kết quả có những gì?

Kết quả phải có thể test được, và là những gì người dùng muốn nhận được khi họ thực hiện hành động. Ví dụ với user story ở trên Là một người quản lý nhân sự, tôi muốn tìm kiếm các ứng viên kỹ thuật thì kết quả biết được những kỹ năng của các ứng viên có thể test được, nhưng nó không phải là kết quả mong muốn của Helen. Không phải ngẫu nhiên mà Helen tìm kiếm các ứng viên kỹ thuật, mà thường đó là do yêu cầu từ các phòng ban khác. Vì vậy mà kết quả có thể sử dụng thông tin các ứng viên khi phỏng vấn họ mới là cái mà Helen cần.

Test các User Story

Cần phải test những gì?

Việc test các user story không phải là kiểm tra với hành động của người dùng, họ có thu được kết quả đúng như trong user story hay không. Mà việc test các user story là kiểm tra xem họ có muốn thực hiện hành động trong user story hay không?

Vì thế mà bạn nên sử dụng công cụ BJ Fogg’s curve để mô tả nó:

Như vậy để có thể test được thì cần phải

• Đưa ra một sự phân biệt rõ ràng giữa động cơ (motivation) thôi thúc người dùng sử dụng chức năng gắn với user story và tính dễ dùng (usability) của chức năng đó
• Hiểu được mối quan hệ giữa động cơ và tính dễ dùng: nếu người dùng thật sự cần dùng ứng dụng của bạn thì cho dù nó có khó dùng đi nữa họ vẫn sẽ dùng. Còn nếu họ không cần dùng nó (ví dụ như trong trường hợp ứng dụng của bạn có nhiều đối thủ cạnh tranh) thì bạn phải cố gắng làm tăng tính dễ dùng của chức năng để lôi kéo họ

Test như thế nào?

Việc test các story nên được chia thành các giai đoạn (phase), mỗi giai đoạn bao gồm nhiều vòng lặp thiết kế (design)- xây dựng nguyên mẫu (prototype) - kiểm thử (test).

Giai đoạn khám phá (exploratory) có mục đích là tìm ra một hướng tiếp cận phù hợp cho việc test. Giai đoạn đánh giá (assessment) có mục đích là đánh giá chức năng đã hoàn thành chưa. Giai đoạn xác thực (validation) có mục đích là  xác nhận xem chức năng đã sẵn sàng để triển khai cho người dùng hay chưa.

Khi nào story kết thúc?

Để trả lời câu hỏi này, cần phải hiểu rằng bạn không thể dự đoán được cái gì là có giá trị với người dùng. Do đó, bạn cần phải có những ý tưởng mà có thể test được và kiểm chứng nó bằng những thử nghiệm.

Trong trường hợp lý tưởng, story của bạn bắt đầu bằng việc quan sát người dùng và những vấn đề họ gặp phải. Sau đó bạn đưa ra 1 mô hình để đo lường được tính hữu ích của giải pháp của bạn.

Ví dụ điển hình của Lean UX là tạo 1 button giả trên ứng dụng. Khi người dùng click vào button đó, họ sẽ nhận được một thông báo "comming soon". Như vậy bạn có thể đo lường xem có bao nhiêu người dùng click vào button đó. Nếu như có đủ nhiều người muốn dùng chức năng đó thì hãy bắt đầu xây dựng các user story. Sau đó khi bạn release chức năng, bạn sẽ thu được những số đo về động cơ người dùng và tính khả dụng của chức năng. Lúc đó bạn sẽ biết khi nào story sẽ kết thúc (khi mà động cơ người dùng và tính khả dụng của chức năng rơi vào phần trên của BJ Fogg’s curve)

Phát triển ứng dụng với user story và story map

Ai viết các user story?

Vì user story là một khái niệm của Agile, nên người viết các user story tất nhiên sẽ là PO (Product Owner). Nhưng bạn hãy chú ý vài vấn đề sau:

• 1/40: theo một nghiên cứu của Stanford, mọi người chỉ hiểu 1/40 những gì bạn đã nói. Vì vậy nếu như PO đưa user story lên JIRA hay trello và cho rằng mọi thành viên đội phát triển đã hiểu, thì sớm muộn sẽ có hiểu nhầm.
• Chúng ta đo hiệu suất của chính mình theo cách chủ quan: Bản chất của con người chỉ muốn biết đủ mức để giải quyết công việc của họ, và muốn biết rõ mình đã làm được đến đâu. Họ luôn muốn sự chắc chắn và cảm thức lập tức về sự hoàn thành. Nhưng làm phần mềm thì không như thế. Nếu bạn không hợp tác với đội phát triển để xây dựng lên các user story, họ sẽ cảm thấy mình không phải chịu trách nhiệm về nội dung của user story và không cần thiết phải suy nghĩ về tính khả dụng, tính thực tiễn của user story đó. Họ chỉ nghĩ rằng công việc của mình là biến user story đó thành chức năng chạy được.
• Bạn không phải lúc nào cũng nghĩ ra được những ý tưởng tốt nhất. Vì thế mà PO nên tổ chức các buổi thảo luận để xây dựng user story

Sử dụng story trong nội bộ team như thế nào?

Chúng ta nên sử dụng story map, một công cụ giúp kết nối các story trong một epic với nhau và làm cho chúng trở nên trực quan với team phát triển.

Dải đầu tiên (stripe 0) là trục x của story map,  mô tả các hành động của người dùng theo thời gian trong một epic story. Nó nên được mô tả bằng các hình ảnh lấy từ storyboard. Trục y mô tả thứ tự ưu tiên của các user story, như trong hình vẽ thì các user story trong dải 1(stripe 1) có độ ưu tiên thực hiện cao hơn dải 2 (stripe 2).

Sử dụng story hàng ngày như thế nào?

Để user story trở nên thân thiện dễ dùng, thì nó nên tuân theo quy tắc INVEST: Độc lập (Independent), Có thể trao đổi(Negotiable), Hữu ích (Valuable),  Có thể ước lượng (Estimable), Nhỏ (Small), và Có thể kiểm chứng được (Testable).

• Independent: các user story phải độc lập không phụ thuộc vào nhau. mỗi story đều có thể triển khai độc lập.
• Negotiable: user story không phải là các yêu cầu bắt buộc phải tuân theo chính xác, mà nó có thể bị thay đổi cho phù hợp
• Valuable: mỗi user story phải đem lại giá trị gì đó cho người dùng
• Estimable: có thể ước lượng được độ lớn của user story (ví dụ cần bao nhiêu man day hoặc bao nhiêu point)
• Small: user story nên đủ nhỏ để có thể đưa vào hệ thống, và dễ dàng thực hiện kiểm thử tích hợp (incremental integration testing)
• Testable: người viết ra user story nên viết ra các test case cho nó.