Tại sao nên viết user stories và lưu giữ những cuộc trò chuyện (conversation) về nó? Tại sao chúng ta không cần phải tiếp tục cách tiếp cận truyền thống là viết tài liệu mô tả yêu cầu (URD user requirements documents & FSD functional specifications documents) hoặc sử dụng sơ đồ use case?

User stories cung cấp một số lợi thế so với những cách tiếp cận kia, ví dụ như:

• User stories nhấn mạnh vào giao tiếp bằng lời nói hơn là giao tiếp bằng văn bản
• User stories có thể hiểu được bởi cả customers + đơn vị nghiệp vụ và developers
• User stories là thứ có kích thước phù hợp để lập kế hoạch
• User stories hoạt động tốt cho qui trình phát triển lặp xoắn ốc (iterative process)
• User stories khuyến khích trì hoãn làm chi tiết cho đến khi bạn hiểu rõ nhất về thứ bạn thực sự cần cho sản phẩm

Bởi vì user stories chuyển trọng tâm sang việc đối thoại với nhau và tránh tối đa việc viết tài liệu. Những quyết định quan trọng không được ghi lại trong các tài liệu yêu cầu, những thứ mà nhiều khả năng là không được đọc kỹ.

Thay vào đó, các khía cạnh quan trọng về user stories được nắm bắt trong các tiêu chí nghiệm thu (acceptance criteria), những tiêu chí có khả năng được tự động kiểm tra và chạy thường xuyên trong các môi trường phát triển hỗ trợ “Continuous Integration”.

Ngoài ra, chúng ta sẽ tránh được việc viết những câu phát biểu kiểu như:

“Hệ thống phải lưu địa chỉ và số điện thoại doanh nghiệp hoặc số điện thoại.” Điều đó nghĩa là gì? Điều đó có nghĩa là hệ thống phải lưu trữ một trong những điều sau:

• (Địa chỉ và điện thoại doanh nghiệp) hoặc điện thoại di động
• Địa chỉ và (điện thoại doanh nghiệp hoặc điện thoại di động)

Bởi vì User stories không sử dụng thuật ngữ kỹ thuật (hãy nhớ rằng, Customer team viết chúng), chúng có thể hiểu được bởi cả các developers cũng như Customer team.

Mỗi user stories đại diện cho một phần chức năng riêng biệt; đó là một thứ gì đó một người dùng có thể sẽ làm trong một hoàn cảnh/thao tác cụ thể. Điều này làm cho User stories thích hợp như một công cụ lập kế hoạch. Bạn có khả năng đánh giá tác động của việc dịch chuyển những user stories từ  một release này sang một release khác tốt hơn nhiều so với khả năng bạn có thể đánh giá tác động của việc bỏ đi một hoặc nhiều câu phát biểu yêu cầu kiểu như “Hệ thống phải …”.

Một quá trình lặp xoắn ốc (iterative process) là một quá trình tạo ra sự tiến bộ thông qua việc tinh chỉnh (refinement) liên tiếp. Một nhóm phát triển thực hiện lần cut off đầu tiên tại một hệ thống, và biết rằng nó không hoàn chỉnh hoặc còn yếu ở một số, có thể ở nhiều, khu vực. Sau đó, họ liên tục tinh chỉnh những khu vực đó cho đến khi sản phẩm đạt yêu cầu. Trải qua mỗi iteration, phần mềm được cải thiện thông qua việc bổ sung các chi tiết rõ ràng hơn. User stories hoạt động tốt  với quá trình phát triển phần mềm kiểu vòng lặp (iterative) bởi vì chính các user stories cũng được lặp đi lặp lại qua các lần viết, thảo luận, và coding. Đối với một tính năng bạn muốn có nhưng không nhất thiết phải có ngay bây giờ, trước tiên bạn có thể viết một user story lớn (một epic). Khi bạn đã sẵn sàng để thêm user story đó vào hệ thống, bạn có thể tinh chỉnh nó bằng cách chia nhỏ nó thành những user stories nhỏ hơn mà sẽ dễ dàng để mô tả và giải thích chi tiết.

Chúng ta có thể viết một epic với mục đích “giữ chỗ” ngày hôm nay, mà chưa cần viết những user stories về nhóm chức năng của một hệ thống cho đến sát thời điểm khi nhóm chức năng đó sẽ được phát triển. Trì hoãn làm chi tiết rất quan trọng vì nó cho phép chúng ta không tốn thời gian suy nghĩ về một tính năng mới cho đến khi chúng ta chắc chắn tính năng này là cần thiết.

User stories là công cụ khiến cho chúng ta không cần giả vờ rằng chúng ta có thể biết và viết ra mọi thứ đầy đủ ngay từ đầu. User stories phù hợp với một quy trình theo đó phần mềm được tinh chỉnh lặp đi lặp lại dựa trên các cuộc thảo luận giữa Customer team và developers.

Theo Mike Cohn

Why User Stories?