– У меня там на дизайн формы в два раза больше времени…
– А у меня ещё на экспорт и отправку почты маленькие задачи.
– Добавлено, – оценка росла как на дрожжах. – Двигаемся дальше.
Так мы очень быстро проходили по всем пунктам, выбирая максимальные оценки и добавляя максимальное число задач. Я не выдержал:
– Владимир, а почему ты выбираешь максимальные оценки и, не разбираясь, добавляешь задачи в список? Как-то бездумно получается.
– Константин, мой опыт показывает, что если кто-то видит какую-то проблему, то он прав, эта проблема обязательно возникнет и мы потратим на неё время. – Владимир шёл по задачам, округляя все числа в большую сторону. – А это мне ещё все говорят, что я слишком оптимистичен.
Почему Scrum не решает менеджерских задач
Сразу скажу, что я очень уважаю Scrum как философию. Scrum привнёс очень много в индустрию разработки ПО. Достаточно вспомнить хотя бы скрам-митинги, которые сейчас используются повсеместно. И в продуктовой разработке, на которую Scrum ориентирован в первую очередь, результаты его применения очень хороши. Но проблема в том, что Scrum часто позиционируют как средство управления проектами, которым он совсем не является. Да и вообще, как средство управления Scrum вообще рассматривать не стоит. Давайте посмотрим, почему.
Сложность. В официальном “The Scrum Guide” Scrum определяется как нечто, что “легко понять”, но “трудно овладеть”. То есть если у вас Scrum не заработал, то это нормально. Scrum указывает некоторое направление, но совсем мало помогает в достижении ваших целей. Это не инструмент в обычном понимании.
Оценка и планирование. Что хочет знать заказчик, который приходит с некоторым проектом? Ему интересно знать, сколько будет стоить реализация его проекта, и когда будет результат. Какие ответы даёт на это скрам? Никаких. Это гениально, на самом деле, но ответа скрам не даёт. Сейчас даже про story point никаких упоминаний нет.
А как планировать какие-то даты? Если, например, нужно будет код интегрировать с куском, разрабатываемым другой командой, то на какую дату можно ставить эту интеграцию? Неизвестно.
Даже традиционные статистические методы предсказания конца проекта, которые неплохо работают в традиционных проектах (например, статистика багов), очень плохо работают в Скраме, так как он не даёт никаких ограничений на элементы баклога.
От руководителя проектов больше всего требуют конкретные сроки и прогнозы по их выполнению. Скрам тут не помощник.
Командообразование. Может быть, скрам как-то помогает сколотить команду в единое целое? Отнюдь. По скраму команда является самоорганизующейся (self-organizing), а скрам-мастер может только заниматься коучингом (coaching). А коучинг, между прочим, является сложнейшей менеджерской техникой, когда менеджер, абсолютно не высказывает своего мнения и помогает человеку прийти к решению самому. Как овладеть скрам-мастеру такой техникой? Ответа нет. Что делать, если в команде конфликты, если часть команды ведёт себя контрпродуктивно, если разные члены команды действуют неслаженно? Ответа нет.
Даже самые простые вопросы координации скрам не освещает. Например, у вас есть разработчики, тест-дизайнеры, автоматизаторы и ручные тестировщики. Как они должны работать, чтобы никто не простаивал, а спринт выдавал качественный результат? В начале спринта у тестировщиков нет тест-плана, а в конце спринта у тест-дизайнеров нет работы. Скраму это безразлично.
Управление большими командами скрам тоже не поддерживает, указывая, что команды больше 9 членов “нуждаются в слишком большом объёме координации”. А ведь размер команды как раз является одним из показателей мастерства менеджера. Скрам это не покрывает.
People management. Очевидно, скрам игнорирует более сложные вопросы стратегического управления людьми, как, например, мотивацию, профессиональный рост, повышение самооценки, обучение.
Риски и кризисное управление. Скрам заявляет, что следование ему позволяет контролировать риски, но никаких средств по управлению рисками не предоставляет. Предполагается, что максимум, что может пойти не так – это придётся “откатить” работу одного спринта. На практике, конечно, это совсем не так. Повсеместно встречаются проекты, в которых много одинаково критичных кусков, без каждого из которых система не нужна. Успех любого количества спринтов может быть легко перечёркнут одной проблемой, вылезшей в самом конце проекта.
И, конечно, скрам никак не помогает в ситуации, когда проект заходит в тупик по какой-то причине.