User story là gì?

User story là gì?

Một user story là một ghi chú ghi lại điều mà một người dùnglàm hoặc cần làm như một phần công việc của cô ấy. Mỗi user story bao gồm một mô tả ngắn được viết từ góc nhìn của người dùng, bằng ngôn ngữ tự nhiên. Khác với việc thu thập yêu cầu truyền thống, user story tập trung vào nhu cầu của người dùng thay vì điều mà hệ thống cần cung cấp. Điều này tạo điều kiện cho các cuộc thảo luận sâu hơn về giải pháp và kết quả của một hệ thống có thể thực sự phù hợp với quy trình làm việc kinh doanh của khách hàng, giải quyết các vấn đề vận hành của họ và quan trọng nhất là tạo ra giá trị cho tổ chức.

Khái niệm 3C

3C đề cập đến ba khía cạnh quan trọng của các user story tốt. Khái niệm này được đề xuất bởi Ron Jeffries, đồng phát minh ra phương pháp user stories. Ngày nay, khi chúng ta nói về user stories, chúng ta thường đang nói đến loại user stories được tạo thành từ ba khía cạnh này.

1. Thẻ – Các user story được viết dưới dạng thẻ. Mỗi thẻ user story chứa một câu ngắn với lượng văn bản vừa đủ để nhắc nhở mọi người về nội dung câu chuyện.
2. Cuộc trò chuyện – Các yêu cầu được tìm ra và tinh chỉnh thông qua các cuộc trò chuyện liên tục giữa khách hàng và đội phát triển trong suốt toàn bộ dự án phần mềm. Những ý tưởng và quyết định quan trọng sẽ được phát hiện và ghi lại trong các cuộc họp với các bên liên quan.
   
3. Xác nhận – hay còn được gọi là tiêu chí chấp nhận của user story. Trong quá trình thảo luận về yêu cầu, khách hàng không chỉ nói với nhà phân tích điều họ muốn, mà còn xác nhận dưới những điều kiện và tiêu chí nào thì phần mềm hoạt động sẽ được chấp nhận hoặc từ chối. Các trường hợp được xác định sẽ được ghi lại dưới dạng xác nhận. Lưu ý rằng xác nhận tập trung vào việc xác minh tính chính xác của công việc tương ứng với user story. Nó không phải là kiểm thử tích hợp.
   

Làm thế nào để xác định user story?

Các user story nên được xác định cùng với các bên liên quan, tốt nhất là thông qua cuộc họp trực tiếp. User story là một quá trình khám phá yêu cầu thay vì một quá trình phân tích yêu cầu trước. Trong các phương pháp thu thập yêu cầu truyền thống, nhà phân tích hệ thống cố gắng hiểu nhu cầu của khách hàng và sau đó chuẩn bị chi tiết một tài liệu yêu cầu cho hệ thống. Điều này không phải là cách thức hoạt động của phương pháp user story. Thay vì một quy trình tài liệu hóa, việc xác định user story giống như một quy trình ghi chú hơn. Qua các cuộc thảo luận với người dùng, chúng ta lắng nghe và hiểu các vấn đề và nhu cầu của họ, sau đó ghi lại nhu cầu đó dưới dạng user story ngay lập tức. Các user story này sẽ trở thành nguồn gốc của các yêu cầu. Các chi tiết có thể được điền sau đó theo nhu cầu, cung cấp cho đội ngũ một tài liệu tham khảo yêu cầu “vừa đủ” trong suốt quá trình phát triển dự án.

Xác định quy trình kinh doanh với user story

BPMN là một trong những công cụ mạnh mẽ nhất cho phân tích và mô hình hóa kinh doanh. Không chỉ chúng ta có thể sử dụng nó để cải tiến quy trình, mà còn có thể xác định các user story từ những quy trình dự định được tự động hóa thông qua các bước sau:

1. Đơn giản là mô hình hóa luồng công việc của người dùng bằng sơ đồ quy trình kinh doanh BPMN.
2. Đi qua từng bước mô hình quy trình cùng với người dùng.
3. Và, phân tích các hoạt động kinh doanh của vấn đề, sau đó xác định các user story liên quan đến quy trình cần được tự động hóa, điều này còn được gọi là việc chuyển đổi quy trình kinh doanh thành user story.

Làm thế nào để viết user story?

Khi viết một user story, hãy cố gắng viết bằng giọng điệu của người dùng theo mẫu dưới đây (hoặc ít nhất, hãy đảm bảo rằng những gì bạn viết đáp ứng yêu cầu sau):

Là một <vai trò>, tôi muốn <mục tiêu kinh doanh> để <giá trị kinh doanh/lý do>.

Ví dụ: Là một khách hàng, tôi muốn nhận được tin nhắn SMS khi hàng hóa đến để tôi có thể đi lấy nó lên.

ở đâu:

1. <vai trò> đại diện cho người, hệ thống, tiểu hệ thống hoặc bất kỳ thực thể nào khác sẽ tương tác với hệ thống được triển khai để đạt được mục tiêu. Người đó sẽ thu được giá trị thông qua việc tương tác với hệ thống.
2. <mục tiêu kinh doanh> đại diện cho kỳ vọng của người dùng có thể đạt được thông qua việc tương tác với hệ thống.
3. <giá trị kinh doanh> đại diện cho giá trị đằng sau việc tương tác với hệ thống.

Đây không phải là một quy tắc mà là một hướng dẫn giúp bạn suy nghĩ về một câu chuyện người dùng bằng cách xem xét những điều sau:

1. Câu chuyện người dùng sẽ mang lại giá trị cho ai đó hoặc một bên nhất định (ví dụ: khách hàng).
2. Câu chuyện người dùng đáp ứng nhu cầu của người dùng (ví dụ: nhận tin nhắn SMS khi hàng đến)
3. Có lý do để hỗ trợ triển khai câu chuyện người dùng này (ví dụ: khách hàng có thể đến nhận hàng mà họ đã mua)

Mỗi câu chuyện người dùng nên mang lại giá trị cho ai đó. Nhưng đôi khi, giá trị đã rõ ràng chỉ cần đọc mục tiêu kinh doanh. Việc ghi rõ giá trị vào phần tuyên bố sẽ gây phiền toái. Trong trường hợp đó, chúng ta sẽ bỏ qua. Dưới đây là một số ví dụ:

Là một khách hàng, tôi muốn thanh toán bằng thẻ tín dụngđể tôi có thể sử dụng thẻ tín dụng trong mua hàng trực tuyến.

Là một người dùng, tôi muốn thực hiện tìm kiếm bằng cách nhập tên bạn bè của tôiđể tôi có thể tìm thấy bạn bè của mình bằng tên cô ấy.

Dù bạn viết câu chuyện người dùng như thế nào, cũng có hai điều bạn phải luôn ghi nhớ. Thứ nhất, câu chuyện người dùng phải được viết từ góc nhìn của người dùng. Thứ hai, hãy giữ phần mô tả ở mức ‘vừa đủ’. Tránh thêm quá nhiều chi tiết ngay từ đầu của một dự án phần mềm. Sau này bạn sẽ có cơ hội tinh chỉnh và chi tiết hóa câu chuyện người dùng để nó trở thành thứ mà các nhà phát triển có thể sử dụng trong thiết kế và triển khai.

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

Trong một khái niệm rộng, có sáu trạng thái chính cho mỗi câu chuyện người dùng trong suốt một dự án phần mềm:

1. Chờ xử lý – Qua quá trình trao đổi giữa người dùng và đội dự án, các câu chuyện người dùng được xác định. Ở trạng thái này, các câu chuyện người dùng chỉ có một mô tả ngắn gọn về nhu cầu của người dùng. Chưa có thảo luận chi tiết về yêu cầu, chưa có logic hệ thống hay thiết kế giao diện. Thực tế, mục đích duy nhất của câu chuyện người dùng lúc này chỉ là để nhắc nhở tất cả các bên về một cuộc thảo luận trong tương lai về yêu cầu của người dùng được ghi trong câu chuyện người dùng (thẻ). Có thể trong tương lai, câu chuyện người dùng sẽ bị loại bỏ.
2. Chưa bắt đầu – Qua cuộc thảo luận giữa các bên liên quan, các câu chuyện người dùng cần được xử lý trong vài tuần tới được xác định và đưa vào một khoảng thời gian cố định gọi là sprint. Những câu chuyện người dùng này được gọi là ở trạng thái Todo. Chưa có cuộc thảo luận chi tiết nào được thực hiện ở trạng thái này.
3. Đang thảo luận – Khi một câu chuyện người dùng ở trạng thái Đang thảo luận, người dùng cuối sẽ trao đổi với đội phát triển để xác nhận các yêu cầu và xác định tiêu chí chấp nhận. Đội phát triển sẽ ghi lại các yêu cầu hoặc bất kỳ quyết định nào dưới dạng ghi chú cuộc trao đổi. Chuyên gia UX có thể tạo sơ đồ bố cục hoặc bản đồ câu chuyện để người dùng xem trước các tính năng đề xuất trong các bản mô phỏng hình ảnh, và cảm nhận chúng. Quá trình này được gọi là thiết kế trải nghiệm người dùng (UX design).
   
4. Đang phát triển – Sau khi các yêu cầu được làm rõ, đội 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.
5. Xác nhận – Khi đội phát triển đã triển khai một yêu cầu người dùng, yêu cầu người dùng sẽ được người dùng cuối xác nhận. Người dùng cuối sẽ được cấp quyền truy cập vào môi trường kiểm thử hoặc một 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. Việc xác nhận sẽ được thực hiện dựa trên các mục xác nhận được viết khi chi tiết hóa yêu cầu người dùng. Cho đến khi xác nhận hoàn tất, yêu cầu người dùng được coi là ở trạng thái Xác nhận.
6. Hoàn thành – Cuối cùng, khi tính năng đã được xác nhận là hoàn thành, yêu cầu người dùng được coi là ở trạng thái Hoàn thành. Thông thường, đây là điểm kết thúc của yêu cầu người dùng. Nếu người dùng có yêu cầu mới, dù là về một tính năng mới hay cải tiến cho yêu cầu người dùng đã hoàn thành, đội sẽ tạo một yêu cầu người dùng mới cho vòng lặp tiếp theo.

Chi tiết hóa Yêu cầu người dùng – Khi nào và tại sao?

Một điểm quan trọng làm cho yêu cầu người dùng khác biệt với các phương pháp thu thập yêu cầu truyền thống là phương pháp yêu cầu người dùng chia việc xác định vấn đề và giải pháp thành hai bước, được thực hiện ở các giai đoạn khác nhau trong dự án phần mềm. Trong khi các vấn đề và sự hiểu biết sơ bộ về yêu cầu người dùng được xác định ngay từ đầu dự án phần mềm, thì chi tiết về yêu cầu hệ thống chỉ được xác định trước khi bắt đầu thiết kế và triển khai. Dưới đây là một số lợi ích của cách sắp xếp này:

1. Có thể phản hồi kịp thời nhu cầu mới nhất của người dùng vì các yêu cầu được chi tiết hóa ngay trước khi triển khai, thay vì phải kết thúc tất cả ngay từ đầu.
2. Dễ dàng xác định được các yêu cầu phù hợp hơn vì cả vấn đề lẫn giải pháp đều được thảo luận chi tiết. Trong các phương pháp truyền thống, do chi tiết của tất cả yêu cầu cần được xác định ngay từ đầu dự án, các yêu cầu ban đầu có thể thay đổi theo thời gian, dẫn đến lãng phí rất nhiều công sức phân tích.
3. – Mặt khác, các yêu cầu người dùng bị phát hiện không hợp lệ có thể bị loại bỏ dễ dàng. Bạn sẽ không mất nhiều thời gian vào việc nghiên cứu và tài liệu hóa trước đó

Làm thế nào để sử dụng Yêu cầu người dùng hiệu quả?

Giống như nhiều phương pháp phát triển phần mềm khác, nếu bạn áp dụng đúng yêu cầu người dùng trong dự án phần mềm của mình, bạn sẽ có thể tạo ra một hệ thống phần mềm chất lượng và giành được niềm tin cũng như sự hài lòng từ khách hàng. Dưới đây là một số điểm cần lưu ý khi sử dụng yêu cầu người dùng:

1. Giữ phần mô tả yêu cầu người dùng ngắn gọn.
2. Hãy suy nghĩ từ góc nhìn người dùng cuối khi viết một yêu cầu người dùng.
3. Một (UML) trường hợp sử dụng đại diện cho một mục tiêu kinh doanh. Khả năng nhóm các yêu cầu người dùng dưới các trường hợp sử dụng giúp bạn đảm bảo rằng một yêu cầu người dùng đáp ứng được một mục tiêu kinh doanh, nói cách khác, chúng chia sẻ cùng một mục tiêu hệ thống. Nó đóng vai trò như một chỗ trống giúp bạn quản lý, lập lịch và ưu tiên các yêu cầu người dùng theo cách dễ quản lý hơn.
4. Các mục xác nhận phải được xác định trước khi bạn bắt đầu phát triển
5. Ước lượng yêu cầu người dùng trước khi triển khai để đảm bảo khối lượng công việc của đội bạn được kiểm soát.
6. Yêu cầu được xác định cùng người dùng cuối, chứ không phải do người dùng cuối hay chỉ riêng đội phát triển. Duy trì mối quan hệ tốt với người dùng cuối sẽ là lợi ích đôi bên.
7. Giao tiếp luôn quan trọng trong việc hiểu rõ người dùng cuối muốn gì.

Visual Paradigm cung cấp tất cả các công cụ bạn cần trong phát triển phần mềm linh hoạt, bao gồm công cụ sơ đồ trường hợp sử dụng UML, (linh hoạt) yêu cầu người dùng, sprint, sơ đồ câu chuyện và bản phác thảo cho thiết kế người dùng, công cụ quản lý công việc, v.v.