User Story có tương thích với use case không?

Tìm kiếm trên mạng, các bậc thầy Agile coi use cases và user stories là hai thứ khác nhau:

Phương pháp dựa trên use case từng là một trong những kỹ thuật nóng bỏng nhất để thu thập yêu cầu, và một số người hiện nay coi nó là một kỹ thuật lỗi thời, cổ điển, gắn liền với nhiều vấn đề khiến đội của bạn KHÔNG “Agile” do những vấn đề của use case:

  • Yêu cầu ban đầu – cố gắng định nghĩa chi tiết tất cả các khía cạnh ban đầu sẽ dẫn đến nhiều công sức và thời gian bị lãng phí vì phần lớn công việc sẽ phải làm lại.
  • Phân tích chức năng: Bản chất chức năng của use cases tự nhiên dẫn đến việc phân tích chức năng của hệ thống theo các use case cụ thể và trừu tượng, liên kết với nhau thông qua các mối quan hệ extends và include.

Nếu bạn tìm kiếm trên mạng với từ khóa ‘use case vs user story’, bạn sẽ tìm thấy danh sách dài các bài viết đề cập đến những nhược điểm, vấn đề hoặc điểm rủi ro của phương pháp use case, trong khi lại có danh sách dài hơn nữa về những lợi ích liên quan đến user story. Thú vị thay, mọi thứ thay đổi nhanh chóng trong ngành công nghệ thông tin, và còn nhanh hơn nữa đối với những người chuyển từ những thứ từng được coi là ‘thời thượng’ trong quá khứ sang những thứ ‘thời thượng’ mới hiện nay.

Thú vị thay, một số người thích nhìn nhận mọi thứ theo mô hình nhị phân và chạy theo những thứ thời thượng bằng cách liên kết với chúng một cách biểu tượng thay vì thực sự áp dụng một cách chân thành. Một số người thậm chí không muốn để người khác biết họ vẫn đang sử dụng use cases, vì họ sợ bị coi là lỗi thời và cổ điển.

Bây giờ, một số người đặt dấu bằng giữa user story và use case:

  • Agile = user story hoặc Agile = user story + Scrum
  • User story = đủ và đúng thời điểm
  • User story = đáp ứng kỳ vọng người dùng và sự hài lòng
  • Use Case = thu thập yêu cầu chi tiết ngay từ đầu
  • Use case = <<include>> + <<extends>> = phân tích chức năng
  • Use case là kiểu “đầu vào người dùng” → “phản hồi hệ thống” duy nhất
  • Use case = kiểu cũ và lỗi thời

Là một nhà cung cấp công cụ, chúng tôi khá trung lập về các phương pháp, công cụ và kỹ thuật. Cá nhân tôi muốn nhấn mạnh rõ ràng rằng tôi là một người hâm mộ lớn của phát triển Agile, user story và quy trình Scrum. Đặc biệt là những nguyên tắc nền tảng và các thực hành tốt liên quan đến các khái niệm như:

  • Phát hiện yêu cầu thay vì giao yêu cầu
  • Dưới nguyên tắc trên dẫn đến hai đặc tính quan trọng trong quy trình phát triển Agile
    • Đúng thời điểm
    • Đủ

(Tôi sẽ viết thêm các bài đăng liên quan đến các nguyên tắc trên với quan điểm cá nhân của tôi, điều này liên quan mật thiết đến lĩnh vực nghiên cứu tiến sĩ của tôi từ 1992-1995 – mô hình siêu và chuyển đổi sơ đồ)

Bây giờ, hãy quay lại chủ đề ‘use case so với user story’. À, các bậc thầy Agile nặng ký đã đưa ra ý kiến rồi, liệu tôi có quá cố chấp khi cố gắng đảo ngược ‘ý kiến’ đó bằng cách tranh luận rằng chúng giống nhau hoặc thậm chí là một?

Hãy để tôi cho bạn một ví dụ để minh họa xem user story có thực sự “khác biệt” đến vậy so với use case không:

Ví dụ

Các câu chuyện người dùng tốt hơn nhiều so với chỉ là những tuyên bố. Một câu chuyện người dùng tiêu chuẩn bao gồm ba phần, thường được gọi là ba C.

Chữ C đầu tiên trong mỗi câu chuyện người dùng nên tuân theo định dạng chuẩn hóa như:

Là một [vai trò], tôi muốn [làm điều gì đó], để [lợi ích]

đây là nội dung tối thiểu của một câu chuyện người dùng để đưa vào thẻ.

Các cuộc trò chuyện là nội dung của chữ C thứ hai trong một câu chuyện người dùng, đại diện cho cuộc thảo luận giữa người dùng cuối, chủ dự án và đội phát triển. Trong các cuộc trao đổi này, nó ghi lại các cuộc thảo luận bằng lời nói hoặc nhiều thông tin hữu ích khác như email, sơ đồ bố trí, hoặc bất kỳ nội dung liên quan nào khác cho dự án.

Chữ C cuối cùng trong một câu chuyện người dùng là xác nhận, là tiêu chí chấp nhận được sử dụng để xác minh rằng câu chuyện người dùng đã được triển khai đúng và giao thành công.

Hãy để tôi làm rõ thêm một chút về cách phát triển phần xác nhận trong một câu chuyện người dùng. Ở đây, chúng tôi sử dụng mẫu phổ biến nhất được gọi là Gherkin, áp dụng công thức Given-When-Then để hướng dẫn việc viết các bài kiểm thử chấp nhận cho một câu chuyện người dùng:

  • (Cho trước.. và) một bối cảnh nhất định
  • (Khi.. và) một hành động được thực hiện
  • (Sau đó.. và) Thực hiện một số hành động

Các công cụ như Cucumber và khung thử nghiệm Jbehave khuyến khích việc sử dụng mẫu Given/When/Then để thực hiện kiểm thử tự động, mặc dù nó cũng có thể được sử dụng thuần túy như một phương pháp heuristics bất kể có hay không sử dụng công cụ.

Hãy cùng thu thập tất cả thông tin cho câu chuyện người dùng “đăng ký khóa học” và đưa vào định dạng 3C:

confirmation

Tôi đã áp dụng định dạng 3C phổ biến để biểu diễn câu chuyện người dùng “đăng ký khóa học”. Tương tự, tôi cũng đã áp dụng định dạng được sử dụng rộng rãi nhất để mô tả cùng một trường hợp sử dụng “đăng ký khóa học” được trình bày trong mô tả trường hợp sử dụng. Tôi đã đánh số các bước trong phần xác nhận (chữ C cuối cùng) của câu chuyện người dùng, tương ứng với số bước mà tôi đã đặt trong mô tả trường hợp sử dụng. Chúng đều là cùng một “chín bước” của kịch bản, được đặt vào mỗi phương pháp với thứ tự khác nhau. Tôi tin rằng cả hai cách biểu diễn mô hình này đều được chấp nhận đối với các bậc thầy và người theo dõi tương ứng. Sau đó, câu hỏi lại nảy sinh: câu chuyện người dùng rất giống với trường hợp sử dụng, nhưng lại khác nhau, hay chính thứ tự các bước gây ra mọi sự chỉ trích đối với phương pháp trường hợp sử dụng?

Tương đương về mặt ngữ nghĩa nhưng khác nhau về ý nghĩa?

Hãy cùng tìm hiểu xem có trường hợp tương tự nào trong lĩnh vực mô hình hóa hay không, để so sánh với tình huống hiện tại, hoặc có thể giúp chúng ta đưa ra quan điểm riêng về “câu chuyện người dùng so với trường hợp sử dụng”, thay vì mù quáng theo đám đông hay lặp lại những điều các bậc thầy nói như một con vẹt.

use case description - user story

Ví dụ: Tương đương về mặt ngữ nghĩa

Trong UML, chúng ta có thể mô tả một kịch bản trường hợp sử dụng bằng sơ đồ tuần tự, nhưng thông thường chúng ta không sử dụng sơ đồ hợp tác cho cùng một mục đích; mặc dù cả hai sơ đồ này đều tương đương về mặt ngữ nghĩa. Nói cách khác, cả sơ đồ tuần tự và sơ đồ hợp tác đều có cùng số lượng đối tượng tham gia vào một kịch bản, với cùng số lượng tin nhắn được trao đổi giữa cùng một tập hợp đối tượng để thực hiện một nhiệm vụ trong kịch bản. Tuy nhiên, sơ đồ tuần tự tập trung vào thời gian, còn sơ đồ hợp tác tập trung vào không gian. Sơ đồ tuần tự mang tính trực quan hơn khi sử dụng cùng với mô hình hóa kịch bản, trong khi sơ đồ hợp tác phù hợp để mô hình hóa mối quan hệ cấu trúc giữa các đối tượng. Ví dụ, bạn muốn biểu diễn cấu trúc kịch bản của các đối tượng tham gia vào khung MVC (lớp mô hình/xem và điều khiển).

Cá nhân tôi không nghĩ việc sử dụng câu chuyện người dùng sẽ khiến đội của tôi trở nên linh hoạt, và việc sử dụng trường hợp sử dụng sẽ khiến đội tôi trở nên “thiếu suy nghĩ trước”. Điều quan trọng nhất là cách chúng ta áp dụng và sử dụng các công cụ đó với tư duy và các phương pháp tốt nhất nào đằng sau. Tôi không quá lo lắng khi người khác coi tôi là “cũ kỹ” hay lỗi thời, dù thực tế tôi đang hành động một cách linh hoạt.

Tôi vẫn còn nhớ thời kỳ phân tích và thiết kế cấu trúc, có lẽ chúng ta có thể sử dụng Kiểu dữ liệu trừu tượng trong ADA để áp dụng các nguyên tắc phân tích và thiết kế hướng đối tượng mà không cần hỗ trợ từ OOP vào những năm 198x, đúng không? Thật không may, bạn có thể thậm chí chưa từng nghe đến khái niệm Kiểu dữ liệu trừu tượng! Ôi! Chúa ơi, tôi vô tình tiết lộ – tôi già rồi sao? Hay tôi nên nghĩ tích cực hơn – đã có kinh nghiệm?

 

Leave a Reply