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
4. Estimable
Trong ngữ cảnh của INVEST của user story, “Estimable” (Có thể Ước lượng) đề cập đến khả năng của một user story có thể được ước lượng về thời gian và công sức cần thiết để hoàn thành. Điều này rất quan trọng vì nó cho phép nhóm phát triển đánh giá được mức độ phức tạp và tổ chức tài nguyên một cách hiệu quả.
Một user story được coi là “Estimable” khi các thành viên trong nhóm phát triển có thể đồng thuận về mức độ phức tạp của nó và đưa ra ước lượng thời gian hoặc điểm năng lượng cần thiết để hoàn thành. Điều này thường được thực hiện thông qua các phương pháp như “Planning Poker” hoặc “Relative Sizing”, trong đó các thành viên của nhóm đưa ra ước lượng của họ dựa trên kiến thức và kinh nghiệm của họ về dự án.
Tính “Estimable” của user story là quan trọng để:
- Đánh giá Rủi ro và Quản lý Tiến độ: Có thể ước lượng giúp định rõ mức độ rủi ro và dự đoán được thời gian cần thiết để hoàn thành user story, giúp nhóm quản lý tiến độ của dự án một cách hiệu quả.
- Phân chia công việc: Khi các user story được ước lượng, chúng có thể được phân chia thành các công việc nhỏ hơn và cụ thể hơn, giúp nhóm phát triển dễ dàng quản lý và theo dõi tiến độ.
- Lập kế hoạch và Ưu tiên hóa: Việc ước lượng giúp cho việc lập kế hoạch và ưu tiên hóa các user story trở nên dễ dàng hơn, bởi vì nhóm biết được mức độ phức tạp và thời gian cần thiết cho từng user story.
Để minh họa, hãy xem xét một ví dụ về một user story không “Estimable”:
User story: “Tối ưu hóa hệ thống cơ sở dữ liệu để cải thiện hiệu suất của ứng dụng.”
Trong trường hợp này, user story không “Estimable” vì không rõ mức độ phức tạp của việc tối ưu hóa hệ thống cơ sở dữ liệu có thể là bao nhiêu. Việc ước lượng thời gian cần thiết cho việc này có thể rất khó khăn vì nó phụ thuộc vào nhiều yếu tố như cấu trúc hiện tại của hệ thống, quy mô dữ liệu, và kiến thức về công nghệ cụ thể của nhóm phát triển. Điều này làm cho việc lập kế hoạch và quản lý tiến độ trở nên khó khăn hơn.
5. Small
Trong ngữ cảnh của INVEST của user story, “Small” (Nhỏ) ám chỉ đến việc một user story được chia nhỏ thành các phần nhỏ hơn và có quy mô hợp lý để có thể hoàn thành trong một khoảng thời gian ngắn. Điều này là quan trọng vì các user story nhỏ hơn thường dễ quản lý hơn và có thể hoàn thành nhanh chóng hơn, giúp tăng cường sự linh hoạt và hiệu suất của nhóm phát triển.
Một user story được coi là “Small” khi nó thỏa mãn các tiêu chí sau:
- Chỉ tập trung vào một chức năng hoặc tính năng cụ thể: User story được giới hạn về phạm vi để tập trung vào việc giải quyết một vấn đề cụ thể hoặc cung cấp một tính năng đơn giản.
- Có thể hoàn thành trong khoảng thời gian ngắn: User story có quy mô nhỏ và được ước lượng có thể hoàn thành trong một hoặc vài sprint, thường từ 1 đến 3 tuần.
- Giá trị độc lập: User story mang lại giá trị độc lập và có ý nghĩa cho người dùng hoặc tổ chức mà không cần phải chờ đợi các tính năng khác.
- Có thể kiểm thử và chấp nhận: User story có thể được kiểm thử và chấp nhận một cách độc lập, mà không cần phụ thuộc vào các user story khác.
Việc chia nhỏ user story thành các phần nhỏ hơn và có quy mô hợp lý giúp:
- Tăng cường sự linh hoạt: Các user story nhỏ có thể được ưu tiên và lập kế hoạch một cách linh hoạt hơn, giúp nhóm phát triển thích ứng nhanh chóng với thay đổi trong yêu cầu hoặc ưu tiên của khách hàng.
- Tăng cường hiệu suất: User story nhỏ hơn có thể hoàn thành nhanh chóng hơn, giúp tăng cường hiệu suất và đảm bảo rằng sản phẩm được phát triển liên tục và đều đặn.
- Giảm thiểu rủi ro: Bằng cách chia nhỏ user story, nhóm có thể tập trung vào giải quyết các vấn đề nhỏ hơn một cách hiệu quả hơn, giảm thiểu rủi ro và tăng cường khả năng thành công của dự án.
Ví dụ:
User story: “Người dùng có thể thêm sản phẩm vào giỏ hàng.”
Trong trường hợp này, user story được giới hạn về phạm vi chỉ để tập trung vào việc thêm sản phẩm vào giỏ hàng, một tính năng cụ thể mà người dùng cần. Điều này làm cho user story trở nên nhỏ và dễ quản lý, có thể hoàn thành trong một khoảng thời gian ngắn mà không cần phụ thuộc vào các tính năng khác.
6. Testable
Trong ngữ cảnh của INVEST của user story, “Testable” (Có thể kiểm thử) đề cập đến khả năng của một user story có thể được kiểm tra và chấp nhận dễ dàng. Điều này rất quan trọng vì việc có các user story có thể kiểm thử giúp đảm bảo chất lượng của sản phẩm cuối cùng và tạo điều kiện cho việc phát triển phần mềm một cách linh hoạt và hiệu quả.
Một user story được coi là “Testable” khi nó thỏa mãn các tiêu chí sau:
- Có điều kiện chấp nhận rõ ràng: User story có điều kiện chấp nhận được xác định rõ ràng và cụ thể, giúp nhóm kiểm tra xem user story đã được hoàn thành đúng cách hay không.
- Các ca kiểm thử được xác định: Các ca kiểm thử được xác định trước cho user story, bao gồm các ca kiểm thử tích cực (positive test cases) và các ca kiểm thử tiêu cực (negative test cases) để đảm bảo rằng tất cả các khả năng đã được kiểm tra.
- Có thể tự động hóa: User story có thể được kiểm tra một cách tự động bằng các công cụ kiểm thử tự động, giúp giảm thiểu thời gian và công sức cần thiết cho quá trình kiểm thử.
- Có thể tái sử dụng các bộ kiểm thử: Các bộ kiểm thử được tạo cho user story có thể được tái sử dụng cho các phiên bản hoặc tính năng tương tự, giúp tăng cường hiệu suất và tiết kiệm thời gian cho các lần kiểm thử sau này.
Các user story có thể kiểm thử giúp:
- Đảm bảo chất lượng: Việc có các ca kiểm thử rõ ràng và có thể kiểm thử giúp đảm bảo rằng sản phẩm được phát triển đáp ứng đúng yêu cầu và chất lượng của nó.
- Tăng cường sự tin cậy: User story có thể kiểm thử giúp đảm bảo rằng các tính năng mới được triển khai không gây ra lỗi hoặc vấn đề không mong muốn, tăng cường sự tin cậy và tin tưởng của người dùng vào sản phẩm.
- Giảm thiểu chi phí và thời gian: Việc tự động hóa các ca kiểm thử giúp giảm thiểu chi phí và thời gian cần thiết cho quá trình kiểm thử, giúp tăng cường hiệu suất và tiết kiệm nguồn lực của tổ chức.
Ví dụ:
User story: “Người dùng có thể đăng nhập vào hệ thống bằng tên người dùng và mật khẩu.”
Trong trường hợp này, user story được thiết kế sao cho có thể kiểm thử dễ dàng bằng cách xác định rõ ràng các ca kiểm thử như: nhập đúng tên người dùng và mật khẩu, nhập sai tên người dùng hoặc mật khẩu, kiểm tra tính bảo mật của hệ thống khi đăng nhập. Điều này giúp đảm bảo rằng tính năng đăng nhập được kiểm tra một cách toàn diện và đảm bảo hoạt động một cách chính xác trước khi được triển khai cho người dùng cuối.
Tham khảo thêm tại https://scaledagileframework.com/
