Относительная оценка — это пустая трата времени, и не только пустая трата времени, но и наносящая ущерб гибкой разработке и доставке программного обеспечения.
Нижеследующий анализ основан на работе многих ведущих тренеров по Agile и экспертов по трансформации в индустрии разработки программного обеспечения, а также на моем опыте работы инженером-программистом и руководителем Agility в нескольких специализированных группах.
Вдохновлены Алленом Холубом, Васко Дуарте, Вуди Зуиллом, Дэном Нортом и Марти Кейганом.
Нам нужно остановить все относительные оценки.
Относительная оценка не имеет значения. Нулевое значение.
Оценка — это пустая трата времени, и не только пустая трата времени, но и вред для гибкой разработки и доставки программного обеспечения.
Вы можете утверждать, что оценки основаны на наблюдении за прошлым поведением, но программное обеспечение — это постоянно расширяющийся мир, и проблемы, с которыми мы сталкиваемся сегодня, — это не те проблемы, с которыми мы столкнемся завтра. Регулярно мы внедряем то, что еще никогда не было реализовано.
Проблема с этими догадками в том, что они всегда ошибочны. Это то, что мы все знаем, но почему-то ведем себя так, как будто не знаем этого.
Отчет о хаосе
«Римские мосты древности были очень неэффективными сооружениями. По современным меркам они использовали слишком много камня и, как следствие, слишком много труда для строительства. За прошедшие годы мы научились строить мосты более эффективно, используя меньше материалов и труда для выполнения одной и той же задачи».
- Том Клэнси, Сумма всех страхов
Отчет о хаосе — это исследование, основанное на показателях успешности ИТ-проектов и стратегиях управления проектами. Это исследование часто называют авторитетом де-факто в отношении показателей успешности ИТ-проектов. Успешные проекты определяются как отвечающие всем требованиям, завершенные вовремя и в рамках бюджета.
Мосты обычно строятся вовремя, в рамках бюджета и не рушатся. Программное обеспечение, с другой стороны, редко бывает вовремя или в рамках бюджета.
В Отчете о хаосе говорится, что 80% всех проектов в мире разработки программного обеспечения либо терпят неудачу, либо выполняются так поздно, что классифицируются как неудачные.
- Среднее превышение времени всех программных проектов: 222%
- Средний перерасход средств для всех программных проектов: 189 %
Почему это?
Это потому, что мы не знаем, как оценивать программное обеспечение.
Когда-то я участвовал в преобразовании LeSS для глобальной организации. Объем составлял 120 инженеров, уже разделенных на дюжину фиче-команд, и уже несколько лет практикующих некую форму Scrum. В то время я был скрам-мастером в одной из специализированных команд.
После 2 лет использования LeSS, несмотря на множество agile-коучей, консультантов, сертификаты инженеров и предыдущий опыт работы с agile, я понял, что это не работает. Я просмотрел каждый спринт для каждого FT, чтобы обнаружить, что каждая оценка совершенно неверна, каждый спринт никогда не придерживался, скорость никогда не была постоянной и постоянно менялись масштабы.
В некоторых крайних случаях команды предполагали, что они выполнят почти на 500 % больше работы, чем им удалось выполнить на самом деле.
После года использования LeSS (на полпути преобразования) было привлечено PI Planning (приращение продукта), чтобы попытаться решить наши проблемы. К сожалению, это только усугубило ситуацию. Я приберегу свою критику PI Planning для другой статьи.
Интересно, что данные, которые я собрал для этих 12 специализированных команд, почти идеально совпали со статистикой, представленной в The Chaos Report.
Одна конкретная команда действительно выделялась довольно точными оценками. К счастью, у меня были тесные рабочие отношения с инженером из этой команды, поэтому я хотел выяснить, как они это делают. За кружкой пива они признались, что исправляли цифры, потому что их менеджер пытался микроконтролировать все, что делала их команда.
Оценки - ложь
«Очки Story Points были придуманы, чтобы скрыть продолжительность, чтобы определенные менеджеры не давили на команду из-за оценок»
- Рон Джеффрис (один из трех основателей методологии разработки программного обеспечения Extreme Programming примерно в 1996 году.
Каждый инженер-программист, которого я когда-либо встречал, в тот или иной момент жаловался мне на то, что менеджеры воспринимают свои оценки как договорные соглашения. Популярные методологии масштабирования Agile, такие как Less и SAFe, только преувеличивают эту проблему несколькими факторами.
Если инженеры знают, что эти оценки выдуманы и не работают, почему не знает наше руководство? Все полагаются на то, что не работает.
Вуди Зуилл (известный в основном популяризацией моб-программирования) придумал хэштег #NoEstimates, чтобы попытаться начать революцию в своих проблемах.
«#NoEstimates — это хэштег на тему изучения альтернатив [времени, усилий, затрат] для принятия решений в разработке программного обеспечения. Это способы принимать решения с «NoEstimates».
— Вуди Зуилл
Как только вы добавляете оценки к проекту, вы больше не можете иметь устойчивый темп, потому что, как только вы начинаете оценивать, у вас есть сроки, сроки, которые не основаны на фактах, и как только у вас есть нереальные сроки, у вас есть люди, работающие 12 часов в день, чтобы уложиться в эти сроки.
Скорость
Определение скорости. В конце каждой итерации команда суммирует оценки усилий, связанных с пользовательскими историями, которые были завершены во время этой итерации. Эта сумма называется скоростью. Зная скорость, команда может вычислить (или пересмотреть) оценку того, сколько времени потребуется для завершения проекта, на основе оценок, связанных с оставшимися пользовательскими историями, и предполагая, что скорость оставшихся итераций останется примерно неизменной.
Velocity позволяет вам использовать прошлые данные, чтобы спрогнозировать дату завершения, используя количество завершенных Story Points по сравнению с оставшимися Story Points.
Вот некоторые домашние задания, которые можно попробовать с данными Sprint:
Возьмите проект, находящийся в процессе выполнения, используя баллы Story Points, рассчитанные с помощью Фибоначчи, и экстраполируйте расчетную дату завершения, сравнив выполненные SP с течением времени с оставшимися SP.
Повторите со всеми Story Points, преобразованными в добавочные значения (1,2,3,4,5).
Повторите со всеми историями, имеющими значение 1.
Вы можете обнаружить, что получаете один и тот же ответ со всеми тремя расчетами…
Если это относится и к вам, то почему мы вообще занимаемся оценкой? Каждая история может по умолчанию иметь значение 1.
Что вообще такое Истории?
История — это короткое повествование, описывающее, как клиент делает что-то ценное. Нет понятия времени, и оно не должно быть замаскированным способом написания функционального требования.
Приоритет — это единственная ценность, по которой вы должны сравнивать истории.
«По нашим оценкам, эта история займет 3 недели».
«Извините, это не вписывается в наш двухнедельный спринт. Можете ли вы без необходимости разбить его на разные истории, чтобы он мог поместиться в наш спринт. Большое спасибо."
Клиенту все равно, был ли он доставлен в 1 или 10 историй.
Почему мы измеряем?
Менеджеры принимают бизнес-решения на основе ошибочного представления о том, что оценки точны. Они думают, что это число, которое группа инженеров вытащила из шляпы, имеет какую-то реальность.
Даже в идеальном мире, где мы можем оценивать точнее, попадание в вашу оценку не имеет значения. Если оценка настолько важна, что вы устанавливаете вехи для продвижения своего проекта, и о вас судят на основании того факта, что вы достигли этих вех, что произойдет, если вы сделаете не то, что нужно клиенту, но вовремя?
Время — неправильная мера успеха, раздражаемая только оценкой. Перестаньте измерять время и вместо этого измеряйте ценность, доставляемую клиенту.
Психологические факторы
Мотивация инженера редко рассматривается в практиках Agile и Transformation, которые сосредоточены на относительной оценке.
Современные гибкие методологии часто включают сложные системы для отслеживания того, выполняет ли команда работу, которую они оценили при планировании приращения продукта или планировании спринта. Затем инженеры тратят огромное количество времени на ложь о своих оценках, обещания и попытки геймифицировать общие показатели. Это вызывает огромные проблемы с мотивацией. Самоэффективность, которая является частью устоявшейся модели психологического благополучия (модель Циммермана, объясняющая самоэффективность), — это вера в то, что вы можете что-то сделать, и связанная с этим мотивация. Если ваши сроки и оценки не имеют смысла, и вы слишком долго лжете об этом, то вы не можете построить структуру убеждений или мотивацию вокруг выполнения этого, когда это влияет на ваш интерес даже к попытке сделать это. Нам нужно уметь строить структуры убеждений вокруг системы, которой мы следуем.
