Hỏi đáp công nghệ

User story là gì? Ví dụ và template về User story

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn

Table of Contents

Thành phần quan trọng của mô hình phát triển phần mềm agile là đặt con người lên hàng đầu, và user story đặt người dùng cuối vào trung tâm của cuộc trò chuyện. Những câu chuyện này sử dụng ngôn ngữ phi kỹ thuật để cung cấp bối cảnh cho nhóm phát triển và nỗ lực của họ. Sau khi đọc câu chuyện của người dùng, nhóm sẽ biết những gì họ đang xây dựng, tại sao phải xây dựng nó và giá trị mà nó tạo ra.

user story là gì
User story là gì?

User story là một trong những thành phần cốt lõi của một chương trình agile. Chúng giúp cung cấp một framework tập trung vào người dùng cho công việc hàng ngày – điều này thúc đẩy sự hợp tác, sáng tạo và tổng thể là một sản phẩm tốt hơn.

Vậy cụ thể User story là gì?

User story là gì trong Agile?

User story là đơn vị công việc nhỏ nhất trong một Agile framework. Đó là mục tiêu cuối cùng, không phải là một tính năng, được thể hiện từ quan điểm của người dùng phần mềm.

User story là nhưng mô tả chung chung, không chính thức về một tính năng phần mềm được viết từ quan điểm của người dùng cuối hoặc khách hàng. 

Mục đích của user story là để nói rõ cách một phần công việc sẽ mang lại một giá trị cụ thể cho khách hàng. Lưu ý rằng “khách hàng” không nhất thiết phải là người dùng cuối bên ngoài theo nghĩa truyền thống, họ cũng có thể là khách hàng nội bộ hoặc đồng nghiệp trong tổ chức, những người liên quan với nhóm của bạn.

User story là một vài câu bằng ngôn ngữ đơn giản phác thảo các kết quả mong muốn. Chúng không đi vào chi tiết. Các yêu cầu sẽ được bổ sung sau đó, sau khi có được sự đồng ý của nhóm.

Các story nằm gọn trong các Agile framework như scrum và kanban. Trong scrum, user story được thêm vào sprint và “bị đốt cháy” trong suốt sprint đó. Các nhóm Kanban kéo các user story vào backlog các công việc tồn đọng và chạy chúng trong suốt quy trình làm việc của họ. Công việc dựa trên user story này giúp nhóm scrum tiến bộ hơn trong việc ước tính và lập kế hoạch cho sprint, giúp dự đoán chính xác hơn và nhanh nhẹn hơn. Nhờ các story, các nhóm kanban học cách quản lý công việc đang tiến hành (work-in-progress – WIP) và có thể tinh chỉnh thêm quy trình làm việc của họ.

User story cũng là nền tảng xây dựng nên các Agile framework lớn hơn như epic và initiative. Epic là các hạng mục công việc lớn được chia nhỏ thành một tập hợp các story và nhiều epic tạo thành một initiative. Những cấu trúc lớn hơn này đảm bảo rằng công việc hàng ngày của nhóm phát triển sẽ đóng góp vào các mục tiêu của tổ chức được xây dựng trong các epic và initiative.

user story là gì
User story là gì? Mối quan hệ giữa story, epic và initiative

Tại sao phải tạo user story?

Đối với các nhóm phát triển mới làm quen với Agile, user story đôi khi đóng vai trò là một bước bổ sung. Tại sao không chỉ chia nhỏ dự án lớn (epic) thành một loạt các bước và tiếp tục làm việc với các bước đó?

Câu trả lời là, những story mang lại cho team một cái nhìn chung về bối cảnh quan trọng và liên kết các công việc với giá trị mà các cong việc đó mang lại.

User story phục vụ một số lợi ích chính:

  • Các story luôn tập trung vào người dùng. Danh sách việc cần làm giúp nhóm tập trung vào các nhiệm vụ cần hoàn thành, nhưng một bộ sưu tập các story giúp nhóm tập trung vào việc giải quyết các vấn đề cho người dùng thực.
  • Story nâng cao khả năng hợp tác. Với mục tiêu cuối cùng được xác định, nhóm có thể làm việc cùng nhau để quyết định cách tốt nhất để phục vụ người dùng và đáp ứng mục tiêu đó.
  • Story thúc đẩy các giải pháp sáng tạo. Các story khuyến khích nhóm suy nghĩ chín chắn và sáng tạo về cách giải quyết tốt nhất cho mục tiêu cuối cùng.
  • Story tạo ra động lực. Với mỗi story trôi qua, nhóm phát triển tận hưởng một thử thách và một chiến thắng nhỏ, động lực từ đó được thúc đẩy.

Làm việc với user story

Khi một story đã được viết xong, đã đến lúc tích hợp nó vào quy trình làm việc của bạn. Nói chung, một story có thể được viết bởi chủ sở hữu sản phẩm (PO), người quản lý sản phẩm (product manager) hoặc người quản lý chương trình (program manager), sau đó được gửi để xem xét.

Trong một cuộc họp lập kế hoạch sprint hoặc iteration, nhóm sẽ quyết định những story mà họ sẽ giải quyết trong spint đó. Giờ đây, các nhóm thảo luận về các yêu cầu và chức năng mà mỗi user story yêu cầu. Đây là cơ hội để có được những giải pháp kỹ thuật và sự sáng tạo trong quá trình thực hiện story của nhóm. Sau khi đồng ý, những yêu cầu này sẽ được thêm vào story.

Một bước phổ biến khác trong cuộc họp này là đánh giá các story dựa trên mức độ phức tạp hoặc thời gian hoàn thành của chúng. Các đội sử dụng phương pháp T-Shirt Sizing, dãy Fibonacci hoặc planning poker để đưa ra ước tính phù hợp. Một story phải có kích thước đủ nhỏ để hoàn thành trong một sprint, bởi vậy nhóm nghiên cứu thông số kỹ thuật cho mỗi story phải đảm bảo chia nhỏ các story quá lớn thành các story với thời gian hoàn thành phù hợp.

Xem thêm >> SOA là gì? Tìm hiểu chung về kiến trúc hướng dịch vụ

Vòng đời của một câu chuyện người dùng

Theo nghĩa rộng, có sáu trạng thái chính cho mỗi user story trong suốt một dự án phần mềm:

Pending

Thông qua giao tiếp giữa người dùng và nhóm dự án, các user story được tìm ra. Ở trạng thái này, user story không có gì khác hơn là một mô tả ngắn về nhu cầu của người dùng. Không có thảo luận chi tiết về các yêu cầu, không có logic hệ thống và chưa có thiết kế màn hình. Trên thực tế, mục đích duy nhất của user story hiện tại chỉ là để note lại yêu cầu của người dùng được viết trong user story này. Có thể nó sẽ bị loại bỏ trong tương lai.

To-do

Thông qua cuộc thảo luận giữa các bên liên quan khác nhau, user story cần được giải quyết trong vài tuần tới sẽ được quyết định và được đưa vào một sprint. Những story như vậy được đặt ở trạng thái to-do. Không có cuộc thảo luận chi tiết nào đã được thực hiện trong trạng thái này.

Thảo luận

Khi user story ở trạng thái thảo luận, người dùng cuối sẽ giao tiếp với nhóm phát triển để xác nhận các yêu cầu cũng như xác định các tiêu chí chấp nhận. Nhóm phát triển sẽ viết ra các yêu cầu hoặc bất kỳ quyết định nào dưới dạng ghi chú hội thoại. Chuyên gia UX có thể tạo wireframe hoặc storyboard để cho phép người dùng xem trước các tính năng được đề xuất trong mô hình trực quan và cảm nhận nó. Quá trình này được gọi là thiết kế trải nghiệm người dùng (thiết kế UX).

Phát triển

Sau khi các yêu cầu được làm rõ, nhóm phát triển sẽ thiết kế và triển khai các tính năng để đáp ứng yêu cầu của người dùng.

Xác nhận

Sau khi nhóm phát triển đã triển khai user story, những story đso sẽ được xác nhận bởi người dùng cuối. Họ sẽ được cấp quyền truy cập vào môi trường thử nghiệm hoặc sản phẩm phần mềm bán hoàn chỉnh (đôi khi được gọi là phiên bản alpha) để xác nhận tính năng. Xác nhận sẽ được thực hiện dựa trên các item xác nhận được viết khi trình bày chi tiết user story. Cho đến khi quá trình xác nhận được thực hiện, user story được cho là ở trạng thái Đang xác nhận.

Hoàn thành

Cuối cùng, tính năng được xác nhận là xong, lúc này user story được coi là ở trạng thái Đã hoàn tất. Thông thường, đây là phần cuối của user story. Nếu người dùng có yêu cầu mới, đó là về một tính năng mới hoặc đó là sự nâng cao của story đã hoàn thành, nhóm sẽ tạo một user story cho lần lặp tiếp theo.

Cách viết user story

User story là gì
User story là gì? Cách viết user story

Hãy cân nhắc những điều dưới đây khi viết câu chuyện của người dùng:

  • Định nghĩa “hoàn thành” – Story nói chung được gọi là “Done” khi người dùng có thể hoàn thành nhiệm vụ đã vạch ra, nhưng hãy đảm bảo xác định nhiệm vụ đó là gì.
  • Vạch ra các task hoặc subtask – Quyết định các bước cụ thể nào cần được hoàn thành và ai là người chịu trách nhiệm cho từng bước đó.
  • Tính cách người dùng – Dành cho ai? Nếu có nhiều người dùng cuối, hãy cân nhắc tạo nhiều story.
  • Các bước có thứ tự – Viết một story cho mỗi bước trong một quy trình lớn hơn.
  • Lắng nghe phản hồi – Giao tiếp với người dùng của bạn và nắm bắt vấn đề hoặc nhu cầu bằng lời nói của họ. Không cần phải suy đoán story khi bạn có thể lấy chúng trực tiếp từ khách hàng của mình.
  • Thời gian – Thời gian là một chủ đề nhạy cảm. Nhiều nhóm phát triển tránh hoàn toàn các cuộc thảo luận về thời gian, thay vào đó dựa vào các framwork ước tính của họ. Vì các story nên được hoàn thành trong một sprint, nên các story quá lớn, có thể mất vài tuần hoặc vài tháng để hoàn thành, nên được chia thành những story nhỏ hơn hoặc nên được tạo một Epic của riêng chúng.

Sau khi các user story được xác định rõ ràng, hãy đảm bảo rằng chúng được hiển thị công khai cho toàn bộ nhóm.

Template và ví dụ về user story

User story thường được diễn đạt bằng một câu đơn giản, có cấu trúc như sau:

“Là một [đối tượng], tôi [muốn], [để].”

Chia nhỏ điều này để phân tích:

  • “Là một [đối tượng]”: Chúng ta đang xây dựng cái này cho ai? Chúng ta không chỉ theo đuổi một chức danh, chúng ta đang theo đuổi tính cách của con người. Ví dụ, bạn có một “đối tượng” tên Điệp. Nhóm của bạn nên có những hiểu biết chung về Điệp là ai. Các bạn có thể thực hiện nhiều cuộc phỏng vấn với Điệp để hiểu cách làm việc của người đó, cách họ nghĩ và cảm nhận của họ. Qua đó, các bạn sẽ có sự đồng cảm với Điệp.
  • “Muốn”: Ở đây chúng tôi đang mô tả ý định của họ – không phải các tính năng mà họ sử dụng. Họ thực sự đang cố gắng đạt được điều gì? Tuyên bố này phải được triển khai miễn phí – nếu bạn đang mô tả bất kỳ phần nào của giao diện người dùng chứ không phải mục tiêu của họ thì bạn đang thiếu điểm.
  • “Để”: làm thế nào để mong muốn trước mắt của họ tương thích với bức tranh tổng thể? Lợi ích tổng thể mà họ đang cố gắng đạt được là gì? Vấn đề lớn cần giải quyết là gì?

Ví dụ: câu chuyện của người dùng có thể tương tự như sau:

  • Với tư cách là Điệp, tôi muốn mời bạn bè của mình để chúng ta có thể tận hưởng dịch vụ này cùng nhau.
  • Với tư cách là Sascha, tôi muốn sắp xếp công việc của mình để tôi có thể cảm thấy kiểm soát thời gian được nhiều hơn.
  • Là một người quản lý, tôi muốn có thể nắm bắt được tiến độ làm việc của đồng nghiệp, để tôi có thể báo cáo tốt hơn về thành công và thất bại của chúng tôi.

Cấu trúc này không bắt buộc, nhưng nó rất hữu ích cho việc xác định thế nào là “done”. Khi một đối tượng có thể nắm bắt được giá trị mong muốn của họ, thì câu chuyện đã hoàn tất. Chúng tôi khuyến khích các nhóm xác định cấu trúc của riêng họ và sau đó gắn bó với nó.

Xem thêm >> Endpoint là gì? Tại sao endpoint security lại quan trọng đến thế?

Lời cuối

User story mô tả lý do tại sao và ý nghĩa đằng sau công việc hàng ngày của các thành viên trong nhóm phát triển, thường được thể hiện dưới dạng cá tính + nhu cầu + mục đích . Hiểu được vai trò của chúng không chỉ là nguồn chân lý cho những gì nhóm của bạn đang cung cấp, mà còn là lý do tại sao, là chìa khóa cho một quá trình suôn sẻ.

Hãy bắt đầu vận dụng user story bằng cách đánh giá dự án lớn tiếp theo, hoặc dự án cấp bách nhất (ví dụ: Epic). Chia nhỏ nó thành các story nhỏ hơn và làm việc với nhóm phát triển để cải tiến. Sau khi story của bạn được công bố rộng rãi nơi cả nhóm có thể nhìn thấy chúng, bạn đã sẵn sàng bắt tay vào công việc.

Vậy là trong bài viết trên, Hỏi đáp Công nghệ đã trả lời rất chi tiết câu hỏi User story là gì, cách làm việc với story cũng như những ví dụ dễ hiểu về nó. Nếu các bạn có bất cứ thắc mắc gì, hãy để lại comment bên dưới nhé!

Các bài viết liên quan

1 thought on “User story là gì? Ví dụ và template về User story”

  1. Pingback: Mô hình Agile là gì? Chi tiết ưu và nhược điểm của Agile

Leave a Comment

Email của bạn sẽ không được hiển thị công khai.

Bài viết liên quan