Как правильно оценивать сроки выполнения задач программистами. Часть 2

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

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

Наработка опыта оценки задач

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

Младший разработчик

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

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

Разработчик

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

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

Ведущий разработчик

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

Навык оценки выполнения задач растёт как производная от функции роста следующих показателей:

• скиллы кодинга;
• умение проектировать;
• изучение технологий и особенностей их реализации в вашем проекте (в простонародье — костылей);
• знание предметной области.

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

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

Декомпозиция задач

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

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

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

Недекомпозируемые задачи

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

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

Для творческих решений создается R&D-задача (Research and Development), чтобы поиграться и сначала понять, что делать, а уже потом оценивать. Такую задачу берут опытные разработчики, способные за пару дней разобраться в требованиях к интеграции, сделать набросок архитектуры, нарисовать диаграмму взаимодействий, выбрать наилучшую библиотеку или фреймворк для использования.

Результатом R&D-задач являются новые задачи. Да, смейтесь, “он создавал задачи, чтобы создавать задачи”, но другого пути нет. Архитектурная секция на собеседованиях — это скомканный вариант проектирования приложения, в действительности оно занимает гораздо больше 40 минут. Эту работу не всегда можно увидеть на скрам-доске, техлид может сделать её во внерабочее время, просто потому, что ему интересно. Или решение является чем-то, что он уже делал в своей карьере, и остаётся только механическая разбивка на задачи. Но и это требует определённых усилий. Без проектирования невозможно создать хорошее ПО.

Шаги на пути развития

Развитое чутьё — это, конечно, хорошо, но лучше подходить к вопросу аналитически. Далее я опишу правила, которые стали для меня островками надежды в океане безнадёги (оценок).

• Всегда нужно быть уверенным в том коде, который ты оцениваешь. Код бывает разный. Если не повезло и проект в непрерывной разработке уже много лет, на нём менялись подходы и разработчики, то нельзя быть уверенным даже в свежем коде. Он, скорее всего, взаимодействует с чем-то, что трогать в текущем релизе не стоит. В этом случае перед оценкой нужно всегда глазами пробегать стеки вызовов и API, которые планируют меняться. Знать, что покрыто тестами, а что предстоит покрыть, прежде чем вносить изменения.
• Не следует давать оценку на основе плохо описанных требований. Если учитывать непрозрачность требований в оценке, то это может повысить уровень напряжённости, поэтому лучше всегда прояснять требования полностью до оценки. Гораздо хуже допустить ошибку в трактовке требований и реализовать не то, что ожидается. Поэтому лучше помнить, что все участники процесса находятся в одной лодке, и сохранять хорошую атмосферу.
• Нужно стараться планировать задачи так, чтобы не делать длительных перерывов в выполнении. Вспоминать после отпуска, что ты делал и зачем ты начал этот рефакторинг, всегда сложнее, чем принять решение об этом в первый раз. Это крайне негативно отражается на соответствии оценок плану.
• Оценивая крупную фичу, следует всегда закладывать время на стабилизацию решения. Например, если фича заняла месяц разработки, то дня 2-3 следует выделить на то, чтобы просто прокликать юзкейсы самому. Непременно что-то всплывёт ещё до передачи всего проекта в QA. Возможно, потребуется подебажить интеграцию с другими командами или раскопать в логах неожиданный артефакт. Не стоит закладывать это время в каждую задачу, оно потребуется, когда весь код уже будет написан.
• Если фича настолько крупная, что к ней подключены более одного разработчика, то декомпозицию может проводить только один из них. Но оценивать задачи должны все участники, предварительно ознакомившись с документацией. В данном случае идеальным форматом оценки может быть Скрам Покер (Scrum Poker).
• Не стоит использовать покер в поляризованных командах с низким фактором автобуса. Либо большая часть команды не будет знать особенностей задачи и оценки большинства участников будут взяты с потолка. Либо придётся потратить очень много времени на внедрение в контекст задачи людей, очень косвенно связанных с ней. Но даже это может не быть достаточным условием для точной оценки большинством.
• Если происходят перестановки и на проект выделяется новый программист, то ему нужно дать время на погружение. В зависимости от сложности новичок может потратить от дня до недели, чтобы сначала всё понять, задать вопросы и только потом браться за задачи. Более того, стоит ожидать, что первые задачи будут с просадкой производительности. Это неизбежная плата за ротацию.

Запрет на пессимизм

На пути получения опыта мы часто хотим компенсировать свой оптимизм, приведший к ошибкам ранее, и из-за этого перестраховываемся. Шутка, опубликованная в середине прошлого века о том, что работа заполняет всё время, отпущенное на неё (закон Паркинсона), отлично применима к разработке ПО.

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

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

Если у вас есть удачные опыты с разумным пессимизмом, было бы интересно прочитать об этом в комментариях.