Làm cách nào để tôi phác thảo câu chuyện của người dùng với tư cách là nhà phát triển?

Tôi đang viết một hệ thống mà cả chủ sở hữu hệ thống và bản thân tôi đều là nhà phát triển và chúng tôi hiện là nguồn 'yêu cầu' hoặc yêu cầu duy nhất cho hệ thống, mà tôi muốn ghi lại trong các câu chuyện của người dùng gắn với các tính năng {1}. Ưu tiên cấp bách của tôi bây giờ là có được một hồ sơ quản lý tồn đọng. Làm thế nào tôi nên nắm bắt mức độ của thông số kỹ thuật mà tôi đã từng làm việc với các câu chuyện của người dùng, vốn không được coi là quá kỹ thuật.

{1} Tôi đang đánh giá dịch vụ quản lý dự án nhanh nhẹn TargetProcess và mỗi câu chuyện của người dùng phải được gắn với một tính năng chính. Hệ thống có vẻ phù hợp, vì vậy hạn chế nhỏ này là thứ tôi thích làm việc hơn là làm việc xung quanh.

Mẫu câu chuyện điển hình rất dễ hình dung:

As a [ROLE] I need to [WHAT] so that/because [WHY].

Điều thú vị là tầm quan trọng của các thành phần được đảo ngược.

TẠI SAO quan trọng hơn CÁI GÌ và điều đó quan trọng hơn VAI TRÒ

Ví dụ sử dụng Câu hỏi này

Là một nhà phát triển phần mềm, tôi cần học cách viết Câu chuyện người dùng để tôi có thể điền vào các bản tồn đọng bằng các bản nháp để bắt đầu thảo luận về các tính năng và nhận điểm được gán cho chúng.

Bất cứ điều gì nhiều hơn là làm phức tạp ý định và việc thực hiện Câu chuyện của người dùng.

Công cụ bổ sung (Tích hợp là tốt nhất)

Các công cụ có thể được sử dụng để nắm bắt thông tin chi tiết bổ sung về các câu chuyện được ghi lại khi thảo luận về chúng để gán điểm / ước tính, nhưng chi tiết đó không phải là một phần của chính câu chuyện. Một cái gì đó đơn giản như một Wiki với 1 Trang cho mỗi câu chuyện để đặt chi tiết / bảng điểm các cuộc thảo luận là một giải pháp đủ tốt. Bảng tính Excel là một giải pháp khủng khiếp.

Tập trung vào những gì và tại sao và tránh làm thế nào khi viết câu chuyện của người dùng.

Những gì bạn phải đối mặt thực sự là một bài tập rất tốt cho tất cả các nhà phát triển. Có thể diễn đạt yêu cầu một cách đơn giản, kinh doanh là một kỹ năng quan trọng.

Bạn nên tập trung vào yêu cầu chung như "cần có thể thực hiện một lựa chọn duy nhất từ ​​danh sách các đối tượng thả xuống để người dùng có thể kích hoạt hành động Foo" thay vì chỉ định sử dụng combobox hoặc listbox hoặc bất cứ điều gì kích hoạt một thói quen cụ thể .

Một cách khác để tiếp cận điều này là giả vờ như cơ sở / khung mã cơ bản gần như hoàn thành hộp đen. Bất cứ khi nào bạn thấy mình nói "sử dụng đối tượng XYZ", bạn có thể tự kiểm tra bằng cách hỏi xem bạn có biết điều đó trong hệ thống hộp đen không.

Cập nhật:
IMO, bạn có thể đưa chi tiết vào trường hợp sử dụng cho biết mức độ chi tiết cần thiết cho thông tin. Ví dụ: với một hệ thống tuyển sinh, trò chơi công bằng để chỉ định
- họ; trường bắt buộc
- tên đầu tiên; trường bắt buộc
- ID tài khoản; hệ thống tạo ra không cần thiết đầu vào
- dấu hiệu chiêm tinh; trường tùy chọn - (gợi ý) cung cấp tra cứu từ ngày sinh?
- Vân vân....

Điều quan trọng là bạn không chỉ định kỹ thuật làm thế nào cho thông tin đó. Nếu bạn thấy mình nói "sử dụng một lớp Chuỗi / mảng ký tự / hoặc trường varchar" cho tên cuối cùng, thì bạn biết bạn đang chỉ định quá mức.

Nếu bạn là người đa ngôn ngữ, thì hãy sử dụng hai ngôn ngữ khác nhau làm bài kiểm tra giấy quỳ của bạn. Ví dụ, các chuỗi trong C thường là các mảng char (acter) trong khi C ++, Java và C # (được, và hầu hết mọi người khác ...) có một đối tượng như Chuỗi thực tế. Nếu bạn thấy rằng thông số kỹ thuật của bạn bị vô hiệu bằng cách sử dụng một trong những ngôn ngữ đó thì bạn sẽ biết bạn đã chỉ định quá mức.

Điều đáng chú ý là tôi đặc biệt sử dụng thuật ngữ Use Case trái ngược với Câu chuyện của người dùng , mặc dù biến thể mà tôi kết thúc sử dụng là sự kết hợp của cả hai. Mục tiêu của tôi về trường hợp sử dụng là đưa ra một cái nhìn tổng quan về những gì đang diễn ra (Câu chuyện người dùng theo nghĩa chặt chẽ nhất) nhưng sau đó làm việc thông qua các tác nhân, hệ thống và chức năng chung cần có. Cách tiếp cận của tôi gần hơn với những gì Fowler đang đề xuất trong bài viết trên wikipedia đó trái ngược với cách tiếp cận của Cockburn.

Vì vậy, tôi sẽ có một trường hợp sử dụng (hoặc hơn) cho kịch bản đăng ký hoặc mục công việc. Nếu nó thực sự phức tạp, tôi sẽ chia nó thành nhiều phần, nhưng đó không phải là vấn đề lớn. Ca sử dụng sau đó có thể được chia thành các nhiệm vụ riêng lẻ khi cần thiết. Những gì được đưa vào một scrum cụ thể phụ thuộc vào rất nhiều biến số, nhưng không có gì trong phương pháp này ngăn bạn có một thành phần sai lệch ở cuối scrum.