суббота, 13 октября 2012 г.

Я Ненавижу Scrum Planning

Жил-был один большой Проект, и писали его несколько поколений программистов. Шли годы, и проект стал настолько сложным и настолько большим, что уже не помещался в человеческой памяти. По  критериям, таким как количество строк кода, количество подсистем, сложность которая в теории систем определяется как количество подсистем и связей между ними, время билда, количество юз-кейсов, количество тест-кейсов, количество разных технологий,  очевидно что это уже не простая система, а очень сложная. Чтобы что-то сделать, нужно провести несколько дней а то и неделю, разбираясь в требованиях, а потом в коде. Разобравшись в спецификациях и существующем коде, можно осуществить разбивку на мелкие подзадачи для внесения изменений в систему,  например, если на реализацию функционала нужно 30 дней, то количество подзадач может быть 40-50, а на анализ и планирование может уйти  неделя.

Девелоперы решили использовать Scrum planning,  идея его в том чтобы собрать всю команду и дать им карты в руки, пусть обсудят задачи и выставят приблизительные оценки.  Планирование  происходит в митинг румe, у девелоперов нет ноутбуков, и в код они не смотрят. За несколько часов невозможно вьехать в тему, к тому же существует много способов решить одну задачу, и обсуждать и оценивать каждую из 40 или 50 под-задач можно по 10 минут,  получается что  вся команда должна ровести примерно 8 часов в митинг-руме, не учитывая перерывы на обед и кофе-брейки. Что интересно, только один человек (или два) будет реализовывать данную задачу и немного в теме, остальные 4 кидают карты с оценками которые получают пытаясь прочесть выражение лица тех людей, которые в теме, чтобы демонстрировать что они тоже involved и pro-active. Допустим, в команде 6 девелоперов, два из них в теме, остальные 4 не в теме. Все кидают карты с оценками, те двое, которые представляют себе код который им прийдется изменять, кидают карты с точными оценками, остальные 3 с не-точными, то есть вносят погрешности. С таким же успехом можно бросать кости и смотреть какая цифра на верхней грани.

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

Комментариев нет: