Sự khác biệt giữa các câu chuyện và tính năng của người dùng là gì?

25

Chơi với icescrum , tôi nhận ra rằng tôi không hiểu sự khác biệt giữa các câu chuyện của người dùng và các tính năng của người dùng.

Ai đó có thể giải thích sự khác biệt?

agile scrum features

— Bовић
nguồn

23

Một tính năng là một yếu tố riêng biệt của chức năng có thể cung cấp khả năng cho doanh nghiệp.

Câu chuyện là một khía cạnh nhỏ của một tính năng mà bạn có thể sử dụng để nhận phản hồi từ các bên liên quan và tìm hiểu xem bạn có làm gì sai không.

Chẳng hạn, một tính năng có thể là "cho phép người dùng bình luận về bài viết". Những câu chuyện liên quan đến tính năng đó có thể là:

lưu ý kiến
lọc bình luận cho những từ thô lỗ
giới hạn nhận xét ở 400 ký tự và phản hồi lại cho người dùng
thêm captcha để ngăn chặn bot spam trang web
cho phép người dùng đăng nhập thông qua Google id

v.v.

Ở mỗi giai đoạn chúng ta có thể nhận phản hồi về việc liệu hướng đi chúng ta có hữu ích hay không.

Một số đội không bận tâm phân chia các tính năng thành các câu chuyện. Vậy là được rồi.

— Nguyệt thực
nguồn

13

Không phải những câu chuyện liên quan thực sự nhiệm vụ câu chuyện người dùng? Tôi muốn nói rằng họ là. Câu chuyện của người dùng sẽ là: Là người dùng, tôi muốn nhận xét về các bài viết để chúng tôi là người dùng có thể cải thiện nội dung bài viết hoặc bày tỏ mối quan tâm. Câu chuyện người dùng này sẽ được chia thành các nhiệm vụ mà bạn mô tả ...

— Robert Koritnik

4

Tôi coi một nhiệm vụ là một việc cần phải hoàn thành để nhận phản hồi, nhưng trên đó bạn không thể nhận phản hồi một mình - ví dụ: tạo bảng cơ sở dữ liệu. Bất kỳ câu chuyện nào trong số này, ngoại trừ câu chuyện đầu tiên, có khả năng có thể bị xóa trong khi vẫn để lại giá trị trong vận chuyển. Nhiệm vụ thường được cắt theo chiều ngang trong thế giới của tôi. Nhưng, nếu bạn có định nghĩa khác nhau, điều đó ổn. Độ chi tiết không phải là một thứ hoàn toàn rời rạc, mọi mục tiêu là một phần phụ của người khác và tôi nghĩ bạn nên làm bất cứ điều gì thực dụng cho bạn. Tôi thấy sự cố này hữu ích, cũng như nhiều đội của tôi.

— Lunivore

16

Tính năng == Câu chuyện của người dùng.

Verbiage được quyết định bởi phương pháp Agile đã cho đang được sử dụng.

Các phương pháp khác nhau sử dụng thuật ngữ khác nhau để chỉ các tính năng. Tùy thuộc vào nhóm để quyết định sử dụng phương pháp hoặc thuật ngữ nào. Lập trình cực đoan (XP) sử dụng thuật ngữ Câu chuyện người dùng hoặc Câu chuyện để thể hiện các tính năng; Scrum sử dụng Product Backlog để mô tả danh sách tính năng; Phát triển dựa trên tính năng sử dụng tính năng; và DSDM sử dụng Yêu cầu. Tương tự, có nhiều phiên bản nhẹ khác nhau của Quy trình hợp nhất hoặc Agile UP, sử dụng Yêu cầu và / hoặc Trường hợp sử dụng để xác định chức năng có thể phân phối tăng dần. Cuối cùng, mục tiêu là như nhau - cung cấp giá trị doanh nghiệp thường xuyên theo từng bước nhỏ và sớm hơn là sau này.

— Aaron McIver
nguồn

+1, điều này giải thích nó tốt. Tôi không nhất thiết phải nói tính năng == câu chuyện của người dùng, ngoại trừ khi bạn nói về giá trị doanh nghiệp hoặc giá trị khách hàng. Trong các trường hợp khác, thuật ngữ tương ứng có thể không có nghĩa.

— murrekatt

2

Tôi không nghĩ bạn có thể nói chúng giống nhau, ngay cả khi chúng là những thuật ngữ liên quan. Điều gì về các tính năng trải rộng một số câu chuyện của người dùng?

— sleske

@sleske Câu chuyện của người dùng theo cách tiếp cận Scrum thuần túy phải là giá trị gia tăng cho người dùng và do đó là một tính năng. Nếu chúng ta sẽ định danh mục các tính năng như bao quát Epics thì tốt nhưng kết quả cuối cùng là những câu chuyện của người dùng mang lại giá trị.

— Aaron McIver

1

@AaronMcIver: Vâng, đó là sự thật. Tuy nhiên, đôi khi số lượng chức năng thực sự hữu ích cho người dùng (= tính năng) là quá nhiều cho một câu chuyện của người dùng (hoặc thậm chí cho một lần lặp). Trong trường hợp đó, bạn phải chia tính năng thành nhiều câu chuyện.

— sleske

BTW, câu hỏi và câu trả lời liên quan: stackoverflow.com/questions/1714557/ cấp

— sleske

7

Một tài khoản Câu chuyện là một tuyên bố chính thức bằng ngôn ngữ của khách hàng mà nắm bắt được mục đích của cái gì đó mong muốn của khách hàng để đạt được. Bạn có thể nghĩ về Câu chuyện của người dùng như một Tuyên bố yêu cầu không chính thức.

Một tính năng phần mềm là một đặc tính riêng biệt của phần mềm đó góp phần vào việc thiết kế tổng thể và chức năng của phần mềm.

Một vài cân nhắc chính:

Một câu chuyện có thể mô tả một tính năng , nhưng một tính năng không bao giờ mô tả một câu chuyện .
Một câu chuyện có thể không trực tiếp mô tả một tính năng .
Một câu chuyện có thể ngụ ý bao gồm một số tính năng .
Một Tính năng - đơn lẻ hoặc là thành viên của bộ sưu tập Tính năng - có thể nắm bắt được ý định của Câu chuyện .

Với tất cả những điều này, tôi có xu hướng nghĩ về Câu chuyện như những mô tả. Về cơ bản các yêu cầu không chính thức cho tôi biết khách hàng muốn gì. Mặt khác, tôi có xu hướng nghĩ nhiều hơn như một đặc điểm kỹ thuật cho tôi biết hệ thống nên hoạt động như thế nào để đáp ứng yêu cầu của khách hàng.

— S.Robin
nguồn

3

Hai thuật ngữ có liên quan chặt chẽ, nhưng có một số khác biệt.

Đầu tiên, họ đến từ các lĩnh vực khác nhau. Thuật ngữ "tính năng" là một thuật ngữ khá chung cho một số chức năng của phần mềm, trong khi "câu chuyện người dùng" được phát minh ra và thực sự chỉ được sử dụng trong bối cảnh phát triển phần mềm nhanh.

Trong thực tế, chúng rất thường trùng nhau, trong đó một câu chuyện người dùng bao gồm thực hiện một tính năng nhất định.

Tuy nhiên, trong một số tình huống, chúng có thể khác nhau:

Thông thường, một tính năng là quá nhiều công việc cho một câu chuyện người dùng. Câu chuyện của người dùng không nên quá lớn (thường không quá vài ngày, tối đa 1-2 tuần làm việc). Rõ ràng nhiều tính năng lớn hơn nhiều. Trong trường hợp đó, một tính năng sẽ được triển khai trên nhiều câu chuyện của người dùng. Một số người sử dụng "sử thi" để nhóm các câu chuyện của người dùng lại với nhau, trong trường hợp đó bạn có thể nói rằng tính năng này là một thiên anh hùng ca.
Các yêu cầu phi chức năng (hiệu suất, bảo mật, khả năng tương thích, v.v.) cũng có thể được xử lý dưới dạng câu chuyện của người dùng (mặc dù điều này không được chấp nhận phổ biến). Trong trường hợp đó, kết quả của câu chuyện người dùng thường không được gọi là một tính năng (trừ khi bạn gọi "ứng dụng của chúng tôi hiếm khi gặp sự cố" một tính năng).

— sleske
nguồn