Tìm kiếm trên Google trên web, Agile Sages coi các trường hợp sử dụng và câu chuyện của người dùng là hai thứ khác nhau:

• Mike Cohn:  Câu chuyện của người dùng không phải là trường hợp sử dụng
• Alistair Cockburn:  Một câu chuyện của người dùng là một trường hợp sử dụng như một con linh dương là một vọng lâu
• Extreme Programming.org:  Các câu chuyện của người dùng phục vụ cùng mục đích với các trường hợp sử dụng nhưng không giống nhau.

Cách tiếp cận theo hướng trường hợp sử dụng là một trong những kỹ thuật phổ biến nhất để nắm bắt yêu cầu và một số người hiện nay coi nó là một loại kỹ thuật kiểu cũ, lỗi thời có liên quan đến nhiều vấn đề khiến nhóm của bạn KHÔNG “Nhanh nhẹn” do các vấn đề của trường hợp sử dụng :

• Yêu cầu trả trước – cố gắng xác định chi tiết của tất cả các khía cạnh của trả trước sẽ dẫn đến lãng phí nhiều công sức và thời gian vì phần lớn công việc sẽ cần phải được thực hiện lại.
• Phân rã chức năng: Bản chất chức năng của các ca sử dụng tự nhiên dẫn đến việc phân rã chức năng của một hệ thống về các ca sử dụng cụ thể và trừu tượng có liên quan với nhau bởi các phần mở rộng và bao gồm các liên kết ca sử dụng.

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

Điều thú vị là một số người thích nhận thức mọi thứ theo mô hình nhị phân và theo đuổi những thứ hợp thời trang bằng cách kết hợp với chúng một cách tượng trưng thay vì thực sự thực hành nó một cách chân chính. Một số người thậm chí không muốn cho người khác biết họ vẫn đang sử dụng các ca sử dụng, hoặc chúng có thể bị coi là lỗi thời và theo kiểu cũ.

Bây giờ một số người đặt dấu bằng liên quan đến câu chuyện người dùng và trường hợp người dùng:

• Agile = câu chuyện người dùng hoặc Agile = câu chuyện người dùng + Scrum
• Câu chuyện của người dùng = vừa đủ & vừa kịp
• Câu chuyện của người dùng = đáp ứng kỳ vọng của người dùng và thỏa mãn
• Use Case = Trả trước Yêu cầu chi tiết
• Trường hợp sử dụng = <<include>> + <<extends>> = phân rã chức năng
• Trường hợp sử dụng là kiểu chỉ “đầu vào của người dùng” -> kiểu chỉ “phản hồi hệ thống”
• Trường hợp sử dụng = kiểu cũ & lỗi thời

Là một nhà cung cấp công cụ, chúng tôi khá trung lập trong 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 tôi là một người hâm mộ lớn của phát triển Agile, câu chuyện người dùng và quy trình scrum. Đặc biệt, các nguyên tắc cơ bản và thực tiễn tốt nhất liên quan đến các khái niệm như:

• Phát hiện yêu cầu thay vì phân phối yêu cầu
• Theo nguyên tắc trên, mang lại hai đặc tính quan trọng trong quá trình phát triển Agile
  • Vừa kịp giờ
  • Vừa đủ

(Tôi sẽ viết nhiều bài hơn liên quan đến các nguyên tắc ở trên với ý kiến ​​của riêng tôi, có liên quan chặt chẽ đến lĩnh vực nghiên cứu Tiến sĩ của tôi trong năm 1992-1995 – phép biến đổi siêu mô hình & lược đồ)

Bây giờ, hãy quay lại chủ đề “use case và user story”. Chà, các nhà Agile có trọng lượng nặng đã bỏ phiếu cho điều đó, tôi có quá cố chấp cố gắng lật ngược “phiếu bầu của họ bằng cách tranh luận rằng họ giống nhau hoặc thậm chí giống nhau không?

Hãy để tôi cho bạn xem một ví dụ để minh họa liệu câu chuyện của người dùng có “quá khác” với trường hợp người dùng hay không:

Ví dụ

Những câu chuyện về người dùng tốt không 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 phần C.

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

Với tư cách là [vai trò], tôi muốn [làm điều gì đó], để [có lợi]

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

Cuộc trò chuyện là nội dung của chữ “C” thứ hai của câu chuyện người dùng thể hiện cuộc thảo luận giữa người dùng cuối, chủ dự án và nhóm phát triển. Trong quá trình chuyển đổi này, nó ghi lại 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, wireframe hoặc bất kỳ nội dung liên quan nào khác cho dự án.

Chữ “C” cuối cùng của 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 nhận rằng câu chuyện của người dùng được triển khai đã được sửa chữa và phân phối thành công.

Hãy để tôi trình bày kỹ hơn một chút về cách phát triển phần xác nhận của câu chuyện người dùng. Ở đây, chúng tôi sử dụng mẫu nổi tiếng nhất được gọi là Gherkin sử dụng công thức Cho trước Khi-Thì để hướng dẫn việc viết các bài kiểm tra chấp nhận cho Câu chuyện người dùng:

• (Cho .. và) một số ngữ cảnh
• (Khi .. và) một số 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ư khuôn khổ thử nghiệm Cucumber và Jbehave khuyến khích sử dụng khuôn mẫu Cho / Khi nào / Sau đó để tiến hành thử nghiệm 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 heuristic bất kể công cụ có được sử dụng hay không.

Hãy 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à đặt nó ở định dạng 3Cs:

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

Tương đương về ngữ nghĩa với các nghĩa khác nhau?

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

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

Trong UML, chúng ta có thể mô tả một kịch bản ca sử dụng bằng một biểu đồ trình tự, nhưng chúng ta thường không sử dụng một biểu đồ cộng tác cho cùng một mục đích; thậm chí thông qua cả hai sơ đồ là tương đương về mặt ngữ nghĩa. Nói cách khác, cả sơ đồ tuần tự và sơ đồ cộng 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 thông điệp truyền xung quanh cùng một nhóm đối tượng để thực hiện một nhiệm vụ của một kịch bản. Tuy nhiên, cái đầu tiên là tiêu điểm thời gian và cái sau là tiêu điểm không gian. Biểu đồ trình tự trực quan hơn khi sử dụng nó với mô hình kịch bản, trong khi biểu đồ cộng tác thích hợp để mô hình hóa mối quan hệ cấu trúc giữa các đối tượng. tức là bạn muốn biểu diễn kịch bản của đối tượng đã tham gia theo cấu trúc vào khung MVC (mô hình / khung nhìn và các lớp điều khiển).

Cá nhân tôi không nghĩ rằng việc sử dụng câu chuyện của người dùng sẽ làm cho nhóm của tôi trở nên nhanh nhẹn và trường hợp sử dụng sẽ khiến nhóm của tôi bị “trả giá trước”. Quan trọng nhất là cách chúng ta áp dụng và sử dụng những công cụ đó với tư duy và phương pháp hay nhất đằng sau. Tôi không quá lo lắng về việc mọi người coi tôi là “phong cách cũ” hay lỗi thời khi tôi thực sự hành động nhanh nhẹn.

Tôi vẫn nhớ trong những ngày phân tích và thiết kế có 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 thiết kế và phân tích hướng đối tượng mà không cần sự hỗ trợ của OOP năm 198x, phải không? Thật không may, bạn thậm chí có thể không bắt gặp các khái niệm về Kiểu dữ liệu trừu tượng! Ồ! Chúa ơi, tôi vô tình tiết lộ – Tôi già rồi? Hoặc, tôi nên suy nghĩ tích cực – có kinh nghiệm?

Bạn nghĩ sao? Phiếu bầu của bạn về điều này là gì? Hãy cho tôi biết hoặc sửa cho tôi nếu tôi sai.