Как хорошему разработчику не стать плохим менеджером - Константин Борисов Страница 25

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

Сложность. В официальном “The Scrum Guide” Scrum определяется как нечто, что “легко понять”, но “трудно овладеть”. То есть если у вас Scrum не заработал, то это нормально. Scrum указывает некоторое направление, но совсем мало помогает в достижении ваших целей. Это не инструмент в обычном понимании.

Оценка и планирование. Что хочет знать заказчик, который приходит с некоторым проектом? Ему интересно знать, сколько будет стоить реализация его проекта, и когда будет результат.  Какие ответы даёт на это скрам? Никаких. Это гениально, на самом деле, но ответа скрам не даёт. Сейчас даже про story point никаких упоминаний нет.

А как планировать какие-то даты? Если, например, нужно будет код интегрировать с куском, разрабатываемым другой командой, то на какую дату можно ставить эту интеграцию? Неизвестно.

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

От руководителя проектов больше всего требуют конкретные сроки и прогнозы по их выполнению. Скрам тут не помощник.

Командообразование. Может быть, скрам как-то помогает сколотить команду в единое целое? Отнюдь. По скраму команда является самоорганизующейся (self-organizing), а скрам-мастер может только заниматься коучингом (coaching). А коучинг, между прочим, является сложнейшей менеджерской техникой, когда менеджер, абсолютно не высказывает своего мнения и помогает человеку прийти к решению самому. Как овладеть скрам-мастеру такой техникой? Ответа нет. Что делать, если в команде конфликты, если часть команды ведёт себя контрпродуктивно, если разные члены команды действуют неслаженно? Ответа нет.

Даже самые простые вопросы координации скрам не освещает. Например, у вас есть разработчики, тест-дизайнеры, автоматизаторы и ручные тестировщики. Как они должны работать, чтобы никто не простаивал, а спринт выдавал качественный результат? В начале спринта у тестировщиков нет тест-плана, а в конце спринта у тест-дизайнеров нет работы. Скраму это безразлично.

Управление большими командами скрам тоже не поддерживает, указывая, что команды больше 9 членов “нуждаются в слишком большом объёме координации”. А ведь размер команды как раз является одним из показателей мастерства менеджера. Скрам это не покрывает.

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

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

И, конечно, скрам никак не помогает в ситуации, когда проект заходит в тупик по какой-то причине.

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