User Story, Use Case, Functional Specification (Phần 1)

Công việc của Business Analyst thường xuyên gắn liền với requirement và documentation. Các tài liệu là sản phẩm của BA và cũng là đầu vào của quá trình phát triển phần mềm, ba trong những tài liệu quan trọng mà Business Analyst nên biết là User Story, Use Case và Functional Specification. Trong bài viết này, BAC cung cấp những thông tin chi tiết về loại tài liệu đầu tiên là User Story.

 

User Story là một tài liệu mô tả ngắn gọn, đơn giản về nhu cầu của người dùng về một tính năng của phần mềm và được viết bằng ngôn ngữ kinh doanh, từ góc nhìn của người dùng.

 

Mục đích của nó là để nói rõ một tính năng phần mềm sẽ cung cấp giá trị như thế nào cho khách hàng. Khách hàng ở đây không nhất thiết phải là người dùng cuối bên ngoài theo nghĩa truyền thống mà họ cũng có thể là khách hàng nội bộ hoặc nhân viên trong tổ chức.

 

 

User Story được viết dưới dạng mong muốn của người dùng với hệ thống nhưng cũng chính là những chức năng mà hệ thống cần có. User Story phải là người vì nó dùng để giải quyết các vấn đề của người dùng và User Story chỉ cần nói vấn đề chứ không cần ghi giải pháp ra.

 

Bất kỳ ai cũng có thể viết User Story nhưng thông thường do khách hàng, hoặc đại điện của khách hàng viết, tuy nhiên nếu có sự cộng tác của Các Nhà Phát triển thì nhóm và khách hàng sẽ có sự chia sẻ hiểu biết về sản phẩm tốt hơn. Bên cạnh đó, Product Owner sẽ là người chịu trách nhiệm bảo đảm rằng phải tồn tại một Product Backlog bao gồm các user stories, nhưng không nhất thiết phải trực tiếp viết ra các user stories.

 

User story thường được viết ngắn gọn trên Card, giấy note, tài liệu Words, Excels… tùy dự án. Ngoài ra, có thể quản lý chuyên nghiệp hơn thông qua phần mềm quản lý dự án như Jira, Trello,…

 

User Story có cú pháp như sau: As a [actor], I want to [action] so that [achievement]. Và trong mỗi US sẽ có những AC (Acceptance Criteria) – những tiêu chí để US được chấp nhận.

 

 

Như tên gọi của nó thì User Story mô tả cách khách hàng sử dụng sản phẩm, nó được nêu từ quan điểm của khách hàng. User Story rất hữu ích trong việc nắm bắt một chức năng cụ thể, ví dụ như tìm kiếm sản phẩm hoặc đặt hàng,… 

 

Trước tiên, hãy tiến hành nghiên cứu người dùng cần thiết bằng cách quan sát và phỏng vấn người dùng. Nếu không nắm rõ người dùng và khách hàng là ai và tại sao họ muốn sử dụng sản phẩm, thì bạn không nên viết bất kỳ User Story nào. Vì có thể bạn viết những câu chuyện dựa trên suy đoán, niềm tin và ý tưởng, chứ không phải dựa trên dữ liệu và bằng chứng thực nghiệm.

 

Personas là những nhân vật được xây dựng theo hình mẫu giả định dựa trên kiến ​​thức trực tiếp của nhóm đối tượng. Persona thường bao gồm một cái tên và một bức tranh; các đặc điểm, hành vi và thái độ có liên quan; và một mục tiêu – là lợi ích mà nhân vật muốn đạt được hoặc vấn đề mà nhân vật muốn thấy được giải quyết bằng cách sử dụng sản phẩm.

 

Personas giúp bạn làm quen với người dùng của mình. Đặt một nhân vật đại diện cho từng vai trò của người dùng/khách hàng sử dụng sản phẩm/phần mềm của dự án và viết ra những gì thúc đẩy họ cần tính năng đó trong sản phẩm/phần mềm, từ đó sẽ giúp nhóm có những lựa chọn đúng đắn khi suy nghĩ về cách thức và những gì cần làm trong việc phát triển sản phẩm/phần mềm.

Viết những câu chuyện sao cho chúng dễ hiểu, giữ chúng đơn giản và ngắn gọn. Tránh các thuật ngữ khó hiểu và không rõ ràng, đồng thời sử dụng giọng nói chủ động. Tập trung vào những gì quan trọng và bỏ qua phần còn lại. 

 

Sử dụng mẫu As a [actor], I want to [action] so that [achievement] cho thấy như đang mô phỏng như một nhân vật vào câu chuyện và làm rõ lợi ích của nó. Nhưng không phải bắt buộc lúc nào cũng phải sử dụng theo mẫu, hãy thử những cách khác nhau để viết User Story để xem cách nào phù hợp nhất với bạn và team của bạn

 

User Story là một kỹ thuật được tạo ra với mục đích giúp bạn xác định yêu cầu nhanh hơn và đây là một công cụ cộng tác. Thay vì chỉ giao cho một nhóm phát triển, thì chúng nên được lồng vào các cuộc thảo luận, Product Owner và nhóm nên thảo luận về các story cùng nhau. Điều này cho phép mọi người chỉ cần nắm bắt lượng thông tin tối thiểu, giảm chi phí và đẩy nhanh quá trình chuyển giao.

Epic Story là một câu chuyện lớn tổng quát, bao gồm nhiều User Story. Độ lớn tương đương lượng công việc phải làm trong nhiều Sprint.

 

Epic Story cho phép bạn phác thảo chức năng của sản phẩm mà không cần phải chi tiết hóa. Điều này đặc biệt hữu ích cho việc mô tả các sản phẩm và tính năng mới. Nó cho phép bạn nắm bắt được phạm vi sơ bộ và giúp bạn có thời gian để tìm hiểu thêm về cách giải quyết tốt nhất nhu cầu của người dùng.

 

Nó giúp làm giảm thời gian và nỗ lực cần thiết để tích hợp những thông tin chi tiết mới. Nếu bạn có nhiều câu chuyện chi tiết trong Product Backlog, thì thường rất phức tạp, tốn thời gian và có nguy cơ đưa ra sự mâu thuẫn.

Acceptance Criteria là những tiêu chí, điều kiện cần được đáp ứng để User Story được hoàn thành. Các tiêu chí làm phong phú thêm câu chuyện và làm cho câu chuyện có thể kiểm tra được. AC giúp ghi lại những kỳ vọng của khách hàng, làm rõ yêu cầu của khách hàng, đảm bảo thông tin nghiệm thu minh bạch. Đây là một phần quan trọng trong việc hoàn thành User Story được PO và BA nghiên cứu kỹ lưỡng, bởi vì thiếu một tiêu chí duy nhất cũng có thể tốn rất nhiều chi phí. Đây là một danh sách được list ra và đánh số.

 

Tham khảo mẫu template về User Story: Template User Story

 

Hy vọng rằng những chia sẻ trên đây về tài liệu User Story sẽ hữu ích với bạn đọc. Tham khảo thêm về 2 loại tài liệu Use Case (phần 2) và Functional Specification (phần 3) tại đây.