Определение уровня детализации, необходимого для плана выпуска

Опубликовано: 2022-08-23

«Насколько подробно нам нужно для нашего плана выпуска?»

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

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

Короче говоря, агилисты стремятся к достаточному планированию.

Знайте свой контекст при планировании релиза

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

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

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

варианты уровня детализации плана выпуска

Рис. 1. Цель процесса «Планирование выпуска».

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

Связанный: Как финансировать проект разработки программного обеспечения

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

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

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

Варианты уровня детализации в плане выпуска

Я считаю, что есть четыре варианта планирования выпуска решения; хотя я понимаю, что их может быть больше и что вы можете комбинировать стратегии. Как вы можете видеть на рис. 1, рядом со списком параметров есть стрелка, указывающая на то, что он упорядочен. Варианты от наиболее эффективных к наименее эффективным:

  1. Катящаяся волна : план постоянно обновляется на протяжении всего выпуска, как волна, с более подробными сведениями о предстоящей работе и меньшими подробностями о дальнейшей работе. План скользящей волны начинается как план высокого уровня, и детали, по мере необходимости, добавляются вовремя на протяжении всего выпуска.
  2. Высокий уровень: в плане релиза указаны основные вехи , любые фазы, любые итерации/спринты (если ваша команда работает таким образом) и любые зависимости между ними. В нем не рассматривается детальная работа, которую необходимо выполнить. Вместо этого он доверяет команде самоорганизацию и делает все, что уместно в данный момент.
  3. Подробный: план выпуска содержит важные сведения о работе, которую необходимо выполнить, и может даже назначать эту работу определенным ролям или людям. Детали определяются в начале выпуска, в течение периода, который команды Agile и Scrum часто называют «спринтом 0», началом или инициацией. Детали обычно обновляются с течением времени по мере продвижения работы.
  4. None : План выпуска вообще не документирован. Планирование все еще может происходить, но сам план не фиксируется.

Сравнение вариантов планирования выпуска

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

Связанный: Бесплатный шаблон плана проекта

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

Таблица 1. Сравнение каждой стратегии по уровню детализации плана.

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

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

· Позволяет командам составлять честные сроки и бюджеты для своих заинтересованных сторон.

· Требует гибкости со стороны заинтересованных сторон, потому что это устраняет (утешительное) чувство ложной предсказуемости в пользу предоставления им возможности направлять и вести команду к успеху.
Высокий уровень · Хорошо работает для опытных команд, которым не нужно много деталей плана.

· Полезно для предоставления заинтересованным сторонам высокоуровневого прогноза того, что будет выполнено с течением времени, и для выявления зависимостей с другими командами.

· Обеспечивает некоторое ощущение «предсказуемости», не беря на себя затраты на детальное планирование.

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

· Часто оправдывается необходимостью соблюдения нормативных требований, хотя нормативные акты редко требуют подробного предварительного планирования.

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

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

· Снижает боевой дух команды.

Никто · Подходит для простых инициатив с низким уровнем риска в тесной совместной среде.

· Отсутствие накладных расходов на документацию.

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

Выбор — это хорошо при планировании релиза

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

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

Независимо от того, планируете ли вы подробно или следуете гибкой структуре и планируете более свободно, оставляя место для итерации, вам все равно нужно планировать. ProjectManager — это облачное программное обеспечение для управления проектами, которое дает вам возможность планировать по своему усмотрению. Благодаря доскам канбан, диаграммам Ганта и информационной панели в режиме реального времени, которая предоставляет актуальные данные после того, как вы приводите этот план в действие, вы всегда в курсе изменений и можете быстро реагировать. Убедитесь сами, воспользовавшись бесплатной 30-дневной пробной версией.