Как команда Scrum учитывает задачи инфраструктуры на совещании по планированию?

Как работает команда Scrum для задач dev /инфраструктуры на собрании по планированию?

На первый взгляд, они не выглядят как истории пользователей, так как они не доставляют конечное значение пользователя.

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

Итак, это говорит о том, что эти задачи становятся рассказами пользователей. Но тогда, если рассказ команды указывает на них, тогда это изменяет скорость, которая является нечетной, так как Владелец Продукта хочет знать скорость против своего отставания, а не его отставание с кучей технических рассказов пользователей, прикрепленных к нему.

31 голос | спросил user11347 24 MarpmThu, 24 Mar 2011 17:58:19 +03002011-03-24T17:58:19+03:0005 2011, 17:58:19

10 ответов


24

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

Я приведу несколько примеров:

  • статьи с ключевыми словами, которые позволяют рекламодателям получать более эффективные рекламные объявления.
  • CAPTCHA, которые есть, чтобы остановить модераторов, имеющих дело со спамом вручную.

Большинство технических историй фактически обеспечивают выгоду для бизнеса, но это редко для пользователей. Поражение им по-другому может помочь. Я обычно использую Chris Matts 'Feature Injection template:

In order to <achieve my goal>
As <the stakeholder who wants the goal>
I want (<some users to do>) <some stuff>.

Это явно признает всех заинтересованных сторон, включая команду разработчиков. Теперь вы можете также рассказать о своих технических историях, вызывая бизнес-выгоду:

In order to minimize the risk of deploying something broken
As the team deploying the code
We want to spend a few days on an automated deployment system.

Я написал пару сообщений в блоге об этом: Они не рассказы пользователей и Функция инжекции и обработки технических историй . Надеюсь, они помогут.

ответил Lunivore 24 MarpmThu, 24 Mar 2011 18:36:25 +03002011-03-24T18:36:25+03:0006 2011, 18:36:25
12

Velocity - это показатель способности команды выполнять полезную работу (в отличие от Drag). Инфраструктурные задачи по-прежнему доставляют конечную ценность, хотя и косвенно, что делает команду более эффективной в долгосрочной перспективе. У меня нет проблем отслеживать эти вещи как истории пользователей (в этом случае пользователь является командой разработчиков) и уделяет приоритетное внимание им. Владелец продукта в хорошем общении с клиентом (-ами) должен иметь возможность выяснить, где такие задачи могут поместиться, не нарушая результатов.

ответил Kristo 24 MarpmThu, 24 Mar 2011 18:13:41 +03002011-03-24T18:13:41+03:0006 2011, 18:13:41
11

Делайте их постепенно.

Если заинтересованная сторона не хочет этого, не делайте это рассказом. Просто позаботьтесь об этом, немного за раз. Например, при первом развертывании вручную. Во второй раз вы автоматизируете его. В третий раз вы автоматизируете немного больше. В конце концов, ваша сборка не самая большая проблема, поэтому вы фокусируетесь на чем-то еще.

У вас будет больше этих задач, ориентированных на разработчиков, в начале, и это нормально; ваша скорость (измеренная историями) будет только ниже. Это правильное представление об этой ситуации. Но у вас всегда будет что-то, поэтому важно, чтобы команда привыкла делать то, что необходимо для улучшения процесса.

ответил William Pietri 24 MarpmThu, 24 Mar 2011 20:14:17 +03002011-03-24T20:14:17+03:0008 2011, 20:14:17
6

ИМХО - идеальный подход заключается в том, чтобы приложить усилия к инфраструктуре в качестве задач под пользовательской историей, где она сначала сохраняет ценность; как вы уже упоминали.

Принимая ваш пример; ручное строительство и развертывание подразумевает, что это постоянное усилие и не имеет формы завершения. Он существует бесконечно.

То же самое можно сказать и о коде, который автоматизирует любую часть усилий в типичном приложении, которое ранее выполнялось вручную. Определение этого усилия как задачи под пользовательской историей определяет полный; который по самой своей природе имеет ценность для конечного пользователя.

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

ответил Aaron McIver 24 MarpmThu, 24 Mar 2011 19:21:26 +03002011-03-24T19:21:26+03:0007 2011, 19:21:26
4

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

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

ответил Ladislav Mrnka 27 MarpmSun, 27 Mar 2011 17:38:59 +04002011-03-27T17:38:59+04:0005 2011, 17:38:59
2

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

ответил Andy Wiesendanger 24 MarpmThu, 24 Mar 2011 18:01:50 +03002011-03-24T18:01:50+03:0006 2011, 18:01:50
2

Из того, что я видел, большая часть инфраструктуры считается данной. Это включает в себя такие вещи, как:

  • Система контроля версий;
  • Автоматизированная система сборки;
  • IDE и другие инструменты разработчика;
  • Серверы разработки;
  • Процесс развертывания; и
  • Процесс и стандарты проекта.

Большинство методологий, с которыми я работал, не уделяют им много внимания. Они формируют то, что я называю Release 0. Эти вещи должны быть на месте, прежде чем вы начнете разработку. Как только вы начнете работать над историями, любые изменения в этих вещах можно отследить как улучшения процесса.

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

ответил BillThor 24 MarpmThu, 24 Mar 2011 19:01:24 +03002011-03-24T19:01:24+03:0007 2011, 19:01:24
1

Рассмотрим следующее:

  • Команда Scrum добавляет основные функции в существующий набор продуктов.

  • Необходимо обновить технологии разработки /инструменты /утилиты до оставаться в курсе, основываясь на передовых методах проектирования.

  • Имеет смысл передняя загрузка релиза с этой работой, чтобы ход выпуска Sprints может быть разрешен.

  • Поскольку бизнес получает косвенную ценность из этих статей, я предлагаю что в интересах прозрачности эти отставание продукта Элементы (PBI).

  • Команда оценивает эти элементы и обрабатывает их, как и любой PBI.

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

Я не хочу, чтобы размер PBI исказился в результате такой работы инфраструктуры. Я хочу посмотреть, что делается и понять, за что я плачу.

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

ответил Chris 4 52011vEurope/Moscow11bEurope/MoscowFri, 04 Nov 2011 21:03:34 +0400 2011, 21:03:34
0

XP рекомендует предлагает иметь «итерационный нуль», где настроены все инструменты и инфраструктура. Написание историй для них необязательно, но, вероятно, это хорошая идея. Возможность тестирования вашей инфраструктуры (инкрементная сборка, автоматическое тестирование и развертывание, уведомления и т. Д.) Выгодна

ответил Steven A. Lowe 24 MarpmThu, 24 Mar 2011 19:10:51 +03002011-03-24T19:10:51+03:0007 2011, 19:10:51
0

В нашей команде мы делаем следующее:

  1. Предположим более низкий коэффициент фокусировки .
  2. Попробуйте включить такие задачи в истории пользователей , которые действительно нуждаются в их реализации.
  3. Если некоторые задачи полностью необходимы, но не обеспечивают прямой бизнес-ценности (например, перенос модульных тестов из одной структуры в другую), в начале спринта мы создаем список «непрерывных задач» . Это связанные с развитием задачи, которые не являются историями, но команда разработчиков хочет, чтобы они сделали это. Мы перечисляем эти задачи на нашей доске, сохраняя ее отдельно от историй. Во время спринта на каждом ежедневном собрании мы рассмотрим, что было сделано для их выполнения.

Шаг 2 является самым важным. Как в гибкой практике, в Scrum вы пытаетесь сделать как можно меньше для выполнения своих задач. Возьмите его как способ не тратить впустую свою жизнь на ненужную работу: мой опыт показывает, что до 50% «здоровых» вещей в конечном итоге заброшены и оставлены без изменений в конечном итоге.

ответил P Shved 30 MarpmWed, 30 Mar 2011 16:55:25 +04002011-03-30T16:55:25+04:0004 2011, 16:55:25

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132