В последнее время мне всё чаще и чаще приходится выслушивать негативные впечатления от моих друзей, знакомых и экс-коллег, связанные с переходом ИТ-компаний на гибкие (agile) метологии. В частности, наибольшую популярность (и как следствие, народное недовольство) снискал переход на Scrum.
С грустью наблюдая, как порочиться доброе имя Scrum-методологии, и вдохновлённый идеями lean production, я решился написать эту заметку чтобы перечислить основные ошибки, допускаемые компаниями и командами при переходе на agile, в частности Scrum. Некоторые из этих ошибок я уже приводил в своих предыдущих статьях или комментариях к ним, но собрать и обсудить их в одном месте мне всё-таки показалось ценным и актуальным.
Итак, основные антипаттерны перехода на гибкие метологии:
1. Непонимание роли руководства при внедрении методологии. Переход на многие гибкие методологии (Scrum, XP) подразумевает координальную смену задач и методов работы руководителей. В двух словах этот переход можно сформулировать как переход от управления к направлению, переход от приказов и указаний к рекоммендациям. Первая ошибка, которая допускается при таком переходе - подсознательное стремление сохранить за собой власть, ведущее ко всё тому же управлению, но замаскированному идеями agile. Вторая, не менее серьёзная ошибка прямо противоположна - неправильное понимание этого перехода может привести к устранению менеджеров от руководящих функций, когда руководитель перестаёт давать указания, но так и не начинает давать рекомендации. Роль руководителя при этом сводится к чисто формальным, секретарским функциям. Причиной этого может быть и неготовность руководителей давать аргументацию своему мнению (в старой модели им этого зачастую делать не приходилось) или боязнь невыполнения высказанных рекоммендаций.
2. Построение «системы», не обладающей необходимой гибкостью. Отсутствие опыта работы по новой методологии ведёт к тому, что новый процесс внедряется по инструкциям, буква к букве, что ведёт к негибкости и бюрократизации.
3. Начало внедрения не с «основ». При переходе на новые методологии руководство преследует конкретные выгоды, которые должна обеспечить методология: высокая производительность, качество и т.п. При этом некоторые практики нового процесса более очевидно ведут к этим выгодам, а некоторые - совсем не очевидно. В связи с этим возникает соблазн внедрить сначала более "выгодные" практики, а потом уже остальные. При этом не учитывается, что некоторые практики являются базовыми по отношению к другим, и внедрение вторых без первых невозможно. Пример: внедрение таких практик XP как рефакторинг или коллективное владение кодом без отработанной практики юнит-тестирования гарантированно приведёт к резкому ухудшению качества.
4. Изменяются рабочие места, но не меняются привычки. Провозглашение новых правил и следование этим правилам - это, как говорят в Одессе "две большие разницы". Недостаточное понимание новых идей всеми членами команды или слабое осознание выгод от перехода на новый процесс, слабая мотивация, отсутствие переходного периода с явно выраженными послаблениями в графике работ и количестве задач - это далеко не полный список ошибок, способных привести к тому, что новый процесс может соблюдаться лишь формально "для видимости", а в действительности саботироваться членами команды.
5. Все измерять (собирать данные), но ни на что не реагировать. Бесконечный анализ ситуации, вместо непрерывных улучшений («Паралитический анализ»). Большинство гибких методологий подразумевают сбор метрик и обязательную рефлексию - обсуждение ощибок, совершённых на предыдущем этапе, перед началом следующего. Распространённые ошибки в этой сфере - сбор метрик без их последующего анализа или неверная, слишком поверхностная интерпретация метрик; рефлексия без внесения изменений в процесс (или внесение симптотических, экстенсивных изменений).
6. Обходиться без поддержки. Отсутствие опыта работы команды по новой методологии и внедрение по букве инструкций таит много ошибок, неверных интерпретаций и недопонимания. Только участие в процессе перехода опытного инструктора, имеющего непосредственных опыт работы по новому процессу, может избавить команду от множества неверных поворотов и тупиков, или в отдельных случаях даже от построения совершенно неверной методологии.