User Story - Câu chuyện người dùng - Kỹ thuật phân tích phần 1
- Tagi Dona
- Apr 14
- 7 min read
Song song trong quá trình khai thác yêu cầu phần mềm hoặc chuyển sang giai đoạn phân tích yêu cầu và đưa ra giải pháp. Có khá nhiều kỹ thuật giúp ta phân tích yêu cầu phần mềm, giải pháp. Một trong những phương pháp hay công cụ, mà Tagi cảm nhận, nó khá đơn giản chính là sử dụng User Story.
Vậy US là gì ? ứng dụng ra sao và làm thế nào để chúng ta viết một US hoàn chỉnh và đầy đủ nhất. Hãy cùng nhau khám phá nhé ^^
User Story là gì ?
User story là một miêu tả ngắn gọn về tính năng của phần mềm. Tuy nhiên, điểm nổi bật và khác biệt ở đây, chính là nó được viết dựa trên góc nhìn của người dùng cuối (end-user). Nó tập trung vào việc giải thích một tính năng sẽ mang lại giá trị gì cho người dùng.
Sử dụng user story, chúng ta sẽ đứng quan điểm của người dùng sự dụng giải pháp được cung cấp, và nhận thấy rõ rằng những mong đợi cũng như giá trị mà giải pháp mang lại nhằm đáp ứng nhu cầu của người dùng.
Những nhu cầu về mặt nghiệp vụ hoặc nói xa hơn là nhu cầu đó sẽ giúp người dùng hoàn thành được những mục tiêu gì để hướng đến nhu cầu về mặt kinh doanh, mục tiêu của tổ chức.
Vậy, chúng ta có thể xem một US chính là một yêu cầu phần mềm.
Và một US thông thường sẽ có cấu trúc gồm 3 phần chính:
Người dùng (Who) là ai ? tại đây chúng ta xác định người dùng (actor) sử dụng hay tương tác với tính năng.
Và họ sẽ làm gì (What) và có thể là làm như thế nào (How),khi nào(When), ở đâu (Where)
Khi hoàn thành những việc đó sẽ giúp họ đạt được mục đích gì (Why)
Ví dụ về một US:
As a registered user
I want to be able to log in to the application
So that I can access my personal information and features.
Khi đi lấy yêu cầu từ các bên liên quan (stakeholders) chúng ta cũng đã phải đặt bộ câu hỏi 5W1H để hiểu hơn về nhu cầu của họ, thì việc phản ánh những nhu cầu đó thành các tính năng dưới góc nhìn của họ thông qua US sẽ giúp đảm bảo giải pháp đáp ứng đúng được nhu cầu (need) thực sự.
Ứng dụng của US trong phát triển phần mềm
Việc sử dụng US trong việc phát triển phần mềm thường mang lại nhiều lợi ích như sau:
Tập trung vào người dùng: User Story giúp đội phát triển phần mềm luôn đặt người dùng cuối ở vị trí trung tâm, đảm bảo rằng sản phẩm đáp ứng đúng nhu cầu của họ.
Giao tiếp hiệu quả: User Story là công cụ giao tiếp hiệu quả giữa các bên liên quan (khách hàng, nhà phát triển, kiểm thử viên) để đảm bảo mọi người hiểu rõ yêu cầu và mục tiêu của dự án.
Lập kế hoạch và ước lượng: User Story giúp chia nhỏ các yêu cầu lớn thành các phần nhỏ hơn, dễ quản lý và ước lượng thời gian, công sức cần thiết để hoàn thành.
Quản lý thay đổi: User Story cho phép dễ dàng điều chỉnh và thay đổi yêu cầu trong quá trình phát triển dự án một cách linh hoạt.
Xác định phạm vi công việc: User Story giúp xác định rõ ràng phạm vi công việc cần thực hiện, giúp đội phát triển tập trung vào những tính năng quan trọng nhất.
Làm sao để viết một US hoàn chỉnh và "Đẹp"
Trong thực tế việc phát triển phần mềm sử dụng US hay Use case trong việc phát triển phần mềm đều cần có sự chi tiết và đầy đủ thông tin để làm cơ sở cho đội ngũ phát triển (lập trình viên, kiểm thử viên) sản xuất ra những tính năng hoàn thiện và hoạt động tốt.
Nếu xét đơn thuần, US chỉ giúp chúng ta cung cấp những yêu cầu ở dạng ngắn gọn và đội ngũ có thể dựa trên đó để phân tích sâu hơn, chi tiết, hoàn thiện hơn trong suốt quá trình phát triển sản phẩm. Tuy nhiên, để tránh mất thời gian, cũng như đảm bảo chất lượng, thực tế BA cần phải làm việc trước chuẩn bị nội dung chi tiết và đầy đủ hết nhất có thể (này dựa trên kinh nghiệm cá nhân của Tagi).
Thế nào là một US đạt chuẩn
A. Tiêu chí chấp thuận - Accepatance Criteria
Như đã nói ở trên, chỉ một vài chữ trong US thì không khả thi để chúng ta phát triển được tính năng của sản phẩm. Và hơn hết, làm sao để chúng ta đánh giá một tính năng đã được phát triện dựa trên US đã cung cấp là đủ tiêu chuẩn.
Câu trả lời ở đây chính là Acceptance Criteria - Các tiêu chí chấp thuận hay còn gọi tắt là AC. Hiểu nôm nay thì đây chính là những điều kiện mà tính năng hệ thống phải đáp ứng, chỉ khi tất cả các điều kiện này được đáp ứng đầy đủ và chính xác thì mặc nhiên tính năng đã được kiểm duyệt và sẵng sàng để phân phối đến tay người dùng.
Quay lại ví dụ về US- Login ở trên, ta có thể có một vài AC như bên dưới:
Successful login with valid credentials
Error message for incorrect credentials
Account lockout after multiple failed login attempts: After a certain number of consecutive incorrect login attempts (e.g., 5 attempts), the user's account is temporarily locked to protect it from attacks.
Password security: User passwords must be stored securely in the database, e.g., using one-way encryption (hashing)
Response time: The time it takes for the system to authenticate the login information and redirect the user should not exceed a certain threshold (e.g., 3 seconds).
Data validation: The system validates the input data (e.g., email format, password length) before processing it.
Tips: tại AC tuỳ theo độ phức tạp của US mà chúng ta sẽ bổ sung thêm những xử lý logic, công thức tính toán hoặc lưu đồ nhằm làm rõ thêm US
B. Chuẩn INVEST
Chúng ta đã biết cách thành lập một US và bổ sung AC để phục vụ cho việc phát triển tính năng. Tuy nhiên, để đảm bảo một UC chất lượng tốt nhất, thì chúng ta có thể áp dụng chuẩn INVEST.
Không phải luôn luôn phải tuân theo chuẩn này, nhưng nếu áp dụng được, thì sẽ nâng cao chất lượng cũng như giá trị của US và kết quả công việc của BA
Independent (Độc lập): User Story nên độc lập với nhau, có thể phát triển và triển khai mà không phụ thuộc quá nhiều vào các User Story khác.
Negotiable (Có thể thương lượng): User Story không phải là một bản hợp đồng cứng nhắc, mà là một lời mời để thảo luận và làm rõ các yêu cầu.
Valuable (Có giá trị): User Story phải mang lại giá trị cho người dùng cuối hoặc khách hàng.
Estimable (Có thể ước lượng): User Story nên đủ rõ ràng để đội phát triển có thể ước lượng được thời gian và công sức cần thiết để hoàn thành.
Small (Nhỏ): User Story nên đủ nhỏ để có thể hoàn thành trong một Sprint (thường là 1-2 tuần).
Testable (Có thể kiểm thử): User Story phải có các tiêu chí chấp nhận rõ ràng để có thể kiểm tra xem nó đã được hoàn thành đúng yêu cầu hay chưa.
Trong 6 tiêu chí trên thì có lẻ 2 tiêu chí Độc lập và Có thể thương lượng là hơi trừu tượng. Vậy thì hãy xem phần giải thích sau hén:
Tính Độc Lập
Thay vì viết hai User Story phụ thuộc vào nhau như "Người dùng có thể tạo tài khoản" và "Người dùng có thể đăng nhập", hãy viết một User Story bao gồm cả hai chức năng: "Với vai trò là người dùng mới, tôi muốn tạo tài khoản và đăng nhập để sử dụng ứng dụng."
Mục đích: Giúp đội phát triển có thể làm việc song song trên các User Story khác nhau mà không bị xung đột.
Có thể thương lượng
Thay vì viết "Người dùng phải nhập địa chỉ email hợp lệ", hãy viết "Với vai trò là người dùng, tôi muốn được thông báo nếu địa chỉ email tôi nhập không hợp lệ để tôi có thể sửa lại."
Mục đích: Khuyến khích sự thảo luận và làm rõ các yêu cầu, cho phép đội phát triển đưa ra các giải pháp sáng tạo hơn:
Khuyến khích sự hợp tác: Tạo ra một môi trường cởi mở, nơi mọi người có thể chia sẻ ý tưởng và đóng góp vào việc tìm ra giải pháp tốt nhất.
Tìm ra các giải pháp sáng tạo: Đôi khi, các giải pháp tốt nhất không phải là những giải pháp được đề xuất ban đầu.
Đề xuất các giải pháp thay thế: Có thể có những cách khác tốt hơn để đạt được mục tiêu của User Story.
Làm rõ các chi tiết: User Story thường chỉ mô tả yêu cầu ở mức cao, cần làm rõ các chi tiết cụ thể hơn.
Đảm bảo rằng sản phẩm đáp ứng đúng nhu cầu: Bằng cách thảo luận và làm rõ các yêu cầu, chúng ta có thể đảm bảo rằng sản phẩm cuối cùng đáp ứng đúng nhu cầu của người dùng.
Tăng tính linh hoạt: Cho phép chúng ta thích ứng với những thay đổi trong quá trình phát triển.
P.S: Trong loạt bài viết về US này chúng ta sẽ thảo luận thêm hai nội dung:
Ứng dụng BDD vào nội dung của US
Xây dựng US Map trong giai đoạn phân tích.
Tagi Dona
Comments