Agile teams dành rất nhiều thời gian để khám phá, tìm hiểu, phân tích và đưa ra tình huống/testcases đáp ứng cho các yêu cầu. Khi User story được viết một cách chi tiết, có thể giúp cho dev team có thể hiểu nhanh hơn và có góc nhìn tổng quát hơn rất nhiều trong quá trình này, từ đó có thể đưa ra những phân tích rõ ràng hơn, không sai hướng trong quá trình thiết kế hệ thống/viết dev note.
Để đánh giá một User Story chất lượng hay không, có rất nhiều tiêu chí hoặc cách đánh giá khác nhau. Bài viết này tập trung vào INVEST:
Independent
Negotiable
Verifiable
Estimable
Small
Testable
- Independent
Độc lập có nghĩa là một US có thể được phát triển, kiểm thử, và thậm chí có thể được giao hàng một cách độc lập. Do đó, nó cũng có thể được đánh giá độc lập.
Nhiều US sẽ có một số dependency tự nhiên, tuần tự khi chức năng sản phẩm được xây dựng, và tuy nhiên, mỗi phần có thể cung cấp giá trị độc lập. Ví dụ, một sản phẩm có thể hiển thị một bản ghi duy nhất, sau đó là một danh sách, sau đó sắp xếp danh sách, lọc danh sách, chuẩn bị một danh sách nhiều trang, xuất danh sách, chỉnh sửa các mục trong danh sách, v.v. Nhiều trong số những mục này có phụ thuộc tuần tự, tuy nhiên, mỗi mục cung cấp giá trị độc lập và sản phẩm có thể được giao hàng thông qua bất kỳ điểm dừng nào của quá trình phát triển.
Tuy nhiên, nhiều dependency không có giá trị, bất kể là kỹ thuật hay chức năng, cũng thường xuất hiện trong các backlog và chúng ta cần tìm và loại bỏ chúng. Ví dụ, một phụ thuộc chức năng không có giá trị có thể là:
As an admin, I can set the user’s password security rules so that users are required to
create and retain secure passwords, keeping the system secure.
As a user, I am required to follow the password security rules set by the admin so that I
can maintain high security to my account
Trong ví dụ này, US của consumer phụ thuộc vào US của admin. US của admin chỉ test được ở setting, nhưng không test được ở phần của user. Việc release US 1 không giúp cho sản phẩm có thể “potentially shippable” với tính năng mới – như vậy, nó không phải là 1 US mang lại giá trị độc lập.
Để reconsider 2 US này, chúng tả có thể loại bỏ dependency không giá trị này, bằng cách tiếp cận khác: tách các loại policy ra thành nhiều US khác nhau, và kết hợp giữa user và admin luôn.
Sau khi cân nhắc, ta có thể tách lại thành 2 US như sau:
As an Admin, I can set the password expiration period so that users are forced to change
their passwords periodically.
As an Admin, I can set the password strength characteristics so that users are required to
create difficult to hack passwords.
Bây giờ, 2 US này có thể trở lên độc lập và có thể test riêng biệt nhau.
2. Negotiable
Trong ngữ cảnh của INVEST của user story, “Negotiable” đề cập đến khả năng thương lượng và thay đổi của một user story. Điều này ám chỉ rằng user story không nên là một chỉ thị cụ thể về cách triển khai hay làm sao để giải quyết vấn đề, mà thay vào đó nó nên là một phác thảo linh hoạt có thể điều chỉnh dựa trên phản hồi và hiểu biết mới được nhận được trong quá trình phát triển.
Khả năng thương lượng của một user story là quan trọng đối với việc duy trì sự linh hoạt trong quá trình phát triển phần mềm. Nó cho phép các thành viên trong nhóm làm việc cùng nhau để hiểu rõ yêu cầu và tìm ra cách tốt nhất để thực hiện chúng. Điều này cũng mở ra cơ hội để cải thiện hoặc điều chỉnh các yêu cầu khi cần thiết, giúp tái cấu trúc và tinh chỉnh sản phẩm để đáp ứng nhu cầu của khách hàng.
Một user story “Negotiable” không nên bị ràng buộc bởi các giới hạn cứng nhắc về kỹ thuật hoặc giao diện người dùng. Thay vào đó, nó nên được coi là một tài liệu định hình sơ bộ mà nhóm có thể làm việc với để phát triển và cải thiện dự án.
Tóm lại, tính “Negotiable” của user story làm nổi bật khả năng linh hoạt và thích ứng của quá trình phát triển, tạo điều kiện cho sự hợp tác và sáng tạo giữa các thành viên trong nhóm để đạt được kết quả tốt nhất.
Hãy xem xét một ví dụ về việc áp dụng nguyên tắc “Negotiable” trong việc phát triển một ứng dụng di động.
Giả sử bạn là một phần của một nhóm phát triển ứng dụng di động đang làm việc trên một tính năng mới để cải thiện trải nghiệm người dùng. Yêu cầu ban đầu là tạo ra một trang chào mừng cho ứng dụng, hiển thị tên và logo của ứng dụng cùng với một nút “Bắt đầu” để chuyển hướng người dùng đến một màn hình khác để bắt đầu sử dụng ứng dụng.
Tuy nhiên, khi nhóm bắt đầu phát triển tính năng này, họ nhận ra rằng một trang chào mừng đơn giản có thể làm ít để giới thiệu ứng dụng của họ và gây ấn tượng với người dùng. Thay vào đó, họ muốn thêm một số nội dung mô tả về ứng dụng, nhấn mạnh vào các tính năng nổi bật và cung cấp một trải nghiệm hấp dẫn hơn cho người dùng.
Tại cuộc họp lập kế hoạch tiếp theo, nhóm đã thảo luận về sự linh hoạt của yêu cầu ban đầu và quyết định rằng họ có thể thương lượng và điều chỉnh nội dung và giao diện của trang chào mừng để đáp ứng tốt hơn yêu cầu của khách hàng.
Nhờ vào tính “Negotiable” của user story, nhóm đã có cơ hội thảo luận và đưa ra quyết định tự chủ về cách triển khai tính năng mới. Họ đã quyết định mở rộng phạm vi của trang chào mừng để cung cấp thông tin chi tiết hơn về ứng dụng và tạo ra một trải nghiệm người dùng tốt hơn.
Kết quả là, nhờ vào việc áp dụng nguyên tắc “Negotiable”, nhóm đã phát triển một trang chào mừng đầy ấn tượng và hấp dẫn hơn, giúp tạo ra một ấn tượng tích cực với người dùng và cải thiện trải nghiệm sử dụng ứng dụng.
3. Valuable
Trong ngữ cảnh của INVEST của user story, “Valuable” (Có Giá Trị) ám chỉ đến khả năng của một user story mang lại giá trị cho người dùng hoặc cho tổ chức phát triển sản phẩm. Một user story được coi là có giá trị khi nó giúp giải quyết một vấn đề thực tế hoặc cung cấp một lợi ích cụ thể cho người dùng hoặc tổ chức.
Khả năng đánh giá giá trị của một user story là quan trọng để đảm bảo rằng các nỗ lực phát triển được tập trung vào các tính năng hoặc chức năng có thể mang lại lợi ích lớn nhất. Các yếu tố quan trọng cần xem xét khi đánh giá giá trị của một user story bao gồm:
- Tiện ích cho người dùng: User story có thực hiện một chức năng hoặc tính năng mà người dùng cần hoặc muốn sử dụng, đáp ứng được nhu cầu hoặc giải quyết được một vấn đề cụ thể của họ.
- Tiện ích cho tổ chức: User story mang lại lợi ích hoặc tạo ra giá trị cho tổ chức, bao gồm việc tăng cường hiệu suất làm việc, giảm chi phí, tăng cường sự cạnh tranh hoặc cải thiện hình ảnh thương hiệu.
- Độ ưu tiên: User story được xác định có mức độ ưu tiên cao do sự quan trọng và ảnh hưởng của nó đối với mục tiêu tổng thể của dự án hoặc sản phẩm.
- Khả năng đo lường: User story có thể được đo lường hoặc đánh giá một cách cụ thể để xác định mức độ hoàn thành và đánh giá hiệu quả của nó.
Think of a whole story as a multi-layer cake, e.g., a network layer, a persistence layer, a logic
layer, and a presentation layer. When we split a story [horizontally], we’re serving up only part
of that cake. We want to give the customer the essence of the whole cake, and the best way is to
slice vertically through the layers. Developers often have an inclination to work on only one layer
at a time (and get it “right”); but a full database layer (for example) has little value to the
customer if there’s no presentation layer
Việc đọc vào US và thấy được giá trị của nó, BA có thể phân tích lại giá trị của US tương ứng với nhóm đối tượng nào, để paraphrase lại cho US trở nên giá trị hơn.
Ví dụ:
As a course learner, I can see other related courses that appeal to me so that I can enroll in a
course that matches my needs.
Có thể paraphrase lại để US này có giá trị hơn với các product owner.
As a Marketing Director, I can present users with new courses so that they are more
likely to continue purchasing/entrolling new course from our system.
Cũng giống như thay vì tạo 1 US nói về Refactor hệ thống log, ta có thể viết US thành:
As a consumer, I can receive a consistent and clear error message anywhere in the product so that I
know how to address the issue.
Tham khảo thêm tại https://scaledagileframework.com/
