Những loại câu chuyện người dùng nên được viết trong giai đoạn đầu của một dự án?

Khi chỉ bắt đầu một dự án, bạn không có gì --- không có UI, không có lớp dữ liệu, không có gì ở giữa. Do đó, một câu chuyện như "người dùng sẽ có thể xem foos của họ" sẽ đòi hỏi rất nhiều công việc. Khi bạn có câu chuyện đó, một câu như "người dùng sẽ có thể chỉnh sửa foos" của họ thực tế hơn, nhưng câu chuyện đầu tiên sẽ liên quan đến việc thiết lập lớp UI, lớp logic trình bày, lớp logic miền và lớp truy cập dữ liệu.

Điều này không phù hợp với khái niệm "nhiệm vụ" của tôi: với tôi, tôi muốn có một cái gì đó giống như "nhiệm vụ" sau:

• Hiển thị dữ liệu giả cho các foos của người dùng trong HTML, xuất phát từ các đối tượng JavaScript.
• Thiết lập lớp logic trình bày và kết nối các đối tượng JavaScript với nó.
• Thiết lập lớp logic miền và kết nối lớp logic trình bày với nó.
• Thiết lập lớp truy cập dữ liệu và kết nối lớp logic miền với nó.

Có phải tất cả những điều này thuộc "câu chuyện" duy nhất ở trên? Nếu vậy, tôi cảm thấy như những câu chuyện không phải là một khuôn khổ hữu ích khủng khiếp trong giai đoạn đầu của một dự án. Nếu vậy, điều đó tốt thôi --- Tôi chỉ muốn chắc chắn rằng tôi không thiếu thứ gì, vì tôi thực sự đang cố gắng học phương pháp nhanh nhẹn này một cách tốt nhất có thể.

Đây là một câu hỏi hay và có lẽ có một số câu trả lời tốt cho nó. Của tôi là thế này:

Câu chuyện là một câu chuyện của người dùng vì vậy nó phải được xác định theo thuật ngữ mô tả cách nó mang lại lợi ích cho người dùng.

Nếu Agile và các câu chuyện sẽ làm việc cho bạn, thì chúng nên hoạt động ngay cả trong giai đoạn đầu. Điểm đầu tiên là một câu chuyện người dùng (mặc dù có một chút công nghệ-y), nhưng ba câu chuyện còn lại là các mô tả nhiệm vụ kỹ thuật.

Trong giai đoạn đầu của một dự án, khi bạn không có các khung thích hợp để tạo CRUD ( C reate, R ead, U pdate, D elete) phát triển nhanh chóng và dễ dàng, các câu chuyện của bạn cần phải nhỏ hơn, tăng dần miếng.

Thay vì "Người dùng sẽ có thể xem foo của họ" , đại loại như thế này:

1. Người dùng sẽ có thể thấy một trang với dữ liệu mẫu
2. Người dùng sẽ có thể thấy một trang có dữ liệu mẫu tương tác
3. Người dùng sẽ có thể thấy một trang có dữ liệu mẫu tương tác trực tiếp

Hãy nhớ rằng hầu hết các câu chuyện của người dùng dường như quá lớn để phát triển trong một lần chạy nước rút (tôi đã thấy rằng bất cứ điều gì lớn hơn khoảng 8 điểm câu chuyện, hoặc ngày phát triển, quá lớn) có thể được chia thành các phần vẫn có ý nghĩa người dùng.

Câu chuyện / tính năng không phải là thị trường, nó chỉ có ý nghĩa đối với chủ sở hữu sản phẩm. Trong trường hợp trên, bạn có thể đưa vào một số bản demo nhanh để hiển thị những gì đã thay đổi và câu chuyện đó được thực hiện như thế nào - ví dụ, đối với # 3, bạn có thể hiển thị trang cho hai người dùng khác nhau với dữ liệu được điền trước trong cơ sở dữ liệu . Ở giai đoạn # 2, tất cả người dùng sẽ thấy cùng một dữ liệu.

Những gì bạn đang hỏi là rất cần thiết "bạn nghĩ như thế nào về không gian vấn đề" để chia nó thành những phần hợp lý, từ đó bạn có thể thực hiện một thiết kế.

Cho dù bạn gọi đây là câu chuyện của người dùng, hoặc phân tích, hoặc phân tách, hoặc đặc tả hoặc thu thập các yêu cầu ... cuối cùng, nó sẽ dẫn đến một số điều mà thông thường sẽ có một số lần lặp.

Bạn cần nhận được từ người dùng những gì họ muốn. (Họ có thể biết một số thứ họ muốn và muốn những thứ không nhất quán nhưng chưa thể thấy điều đó.)

Bạn cần nắm bắt điều này dưới một số hình thức - bạn thực sự chỉ có 2 lựa chọn: từ hoặc hình ảnh. Cả hai đều có sức mạnh, sử dụng cả hai nếu bạn có thể. Từ ngữ cuối cùng mạnh mẽ hơn từ quan điểm của một tranh chấp hợp đồng sau này.

Bạn cần phải trình bày lại và tìm kiếm thỏa thuận.

Một số người làm nguyên mẫu trực quan sớm mà không có kinh doanh hoặc logic khác phía sau. Đây có thể là một kỹ thuật mạnh mẽ - lên đến một điểm vì nó vẫn liên quan đến một số lần vẫy tay nhất định.

Một số sẽ kể chuyện - và sau đó trình bày và giải thích.

Một số sẽ viết các tài liệu nghiêm ngặt và phân tích cẩn thận.

Mỗi kỹ thuật đều có ưu điểm và nhược điểm.

Về lời khuyên duy nhất tôi đưa ra là: Việc tham gia viết mã giải pháp quá sớm thường là một động thái tồi tệ. Hiểu những gì cần làm, đối với WHO và TẠI SAO, trước khi bạn làm điều đó thường dẫn đến việc làm lại ít hơn và phát triển nhanh hơn.

Khi bạn nói về "nhiệm vụ", điều này đối với tôi giống như một sự phá vỡ công việc, đã tìm ra những điều trên, ai và tại sao. Bạn không thể tìm ra các nhiệm vụ WELL cho đến khi bạn hiểu được câu chuyện của người dùng, trong một tài liệu, được khách hàng chấp thuận là phạm vi công việc bạn sẽ làm. Biết những gì bạn phải đạt được (đầu ra) cho phép bạn tìm ra các nhiệm vụ (các bước liên quan đến việc đạt được điều đó).

Đừng bỏ qua việc phân tích và tài liệu phân tích mặt trước.

Tôi nghĩ những gì bạn đang thiếu là những câu chuyện của người dùng là về việc mô tả cách người dùng mong đợi sử dụng hệ thống. Đây là một cách để xác định các yêu cầu kinh doanh . Chúng không được thiết kế để trực tiếp cho bạn biết phải làm gì về mặt kỹ thuật, đó là những gì bạn dường như đang muốn.

Đây được cho là một trong những phần quan trọng nhất của một dự án. Nếu bạn không nhận được các yêu cầu nghiệp vụ chính xác thì hệ thống sẽ không được sử dụng cho người dùng.