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

9

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

введите описание изображения здесь

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

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

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

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

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

Боб Твей
источник
2
Если я скажу вам, что компьютер или сервис также могут рассматриваться как «пользователь», это изменит ваш анализ?
Роберт Харви
1
@ mmathis я видел этот вопрос, и он похож и уместен. Однако ни один из ответов на самом деле не отвечает на этот вопрос. Особенно, если вы сосредоточитесь на том, как сделать это в существующих рамках, таких как TFS.
Боб Tway
@ РобертХарви частично, да. Это будет охватывать службу в этом случае, но не устаревший код. Я могу вспомнить другие ситуации, когда такой подход может не соответствовать требованиям. Мне также было бы интересно узнать, насколько широко это принято: кажется, что это семантическое изменение, чтобы обойти проблему «как разработчика».
Боб Tway
2
Вы можете обманывать у системных пользователей итерацию 0, или вы порежете торт по-другому. Первая функция дает некоторую функциональность пользователя и инфраструктуру, необходимую для его работы. Затем функция 2, которая, следовательно, вызывает еще больше инфраструктуры, таким образом вы не тратите время на настройку инфраструктуры, которая вам не нужна. Если вы сейчас кричите, но это означает, что мне нужно перепланировать, значит, вы не делаете проворство.
ctrl-alt-delor

Ответы:

12

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

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

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

Грэхем
источник
Я собирался ответить аналогично этому. Если истории нужно что-то, это часть этой истории. Некоторые истории могут просто получить выгоду после другой истории, которая построила инфраструктуру. Тем не менее, вам нужно сохранить все те истории, которые нуждаются в этом, на случай, если они будут переориентированы. Вы не можете быть уверены, что будет первым.
Джей С
1
+1 Это касается замечательного момента. Называется ли это итерацией 0, 1 или чем-то еще, что является вещицей. Все, кроме самых неразумных или неосведомленных, понимают, что требуется некоторая основа. Если вы рисуете, вы готовите стены, если готовите, рубите, если вы музыкант, вы тренируетесь.
Робби Ди
6

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

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

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

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

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

Джон Рейнор
источник
4
+1, потому что мы также используем это, но в действительности Interation Zero - это новая Iteration One. Это просто итерация, о которой заинтересованные стороны бизнеса на самом деле не заботятся, но они необходимы для того, чтобы заинтересоваться заинтересованными сторонами.
Грег Бургхардт
Вы можете иметь добросовестную итерацию 0, но это не значит, что вы не можете начать приносить прибыль с первого дня. Вам не нужен сервер сборки, автоматическое развертывание и репозиторий исходного кода, чтобы начать резать код - это может произойти позже (или даже параллельно).
Робби Ди
3

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

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

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

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

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

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

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