В agile, как основные инфраструктурные задачи в начале проекта планируются и распределяются с использованием строгих структур управления, таких как TFS онлайн?

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

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

Например, частью этого приложения является служба, которая анализирует XML. С точки зрения пользователя, есть конкретные истории, в которых нужно будет делать разные вещи в зависимости от содержания XML. На самом деле написание синтаксического анализатора XML - биты, которые ищут файл, читают его и извлекают соответствующие данные, прежде чем решить, что делать с содержимым, - являются частью всех этих историй. Как и завершение его в службе Windows с помощью установщика и т. Д. Это задача, ориентированная на разработчика и не имеющая прямого отношения к пользователю.

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

Я видел, как люди решали эту проблему, написав пользовательские истории «Как разработчик, я хочу…», но, как уже говорилось в других местах, это не пользовательская история. Это разработчик.

Я ищу конкретный ответ на этот вопрос, чтобы помочь мне (и другим) планировать проекты с использованием строгих систем управления, таких как TFS онлайн. Они, как правило, не имеют функции создавать «истории заинтересованных сторон» или другие расплывчатые мета-решения, упомянутые в ответах на вопрос « Как команда Scrum учитывает инфраструктурные задачи на совещании по планированию?

Мне нравятся другие ответы, в которых говорится, что в итерацию 0 нужно как можно больше «инструментального» кода. Однако иногда такие инструменты появляются после того, как проект уже запущен. Возможно, в итерации 3 вы понимаете, что вам нужен обобщенный виджет XML-парсера, который будет использоваться в различных историях в будущем.

В этом случае первой пользовательской историей, которая опирается на эти внутренние архитектурные элементы, является та, к которой они принадлежат . Если вы собираетесь работать над Story # 345, и он будет зависеть от вашего синтаксического анализатора XML, прежде чем его можно будет считать «выполненным», то ваш анализатор многократного использования будет присоединен в качестве работы для завершения этой истории.

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

Если это инфраструктура, то она обычно помещается в Iteration Zero. Что такое ноль итераций? Обычно это время между началом и планированием до начала реальных итераций.

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

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

Я все еще отслеживаю и планирую эту работу как часть работы над итерацией 0.

Рефакторинг звучит как техническая история, которая может идти в любую итерацию.

Зависит от инфраструктуры.

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

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

Если настройка инфраструктуры займет несколько итераций (например, возможно, вы сейчас настроили свой сервер сборки, но серверы QA и preprod будут построены чуть позже), тогда их сборкой можно управлять как нефункциональными PBI. Функциональные PBI могут иметь определенные зависимости от них, которые можно кодировать в TFS, используя ссылку «предшественник».

И, конечно, вы можете смешивать и сочетать все вышеперечисленное. Например, вы не можете многое сделать без сервера непрерывной сборки, поэтому вы можете поместить это в итерацию 0. Между тем ваши серверы preprod могут быть определены как задачи для итераций 2 и 3, и они могут иметь внешние зависимости от вашей команды DBA ( кто не Agile) кто будет выделять вам экземпляры БД в вашем центре обработки данных. Или, может быть, вам придется подождать выдачи сертификатов SSL для определенных функций; они могут идти в итерации 4, и любые функциональные элементы, которые полагаются на эти сертификаты, должны быть связаны с ними отношениями предшественник / преемник.

Во всех случаях помните:

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