К основному контенту

Оценивание и планирование необходимы для повышения поставляемой ценности

Автор: Майк Кон (Mike Cohn) 
Перевод с английского.


Я сильно интересуюсь оцениванием и планированием и всегда обращаю внимание на новые статьи в блогах и новостях, говорящих о том, что “Оценивание - напрасная трата времени! Не делайте его!”. Меня не удивляет, что аргументы против оценивания и планирования исходят не от бизнесменов, для которых мы разрабатываем продукты или системы. Они понимают важность оценок и планов (и недостатки плохих оценок и планов).


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

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

А что насчет оценивания? Действительно ли нам нужно оценивать? Да, потому что оценивание является предпосылкой для планирования. Вы не сможете планировать без оценок. Эти оценки могут быть очень неформальными и очень неявными. В данный момент я лечу в Калифорнию. Перед посадкой я снял деньги в банкомате. Я предположил, что на предстоящие нужды мне необходимо $200. Эта оценка забрала у меня менее секунды, и я даже не осознал, что я что-то оценивал.

Когда Владелец Продукта говорит “Я предпочел бы добавить этот функционал, а не тот”, он действует на основании какой-то неявной оценки (возможно предположения) того, сколько времени займет разработка каждой функциональности. Когда программист решает в конце дня исправить ошибку, а не начать новую пользовательскую историю перед тем как идти домой. Он делает неявную оценку того, что ошибку он успеет исправить до конца рабочего дня, а закончить новую пользовательскую историю нет.

Команды, которые говорят “Мы не будем оценивать. Мы будем делать все пользовательские истории одинаковыми по объему работы”, на самом деле оценивают. Они предполагают, что объем работ в каждой новой истории такой же как и в остальных. Я готов поспорить - сложнее сделать все истории одинакового размера, чем использовать небольшой диапазон оценок усилий для разных историй. Такие оценки должны быть сделаны. Да, они могут быть подсознательными, но они сделаны. Те, кто пишут в блогах и новостях “оценивание - пустая трата времени, не делайте его”, - игнорируют такие типы оценивания.

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

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

К примеру, мы недавно добавили немного функционала на наш сайт по удаленному обучению eLearning course on Agile Estimating and Planning. Я не просил программиста, который делал эту работу, дать мне более чем поверхностную оценку. Я всё ещё достаточно хорошо разбираюсь в программировании, чтобы иметь понятие о том, как долго разрабатывать новый функционал. Также я достаточно давно с ним работаю и знаю насколько он быстр. Более детальная оценка ничего бы не изменила в данном проекте.

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


Переведено с английского проектом Agile Translations.
Оригинальная статья: Estimating and Planning Are Necessary for Maximizing Delivered Value.

ПОПУЛЯРНОЕ

Шаблоны декомпозиции Пользовательских Историй (User Stories)

Автор: Richard Lawrence Переведено с английского проектом Agile Translations   Хорошие Пользовательские Истории следуют INVEST модели , предложенной Биллом Вейком (Bill Wake). Они независимые ( I ndependent), обсуждаемые ( N egotiable), ценные ( V aluable), поддающиеся оценке ( E stimable), небольшие ( S mall) и тестируемые ( T estable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели. Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая” , однако, не сможет похвастаться тем же в случае с “независимая” и “ценная” . За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

Скрамбан - собираем лучшее

Автор: Илья Павличенко . Иногда я слышу фразу - «теперь у нас будет СкрамБан». И, к сожалению, наблюдаю, что чаще всего это означает, что у команды теперь не будет ни полноценного Скрама, ни внедренного должным образом Канбана. Хотя это понятие (СкрамБан) подразумевает и первое, и второе. Таким образом, команды лишают себя преимуществ обоих методов, переходя в серую зону неопределенности. Привожу цитату Алана Шалловея, одного из родоначальников Канбана (полностью его блог-пост по этому вопросу можно прочесть здесь ): « Теперь стало модно у многих Скрам команд уходить от итераций и кросс-функциональных команд и говорить, что теперь у них внедрен Канбан. Я принимаю то, что в Канбане отсутствует и первое, и второе. Но Канбан не определяется отсутствием итераций или кросс-функциональных команд. Он определяется визуализацией, управлением потока, наличием явных полиси и т.д. Если у вас был Скрам и вы решили уйти от итераций - у вас не Канбан. Вы даже и близко не подошли к тому, чтобы

Ретроспектива спринта - эффективный формат

Автор: Майк Кон (Mike Cohn) Перевод с английского Неважно, насколько опытной является Скрам-команда, при этом всегда существует возможность для ее улучшения. Не смотря на то, что хорошая Скрам-команда будет постоянно искать возможности для своего улучшения, она должна выделять короткий период времени в конце каждого спринта для сознательного размышления над тем, как идут их дела, и для поиска способов их улучшения. Все это происходит во время Ретроспективы спринта.

Планирование релиза: уходим от термина, но не от практики

Автор: Майк Кон (Mike Cohn) Перевод с английского. Я хочу обратить внимание на термин, используемый в Скраме (точнее, даже Аджайл термин), который во многом пережил себя: планирование релиза. Общепринятое использование "релизного планирование" заключалось в том(я так тоже делал), что мы смотрели в будущее на несколько спринтов вперед и пытались предсказать, что бы мы могли выпустить. Было бы хорошо в идеале эти предположения выражать в виде диапазона значений, возможно даже с использованием интервалов вероятности. В течение многих лет я учил команды делать именно так. Скажем, мы могли сказать, что “Мы уверены на 90%, что через шесть месяцев сможем выпустить продукт с функционалом в диапазоне между 150 и 200 стори поинтов.” Я до сих пор считаю эту практику полезной и каждый Скрам-мастер должен знать как это делается. Что на самом деле потеряло смысл, так это сам термин “планирование релизов”.

Аджайл Менеджер Проектов – кто это?

Автор: Карлтон Неттлетон (Carlton Nettleton) Переведено с английского проектом Agile Translations . Несколько недель назад я получил сообщение от своего бывшего ученика с печальными новостями – его компания уволила всех Скрам-мастеров и заменила их на “Аджайл Менеджеров Проектов”. Теперь он остался без работы, а Cкрам потерпел серьезную неудачу в их организации. Это было довольно грустно :(