Giải thích sự khác biệt giữa Mục tồn đọng của sản phẩm và Tác vụ

Tôi đã gặp thử thách này một vài lần và tôi hy vọng ai đó có thể cung cấp một số tài liệu tham khảo, đào tạo hoặc tư vấn về cách giải thích sự khác biệt giữa Mục tồn đọng sản phẩm và Nhiệm vụ trong TFS.

Tôi hiểu và đã giải thích rằng Mục tồn đọng của sản phẩm là "Cái gì" và Nhiệm vụ là "Cách". Tôi cũng đã giải thích rằng PBI là yêu cầu và Nhiệm vụ là cách yêu cầu được đáp ứng.

Tôi liên tục gặp những ánh mắt trống rỗng và gãi đầu khi tôi giải thích điều này. Có vẻ như các Kỹ sư phần mềm tôi giải thích điều này không thể tạo ra sự khác biệt. Tất cả đều giống nhau đối với họ.

Tôi tin rằng thách thức khác của tôi là tôi không thể minh họa một cách hiệu quả tại sao điều quan trọng là tạo ra sự khác biệt.

"Mục tồn đọng sản phẩm" thực sự là Cái gì, chức năng cần được xây dựng. Nhiệm vụ mô tả các bước cần thực hiện để đạt được điều đó.

Nhiều đội không được sử dụng để phân rã thành các nhiệm vụ, họ chỉ xây dựng những gì thông số kỹ thuật nói. Đối với những người này, thật khó để xem họ là hai điều riêng biệt.

Có lẽ một giai thoại đơn giản sẽ giúp:

Xem các mục tồn đọng sản phẩm là các mục trong danh sách mua sắm của họ cho kỳ nghỉ của họ. Có thể là "lều", "cần câu", "xe chuẩn bị đi du lịch".

Các nhiệm vụ cho mục "lều" sẽ là "Mô tả các yêu cầu về lều", "So sánh lều trực tuyến", "Nhận lời khuyên từ bạn bè có kinh nghiệm ngoài trời", "Đi đến cửa hàng ngoài trời", "Mua lều", "dựng lều ở sân sau để xác minh tính đầy đủ "," gói lều đi du lịch "

Nhiệm vụ cho Cần câu sẽ rất giống nhau, nhưng các nhiệm vụ cho "chuẩn bị xe đi du lịch" có lẽ rất khác nhau: "Kiểm tra các yêu cầu cho các quốc gia / quốc gia trên tuyến đường mong muốn", "mua áo bảo hộ", "thay thế nội dung đã hết hạn từ sơ cứu kit "," kiểm tra lốp dự phòng "," hẹn lịch với gara để kiểm tra động cơ "," đến gara để kiểm tra động cơ "," đến cơ quan nhà nước để mua đường cao tốc "," kiểm tra bảo hiểm xe hơi "

Điều này phân tách rõ ràng câu hỏi về những gì chủ sở hữu sản phẩm muốn từ những gì họ cần làm. Tất nhiên trừ khi chủ sở hữu sản phẩm đã phân tách thành các mục có thể thao tác trên Product Backlog, trong trường hợp đó bạn cũng cần nói chuyện với họ.

Như tôi đã nói, đối với nhiều nhà phát triển, họ nghĩ rằng họ đã có đủ thông tin và biết phải làm gì, họ không muốn phân tách các bước thành bước nào, họ sẽ đến đó khi đến đó. Khi bạn bắt đầu nói chuyện với họ về việc theo dõi tiến trình chạy nước rút, cải thiện các ước tính, theo dõi công việc bị lãng quên trong kế hoạch chạy nước rút và các mục khác phải làm với các cải tiến chuyên nghiệp, hãy hỏi họ và nhóm của họ sẽ biết họ có thể cải thiện ở đâu và làm thế nào biết họ đã thực sự hoàn thành. Khi họ có thể đưa ra một hệ thống hoạt động mà không tạo ra các nhiệm vụ và nó hoạt động, thì điều đó cũng tốt, nhưng khả năng rất thấp là họ thực sự có thể.

Trước khi thử làm việc với TFS và các công cụ nhanh, nhóm của bạn sẽ cần hiểu cách thức hoạt động của tất cả. Cách tốt nhất là để chúng làm việc với một bảng giấy, có thể nhìn thấy trên sàn làm việc cho tất cả mọi người. Sau này, khi quy trình được hiểu rõ hơn, chuyển sang các công cụ sẽ giúp ích. Nếu không có sự hiểu biết, các công cụ sẽ không được sử dụng nhiều và sẽ gặp rất nhiều sự kháng cự.

Tôi nghĩ Jesse đã cung cấp một câu trả lời tuyệt vời. Tôi chỉ đơn giản là sẽ thử và làm nó, tốt hơn, đơn giản hơn (nếu có thể) :) Mục Backlog của sản phẩm (hoặc Câu chuyện người dùng, nếu bạn thích) thường được viết như thế này:

Là một khách hàng mới, tôi muốn đăng ký thông tin của mình để tôi được thông báo về việc phát hành sản phẩm mới

Trong một nhà phát triển, điều này có thể dịch sang:

1. Tạo một mẫu đăng ký
2. Ghi dữ liệu đăng ký vào cơ sở dữ liệu
3. Gửi email cho khách hàng mới để xác nhận đăng ký của họ

Ba mục này là các nhiệm vụ.

Mong rằng sẽ giúp.

- Làm cho nó đơn giản nhất có thể nhưng không đơn giản hơn (Einstein)

Đây là cách chúng tôi cuộn:

PBI:

• là yêu cầu hay còn gọi là "cái gì"
• là những gì bạn nói về một khách hàng .
• Đó là những gì hiển thị trên Cập nhật dự án hàng ngày (DPU) cho lần chạy nước rút ..... một lần nữa vì DPU là khách hàng phải đối mặt.
• Đó là những gì khách hàng sẽ nói và tham khảo về các ước tính và ngân sách.
• Có thể bao gồm một hoặc nhiều nhiệm vụ.
• Là định hướng kinh doanh và được mô tả bằng ngôn ngữ phong cách kinh doanh theo định hướng / tên miền mà khách hàng hiểu.
• Là những gì được kiểm tra và chấp nhận trong Kiểm tra chấp nhận người dùng (UAT)

Nhiệm vụ:

• Là một phần công việc cần thiết để cụ thể hóa PBI (yêu cầu)
• Không phải điều bạn nói với khách hàng
• Không hiển thị trên DPU vì bạn không nói về họ với khách hàng
• Được ước tính nhưng ước tính đã được đưa vào PBI
• Là một đứa trẻ cho một và chỉ một yêu cầu.
• Có thể được mô tả (và thường là) sử dụng thuật ngữ kỹ thuật
• Đã thử nghiệm nội bộ và ký tắt bằng thử nghiệm
• Không được khách hàng chấp nhận hoặc thử nghiệm cách ly (họ không biết họ tồn tại)

Tôi có xu hướng đưa ra điều này khi được hỏi: -

PBI, hoặc Câu chuyện là thứ mà nhiều người có thể có được xung quanh.

Nhiệm vụ là thứ chỉ một người có thể nhặt được.