Mối quan hệ giữa câu chuyện của người dùng, tính năng và sử thi?


111

Là một người vẫn còn mới với sự nhanh nhẹn, tôi không chắc mình hoàn toàn hiểu mối quan hệ hoặc sự khác biệt giữa câu chuyện của người dùng, tính năng và sử thi.

Theo câu hỏi này , một tính năng là một tập hợp các câu chuyện. Một trong những câu trả lời cho thấy một tính năng thực sự là một bản anh hùng ca. Vì vậy, các tính năng và sử thi được coi là cùng một điều, về cơ bản đó là một tập hợp các câu chuyện người dùng liên quan?

Người quản lý dự án của chúng tôi khẳng định rằng có một cấu trúc phân cấp:

Sử thi -> Tính năng -> Câu chuyện của người dùng

Và về cơ bản, tất cả các câu chuyện của người dùng phải nằm trong cấu trúc này. Do đó, tất cả các câu chuyện của người dùng phải thuộc một tính năng ô và tất cả các tính năng phải thuộc một sử thi.

Đối với tôi, điều đó nghe thật khó xử. Ai đó có thể vui lòng làm rõ các câu chuyện, tính năng và sử thi của người dùng có liên quan như thế nào không? Hoặc có một bài viết nêu rõ sự khác biệt?


15
Câu trả lời thực sự duy nhất cho điều này là "không có câu trả lời dứt khoát". Mỗi cá nhân / công ty giải thích là hơi khác nhau. Đối với tôi, các tính năng và câu chuyện của người dùng là như nhau, những người khác có thể tạo ra sự khác biệt (mà đối với tôi có vẻ ngớ ngẩn), nhưng không phải là đúng hay sai. Tôi không nghĩ bất cứ ai trên trái đất có thể nói với bạn một cách dứt khoát, "đây là một thiên anh hùng ca, đây là một câu chuyện, đây là một tính năng" ... mặc dù nhiều người sẽ cố gắng!
MattDavey

Tôi không đồng ý. Một tính năng KHÔNG phải là câu chuyện của người dùng, trong khi sử thi là câu chuyện của người dùng. Một ví dụ về giao diện của một tính năng là "thanh toán qua paypal". Trong khi một câu chuyện người dùng mẫu là, với tư cách là một khách hàng trên iPhone, tôi muốn mua một cái búa và thanh toán bằng tài khoản paypal của mình để tôi không phải nhập thông tin thẻ tín dụng của mình. Hơn nữa, tôi sẽ coi câu chuyện đó là một Sử thi vì sẽ mất hơn một ngày để thực hiện nó.
Joey Guerra

3
@JoeyGuerra Cách chúng tôi sử dụng các thuật ngữ đó, bạn chỉ cần viết 1 câu chuyện người dùng sẽ dẫn đến 1 tính năng. Chúng tôi hoàn toàn không sử dụng "sử thi", nhưng từ bao quát của chúng tôi là "dự án" - trong đó, để mở rộng ví dụ của bạn, sẽ liên quan đến giỏ mua hàng và tất cả các hình thức thanh toán (và có thể có nhiều phần liên quan hơn).
Izkata

Câu trả lời:


93

Họ là thuật ngữ rất chung chung thực sự. Có nhiều cách để giải thích chúng, khác nhau trong tài liệu và cách mọi người nhìn thấy chúng. Lấy tất cả mọi thứ tôi nói với một hạt muối khổng lồ.

Thông thường, một Epic bao gồm một chức năng rất toàn cầu và không được xác định rõ ràng trong phần mềm của bạn. Nó rất rộng. Nó thường sẽ được chia thành câu chuyện hoặc tính năng người dùng nhỏ hơn khi bạn cố gắng hiểu ý nghĩa của nó và làm cho chúng phù hợp với một lần lặp nhanh. Thí dụ :

Sử thi
- Cho phép khách hàng quản lý tài khoản của mình thông qua Web

Tính năng và Câu chuyện người dùng là chức năng cụ thể hơn, mà bạn có thể dễ dàng kiểm tra bằng các bài kiểm tra chấp nhận. Chúng tôi thường khuyên rằng chúng đủ nhỏ để phù hợp với một lần lặp duy nhất.

Các tính năng thường có xu hướng mô tả những gì phần mềm của bạn làm:

Tính năng
- Chỉnh sửa thông tin khách hàng qua cổng web

Câu chuyện của người dùng có xu hướng thể hiện những gì người dùng muốn làm:

Câu chuyện người dùng
Là nhân viên ngân hàng,
tôi muốn có thể sửa đổi thông tin khách hàng
để tôi có thể cập nhật thông tin.

Tôi không nghĩ thực sự có một hệ thống phân cấp giữa hai thứ này, nhưng bạn có thể có một thứ nếu bạn muốn hoặc nếu nó phù hợp với cách bạn làm việc. Câu chuyện của người dùng có thể là một lời biện minh cụ thể cho một tính năng hoặc một cách cụ thể để thực hiện nó. Hoặc nó có thể là cách khác xung quanh. Một tính năng có thể là một cách để nhận ra một câu chuyện người dùng. Hoặc họ có thể biểu thị điều tương tự. Bạn có thể sử dụng cả hai: Câu chuyện của người dùng để xác định những gì mang lại giá trị và tính năng kinh doanh để mô tả sự hạn chế của phần mềm.

Câu chuyện của người dùng : với tư cách là một khách hàng, tôi muốn thanh toán bằng các thẻ tín dụng phổ biến nhất
Tính năng hỗ trợ API XML GOV-TAX-02 của chính phủ.

Ngoài ra còn có câu hỏi về kịch bản, thường là cách một câu chuyện Tính năng / Người dùng sẽ được thực thi. Họ thường lập bản đồ sạch sẽ đến một bài kiểm tra chấp nhận cụ thể. Ví dụ

Kịch bản : Rút tiền
Cho tôi có 2000 đô la trong tài khoản ngân hàng của tôi
Khi tôi rút 100 đô la
Sau đó tôi nhận được 100 đô la tiền mặt
và số dư của tôi là 1900 đô la

Đó là cách chúng tôi xác định những điều khoản nơi tôi làm việc . Những định nghĩa khác xa với một định nghĩa toán học hoặc một thuật ngữ được tiêu chuẩn hóa. Nó giống như sự khác biệt giữa một chính trị gia cánh phải hoặc một chính trị gia cánh trái. Nó phụ thuộc vào nơi bạn sống. Ở Canada, những gì được coi là cánh phải có thể được coi là cánh trái ở Hoa Kỳ. Nó rất khác nhau.

Nghiêm túc mà nói, tôi sẽ không lo lắng quá nhiều về nó. Điều quan trọng là mọi người trong nhóm đồng ý về một định nghĩa để bạn có thể hiểu nhau. Một số phương pháp như scrum có xu hướng xác định chúng chính thức hơn, nhưng chọn những gì phù hợp với bạn và bỏ phần còn lại. Rốt cuộc, không nhanh nhẹn về Cá nhân và tương tác qua các quy trình và công cụPhần mềm làm việc trên tài liệu toàn diện ?


17
+1 cho "Điều quan trọng là mọi người trong nhóm đồng ý về một định nghĩa"
MattDavey

Trường hợp sử dụng sẽ phù hợp với hệ thống phân cấp này?
Renegrin

Điều này phụ thuộc vào cách bạn xác định trường hợp sử dụng trong nhóm của mình. Hãy giả sử kiểu RUP của trường hợp sử dụng. Trong trường hợp đó, ca sử dụng sẽ đóng vai trò của cả kịch bản và câu chuyện, trộn lẫn cả hai, và do đó, trong RUP, các yêu cầu phần mềm chỉ được chỉ định trong trường hợp sử dụng. Hãy tự hỏi: một câu chuyện nên gì? Và trường hợp sử dụng nên gì? Bạn có cần cả hai? tại sao? Cá nhân, tôi sẽ sử dụng câu chuyện hoặc trường hợp sử dụng, nhưng không phải cả hai, bởi vì chúng có cùng một mục tiêu. Tuy nhiên, nó luôn luôn phụ thuộc. Nếu bạn có một vai trò cho mỗi, hãy sử dụng từng vai trò; nếu không, hãy sử dụng cái bạn biết :).
Laurent Bourgault-Roy

1
Ngoài ra, tôi đã làm việc là bạn sẽ không bao giờ hoàn thành mọi thứ bạn xác định trong một Epic. Một số câu chuyện của người dùng bên dưới sẽ không được đưa lên đầu trang tồn đọng.
itj

2
Đây chỉ là những mô tả về vấn đề cần giải quyết ở các độ cao khác nhau. Sử thi có ý nghĩa cho quản lý cấp trên. Các tính năng là những gì các nhà tiếp thị muốn sử thi cung cấp. Quan điểm này làm việc cho các nhà quản lý cấp trung. Câu chuyện của người dùng phá vỡ công việc cho những người phải tạo ra giải pháp, cho các nhà phát triển và quản lý cấp thấp.
rfportilla

36

Sử thi : Một câu chuyện người dùng rất lớn cuối cùng được chia thành các câu chuyện nhỏ hơn.

Câu chuyện của người dùng: Một định nghĩa cấp cao về một yêu cầu, chỉ chứa đủ thông tin để các nhà phát triển có thể đưa ra ước tính hợp lý về nỗ lực thực hiện nó.

http://www.telerik.com/agile-project-manloyment-tools/agile-resource/vocellect.aspx

Tính năng : Một đặc điểm hoặc khả năng phân biệt của một ứng dụng hoặc thư viện phần mềm (ví dụ: hiệu suất, tính di động hoặc chức năng).

http://en.wikipedia.org/wiki/Software_feature


26

Tôi cảnh báo bạn không nên áp dụng một hệ thống phân cấp quá cứng nhắc cho các điều khoản này. Chúng tôi đã cố gắng làm điều đó trong công việc trước đây của tôi. Hai lần. Cả hai lần thử đều khác nhau và cả hai lần chúng tôi thấy chúng tôi đã giới hạn bản thân một cách không cần thiết. Hằng số duy nhất là định nghĩa của Câu chuyện người dùng . Từ góc độ quy hoạch, một câu chuyện là khối xây dựng cơ bản của một dự án. Các thuật ngữ lớn hơn (sử thi, tính năng, v.v.) thực sự chỉ là các thẻ . Thẻ là một cách dễ dàng để cho phép một câu chuyện tồn tại như một phần của nhiều Epics và nhiều Tính năng cùng một lúc. Không đáng để nỗ lực tinh thần nghiêm khắc hơn thế.

Thẻ hoạt động cho Stack Exchange và chúng cũng có thể làm việc cho bạn.


1
Chính xác. Tôi nhấp vào câu hỏi này với hy vọng tôi có thể tìm thấy câu trả lời như thế này.
Zimano

23

Cách chúng tôi làm việc với Epics, Câu chuyện và Tính năng như sau

Đầu chu kỳ dự án, chúng tôi đến với Epics . Đây là những điểm rất cao, gần như là trung tâm tiếp thị, điểm nhấn của chức năng. Loại điều bạn có thể sử dụng trong bản tóm tắt điều hành, chẳng hạn như,

Trang web mới của chúng tôi sẽ cho phép khách hàng duyệt sản phẩm, xem tính khả dụng và giá cả, đặt hàng và xem lịch sử đặt hàng trước đây của họ

Điều này dẫn đến các sử thi như

  • Duyệt qua danh mục sản phẩm
  • Xem sẵn có
  • Xem giá
  • Đặt hàng
  • Xem lịch sử đặt hàng

Chúng được viết dưới dạng câu chuyện của người dùng (ví dụ: Là một khách hàng, tôi muốn duyệt qua danh mục sản phẩm, để tôi có thể đưa ra quyết định mua hàng sáng suốt), nhưng chỉ đóng vai trò là người khởi đầu cho mười cho những gì sẽ thực sự được phát triển và phát hành.

Những sử thi này sau đó được chia nhỏ thành Câu chuyện người dùng . Đây là những hành trình người dùng từ đầu đến cuối thực tế, rất hạn chế về phạm vi và được xác định theo cách có thể ước tính và lập kế hoạch độc lập, được phát triển , thử nghiệmphát hành trong một chu kỳ phát hành.

Câu chuyện người dùng là đơn vị giao hàng. Đó là câu chuyện của người dùng đã hoàn thành hoặc chưa hoàn thành, phát trực tiếp hoặc không phát hành trực tuyến.

Một Epic có thể dẫn đến một số lượng lớn các câu chuyện của người dùng, không phải tất cả sẽ được phát triển hoặc phát hành cùng một lúc.

Ví dụ, sử thi Danh mục sản phẩm có thể được chia thành

  • Điều hướng phân cấp danh mục
  • Tìm kiếm bằng từ khóa
  • Lọc theo các thuộc tính sản phẩm (ví dụ: phạm vi giá, nhãn hiệu, màu sắc, kích thước, v.v.)

Một lần nữa, mỗi trong số này sẽ được viết theo định dạng, ví dụ như là một khách hàng, tôi muốn điều hướng phân cấp danh mục, để tôi có thể duyệt các sản phẩm và đi sâu vào sản phẩm phù hợp nhất với nhu cầu của mình.

Nói chung, đối với hầu hết các dự án của chúng tôi, chúng tôi có hàng chục sử thi và hàng trăm câu chuyện.

Bây giờ, khi chúng ta trải qua vòng đời câu chuyện, chúng ta gắn thẻ những câu chuyện này với Feature s. Ví dụ: tất cả các câu chuyện duyệt và tìm kiếm và chứng khoán và giá cả sẽ được gắn thẻ, giả sử, 'danh mục sản phẩm'. Đặt câu chuyện để thực hiện thanh toán bằng Thẻ tín dụng có thể được gắn thẻ 'thẻ tín dụng' và những câu chuyện cần thanh toán bằng PayPal sẽ được gắn thẻ 'paypal'.

Các nhãn này dùng để nhóm các câu chuyện thuộc về nhau, không phải vì chúng là các loại khác nhau thực hiện cùng một hoạt động (ví dụ: tất cả các câu chuyện theo thứ tự địa điểm) mà vì chúng phải được phát hành cùng nhau.

Ví dụ: câu chuyện "đặt hàng thanh toán bằng thẻ tín dụng" thuộc cùng một sử thi như câu chuyện "đặt hàng thanh toán bằng PayPal", nhưng chúng không cần phải được phát hành cùng nhau.

Trong khi đó, câu chuyện "đặt hàng thanh toán bằng thẻ tín dụng", câu chuyện "xử lý hoàn trả vào thẻ tín dụng" và câu chuyện "cho phép khách hàng quản lý thẻ tín dụng đã lưu trên tài khoản của họ" dường như thuộc về nhau . Tất cả chúng sẽ được gắn thẻ với nhãn tính năng 'thẻ tín dụng'. tức là tất cả chúng sẽ thuộc về tính năng "Thẻ tín dụng". Sẽ không hữu ích lắm khi giải phóng khả năng đặt hàng thanh toán bằng Thẻ tín dụng, nếu không thể xử lý hoàn trả lại cho PayPal hoặc nếu không thể quản lý Thẻ tín dụng đã lưu trên tài khoản của bạn

Lưu ý : Như một quy tắc chung, đó là. Cuối cùng, đây là một quyết định kinh doanh. Nếu thời gian tiếp thị là quan trọng, có thể có một lý do chính đáng để sống với một trong những thứ này chứ không phải cái kia.

Do đó, Epics phục vụ để chia thành các câu chuyện (có liên quan, nhưng riêng biệt) có thể được phát triển độc lập, trong khi các Tính năng phục vụ để nhóm các câu chuyện nên được phát hành cùng nhau.

Bạn có thể nói rằng Epics phân rã thành Câu chuyện của người dùng và Câu chuyện của người dùng được sáng tác thành các Tính năng. Những câu chuyện thuộc về một tính năng thường là trên Epics. Do đó, Epics và Feature là trực giao, không theo một hệ thống phân cấp chặt chẽ.

Theo cách làm việc của chúng tôi, một khi các sử thi đã được chia thành các câu chuyện, họ mất mục đích của họ. Chúng tôi không ước tính, hoặc lập kế hoạch sử thi. Chúng tôi không theo dõi tiến trình trên Epics. Chúng tôi không phát hành Epics. Chúng tôi ước tính, lập kế hoạch và theo dõi Câu chuyện của người dùng. Và chúng tôi phát hành Tính năng.


4
"... Vì vậy, Epics phục vụ để phân chia thành các câu chuyện (có liên quan, nhưng riêng biệt) có thể được phát triển độc lập, trong khi các Tính năng phục vụ để nhóm các câu chuyện nên được phát hành cùng nhau ..." Khoảnh khắc của Eureka !!
Henry Rodriguez

Bài đăng này xứng đáng nhiều ngón tay cái lên! Thanh danh!
Goo Sơn

10

Tôi đồng ý như nhiều câu trả lời rằng thực sự không có câu trả lời đúng vì đây chỉ là những thuật ngữ có thể thay đổi tùy thuộc vào trại Agile mà bạn dựa vào và bạn chắc chắn có thể tạo nên trại của mình miễn là mọi người trong nhóm của bạn bao gồm cả các bên liên quan bên ngoài hiểu ý nghĩa của chúng Nó chỉ là một cách tổ chức yêu cầu của bạn.

Câu trả lời tôi thích là từ trại của Mike Cohn và nó khá đơn giản.

http://www.mountaingoatsoftware.com/blog/stories-epics-and-theme

  • Sử thi chỉ là một Câu chuyện lớn (phân cấp)
  • Chủ đề chỉ là một nhóm Câu chuyện (khá giống thẻ)

Ông thực sự tránh thuật ngữ "Tính năng". Tôi cho rằng đó chủ yếu là vì đó là một thuật ngữ phổ biến trong thế giới thác nước truyền thống. Nhiều trại Agile có xu hướng sử dụng các thuật ngữ khác nhau để nhấn mạnh sự khác biệt.

Vì vậy, theo định nghĩa của PM của bạn, Feature nằm ở đâu đó ở giữa hệ thống phân cấp của Epic-Story.

Đây là thông tin đồ họa của tôi về định nghĩa này từ bài viết InfoQ của tôi http://www.infoq.com/articles/visualize-big-picture-agile ;-)

nhập mô tả hình ảnh ở đây


6

Các tính năng và sử thi không giống nhau.

  • Một tính năng không phải là một câu chuyện người dùng.
  • Một sử thi là một câu chuyện người dùng.
  • Câu chuyện người dùng có thể là một sử thi.
  • Câu chuyện người dùng có thể chứa nhiều tính năng.
  • Một tính năng có thể đáp ứng 1 đến nhiều Câu chuyện của người dùng.

Trong các giai đoạn lập kế hoạch, các cuộc thảo luận dẫn đến Câu chuyện người dùng được xác định là điển hình vì Epics vì nỗ lực thực hiện các giải pháp cho chúng là quá lớn để hoàn thành trong vài ngày. Tính năng sản phẩm được xác định trong giai đoạn này. Nhưng đó chỉ là sản phẩm phụ của cuộc thảo luận. Các tính năng sau đó được sử dụng để lập kế hoạch bản đồ sản phẩm, đây là một cuộc thảo luận riêng.

Các sử thi được lấy và thảo luận thêm, dẫn đến Câu chuyện của người dùng cho mỗi Sử thi. Các tính năng và sử thi được sử dụng để thúc đẩy các cuộc thảo luận trong các phiên Tinh chỉnh BacklogLập kế hoạch Sprint . Vào thời điểm đó, Câu chuyện người dùng ra khỏi các cuộc thảo luận đó được tinh chỉnh , ưu tiên và, trong Kế hoạch Sprint , được chấp nhận thành các lần chạy nước rút để thực hiện.


4

Đó chỉ là vấn đề phân hủy. Chúng chỉ là những câu chuyện, ngoại trừ với các kích cỡ khác nhau.

Cá nhân tôi không thích dán nhãn kích thước của chúng, nhưng nếu bạn làm điều đó cũng tốt. Hỏi bạn PM định nghĩa trong không gian làm việc của bạn là gì.


1

Tổ chức của chúng tôi có hơn 2.000 nhà phát triển, vì vậy câu trả lời cho câu hỏi này rất quan trọng để giao tiếp trôi chảy và rõ ràng giữa hàng trăm nhóm Agile mà chúng tôi đã làm việc cùng nhau trên sản phẩm chung của chúng tôi. Đối với một tổ chức rất nhỏ, bạn có thể có một cấu trúc rất đơn giản mà thậm chí không cần phải phân cấp (như những người khác đã trả lời). Tuy nhiên, đối với các tổ chức lớn, chắc chắn cần có một hệ thống phân cấp nhất quán, có quy mô, nhất quán - và vấn đề nằm ở việc cố gắng tạo ra một hệ thống phân cấp từ một thứ không theo thứ bậc nghiêm ngặt.

Ngẫu nhiên, chúng tôi gọi mỗi cấp độ khác nhau này là "các mục công việc". Một số tổ chức (bao gồm một số người được hỏi ở trên) gọi các cấp độ khác nhau là Câu chuyện hoặc Câu chuyện của người dùng (và chúng tôi cũng có trong quá khứ), nhưng chúng tôi thấy điều này quá mơ hồ, vì vậy bây giờ chúng tôi gọi chung là Mục Công việc.

Điều tốt nhất chúng tôi đã "chính thức" thực hiện cho đến nay là tuân theo cấu trúc SAFe của Chủ đề đầu tư và sử thi kinh doanh của SAFe đứng đầu (và thứ hai từ trên cùng) của hệ thống phân cấp, sau đó là Tính năng theo đó, và cuối cùng là Câu chuyện trong Tính năng. Theo Agile, Nhiệm vụ luôn nằm trong Câu chuyện, vì vậy chúng tôi cẩn thận không sử dụng lại thuật ngữ đó cao hơn nữa. Chúng tôi đã chọn theo dõi SAFe để ít nhất có MỘT SỐ thống nhất trong tất cả các đội của chúng tôi.

Nhưng điều này vẫn không đủ cho nhu cầu của chúng tôi. Chúng tôi xác định một Tính năng là một giá trị rõ ràng có thể phân phối cho người tiêu dùng sản phẩm phần mềm của chúng tôi (tức là chúng tôi liệt kê các Tính năng này trên các thông báo của chúng tôi về các Bản phát hành sắp tới). Và chúng tôi định nghĩa Câu chuyện là một phạm vi nhỏ hơn và phạm vi có thể được phân phối trong một Sprint duy nhất bởi một nhóm nhà phát triển Agile duy nhất. Hiện tại chúng tôi cũng đang BẮT ĐẦU để tuân theo định nghĩa SAFe về Chủ đề đầu tư và Sử thi kinh doanh ở cấp Danh mục đầu tư (và không dưới mức này). Và chúng tôi đang BẮT ĐẦU để KHÔNG sử dụng các định nghĩa OLD về "Chủ đề" và "Sử thi".

Bây giờ chúng ta đang dần phát triển theo hướng này, nhưng các bánh xe của sự tiến bộ chậm lại. Chúng tôi vẫn đang cố gắng làm thế nào để phân chia công việc thành các phần có kích thước cắn để chúng tôi có thể xác định công việc và hoàn thành công việc một cách trơn tru bởi nhiều nhóm. Để làm điều này, chúng tôi thấy cần có "Tính năng phụ" nhỏ hơn Tính năng nhưng lớn hơn Câu chuyện. Các tính năng phụ có thể được sử dụng cho các khối công việc được thực hiện trên Tính năng bởi nhóm EACH INDIVIDUAL hoặc các khối công việc được thực hiện bởi nhóm SINGLE vào các thời điểm khác nhau (trong các Sprint khác nhau hoặc thậm chí các Bản phát hành khác nhau).

Chúng tôi cũng cần nhiều cấp độ phân cấp giữa Feature và Business Epic, nhưng chúng tôi chưa giải quyết được cấp độ này, ngoài việc gọi chúng là "Chủ đề" - mà chúng tôi biết không phải là thuật ngữ chính xác, vì nó dễ bị nhầm lẫn với Chủ đề đầu tư SAFe. Đối với một số dự án lớn (bản phát hành), chúng tôi có tới 5-8 cấp bậc khác nhau, mỗi cấp phân chia công việc thành các phần nhỏ hơn và nhỏ hơn. Bạn có thể nghĩ các Chủ đề này là "Nhóm tính năng", nhưng đó cũng không hẳn là thuật ngữ chính xác.

Tôi nghĩ điều quan trọng là cố gắng sử dụng các thuật ngữ mang lại sự rõ ràng hơn là sự mơ hồ. Vì vậy, bất cứ ai đề cập đến Câu chuyện đều có nghĩa là đơn vị công việc nhỏ nhất có thể được thực hiện trong một Sprint duy nhất (ngoại trừ Nhiệm vụ trong Câu chuyện) và Tính năng phụ có nghĩa là đơn vị công việc nhỏ nhất trên Tính năng có thể được thực hiện bởi một đội. Tương tự, Nhóm tính năng là một cấp độ phân cấp trên Tính năng. Ở trên nó hơi mờ, vì vậy chúng tôi thường chỉ gọi chúng là Chủ đề và chúng tôi cho phép Chủ đề là cha mẹ và con của các Chủ đề khác. Chúng tôi cố gắng giới hạn các cấp Tính năng, Tính năng phụ và Câu chuyện ở một cấp độ duy nhất (Các tính năng không nên là con của các Tính năng khác) nhưng chúng tôi chưa thành công 100% trong việc hạn chế điều này.

Tôi biết chúng tôi có thể sử dụng "Thẻ" để tổ chức một số điều này, nhưng các thẻ không cung cấp cho chúng tôi cấu trúc phân chia công việc tổ chức mà chúng tôi cần phân loại công việc giữa tất cả các nhóm của chúng tôi. Theo định nghĩa, các thẻ là mơ hồ (mối quan hệ nhiều-nhiều), nhưng một hệ thống phân cấp hoàn toàn là một-nhiều.

Điểm mấu chốt là đây vẫn là một công việc đang tiến triển đối với chúng tôi và chúng tôi vẫn đang vật lộn với nó. Nhưng việc tuân thủ các định nghĩa của SAFe về Chủ đề, Sử thi, Tính năng và Câu chuyện đã khiến chúng ta đi đúng hướng!


1

Phân cấp tồn đọng sản phẩm phụ thuộc khá nhiều vào kích thước sản phẩm và tính mô đun của nó (số lượng khu vực sản phẩm được xác định).

Đối với các dự án nhỏ: Epic> Story là quá đủ; và bạn gọi là "tính năng".
Các dự án lớn có thể trở nên giống nhau: Tiểu thuyết> Chủ đề> Sử thi> Tính năng> Câu chuyện

Ví dụ tốt nhất có thể là như sau:
Novel = MS Office
Theme = MS Word / MS Excel ...
Epic = Bảng / Thư mục phông chữ ...
Tính năng = Bảng cơ bản / Lược đồ màu bảng / Thao tác với các ô ...
Câu chuyện (cho ' Tính năng của các bảng cơ bản trong 'Bảng' Sử thi) = Thêm bảng / Vẽ bảng / Chèn thô / Chèn cột ...

Những gì tôi tin là có ích để ghi nhớ khi xác định tỷ lệ tồn đọng của riêng bạn để tồn đọng là:
1. Câu chuyện: a) luôn khả thi trong một lần chạy nước rút; b) không phải lúc nào cũng có thể kiểm tra được đối với người dùng cuối
2. Sử thi / Tính năng: a) không phù hợp với thời lượng nước rút và cần phải phân tách; b) luôn luôn có thể kiểm tra được đối với người dùng cuối; c) luôn shippable, có thể tạo thu nhập - được ROI tính cho nó
3. Khi xem xét thêm hay không Epic> Tính năng phần hoặc dính vào Epic> Câu chuyện: tôi khuyên bạn nên để chèn Nét đặc sắc trong giữa Epic và Câu chuyện chỉ khi: Epic doesn' t vừa với 1 Bản phát hành, vì vậy bạn cần xác định phần tử có thể chuyển đổi sẽ phù hợp với 1 Thời lượng phát hành .

Hy vọng điều này là hữu ích.


-1

Trong tổ chức của chúng tôi, chúng tôi có những điều sau đây:

Chủ đề = Được sử dụng để nhóm lại một tập truyện

Sử thi = Mô tả một câu chuyện người dùng lớn (trong thực tế là một yêu cầu) cần được chia thành các câu chuyện của người dùng

Tính năng = Liệu những gì nó nói trên hộp thiếc, mô tả một tính năng của sản phẩm được yêu cầu

Câu chuyện của người dùng = Đây là mức độ chi tiết thấp nhất mà từ đó các tác vụ được bắt nguồn.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.