Поговорим о том, почему сроки в разработке ПО *всегда* проебываются.
У меня за 15 лет разработки продуктов выработалось эмпирическое правило — любая фича занимает в 2 раза больше времени, чем думали изначально. Это правило работает для более-менее опытных команд. Неопытные команды тратят в 3 раза больше времени. Правило работает прекрасно на уровне фич, важных релизов или любых приличных кусков работы от месяца и выше. Хотите успеть к выставке через полгода? Сделаете ровно в 2 раза меньше, чем планировали. В январе обещаете клиентам выпустить новую систему нотификацией летом? Сделаете это в январе следующего года. Поэтому я давно перестал что-то обещать, я только прогнозирую и умножаю текущие сроки на нужный коэффициент.
Многим со стороны кажется, что все это бардак и вообще невозможно работать. Очень хочется навести порядок и получить нормальные сроки, которые можно спокойно поведать клиентам, подготовить маркетинговые мероприятия и быть уверенным в завтрашнем дне. К сожалению, оценка работы в нашей индустрии на дне, в связи с чем появляются движения вроде #noestimates.
Современный agile решает эту проблему примерно никак. Техника Planning Poker у любого опытного разработчика не вызывает ничего, кроме утробного смеха (который приходится сдерживать в присутствии скрам мастера). Ну в самом деле, вы собрались командой на Sprint Planning, вам Product Owner читает описание User Story, и вы должны, подумав примерно 3 минуты, выдать какую-то приличную оценку в зеленых попугаях.
Главная причина плохих оценок — высокая неопределенность. Вы не знаете ЧТО вы будете делать, и не знаете, КАК вы это будуте делать. У вас есть ИЛЛЮЗИЯ и того и другого, но нет никакого столкновения с реальностью. А реальность очень любит превращать ваши иллюзии в суровый марафон. Мы практически никогда не представляем объем работ в полной мере. Разум не может эффективно заглянуть в будущие месяцы разработки, он может оперировать только горизонтом около месяца. Типичный мой диалог с программистом такой:
— Андрей, сколько осталось до конца фичи?
— Две недели.
(спустя две недели)
— Ну что, уже скоро?
— Еще две недели.
Начало задачи — худшая точка для эстимейта. Мы знаем крайне мало. И нет никаких способов улучшения оценки, кроме получения дополнительных знаний. Больше знаем — даем более точную оценку. Поэтому если мы хотим иметь оценки получше, нужно начинать работу на прорыв и устранять неопределенности. Это в Экстремальном Программировании называли Спайками. Если после нескольких спайков мы начинаем четко видеть путь и решения всех сложных вопросов на этом пути, мы в целом можем улучшить качество оценки.
Большинство команд пытаются дать оценку без спайков и прототипов. В таком случае 2x — вполне нормальная ошибка. Никакие попытки проникнуть в задачу интеллектуально, без совершения реальной работы, не способны радикально улучшить качество оценки. Вы пытаетесь дробить фичу на юзер стори, их, в свою очередь, на таски и улучшить оценку через гранулярность задач. Но за этим разумным подходом вы либо вообще игнорируете неопределенность, либо сразу же в задачи закладываете решение, которое вряд ли является оптимальным.
Самая большая ошибка — придумывать решение во время эстимейта. Не делайте так.
P.S. Все это не имеет никакого отношения к простым повторяемым задачам. Для них нужно использовать Waterfall и не ебать себе мозг аджайлом.