Coông thức 3c card conversation confirmation là gì năm 2024

Trong nhiều năm, người ta thường thắc mắc và tranh luận với nhau về việc 1 team Agile nên thực hành sử dụng User story hay Use case. Vậy User story và Use case có phải cùng là 1 thứ? Nếu không thì cái nào tốt hơn? Nên sử dụng cái nào? Hay là dùng cả hai?

Mặc dù có một số điểm tương đồng, User story và Use case vẫn không thể thay thế cho nhau được. Cả User story và Use case đều cần xác định người dùng và cả hai đều mô tả mục tiêu, nhưng chúng phục vụ các mục đích khác nhau. User story tập trung vào kết quả và lợi ích của cái cần mô tả, trong khi Use case mô tả chi tiết hơn cách hệ thống hoạt động.

Vậy trong mô hình Agile có thể không có Use case không, hay chúng phải sử dụng kết hợp với nhau? Bài viết này sẽ giải đáp thắc mắc và cho bạn biết sự khác biệt giữa User story và Use case.

Mục lục

User story là một ghi chú ghi lại những gì người dùng đang làm hoặc cần phải làm với mỗi yêu cầu công việc của họ. Mỗi User story bao gồm một mô tả ngắn gọn được viết theo cách hiểu của người dùng, với ngôn ngữ tự nhiên. Không giống như cách những yêu cầu truyền thống được đặt ra, User story tập trung vào những gì người dùng cần thay vì những gì hệ thống sẽ cung cấp. Điều này sẽ tạo cơ hội để thảo luận thêm về các giải pháp và kết quả của một hệ thống có thể thực sự phù hợp với quy trình kinh doanh của khách hàng, giải quyết các vấn đề về vận hành của họ và quan trọng nhất là tăng thêm giá trị cho tổ chức.

3C trong User story

3C đề cập đến ba khía cạnh quan trọng của một User story tốt. Khái niệm này được đề xuất bởi Ron Jeffries, người đồng phát minh ra phương pháp User story. Ngày nay, khi chúng ta nói về User story, chúng ta thường đề cập đến những User story được cấu thành từ ba khía cạnh này.

Thẻ (Card)

User story được viết dưới dạng thẻ. Mỗi thẻ User story là một câu văn bản ngắn, vừa đủ để đưa thông tin cho mọi người về nội dung yêu cầu.

Trao đổi (Conversation)

Các yêu cầu được tìm thấy và xử lý lại thông qua những cuộc trò chuyện liên tục giữa khách hàng và nhóm phát triển trong toàn bộ dự án phần mềm. Những ý tưởng và quyết định quan trọng sẽ được phát hiện và ghi lại trong các cuộc họp của các bên liên quan.

Xác nhận (Confirmation)

Xác nhận hay còn gọi là tiêu chí chấp nhận (Acceptance Criteria) của User story. Trong quá trình thảo luận về các yêu cầu, khách hàng không chỉ nói với nhà phân tích những gì họ muốn, mà còn phải xác định những điều kiện và tiêu chí mà phần mềm làm việc có thể được chấp nhận được hay từ chối. Các trường hợp chấp nhận được viết là “Xác nhận”. Lưu ý rằng Xác nhận tập trung vào việc xác minh sự chính xác của User story tương ứng, nó không phải là một thử nghiệm tích hợp.

Use Case là gì?

Use case được giới thiệu bởi Ivar Jacobson hơn 20 năm trước, được sử dụng để nắm bắt quan điểm của người dùng (actor) trong khi mô tả các yêu cầu chức năng của hệ thống. Chúng mô tả từng bước quy trình mà người dùng trải qua để hoàn thành mục tiêu đó bằng hệ thống phần mềm.

Coông thức 3c card conversation confirmation là gì năm 2024

Mỗi Use case là một mô tả từ đầu đến cuối cách mà người dùng cuối (end-user) sử dụng một hệ thống. Use case bao gồm tất cả các cách có thể mà người dùng và hệ thống tương tác để dẫn đến kết quả là người dùng đạt được mục tiêu. Chúng cũng chỉ ra tất cả những khả năng ngoại lệ trong quá trình người dùng đạt được mục tiêu.

Mô hình Use case bao gồm những thành phần bắt buộc. Các thành phần quan trọng nhất là:

• Đối tượng mà người dùng muốn nhận được từ hệ thống.

• Người dùng.

• Các mối quan hệ giữa chúng.

Chi tiết đặc tả Use case (Use case specification)

Đặc tả Use case là một văn bản mô tả chức năng được cung cấp bởi hệ thống. Nó chỉ rõ sự tương tác người dùng – hệ thống. Cụ thể, nó làm rõ người dung sẽ tương tác với hệ thống như thế nào và cách mà hệ thống sẽ trả kết quả tương ứng hành động của người. Nó thường được mô tả dưới dạng một bảng ghi chú người dùng và hệ thống. Đặc tả Use case được biểu diễn trong biểu đồ Use case dưới dạng hình bầu dục, và cũng là điều mà hầu hết mọi người nghĩ đến khi nghe đến thuật ngữ Use case.

Coông thức 3c card conversation confirmation là gì năm 2024

Tại sao chúng ta cần Use case?

  1. User story không đủ rõ ràng để team phát triển sử dụng
  2. Không có cơ sở để xác định được công việc tiếp theo

So sánh User story với Use case

User story thường bắt đầu giống với Use case, chúng đều mô tả một cách sử dụng hệ thống, tập trung vào một mục tiêu, được viết từ quan điểm của người dùng, sử dụng ngôn ngữ kinh doanh và bản thân nó không kể hết toàn bộ câu chuyện.

Điểm tương đồng

Chúng ta xem xét thành phần chính trong cả hai phương pháp:

  • User story gồm có vai trò người dùng, mục tiêu và tiêu chí nghiệm thu.
  • Use case gồm các thành phần tương đương: người sử dụng, luồng vận hành và điều kiện tương ứng (Một Use case chi tiết có thể bao gồm rất nhiều thành phần khác).

Điểm khác nhau

  • User story được soạn thảo không chi tiết bằng Use case.
  • User story không cần nêu những chi tiết quan trọng. User story có mục đích gợi ra các cuộc hội thoại bằng cách đặt câu hỏi trong các cuộc họp Scrum.
  • Mục đích của việc đơn giản hóa User story là để nhận phản hồi thường xuyên hơn, khác với Use case yêu cầu nhiều thông số kỹ thuật chi tiết hơn.

Hy vọng bạn đã hiểu được sự khác nhau giữa User story và Use case và chức năng của chúng trong các dự án. Nếu như bạn mới chỉ sử dụng một loại: User story hoặc Use case thì trong những dự án tiếp theo của mình, hãy thử áp dụng cả hai nhé.