Пояснення різниці між предметом затримки товару та завданням

Я зіткнувся з цим завданням кілька разів, і сподіваюся, що хтось може надати деякі довідки, навчання або поради щодо пояснення різниці між предметом провідника товару та завданням у TFS.

Я розумію і пояснив, що товарний елемент "Блокування" - це "Що", а завдання - "Як". Я також пояснив, що PBI є вимогою, і завдання полягає в тому, як ця вимога виконується.

Мене неодноразово зустрічають з порожніми поглядами та дряпанням голови, коли я пояснюю це. Здається, інженери програмного забезпечення, яким я пояснюю це, не можуть розрізняти. Їм все одно.

Я вважаю, що іншим моїм завданням є те, що я не в змозі ефективно проілюструвати, чому важливо зробити відмінність.

"Елемент затримки продукту" - це справді те, що потрібно функціонувати. Завдання описує кроки, які потрібно вжити, щоб потрапити туди.

Багато команд не використовуються для розкладання завдань, вони просто будують те, що говорить специфікація. Цим людям важко сприймати їх як дві окремі речі.

Можливо, простий анекдот допоможе:

Ознайомтесь із предметами закупівель товарів як товари зі списку покупок для своєї відпустки. Може бути "намет", "вудка", "підготувати машину до подорожі".

Завданнями для предмета "намет" були б "Опишіть вимоги до намету", "Порівняйте намети в Інтернеті", "Отримайте поради у друзів із досвідом на відкритому повітрі", "Зайдіть у магазин на відкритому повітрі", "Купуйте намет", "Намет на наметі на задньому дворі перевірити повноту "," упакувати намет для подорожей "

Завдання для вудки будуть дуже схожими, але завдання "підготувати машину до подорожі", ймовірно, дуже різні: "Перевірте вимоги до держав / країн за потрібним маршрутом", "придбайте жилет безпеки", "замініть прострочений вміст з першої допомоги комплект "," оглянути запасну шину "," графік зустрічі з гаражем, щоб перевірити двигун "," піти в гараж, щоб перевірити двигун "," піти в державне агентство, щоб купити проїзд на шосе "," перевірити страхування автомобіля "

Це чітко відокремлює питання, що власник товару хоче від того, що їм потрібно зробити. Якщо, звичайно, власник продукту вже розклався на реальні елементи в Блоку продукту, і в цьому випадку вам також потрібно поговорити з ними.

Як я вже говорив, для багатьох розробників вони думають, що вони вже мають достатньо інформації та знають, що робити, вони не хочуть розкладати кроки Що робити на те, як вони потраплять, коли потраплять туди. Коли ви починаєте говорити з ними про відстеження прогресу спринту, вдосконалення оцінок, відстеження роботи, яку забули під час планування спринту, та інших предметів, що мають відношення до професійних удосконалень, запитайте їх, як вони та їх команда будуть знати, де вони можуть вдосконалюватися та як вони знайте, що вони справді зроблені. Коли вони можуть придумати систему, яка працює без створення завдань, і вона працює, тоді це добре, але шанси дуже низькі, ніж вони насправді можуть.

Перш ніж спробувати працювати з TFS та спритними інструментами, вашій команді потрібно буде зрозуміти, як це все працює. Найкращий спосіб - змусити їх працювати з паперовою дошкою, яку видно на робочому поверсі всім. Пізніше, коли процес зрозуміють краще, перехід до інструментів допоможе. Без розуміння інструменти не принесуть великої користі і зустрінуть чималий опір.

Я думаю, що Джессі дав чудову відповідь. Я просто спробую зробити це, ну, простіше (якщо це можливо) :) Елемент "Блокування продукту" (або Історія користувача, якщо ви хочете) зазвичай пишеться так:

Як новий клієнт, я хочу зареєструвати свої дані, щоб отримувати інформацію про нові випуски товарів

У голові розробників це може бути перекладено на:

1. Створіть реєстраційну форму
2. Запишіть дані реєстрації в базу даних
3. Надішліть електронному листу нового клієнта, щоб підтвердити його реєстрацію

Ці три пункти - це завдання.

Сподіваюся, що це допомагає.

- Зробіть це максимально просто, але не простіше (Ейнштейн)

Ось як ми котимося:

PBI:

• є вимога aka "що"
• це те, про що ти розмовляєш із замовником .
• Це те, що з'являється у щоденному оновлення проекту (DPU) для спринту ... знову ж таки, тому що DPU стоїть перед клієнтом.
• Це те, про що замовник буде говорити і посилатися з точки зору кошторису та бюджету.
• Може містити одне або кілька завдань.
• Чи орієнтований на бізнес і описаний мовою, орієнтованою на бізнес / домен, яку розуміє замовник.
• Що тестується та приймається в Тестуванні прийняття користувача (UAT)

Завдання:

• Чи потрібна робота, щоб здійснити ПІІ (вимога)
• Не те, про що ти розмовляєш із замовником
• Не відображається в DPU, оскільки ви не розмовляєте про них із замовниками
• Оцінюється, але чи є його оцінки, зведені в ІПП
• Є дитина до однієї і лише однієї вимоги.
• Можна описати (і часто є) за допомогою технічного жаргону
• Перевірено внутрішньо та підписано тестом
• Замовник не приймає або перевіряє окремо (він не знає, що існує)

Я схильний пропонувати це, коли мене запитують:

PBI або Story - це щось більше, ніж одна людина може обійти.

Завдання - це те, що тільки одна людина може забрати.