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

Автор: Джереми Дюваль, автор статей InfoWorld

 

Большинство оценок разработки программного обеспечения – полная ерунда.

 

Это не потому, что компании используют неправильные методы или инструменты. Структура работы по разбивке или основанная на аналогиях? Механическая или субъективная комбинация? Функция, пример использования или сюжетные моменты? SEER-SEM, WMFP или широкополосный Delphi? Отлично.

 

Проблема не в инструментах. Скорее всего, большинство оценок – это мусор, потому что они основаны на фундаментально ошибочном понимании того, как создается качественное программное обеспечение.

 

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

 

Шум и недетерминизм присущи программной инженерии

 

В средах Agile оценки часто основываются на баллах и скорости. Насколько «сложным» будет создание отдельной части решения? И сколько времени нам обычно требуется, чтобы завершить историю такой сложности?

 

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

 

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

 

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

 

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

 

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

 

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

 

Другими словами, эта неопределенность – это хорошо. Это признак того, что наши амбиции достаточно дальновидны, что мы беремся за значимую и стоящую работу. Плохая предсказуемость – это не проблема. Произвольные оценки таковы.

 

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

 

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

 

Плохие оценки приводят к плохому поведению, которое также вредно для бизнеса

 

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

 

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

 

Не можете разработать качественное решение за отведенное вам время? Найдите быстрое решение, чтобы закрыть тикет. Решение последующих проблем, которые вы создадите, – это проблема кого-то другого. Кому вообще нужны автоматизированные тесты?

 

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

 

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

 

Люди и взаимодействия создают большую ценность, чем процессы и инструменты

 

«Люди и взаимодействия важнее процессов и инструментов». Это одна из ключевых ценностей манифеста Agile. Это утверждение о том, что мы должны учитывать сострадание и этику человеческих существ. Это также утверждение о том, что сосредоточение внимания на людях, а не на процессах, приводит к более качественным результатам.

 

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

 

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

 

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

 

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

 

Дорожные карты, диапазоны и отношения – это выход

 

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

 

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

 

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

 

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

 

Чего, по нашему мнению, мы можем достичь с помощью имеющихся ресурсов? Что мы можем доставить и когда? Каковы наши планы резервного копирования на случай нехватки времени или ресурсов?
Эти разговоры приводят к предварительным дорожным картам и диапазонам: вот как, по нашему мнению, будет развиваться проект. А вот верхний и нижний пределы того, сколько времени, по нашему мнению, потребуется для завершения.

 

По мере продвижения разработки разговоры продолжаются. Если некоторые аспекты проекта оказываются более сложными для решения, чем ожидалось, откладываем ли мы какую-либо функцию? Выбираем более простое решение? Меняем дорожную карту, чтобы учесть дополнительное время?

 

Если (когда) мы придумаем более ценную идею в разгар разработки, изменим ли мы дорожную карту или сохраним эту идею для следующего раунда?

 

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

 

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

 

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

 

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

Ссылка на источник