Làm cách nào để xác định quy tắc kinh doanh phức tạp bằng Câu chuyện của người dùng?

Một định nghĩa nhanh và bẩn về Câu chuyện người dùng :

"As a <role>, I want <goal/desire> so that <benefit>"

Trong định nghĩa thường được chấp nhận này, có rất ít không gian để xác định quy tắc kinh doanh, các ràng buộc hoặc đầu vào của người dùng.

Ví dụ tầm thường chỉ để minh họa:

"As a <librarian>, I want to <register new books> so that
<students can find their availability online>"

Trong ví dụ ngớ ngẩn này, người ta sẽ xác định các trường cần thiết khi đăng ký sách ở đâu? Có nên viết ở bất cứ đâu? Hoặc các quy tắc kinh doanh bắt buộc phải được thông qua như lời nói của Chủ sở hữu sản phẩm?

Các lĩnh vực là một phần của cuộc trò chuyện nên có. Chúng có thể được viết ra nếu điều đó hữu ích nhưng đó là một lời kêu gọi phán xét. Giữ tài liệu cập nhật có thể là thách thức trong khi phần mềm làm việc có thể được coi là tài liệu ở một mức độ nào đó.

Câu chuyện của người dùng - Lời hứa sẽ có một cuộc trò chuyện sẽ là một mục blog về điều này.

Ví dụ tầm thường của bạn có một vài điểm mà tôi không biết bạn sẽ nhận thấy điều này tốt như thế nào. "Đăng ký sách mới có nghĩa là gì?" "Tìm sự sẵn có của họ trực tuyến là gì?" Đó là nơi cuộc trò chuyện bắt đầu và một khi câu chuyện được thực hiện, có thể có những câu chuyện mới vì có lẽ những đăng ký đó phải được lưu trong hồ sơ hoặc các báo cáo phải được tạo theo định kỳ.

Các câu trả lời trước cung cấp các điểm hợp lệ, đặc biệt liên quan đến câu chuyện của người dùng là một lời nhắc nhở để có một cuộc trò chuyện . Những điều khác cần xem xét:

1. Nếu câu chuyện là quá phức tạp, nó có thể là một thiên anh hùng ca . Bạn có thể chia sử thi thành các câu chuyện nhỏ hơn ngay bây giờ hoặc một khi chúng được ưu tiên trên hồ sơ tồn đọng của sản phẩm

2. Chi tiết ngụ ý các trường hợp thử nghiệm được tách ra khỏi câu chuyện. [ Mike Cohn ]

   Bạn có thể thêm vào mặt sau của thẻ câu chuyện, ghi chú nhỏ nếu chúng thực sự quan trọng hoặc đưa chúng vào tài liệu kiểm tra chấp nhận .

Là một hướng dẫn để đánh giá xem các câu chuyện của người dùng của bạn có tốt không, bạn có thể làm theo đề xuất của Bill Wake :

• Tôi phụ thuộc (của những câu chuyện khác)
• N vô nghĩa
• V có thể thay đổi (cho người dùng hoặc khách hàng)
• E kích thích (đến một xấp xỉ tốt)
• S mall (đủ để có thể ước tính)
• T estable

Bạn có thể muốn đọc te Chương 2 "Viết truyện" của cuốn sách Câu chuyện người dùng được áp dụng, bởi Mike Cohn.

Thông thường trên một câu chuyện bao gồm rộng rãi bao gồm nhiều khía cạnh, tôi cố gắng lấy ví dụ chung nhất về câu chuyện, và sau đó để biết cụ thể tôi tạo ra các câu chuyện người dùng con kế thừa từ nó. Nhiều công cụ quản lý dự án Agile như RallyDev cho phép bạn làm điều này một cách dễ dàng và tôi thấy nó có ý nghĩa.

Đăng ký sách mới rất rộng, vì vậy có lẽ có 10 câu chuyện người dùng trẻ em khác về cách <role>đăng ký sách.

Chi tiết cực đoan về những điều này hoặc chi tiết rìa kỳ quái tôi thường xác định trong một hoặc nhiều nhiệm vụ theo câu chuyện người dùng đó. Các tác vụ giúp xác định công việc phát triển và thiết kế nên được thực hiện (ở mức độ chung) để đáp ứng câu chuyện của người dùng đó (Ví dụ: Viết trình xác nhận để đảm bảo đầu vào trong trường mô tả dưới 50 ký tự ...) EDIT: Tôi chỉ muốn thêm rằng có lẽ tốt hơn là giữ các chi tiết cực đoan ra khỏi câu chuyện của người dùng vì có thể đó không phải là điều mà người dùng sẽ thực sự quan tâm nhiều. Người dùng muốn giải thích phần mềm theo thuật ngữ chung và họ phụ thuộc vào các nhà phát triển phần mềm để tìm ra và ẩn các chi tiết khỏi chúng.

Đây chỉ là cách tôi tiếp cận vấn đề nhưng tôi chắc chắn có một số cách khác nhau.

Câu trả lời rất đơn giản, kết hợp các quy tắc kinh doanh vào các tiêu chí chấp nhận.

Ví dụ tầm thường chỉ để minh họa:

Là một thủ thư, tôi muốn đăng ký sách mới, để sinh viên có thể tìm thấy sự sẵn có của họ trực tuyến

Tôi sẽ hài lòng khi: * Tôi có thể đăng ký các trường sau: - ISDN - Tác giả - Dewey Decimal blah blah * Tôi có thể thấy xác nhận sách đã được hệ thống đăng ký * Tôi có thể xem sách trong hệ thống

Làm cách nào để xác định quy tắc kinh doanh phức tạp bằng Câu chuyện của người dùng?

Đó không phải là những gì câu chuyện người dùng dành cho. Chúng không phải là yêu cầu phần mềm nắm bắt tất cả các chi tiết hoặc quy tắc kinh doanh cần thiết để viết việc thực hiện. Chúng chỉ là một mô tả về những gì ứng dụng nên làm theo quan điểm của người dùng.

Hãy nhớ những gì quan trọng: xây dựng phần mềm thích hợp. Bạn sử dụng bất cứ điều gì cần thiết để làm điều đó và các câu chuyện của người dùng chỉ để bạn đảm bảo rằng bạn đã thu thập các tính năng cần thiết mà ứng dụng cần có để sau đó bạn có thể nói về chúng, ưu tiên chúng, ước tính chúng, v.v. Phần còn thiếu từ người dùng cổ điển câu chuyện (như một ... tôi muốn ... vì vậy) là về giao tiếp giữa những người tham gia xây dựng phần mềm.

Có các chi tiết như tiêu chí chấp nhận, câu chuyện phụ, nhiệm vụ kỹ thuật gắn liền với câu chuyện của người dùng, trong tài liệu đặc tả hoặc bất cứ điều gì, vượt xa những gì câu chuyện người dùng giúp bạn. Nhóm người dùng chỉ là "chủ đề" của cuộc trò chuyện khi quyết định cách xây dựng phần mềm.

Trong ví dụ đưa ra, có nhiều chi tiết đăng ký sách mà các nhà phát triển di chuyển ít biết đến, chẳng hạn như Dewey hoặc các hệ thống phân loại khác, ISBN, số mua lại, bản sao / tiêu đề / tác giả, phiên bản khác, v.v. Đối với một hệ thống mới, các chi tiết như vậy phải được cung cấp bởi khách hàng (và một thủ thư, của tất cả mọi người, chắc chắn sẽ quan tâm đến họ).

Để trích dẫn Steve O'Connell, "Thật đáng sợ khi chiêm ngưỡng bao nhiêu chính sách kinh doanh được tạo ra bởi các nhà phát triển thiếu chi tiết cần thiết trong thông số kỹ thuật nên chỉ tự tạo ra nó."