Ситуация: программист ошибся в оценке объема работ и просит расширения.
Классическая проблема. Причины, как правило, две:
- Некорректно поставленная задача, т.е. неправильно сформулированные цели или области применения разрабатываемого функционала, которые корректируются в процессе реализации. Проблема обоюдная, как постановщика задачи в лице менеджера продукта, так и тимлида, который вовремя не задал вопрос менеджеру продукта. Решается выделением большего количества времени на изучение задачи до момента начала реализации
- Некорректная оценка сроков реализации. Программист может просто не видеть потенциальных подводных камней или область реализации - не его сильная сторона.
Все проблемы решаются грамотным анализом задач, декомпозицией задачи на подзадачи, оценкой сроков исполнения несколькими участниками + выделением дополнительного времени на «неожиданности». Грубо говоря, если четыре программиста оценили задачу в 12, 40, 32, 80 часов, то отбрасываем крайние наибольшие и наименьшие сроки (предварительно получив объяснения, из чего складывалась оценка). Берем условные 40 часов, закладываем 30% на «неожиданности», получаем 52 часа.
Ситуация: код, написанный одним программистом с использованием стандартных фреймворков и CMS, не сразу понятен другому и требует много времени на изучение.
С проблемами понимания кода не сталкивались, сталкивались с вопросом «а почему реализовали именно так, а не иначе». Основная проблема здесь - слабое документирование, как целей конкретного функционала, так и самого процесса реализации. Как правило, ситуацию спасает наличие тестов, но без документирования неизбежно возникают излишние затраты времени при попытке масштабирования команды.
Ситуация: новый программист на проекте критикует предыдущего исполнителя и настойчиво рекомендует переделать все с нуля.
С подобной ситуацией сталкивались. Прежде всего, начинаем с беседы, почему сложилось такое мнение о предыдущем исполнителе. Чаще всего это говорит о недостаточной компетентности нового сотрудника, но бывает, что замечания справедливые – в этом случае они становятся частью технического долга. По нашей практике, переписать с нуля сильные программисты не предлагают.
Ситуация: разработчик просит выделить оплачиваемое время на рефакторинг своего кода и устранение дефектов, которые не видны пользователям системы.
Это нормальная ситуация. В процессе роста проекта могут появляться идеи оптимизации решений и появление новых технологий, позволяющих эффективнее решить проблему. Воспринимаем такие запросы как технический долг. Проводим общекомандную оценку для обсуждения положительных эффектов после доработок. Если код работает хорошо и не влияет на другие зависимости, а править его приходится редко или вообще не приходится развивать, то нецелесообразно его переписывать, если это трудозатратно.
В целом, большинство проблем удалось решить выделением большей части времени спринта на изучение и декомпозицию задачи (70% времени в среднем), а также обязательным ведением технического долга. Обязательные командные встречи (ежедневно) и контроль исполнения. Основная проблема – несвоевременная реакция команды, если программист «закопался», тогда процесс разработки становится хаотичным, сроки срываются. Как раз подобная проблема решается обязательными общекомандными ежедневными встречами.
Также крайне важно взаимодействие менеджера продукта и тимлида. Если взаимодействие между этими участниками постоянно и построено на доверии, то проблемы минимизируются.