Архивы для Апрель, 2011

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

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

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

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

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

Последняя причина связана с фокусом на важных вещах. Тут все вообще непонятно. Как связаны оценки с приоритетами задач? В Scrum только Product Owner управляет приоритетами и его выбор может зависеть или не зависеть от ваших оценок. Но, добровольно брать задачи «попроще» – это принцип, который противоречит разумной логике определения функционала проекта на итерацию или релиз. Большая оценка говорит заказчику о том, что, возможно, стоит повременить с данной функциональностью в пользу другой чуть менее важной, но гораздо более простой. Это всего лишь дополнительная информация для принятия правильного решения.

Так стоит ли отказываться от оценок? На мой взгляд, только при определенных обстоятельствах. К примеру, если планирование вашего продукта не предполагает вариаций на тему объема функциональности. То есть, либо продукт готов целиком, либо он не готов вовсе. В таком случае, если вам повезло с замотивированной командой профессионалов, то оценки почти не представляют ценности. Вы и так знаете, что команда сделает все правильно: разобьет большие задачи на части, будет контролировать время разработки, сделает выводы из собственных ошибок, произведет нужный функционал вместо интересной архитектурной поделки и так далее. При этом можно работать как итеративно с использованием Scrum, так и с потоковой моделью Kanban. Только для определения объема работ на итерацию нужно использовать другие методики, отличные от Velocity. Приведенный пример скорее является исключением из правил, особенно в контексте рынка аутсорсинга.

Практика оценивания и правильного использования оценок для улучшения процесса разработки является очень интересной темой. Я планирую рассказать о ней подробнее в своем докладе «Методы оценок в Agile проектах» на конференции AgileBaseCamp Киев 16 апреля. Приходите, будет интересно!