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

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

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

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

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

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

Я приведу пару примеров:

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

Большинство технических историй на самом деле приносят пользу бизнесу, но редко для пользователей. Фразировка их по-другому может помочь. Я обычно использую шаблон Криса Мэтта:

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Учтите следующее:

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

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

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

• Поскольку Компания получает непрямое значение из этих пунктов я полагаю , что в интересах прозрачности это Отставание продукта Пункты (PBIS).

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

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

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

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

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

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

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

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