Автор: Майк Кон (Mike Cohn)
Перевод с английского.
Я хочу обратить внимание на термин, используемый в Скраме (точнее, даже Аджайл термин), который во многом пережил себя: планирование релиза. Общепринятое использование "релизного планирование" заключалось в том(я так тоже делал), что мы смотрели в будущее на несколько спринтов вперед и пытались предсказать, что бы мы могли выпустить. Было бы хорошо в идеале эти предположения выражать в виде диапазона значений, возможно даже с использованием интервалов вероятности.
В течение многих лет я учил команды делать именно так. Скажем, мы могли сказать, что “Мы уверены на 90%, что через шесть месяцев сможем выпустить продукт с функционалом в диапазоне между 150 и 200 стори поинтов.” Я до сих пор считаю эту практику полезной и каждый Скрам-мастер должен знать как это делается.
Что на самом деле потеряло смысл, так это сам термин “планирование релизов”.
Десять лет тому назад каждый, кто работал в Скраме, следовал следующей модели - спринт, спринт, спринт, релиз. Мы работали в течение (как правило) нескольких спринтов, а затем выходили в релиз. Но в сегодняшнем мире это не так. Некоторые команды действительно еще так работают.
Но другие выходят в релиз чаще чем один раз в несколько спринтов. Некоторые команды выходят в релиз каждый спринт. А есть команды, выходящие в релиз несколько раз за спринт. Во время проведения одного из своих классов, я встретил человека, который сказал, что они выходят в релиз семь раз в день, используя Скрам.
Я вижу как усиливался этот тренд за последних несколькл лет. Я действительно понял, что мы достигли критической точки, когда этот термин вызвал непонимание на одном из моих классов. Я описывал “планирование релиза” как проекцию того, что мы делаем на протяжении нескольких спринтов. Кто-то в классе подумал, что “планирование релиза” значило ежедневное планирование того, что мы будем выпускать в конце дня.
Возможно, пришло время изъять фразу “планирование релиза” из словарей Скрам и гибкой разработки. Но поймите меня правильно. Иметь возможность планировать на 3, 6 и 12 месяцев вперед до сих является основополагающим понятием для многих команд и Скрам-мастеров. Но сам по себе термин уже неточен. Нам нужен новый термин.
За последние несколько лет я пробовал использовать несколько различных терминов на моих Сертификационных классах для Скрам-мастеров. Мне не хочется называть это “долгосрочным планированием”. Может быть в современном мире "бережливых стартапов" (пл англ. lean startup), три месяца и можно назвать “долгосрочным планированием”, но мне, все же, и это кажется неверным. Я считаю, что термин “среднесрочное планирование” могло бы иметь право на жизнь.
Итак, техники остаются, но термины уже пережили себя.
Переведено с английского проектом Agile Translations.
Оригинальная статья: Release Planning: Retiring the Term but not the Technique.
Перевод с английского.
Я хочу обратить внимание на термин, используемый в Скраме (точнее, даже Аджайл термин), который во многом пережил себя: планирование релиза. Общепринятое использование "релизного планирование" заключалось в том(я так тоже делал), что мы смотрели в будущее на несколько спринтов вперед и пытались предсказать, что бы мы могли выпустить. Было бы хорошо в идеале эти предположения выражать в виде диапазона значений, возможно даже с использованием интервалов вероятности.
В течение многих лет я учил команды делать именно так. Скажем, мы могли сказать, что “Мы уверены на 90%, что через шесть месяцев сможем выпустить продукт с функционалом в диапазоне между 150 и 200 стори поинтов.” Я до сих пор считаю эту практику полезной и каждый Скрам-мастер должен знать как это делается.
Что на самом деле потеряло смысл, так это сам термин “планирование релизов”.
Десять лет тому назад каждый, кто работал в Скраме, следовал следующей модели - спринт, спринт, спринт, релиз. Мы работали в течение (как правило) нескольких спринтов, а затем выходили в релиз. Но в сегодняшнем мире это не так. Некоторые команды действительно еще так работают.
Но другие выходят в релиз чаще чем один раз в несколько спринтов. Некоторые команды выходят в релиз каждый спринт. А есть команды, выходящие в релиз несколько раз за спринт. Во время проведения одного из своих классов, я встретил человека, который сказал, что они выходят в релиз семь раз в день, используя Скрам.
Я вижу как усиливался этот тренд за последних несколькл лет. Я действительно понял, что мы достигли критической точки, когда этот термин вызвал непонимание на одном из моих классов. Я описывал “планирование релиза” как проекцию того, что мы делаем на протяжении нескольких спринтов. Кто-то в классе подумал, что “планирование релиза” значило ежедневное планирование того, что мы будем выпускать в конце дня.
Возможно, пришло время изъять фразу “планирование релиза” из словарей Скрам и гибкой разработки. Но поймите меня правильно. Иметь возможность планировать на 3, 6 и 12 месяцев вперед до сих является основополагающим понятием для многих команд и Скрам-мастеров. Но сам по себе термин уже неточен. Нам нужен новый термин.
За последние несколько лет я пробовал использовать несколько различных терминов на моих Сертификационных классах для Скрам-мастеров. Мне не хочется называть это “долгосрочным планированием”. Может быть в современном мире "бережливых стартапов" (пл англ. lean startup), три месяца и можно назвать “долгосрочным планированием”, но мне, все же, и это кажется неверным. Я считаю, что термин “среднесрочное планирование” могло бы иметь право на жизнь.
Итак, техники остаются, но термины уже пережили себя.
Переведено с английского проектом Agile Translations.
Оригинальная статья: Release Planning: Retiring the Term but not the Technique.