User Story, Use Case, Functional Specification (P1)

User Story, Use Case, Functional Specification (p1) là 3 nội dung quan trọng trong các document của Business Analyst trong quá trình phát triển phần mềm. Hãy cùng Cole tìm hiểu về loại document đầu tiên – User Story – trong bài viết dưới đây. 

User Story là gì?

Trong software development và product management, user story là một mô tả bằng ngôn ngữ tự nhiên, không chính thức về một hoặc nhiều tính năng của hệ thống phần mềm, được sử dụng trong quá trình Agile software development để nắm bắt mô tả về tính năng phần mềm từ góc độ người dùng cuối. Mô tả loại người dùng, họ muốn gì và tại sao. User story giúp tạo ra một mô tả đơn giản về một yêu cầu.

User stories thường được ghi lại trên index cards, trên ghi chú Post-it hoặc trong phần mềm quản lý dự án. Tùy thuộc vào dự án, User story có thể được viết bởi nhiều stakeholders khác nhau như clients, users, managers hoặc development team members.

“User stories là một phần của agile approach giúp chuyển trọng tâm từ việc viết về các yêu cầu để nói về chúng. Tất cả các user story Agile bao gồm một câu lệnh hoặc hai và quan trọng hơn là một loạt các cuộc trò chuyện về chức năng mong muốn ” – Mike Cohn, một người đóng góp chính cho việc phát minh ra Scrum software development methodology.

Lợi ích của việc sử dụng user story

Requirements bao giờ cũng thay đổi khi team và khách hàng tìm hiểu thêm về hệ thống như project progresses. Sẽ không thực tế nếu mong đợi project teams thực hiện một danh sách yêu cầu tĩnh và sau đó cung cấp functional software vài tháng sau đó.

Với user story approach chúng tôi thay thế thiết kế trả trước lớn bằng cách tiếp cận “vừa đủ”. Giúp giảm thời gian viết tài liệu đầy đủ bằng cách nhấn mạnh các cuộc trò chuyện lấy khách hàng làm trung tâm. Do đó, user story cho phép các nhóm cung cấp phần mềm chất lượng nhanh hơn, đó là điều khách hàng ưa thích. Có khá nhiều lợi ích khi áp dụng user story approach trong agile development như:

• Định dạng đơn giản và nhất quán giúp tiết kiệm thời gian khi nắm bắt và sắp xếp thứ tự ưu tiên các yêu cầu trong khi vẫn đủ linh hoạt để sử dụng cho các tính năng lớn và nhỏ.
• Luôn thể hiện giá trị kinh doanh bằng cách cung cấp sản phẩm mà khách hàng thực sự cần.
• Tránh giới thiệu chi tiết quá sớm sẽ ngăn cản các lựa chọn thiết kế và ràng buộc developers vào một giải pháp một cách không thích hợp.
• Tiếp cận các phần tử nhỏ nhất để bắt đầu đàm phán và hoạt động trong backlog.
• Để lại các technical functions cho architect, developers, testers,…

Basic Concepts 

User story là một phương pháp đơn giản để nhanh chóng nắm bắt được “ai”, “cái gì” và “tại sao” của yêu cầu sản phẩm. Nói một cách đơn giản, nó là những ý tưởng về yêu cầu thể hiện những gì người dùng cần. Mỗi phần tử thường chứa ít hơn 10 hoặc 15 từ mỗi phần. Còn là danh sách “to-do-list” giúp bạn xác định các bước trong lộ trình của dự án. Chúng giúp đảm bảo rằng quy trình cũng như sản phẩm tạo ra sẽ đáp ứng yêu cầu của bạn.

Được xác định tăng dần theo ba giai đoạn:

• Mô tả ngắn gọn về nhu cầu
• Các cuộc trò chuyện diễn ra trong quá trình lập kế hoạch lặp lại và giải quyết tồn đọng để củng cố lại các chi tiết
• Các bài kiểm tra xác nhận sự hoàn thành của story

Tất cả được gói gọn trong quy trình 3C’s – Card, Conversation và Confirmation.

Cách viết user stories

Khi bắt đầu viết, một template có thể giúp đảm bảo rằng bạn không vô tình bắt đầu viết technical tasks:

User Story Template

User stories chỉ nắm bắt được các yếu tố thiết yếu của một requirement:

• Nó dành cho ai?
• Nó mong đợi gì từ hệ thống?
• Tại sao nó quan trọng (optional?)

Ví dụ về User Story 

• Với tư cách là [khách hàng], tôi muốn [tính năng giỏ hàng] để [Tôi có thể dễ dàng mua hàng trực tuyến]
• Với tư cách là [người quản lý], tôi muốn [tạo báo cáo] để [Tôi có thể hiểu bộ phận nào cần thêm nguồn lực]
• Với tư cách là [khách hàng], tôi muốn [nhận được tin nhắn SMS khi hàng đến] để [tôi có thể đến lấy ngay]

Trong các ví dụ trên:

• [Vai trò] đại diện cho con người, hệ thống, subsystem hoặc bất kỳ thực thể nào khác sẽ tương tác với hệ thống được triển khai để đạt được mục tiêu. Người đó sẽ đạt được các giá trị bằng cách tương tác với hệ thống.
• [Hành động] thể hiện sự mong đợi của người dùng có thể được thực hiện thông qua việc tương tác với hệ thống.
• [Lợi ích] thể hiện giá trị đằng sau sự tương tác với hệ thống.

Đó không phải là một quy tắc mà là một hướng dẫn giúp bạn suy nghĩ về user story bằng cách xem xét những điều sau:

• User story sẽ mang lại value cho ai đó hoặc một bên nào đó (ví dụ: khách hàng)
• Đáp ứng nhu cầu của người dùng (ví dụ: nhận SMS khi mặt hàng được gửi đến)
• Có lý do để hỗ trợ triển khai user story này (ví dụ: khách hàng có thể đến nhận món hàng mình đã mua)

Cũng giống như nhiều phương pháp phát triển phần mềm khác, nếu bạn áp dụng user story đúng cách trong dự án phần mềm của mình, bạn sẽ có thể tạo ra một hệ thống phần mềm chất lượng và giành được sự tin tưởng và hài lòng từ khách hàng. Theo dõi Cole và tham gia khóa học data analyst online để đón đọc các nội dung tiếp theo trong series User Story, Use Case, Functional Specification (P1) 

Bên cạnh đó, bạn có thể tham khảo thêm khoá học ba để có nhiều kinh nghiệm trong lĩnh vực này

>> Xem thêm: Hyperion là gì? Hyperion hoạt động như thế nào?