Các đặc điểm của một User Story trong Agile Scrum

Ngắn gọn: User Story (US) có thể được định nghĩa là một phương tiện để mô tả yêu cầu sản phẩm (phần mềm) với góc nhìn người dùng.

Sử dụng US là một phương pháp khá phổ biến trong Agile vì qua đó, ta có thể bao quát toàn bộ các chức năng của sản phẩm, đồng thời giúp cho công việc được thực hiện dễ dàng hơn. Nó nằm ở vị trí đầu tiên trong cả quá trình phát triển. Nhiệm vụ của US là phải truyền đạt thông tin về nhu cầu sử dụng tính năng với tư cách người dùng, cụ thể những gì họ muốn và những lý do tương ứng cho những người làm nhiệm vụ lập trình.

Mỗi US tiêu chuẩn cần phải bao gồm đầy đủ các yếu tố liên quan đến vai trò người dùng, nhiệm vụ, và giá trị business mà tính năng mang lại. US được xây dựng với cấu trúc:

As a (Role)

I Want (What)

So That (Why, Benefit)

Hay

Là <người dùng cụ thể/vai trò> ,

tôi muốn <làm gì đó>

để <phục vụ mục đích nào đó>

Role - Chọn một vai trò được thực hiện bởi người có sự tương tác thực đối với hệ thống

  • Càng cụ thể càng tốt
  • Lưu ý rằng team dev không phải là một role

Action - Hành vi/ Phản ứng của hệ thống

  • Thường mang tính đặc trưng đối với mỗi US
  • "Hệ thống" được ngụ ý và không được viết trong US
  • Lưu ý sử dụng dạng câu chủ động

Benefits - Lợi ích nên là một kết quả nhìn thấy được trong đời thường và không có chức năng hoặc nằm bên ngoài hệ thống.

  • Nhiều US có thể cùng mang lại một lợi ích
  • Lợi ích có thể còn là đối với cả những đối tượng khác bên cạnh người được trực tiếp nhắc đến trong US

Vậy làm thế nào để biết thế nào là một User Story phù hợp? Gợi ý các đặc điểm của một User Story kiểu mẫu:
  • Phải đủ hoàn thiện để cho thấy US đang mang lại giá trị cho người sử dụng
  • Hướng đến mục tiêu phục vụ người dùng cuối. Lỗi thường gặp đối với US là người viết quá chú tâm vào những yếu tố như cấu trúc, hệ thống, mà quên đi mục đích cuối cùng
  • Khi viết US, nên tập trung trả lời hai câu hỏi - “User đang làm gì?” và “User có lợi ích gì” khi thực hiện US này
  • Nội dung một US không nên dài quá ba dòng
  • Muốn có một US hợp lý, cần phải đảm bảo ba yếu tố - mục tiêu rõ ràng (well-defined), đủ chi tiết (well-detailed), và khái quát (comprehensive)
  • Khi xây dựng một US, nên cố gắng đảm bảo tính đơn giản và súc tích
  • Không nên dùng những cụm từ/thuật ngữ mơ hồ hay khó hiểu đê viết US
  • Có nhiều technique khác có thể gộp vào trong một US như story maps, bản phác thảo, mockups, storyboards, và sơ đồ quy trình công việc…
  • Sự tham gia của team dev đối với mỗi US là rất quan trọng
  • Một US chỉ nên tập trung vào phần quan trọng nhất và không đi vào tiểu tiết bên ngoài
  • US được coi như là một công cụ giao tiếp trong công việc, vì vậy, cần đảm bảo US dễ tìm và dễ truy cập nhất có thể
  • Tránh tạo ra sự kết nối giữa nhiều US khác nhau để giảm thiểu những mâu thuẫn trong việc lên kế hoạch công việc và quyết định thứ tự ưu tiên
  • Đảm bảo tính độc lập của mỗi US để trong trường hợp một US bị thay đổi hay hủy bỏ, không có ảnh hưởng gì tới toàn bộ cấu trúc sản phẩm
  • Xây dựng một US thực tế - có thể kiểm chứng được (testing). Định nghĩa một US không thực tế sẽ là “Một phần mềm dễ dùng và tạo cảm giác dễ chịu khi sử dụng”.

Nguồn:

https://www.visual-paradigm.com/guide/agile-software-development/what-is-user-story/

6 Likes

bài này là nợ anh Mike mãi bây giờ mới trả :joy::joy::joy:

Ô hay sao lại gọi anh vào

Chị nghĩ trước khi viết US cần xác định cụ thể người dùng là ai, đặc điểm, thói quen, nhu cầu cấp thiết, khó khăn gặp phải, từ đó mới có thể tạo ra các US thực sự giải quyết được nhu cầu của người dùng

2 Likes

Goooood idea @juca
Khó nhất khi viết user story là phần why, mọi người có thể nghiên cứu thêm

vì bỏ qua khâu khảo sát người dùng nên phần why hay bị hiểu là đầu ra của tính năng, sản phẩm có thể có rất nhiều tính năng mà người dùng ko cần đến, hoặc những thứ người dùng thực sự cần thì lại ko đáp ứng được, dẫn đến tính năng vừa thiếu vừa thừa

1 Like

Khảo sát chưa đủ, giống như bác sỹ mà chỉ hỏi bệnh nhân đau ở đâu!

Thực sự người bác sỹ phải nâng cao chuyên môn mới chẩn đoán bệnh được, lắm khi bệnh nhân kêu đau bụng nhưng thực ra bệnh xuất phát từ đầu!

Chúng ta cũng phải thường xuyên nâng cao khả năng phân tích, nghiệp vụ sản phẩm, tránh chỉ nghe khách hàng nói mà không có sự suy nghĩ khám phá bản chất bên trong họ mong muốn điều gì.

nghe như phân tích tâm lý vậy ah

nếu sales có hành trình khách hàng thì trong sản phẩm cũng phải tìm hiểu hành trình người dùng nữa ah