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

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

Создание итераций

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

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

Анализ скорости работы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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