Установление итераций и составление планов выпусков

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

Установка итераций

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

Чтобы начать выравнивание усилий по временной шкале, мы рекомендуем определить набор итерации, которые длились 6–12 месяцев.

Общие сведения о скорости

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

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

Пример: Группа по внедрению облака пять человек привержена двухнедельным спринтам. Учитывая текущие обязательства, такие как собрания и поддержку других процессов, каждый член команды может последовательно вносить 20 часов в неделю в усилия по внедрению. Для этой команды начальная оценка скорости составляет 100 часов на спринт.

Планирование итерации

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

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

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

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

Пример: Давайте развивать предыдущий пример. Предположим, что для каждой миграции рабочей нагрузки требуется 40 задач. Предположим, что выполнение каждой задачи занимает в среднем один час. Оценочная продолжительность составляет около 40 часов на перенос рабочей нагрузки. Если эти оценки остаются согласованными для всех 10 приоритетных рабочих нагрузок, эти рабочие нагрузки будут занимать 400 часов.

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

Планирование выпуска

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

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

Чтобы гарантировать, что изменение оправдано его потенциальным возвращением, команда по облачной стратегии должна участвовать в планировании выпуска. После выравнивания задач по спринтам команда может определить приблизительные временные шкалы, когда каждый объем работы будет готов к выпуску в производство. Группа по облачной стратегии будет просматривать сроки каждого выпуска. Затем команда определит точку перегиба между риском и бизнес-ценностью.

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

Назначение путей итерации и тегов

Для клиентов, которые управляют планами внедрения облака в Azure DevOps, предыдущие процессы отражаются путем назначения пути итерации каждой задаче и истории пользователя. Мы также рекомендуем присваивать теги каждой рабочей нагрузке, соответствуя определенной версии релиза. Тегирование и назначение способствуют автоматическому заполнению отчетов по временной шкале.

Дальнейшие действия

Оцените сроки для правильного согласования ожиданий.