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

Почему ваши оценки сроков не имеют значения

Автор: Морган Альстром
Перевод с английского проектом Agile Translations.


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

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


Как вы видите, нам необходима еще и оценка нагрузочной способности команды (capacity), чтобы эстимация имела хоть какой-то вес и связь с реальностью. Но беда в том, что и этого не достаточно. Когда мы занимаемся эстимацией, нам нужно быть в четком согласии друг с другом на счет того, что именно мы эстимируем. Нам надо иметь общий взгляд на предполагаемое качество выполнения, причем как на внешнее, так и на внутреннее. Каждый участник этого процесса должен ясно представлять себе ожидаемое поведение нашего решения. Если, скажем, заказчик ожидает на выходе Лексус, но разработчик наивно полагает, что ему предстоит изготовить детскую коляску – то в таком случае эстимация не будет иметь абсолютно никакой ценности. Каждый участник команды должен иметь одно и тоже представление об уровне внутреннего качества продукта. Может так случится, что разработчика вполне устраивает качество Windows 95, в то время как тестировщик ожидает от продукта качество уровня современной флагмагманской операционной системы – в таком случае эстимация так же не будет иметь никакого веса.

Теперь мы ясно видим, что помимо эстимации и оценки нагрузочной способности команды, нам необходимо еще и общее понимание качества продукта. Немаловажно понимать, что если мы делаем эстимацию, и она вдруг оказывается неверной – то эффект этой ошибки скорее всего растворится с течением времени (конечно, если речь идет не о систематических ошибках в эстимации). Скажем, если некой задаче была дана приблизительная оценка в 5 дней, но по факту она заняла все 10 (т.е. мы имеем 100%-ную ошибку в эстимации), то негативный эффект от этой ошибки в рамках 6-месячного проекта сведется всего к 4%. С другой стороны, любая ошибка в оценке нагрузочной способности имеет свойство умножать свое негативное влияние, если ее оставить без внимания.

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

Обобщенно это можно выразить так:

  • Ошибка в эстимации – последствия с течением времени линейно убывают; 
  • Ошибка в оценке нагрузочной способности (capacity) – последствия с течением времени линейно возрастают; 
  • Ошибка в качестве – последствия с течением времени возрастают экспоненциально.

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

Переведено с английского проектом Agile Translations.
Оригинальная статья "Why your estimates don’t matter".

ПОПУЛЯРНОЕ

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

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

Все о Скрам от Майка Кона

На сегодняшний день многие уже знают основы Scrum. Однако я часто сталкиваюсь с разночтениями, и даже спорами по некоторым моментам. Поэтому считаю, что нужно обратиться к истокам. Как, наверняка, многие знают Майк Кон – один из наиболее популярных Scrum-тренеров, он работает с этой методологией более 10 лет, написал 2 концептуальные книги по практикам Agile, а также множество интересных и ценных статей, является одним из основателей Scrum-альянса и Agile-альянса. По праву его можно считать тем специалистом, определениям которого можно доверять. Читать дальше...

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

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

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

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

Диаграммы Ганта и Agile проекты. Так уж они несовместимы?

Автор: Алексей Кривицкий. "Планы бесполезны, планирование необходимо". Ейзенхауэр Диаграммы Ганта – это традиционный механизм визуального планирования, который получил свою популярность благодаря артефакту традиционных проектов, который назывался Work Breakdown Structure (WBS), и продуктам Microsoft Project и Microsoft Project Server, которые позволяли конструировать и хранить WBS. Пропоненты Agile принципов много внимания уделяют визуализации и открытости планирования. Так почему же так часто в контексте Agile мы слышим критику в адрес диаграмм Ганта? Давайте разберёмся. Пару слов о терминологии. В данной статье " традиционными подходами " к управлению проектами (или просто традиционными проектами) называются те подходы или проекты, которые противопоставляются Agile проектам. Я не использовал термин «водопадных проектов», так как во-первых на практике настоящих водопадных проектов не так много, а во-вторых по мимо водопадных и Agile проектов есть ещё мн