Сколько времени нужно, чтобы завязать шнурки? Ну, секунд десять. А чтобы написать инструкцию, как завязывать шнурки?

Вот и в софте у нас самая честная оценка — я не знаю.

А как быть, когда все же надо дать оценку? Чтобы ответить на этот вопрос, подготовил небольшой обзор, в котором мы рассмотрим:

что твердят источники
что творит индустрия
что говорит здравый смысл

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

Что твердят источники

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

И почти сразу становится понятно, что подход этот работает не так хорошо, как, например, в строительстве. Уже в 1970 Winston Royce в своей известной на весь мир статье пишет:

Я верю в эту идею, но описанная реализация оказывается рискованной и сулит неудачу. <...> можно ожидать отставания от графика и/или затрат на 100%.

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

Через 5 лет выходит другой памятник нашей индустрии, не менее эпохальная книга Фреда Брукса "Мифический человеко-месяц", известная, например, тем, что в ней был сформулирован знаменитый Закон Брукса: "Если проект не укладывается в сроки, то добавление рабочей силы задержит его ещё больше."

Книга была написана по следам разработки одной из первых в истории операционных систем IBM OS/360. Вот, что Брукс пишет про эту разработку прямо с предисловия:

Руководство разработкой OS/360 было очень поучительным, хотя и полным расстройств. <...> система вышла с задержкой, потребовала больше памяти, чем предполагалось, стоимость разработки в несколько раз превысила запланированную, и первые несколько версий функционировали не слишком удачно.

Там же он оптимистично напишет:

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

Закат водопада

Уже через 12 лет тот же Фред Брукс, разочарованный положением дел пишет статью "No Silver Bullet", где констатирует:

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

В 1994-м году не менее известный специалист в области разработки программного обеспечения, автор UML-нотации, Грейди Буч, напишет:

Мы часто называем это состояние кризисом программного обеспечения. Но, честно говоря, болезнь, которая длится так долго, должна называться нормой.

В девяностые уже подкатывает реальная статистика, и мы видим, что:

Средний крупный программный проект опаздывает на год и на 100% превышает бюджет (Standish Group, 1994, Jones, 1997, Johnson, 1999).

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

Расцвет Agile

С появлением легковесных методологий, таких как Скрам и XP, постепенно начала уходить необходимость в больших оценках на всю длину проекта. Поначалу, скорее по привычке, оценки проводились, основываясь на таких методиках, как XP Planning Game. Это как раз та самая, которая со сторипоинтами и Velocity.

Тут я вам порекомендую ознакомиться лекцией Дяди Боба с шикарной демонстрацией этой практики. Да и, в целом, вся лекция, безусловно, заслуживает внимания.

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

В большинстве бигтех-компаний сейчас уже наступила эра Continuous Delivery и Lean Startup, где релиз не стоит ничего, а основа для принятия решения о скоупе - не расчёты бюджета на основе оценок методом пальцем в небо, а максимально дешёвый эксперимент и аудит наиболее приоритетных направлений работы.

И этот обзор замечательных источников хочу завершить шикарным докладом Allen Holub "No estimates", где он, по сути, венчает всю нашу эволюцию главной идеей: скорее всего, вам не нужна оценка. А на случай, если вам все же какая-то оценка нужна, тут же он приводит хороший способ оценки, основанный на подсчете сторей.

Что творит индустрия

А всё вместе: и водопады, и аджайлы, и continuous delivery, и что только душе угодно.

Бюрократические организации и заказная разработка

Эти все никак не уйдут от проектов с фиксированным скоупом и, следовательно, с фиксированным бюджетом.

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

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

Бюрократам оценки нужны, что обосновать рентабельность проекта: без расчётов там никто ничего делать не будет. И расчёты должны быть не абы какие, а самые серьёзные, под стать серьезным топам серьезной организации. Для начала оценивается, сколько сэкономит/заработает проект. Естественно, с потолка. Оттуда же берутся оценки, сколько проект будет стоить. Потом из одного вычитается другое и получается профит.

Если профит никакой, то большая организация за него не возьмётся. Поэтому, чтобы профит был большой, проекты должны быть обязательно на 12-18 месяцев разработки и на десятки программистов. Ну и, чтобы начальство не зарубило гениальную идею, оценку стабильно занижают, а ожидания завышают заинтересованные и амбициозные люди.

Именно в таких процессах и происходят регулярные отмены проектов из-за "внезапных" открытий, что оценка и, получается, бюджет не соответствует объёму работ. Ещё чаще по этим же причинам там случаются срывы сроков, работа в минус, долгие доводки по гарантийке. А, в конце концов, как вишенка на торте, разочарование от того, что система, возложенных на неё надежд, не оправдывает: свою задачу не выполняет или выполняет плохо. А помимо этого еще и 2/3 фич пользователями не используются, как из года в год показывают одно исследование за другим, как, например. вот эти:

<...> в исследовании компании DuPont говорилось, что только 25% функций системы действительно необходимы. Исследование Standish показало, что 45% функций никогда не использовались и только 20% функций использовались часто или всегда.

Time&material в таких местах считается исключительной особенностью "продуктовой разработки" и бигтехов.

Вторая часть индустрии

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

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

Faux-Agile

Третья группа - это подгруппы первых двух. Те, кто считает, что, если не оценивать, то это и не аджайл никакой. Этим оценки нужны только для "аджайла". Вот тут все "бестпрактисы" по оценкам и обитают: спринты, сторипоинты, Фибоначчи, planning poker и майки.

"И тогда мы решили, что один митинг равен одному сторипоинту..."

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

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

Ну и для просто для статистики

Есть ещё четвёртый вариант, где клиент просит от вендора какую-то фичу, а вендор ее оценивает, чтобы выкатить счёт за неё, который клиент оплачивает либо по фактическим трудозатратам, либо по оценке

Что говорит здравый смысл

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

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

В остальных случаях, судя по всему, оценки обычно нужны не очень часто. Когда требуется быстро оценить небольшой объём работ, чтобы оперативно принять какое-то решение, то обычно всегда можно просто спросить разработчика. Если понадобилось предсказать что-то большое, то можно сделать так, как рекомендовал Allen Holub:

декомпозировать работу на отдельные фичи
посчитать их количество
померить скорость реализации какой-то части этих фич (число фич на время)
экстраполировать эту скорость на весь скоуп.

Меня зовут Саша Раковский. Работаю техлидом в расчетном центре одного из крупнейших банков РФ, где ежедневно проводятся миллионы платежей, а ошибка может стоить банку очень дорого. Законченный фанат экстремального программирования, а значит и DDD, TDD, и вот этого всего. Штуки редкие, крутые, так мало кто умеет, для этого я здесь - делюсь опытом. Если стало интересно, добро пожаловать в мой блог.

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