Thu thập yêu cầu tạo Product Backlog

Trong giai đoạn bắt đầu dự án, Product Owner gặp những người đại diện cho các bên liên quan, cố gắng hiểu những gì họ cần và chuyển chúng thành các yêu cầu cho sản phẩm phần mềm mới. Có hai phương án tiếp cận thực hiện:

• Top-down: bắt đầu từ mức Rừng (SP tổng thể) => SP mới sẽ bao gồm những gì (có những cây nào trong rừng của bạn) => Xác định các cành của mỗi cây => Xác định lá trên mỗi cành…
• Bottom-up: hỏi người dùng liệt kê tất cả những user story (hoặc lá) mà họ nghĩ đến trước tiên, nhóm chúng lại với nhau, sử dụng phép loại suy “rừng và cây” để lấy từ lá cho đến cành, rồi từ cành cho đến cây, và sau cùng từ cây cho đến rừng.

Các yêu cầu thu thập được viết ra dưới dạng các User story (bản tóm tắt nhu cầu người dùng). Người ta thường dùng một khuôn mẫu nhất định để viết User story cho phép ta biết được yêu cầu của khách hàng là gì, ai sẽ là người sử dụng chức năng đó, nhằm mục đích gì. Một trong các mẫu ấy là:

Là <người dùng cụ thể \ vai trò> , tôi muốn <làm gì đó> để <phục vụ mục đích nào đó>.

Ví dụ: Là quản trị của diễn đàn, tôi muốn xóa một người dùng phạm quy nghiêm trọng để tránh gây gại cho diễn đàn.

Tiêu chí của một User story hoàn chỉnh (nhóm hoàn thành công việc viết các User story để lập KH):

• Liên quan đến tất cả các tầng của ứng dụng và nó không thể chia thành những Story nhỏ nữa.
• Có thể chuyển thành các công việc (4-8h) từ Story đó để bắt đầu việc phát triển.
• Nhóm có thể bắt đầu ước tính điểm của Story đó.

Khách hàng (hoặc Product Owner) có thể viết user story, nhưng sẽ tốt hơn là nhóm phát triển cộng tác với khách hàng trong buổi làm việc User Story Writing Workshop tập trung. Khi đó, bên cạnh việc viết ra các User Story, cả nhóm có điều kiện trao đổi, tìm hiểu sâu về các yêu cầu của hệ thống, giúp cho quá trình phát triển sau này.

Quy tắc CUTFIT là một trong những cách để đảm bảo các yêu cầu được viết đúng

• Nhất quán (Consistent): không mâu thuẫn với các yêu cầu khác
• Không mơ hồ (Unambiguous): có thể diễn giải nó theo một cách duy nhất trong mọi trường hợp
• Kiểm thử được (Testable): phải có khả năng tạo ra các test case cho một yêu cầu
• Khả thi (Feasible): phải triển khai được từng yêu cầu trong những khả năng và hạn chế đã biết
• Độc lập (Independent): không có chuyện User story này phụ thuộc vào User story kia
• Theo dõi được (Traceable): bạn phải có khả năng liên kết từng yêu cầu đến với người dùng và mục đích của họ.

Không chỉ phục vụ cho việc thể hiện chính xác nhu cầu của người dùng, User Story còn là công cụ để triển khai việc kiểm thử chấp nhận (acceptance test). Khi đó, User Story có thể thêm điều kiện kiểm thử chấp nhận Ví dụ: Là quản trị của diễn đàn, tôi muốn xóa một người dùng phạm quy để tránh di hại về sau cho diễn đàn. Sau khi xóa xong, người dùng không thể truy xuất hệ thống sử dụng tài khoản đã xóa, các bài viết của người này trên diễn đàn cũng bị hủy khỏi diễn đàn.