Scrum - Câu chuyện của người dùng

Như bạn đã hiểu, Câu chuyện người dùng thường được sử dụng để mô tả các tính năng của sản phẩm và sẽ tạo thành một phần của Tạo tác Scrum - Product Backlog và Sprint Backlog.

Câu chuyện của người dùng

Trong phát triển phần mềm, các tính năng của sản phẩm đóng một vai trò quan trọng. Đó là các tính năng mà người dùng cuối cùng thích sử dụng trong sản phẩm cuối cùng. Chúng được gọi là Yêu cầu trong thuật ngữ chung. Sự thành công của dự án phát triển phần mềm nằm ở việc hiểu các yêu cầu của người dùng một cách chính xác và phù hợp, sau đó thực hiện chúng trong sản phẩm cuối cùng. Do đó, các yêu cầu hoặc tính năng của sản phẩm cần được nhóm dự án phát triển biết kỹ lưỡng.

Năm 1999, Kent Beck đưa ra thuật ngữ Câu chuyện người dùng cho các tính năng của sản phẩm. Ông mô tả rằng một Câu chuyện người dùng được tường thuật từ góc độ người dùng liên quan đến những gì họ muốn có hơn là những gì hệ thống có thể làm cho anh ta. Do đó, chế độ xem đã thay đổi hoàn toàn từ sản phẩm sang người dùng và Câu chuyện của người dùng trở thành tiêu chuẩn thực tế cho các Yêu cầu trong tất cả các khuôn khổ Agile.

Trong các dự án Scrum, Product Backlog là một danh sách các câu chuyện của người dùng. Những Câu chuyện Người dùng này được ưu tiên và đưa vào Sprint Backlog trong Cuộc họp Lập kế hoạch Sprint.

Ước tính cũng dựa trên câu chuyện của người dùng và quy mô của sản phẩm được ước tính trong Điểm câu chuyện của người dùng.

Cấu trúc câu chuyện người dùng

Cấu trúc Câu chuyện người dùng như sau:

Với tư cách là <Loại người dùng> ,

Tôi muốn <Thực hiện một số tác vụ> ,

Để <Tôi có thể đạt được mục tiêu / lợi ích / giá trị nào đó> .

Hãy cùng chúng tôi xem xét cách một câu chuyện người dùng được đóng khung cho tình huống Khách hàng Ngân hàng rút tiền mặt từ ATM.

Câu chuyện người dùng: Rút tiền mặt của khách hàng

Như một Customer,

tôi muốn withdraw cash from an ATM,

Vậy nên I don't have to wait in line at the Bank

Tiêu chí chấp nhận câu chuyện của người dùng

Mỗi Câu chuyện người dùng cũng có Tiêu chí chấp nhận được xác định, do đó tính đúng đắn của việc triển khai câu chuyện người dùng được xác nhận bằng cách vượt qua Kiểm tra chấp nhận dựa trên Tiêu chí chấp nhận.

Sau đây là tiêu chí chấp nhận mẫu cho ví dụ về việc rút tiền mặt của khách hàng trong User Story.

Acceptance Criterion 1:

Given rằng tài khoản đáng tin cậy

Và thẻ hợp lệ
Và bộ phân phối chứa tiền mặt,

When khách hàng yêu cầu tiền mặt

Then đảm bảo tài khoản được ghi nợ

Và đảm bảo tiền mặt được phân phối
Và đảm bảo thẻ được trả lại.

Acceptance Criterion 2:

Given rằng tài khoản được thấu chi

Và thẻ hợp lệ

When khách hàng yêu cầu tiền mặt

Then đảm bảo thông báo từ chối được hiển thị

Và đảm bảo tiền mặt không được phân phối
Và đảm bảo thẻ được trả lại.

Viết câu chuyện người dùng

Chủ sở hữu sản phẩm chịu trách nhiệm về Product Backlog và do đó đối với Câu chuyện của người dùng. Tuy nhiên, điều đó không có nghĩa là chỉ có chủ sở hữu sản phẩm mới viết các câu chuyện của người dùng. Bất kỳ ai trong Nhóm Scrum đều có thể viết các câu chuyện của người dùng và hoạt động có thể được dàn trải trong toàn bộ dự án khi các yêu cầu được tinh chỉnh và các chức năng mới được bổ sung.

Yêu cầu phi chức năng trong câu chuyện của người dùng

Có thể kết hợp các yêu cầu phi chức năng trong các câu chuyện của người dùng. Trong ví dụ ATM đã cho, máy ATM có sẵn cho người dùng 24X7, 365 ngày là một yêu cầu phi chức năng, có thể được mô tả bằng một trường hợp sử dụng.

Quản lý câu chuyện của người dùng

Câu chuyện của người dùng được quản lý trong Product Backlog. Câu chuyện của người dùng được sắp xếp theo mức độ ưu tiên. Các câu chuyện của người dùng được ưu tiên nhất được tinh chỉnh ở mức chi tiết, trong khi các câu chuyện của người dùng ít ưu tiên nhất được giữ ở mức chi tiết hơn. Đối với mỗi sprint, những câu chuyện về người dùng được ưu tiên nhất và do đó chi tiết hơn sẽ được đưa vào sprint backlog. Nếu một câu chuyện của người dùng được thêm vào product backlog, thì mức độ ưu tiên của nó sẽ được xác định trước tiên và nó được đặt theo vị trí của nó theo mức độ ưu tiên. Các câu chuyện của người dùng có thể được đánh giá lại bất cứ lúc nào. Cũng có thể xóa bất kỳ câu chuyện người dùng nào nếu được yêu cầu.

Lợi ích với Câu chuyện của người dùng

Lợi ích chính của Câu chuyện người dùng nằm ở chính định nghĩa lấy người dùng làm trung tâm. Điều này là do cuối cùng, chính người dùng sẽ sử dụng sản phẩm trong các tình huống người dùng có liên quan. Nó kết nối người dùng cuối với các thành viên trong nhóm.
Bản thân cú pháp của Câu chuyện người dùng đảm bảo nắm bắt được mục tiêu hoặc lợi ích hoặc giá trị mà người dùng muốn đạt được.
Vì các tiêu chí chấp nhận tạo thành một phần của câu chuyện người dùng nên nó sẽ là một lợi thế bổ sung cho Nhóm Scrum.
Có thể thực hiện các thay đổi đối với câu chuyện người dùng trong quá trình thực hiện dự án. Nếu phạm vi của câu chuyện người dùng trở nên lớn, nó cần được chia thành các câu chuyện người dùng nhỏ hơn. Các điều kiện trong tiêu chí chấp nhận cũng có thể được thay đổi.
Khi các sản phẩm gia tăng đang hoạt động được chuyển đến người dùng vào cuối mỗi sprint, nhóm scrum có thể nhận được phản hồi từ người dùng trong cuộc họp đánh giá sprint. Điều này cho phép liên tục kết hợp phản hồi vào sản phẩm.

Phần kết luận

Câu chuyện người dùng của Scrum đưa người dùng đến gần hơn với nhóm Scrum và ngăn chặn những bất ngờ vào phút cuối.