Объяснение разницы между элементом журнала незавершенного производства и задачей

Я сталкивался с этой проблемой пару раз, и я надеюсь, что кто-то может предоставить некоторые рекомендации, обучение или советы о том, как объяснить разницу между элементом продукта, оставшимся в запасе, и задачей в TFS.

Я понимаю и объяснил, что элемент «Журнал невыполненных работ» - это «Что», а Задача - «Как». Я также объяснил, что PBI является требованием, а Задача состоит в том, как выполняется это требование.

Меня постоянно встречают пустые взгляды и царапины на голове, когда я объясняю это. Кажется, что разработчики программного обеспечения, которым я объясняю это, не могут сделать различие. Им все равно.

Я считаю, что моя другая проблема заключается в том, что я не могу эффективно проиллюстрировать, почему важно проводить различие.

«Элемент незавершенного производства» - это действительно что, функциональность, которую необходимо создать. Задача описывает шаги, которые необходимо предпринять, чтобы туда добраться.

Многие команды не используются для разложения на задачи, они просто строят то, что говорит спецификация. Для этих людей трудно рассматривать их как две разные вещи.

Может быть, поможет простой анекдот:

См. Товары в списке товаров в качестве товаров в их списке покупок на время отпуска. Может быть, «палатка», «удочка», «подготовить машину к путешествию».

Задачами для элемента «палатка» будут «Описать требования к палатке», «Сравнить палатки онлайн», «Получить совет от друзей с опытом на открытом воздухе», «Перейти в магазин на открытом воздухе», «Купить палатку», «Установить палатку на заднем дворе, чтобы проверить комплектность "," упаковать палатку для путешествий "

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

Это четко отделяет вопрос о том, что хочет владелец продукта от того, что ему нужно сделать. Если, конечно, владелец продукта уже не разложился на доступные элементы в Журнале невыполненных работ, в этом случае вам также необходимо поговорить с ними.

Как я уже сказал, для многих разработчиков они думают, что у них уже достаточно информации и знают, что делать, они не хотят разбивать шаги «Что на», они попадут туда, когда доберутся. Когда вы начнете говорить с ними о том, как отслеживать ход спринта, улучшать оценки, отслеживать работу, которая была забыта при планировании спринта, и другие вопросы, связанные с профессиональными улучшениями, спросите их, как они и их команда узнают, где они могут улучшиться и как они знаю, что они действительно сделали. Когда они могут придумать систему, которая работает без создания задач, и это работает, тогда это нормально, но шансы очень малы, что они действительно могут.

Прежде чем пытаться работать с TFS и гибкими инструментами, ваша команда должна понять, как все это работает. Лучший способ - заставить их работать с бумажной доской, которая видна всем на рабочем этаже. Позже, когда процесс станет понятнее, переход на инструменты поможет. Без понимания инструменты не будут очень полезны и встретят большое сопротивление.

Я думаю, что Джесси дал отличный ответ. Я просто попытаюсь сделать это, ну, проще (если возможно) :) Элемент журнала невыполненных работ (или пользовательская история, если вы предпочитаете) обычно пишется так:

Как новый клиент, я хочу зарегистрировать свои данные, чтобы получать информацию о новых выпусках продукта

В голове разработчика это может привести к:

1. Создать регистрационную форму
2. Записать регистрационные данные в базу данных
3. Отправить электронное письмо новому клиенту, чтобы подтвердить его регистрацию

Эти три пункта являются задачами.

Надеюсь, это поможет.

- Сделать это как можно проще, но не проще (Эйнштейн)

Вот как мы катимся:

PBI:

• это требование ака "что"
• это то, что вы говорите с клиентом .
• Это то, что отображается в ежедневном обновлении проекта (DPU) для спринта ... опять же, потому что DPU ориентирован на клиента.
• Это то, о чем клиент будет говорить и ссылаться с точки зрения сметы и бюджета.
• Может включать одну или несколько задач.
• Ориентирован на бизнес и описан на языке бизнес-ориентированных / доменных стилей, который понимает клиент.
• Является ли то, что проверено и принято в User Acceptance Testing (UAT)

Задание:

• Требуется ли часть работы для материализации PBI (требование)
• Не то, что вы говорите с клиентом
• Не появляется на DPU, потому что вы не говорите о них с клиентами
• Оценено, но есть свои оценки свернутые в PBI
• Является ли ребенок одним и только одним требованием.
• Может быть описано (и часто так) с использованием технического жаргона
• Протестировано внутри и подписано тестом
• Не принимается и не тестируется клиентом отдельно (они не знают, что существуют)

Я склонен предлагать это, когда спрашивают:

PBI, или Story - это нечто, что может обойти более чем один человек.

Задачи - это то, что может принять только один человек.