Agile INVEST – 6 nguyên tắc tuyệt vời cho các câu chuyện người dùng

Agilesử dụng các câu chuyện người dùng để thể hiện những vấn đề mà một sản phẩm hoặc hệ thống cần giải quyết. Nguyên tắc Agile INVEST là một bộ khuyến nghị được tổng hợp bởi Bill Wake nhằm giúp kiểm tra và tạo ra các câu chuyện người dùng chất lượng cao (hoặc nói rộng hơn là các mục trong danh sách sản phẩm) hỗ trợ quản lý dự án Agile hiệu quảquản lý dự án Agile.

Theo nguyên tắcAgile INVESTnguyên tắc, các câu chuyện người dùng chất lượng cao dễ dàng:

• Hiểu rõ
• Triển khai
• Kiểm thử
• Trình bày cho khách hàng
• Độc lập

Nhưng hãy cùng phân tích rõ ràng chữ viết tắt INVEST thực sự có nghĩa là gì.

Agile INVEST – Độc lập

Điều này có nghĩa là câu chuyện có thể tồn tại như một mục trong danh sách sản phẩm (PBI) với mức độ ưu tiên riêng, có thể được ước lượng độc lập và không phụ thuộc vào bất kỳ câu chuyện nào khác.

Mức độ ưu tiên được gán cho một câu chuyện người dùng nên là yếu tố duy nhất quyết định thời điểm đội triển khai nó. Nếu mức độ ưu tiên thấp, câu chuyện sẽ nằm ở vị trí thấp hơn trong danh sách và được triển khai muộn hơn; nếu cao hơn, đội sẽ di chuyển nó lên trên danh sách để giao hàng nhanh hơn. Khi các câu chuyện người dùng phụ thuộc lẫn nhau, chính mối phụ thuộc—không phải mức độ ưu tiên—sẽ quyết định thời điểm đội triển khai chúng.

Agile INVEST – Có thể thương lượng

Một câu chuyện người dùng tốt cần nắm bắt được cốt lõi nhu cầu của khách hàng. Nếu có câu hỏi, đội sẽ thảo luận với khách hàng để xác định giá trị đúng của câu chuyện. Đội phát triển có thể thương lượng với người sở hữu sản phẩm và các bên liên quan. Nhờ vậy, sự hợp tác giữa đội dự án (nhà cung cấp và khách hàng) sẽ tạo ra một sản phẩm hoặc dịch vụ xuất sắc.

Liệu một đội Agile không còn gì để hỏi vì mọi thứ đã được ghi chép trong câu chuyện người dùng Agile? Nếu vậy, thì một chuyên viên phân tích kinh doanh đã viết các yêu cầu.

Sẽ có một số nội dung không thể thương lượng (thường là phi chức năng), ví dụ như:

• Các chính sách bảo mật liên quan đến tài khoản người dùng
• Các yêu cầu về hiệu suất, ví dụ như số lượng người dùng đồng thời mà hệ thống phải xử lý

Điều đó là ổn—nhưng chỉ khi chi tiết về chức năng bản thân vẫn mở và khuyến khích trao đổi.

Agile INVEST – Có giá trị

Theo các nguyên tắc Agile, ‘có giá trị’ có nghĩa là chúng ta có thể trình bày tính năng hoặc chức năng được yêu cầu cho khách hàng trong buổi họp xem xét Sprint.

Khi chia nhỏ các câu chuyện người dùng, đội phải chia theo chiều dọc (cũng đại diện cho chữ ‘V’) thay vì theo chiều ngang. Điều này giúp cung cấp chức năng đầy đủ vào cuối Sprint và tăng cường phần tăng trưởng sản phẩm có thể giao được.

Các đội có thể thấy việc triển khai các PBI kỹ thuật thú vị hơn, nhưng chúng không phải lúc nào cũng mang lại giá trị trực tiếp cho khách hàng—điều này mâu thuẫn với một trong cácnguyên tắc Agile: đáp ứng khách hàng thông qua việc giao phần mềm có giá trị sớm và liên tục.

Agile INVEST – Có thể ước lượng được

Một câu chuyện người dùng tốt phải có thể ước lượng được. Trong agile, việc ước lượng là tương đối—so sánh với các câu chuyện người dùng khác trong danh sách công việc. Các phương pháp phổ biến bao gồm dãy Fibonacci, Kích cỡ áo thun (S, M, L, v.v.), và nhiều hơn nữa.

Việc thảo luận về việc ước lượng giúp toàn bộ đội đạt được sự đồng thuận về các điều kiện cần thiết để hoàn thành câu chuyện. Đôi khi một câu chuyện không thể ước lượng được, điều này là bình thường nếu câu chuyện quá lớn hoặc chứa nhiều tính năng trong cùng một mục. Trong những trường hợp như vậy, hãy chia câu chuyện thành nhiều câu chuyện nhỏ hơn. Ở những tình huống khác, có quá nhiều điều chưa biết cần phải nghiên cứu.

Agile INVEST – Nhỏ gọn

Các câu chuyện nên kéo dài từ vài giờ đến tối đa một chu kỳ Sprint đầy đủ. Ngược lại, sẽ phát sinh các vấn đề khác nhau—như tốc độ (cách đội tự chịu trách nhiệm về các điểm giao hàng), khó khăn trong việc ước lượng chính xác, và nhiều vấn đề khác.

Agile INVEST – Có thể kiểm thử được

Trong ngữ cảnh này, ‘có thể kiểm thử được’ đề cập đến các tiêu chí chấp nhận được xác định trong quá trình phân tích.

Chúng ta không thể coi một câu chuyện người dùng là ‘hoàn thành’ trừ khi nó đáp ứng các tiêu chí chấp nhận. Cách duy nhất chúng ta biết được điều đó là được thỏa mãn là thông qua kiểm thử và xác minh.

Các tiêu chí chấp nhận không phải là các trường hợp kiểm thử. Chúng trả lời câu hỏi: ‘Làm sao tôi biết mình đã hoàn thành câu chuyện người dùng này?’

Các trường hợp kiểm thử nêu rõ các bước cần thiết để kiểm thử chức năng.

Khách hàng có thể nói cho bạn biết môi trường kiểm thử trông như thế nào và các điều kiện kiểm thử mà đội coi câu chuyện người dùng là HOÀN THÀNH.