Пока в Москве повальное увлечение методологией “скрам” меняется на “бирюзу”, в регионах так и продолжают внедрять “скрам”. Оба эти увлечения обычно не приводят ни к чему хорошему. В конце концов всё приходит к “у нас скрам, но не совсем” или “скрам — говно”.
Давайте посмотрим, почему же это так.
Кто пользовался scrum-ом? У кого он работал (в чистом виде)?
Для начала мне обычно интересно: пользовались ли вы “скрамом”, видели ли его? Обычно, это около половины читающих, слушающих.
Следующий вопрос, который мне интересен: у кого до сих пор он введён? И тут положительных ответов уже куда меньше.
— И как, по ощущениям: он работает? Довольны ли вы им? — Вот тут и начинается самое весёлое. Скрам то оказывается “хороший, но у нас не работает”.
А что такое Скрам?
Для тех, кто не в курсе вообще о чём я. Scrum — это одна из методологий управления проектами (wiki, официальный гайд). И она прижилась в такой сфере как “разработка ПО”. Вообще, она может использоваться в разных сферах… Но хайп всё же в разработке ПО.
Для тех, кто уже сходил по ссылкам становится ясно: скрам это не простая методология, в ней есть и роли, и события, и артефакты. Взаимодействия всего со всем прописано. То есть всё чётко: надо только взять её, рассмотреть на предмет: подходит нам / не подходит и жёстко придерживаться. Шаг влево, шаг вправо — всё, вы делаете что-то другое, а тут уже талант нужен.
Что использовали для этого? Что осталось после?
И говоря о “хайпе”, я не преувеличиваю (как вы уже могли видеть). Почти в каждой команде, где есть хоть сколько-то “модные” менеджеры, был разговор о том, чтобы внедрить ЭТО. Иногда это решение получалось протолкнуть.
И вот тут уже возникал вопрос: ну ок, скрам, а что делать то? А давайте посмотрим, как это устроено у других!
- Так, они собираются каждый день и обсуждают… И понеслись ежедневные полуторачасовые совещания…
- А добавим итерации… Ну по плану было 2 недели, но по факту - полгода…
Понятно, что просто так менеджеру никто не дал бы внедрять какую-то левую методологию (если, конечно, компания адекватная). Понятно, что у нас тут “цирк с конями” и с контролем и прогнозами всё плохо. Но в итоге частый результат:
- Мы использовали, нам не подошёл.
- У нас остался только stand-up meeting.
- А у нас ещё планирование прижилось (иногда покер, да)
Однако, если немного абстрагироваться от scrum и вернуться к здравому смыслу:
- Мы догадались ввести ежедневную планёрку, которая была даже у тех же дворников, работяг на заводах, в советских КБ…
- О! Мы таки додумались, что сначала неплохо бы понять, что нужно делать!
- Continuous integration… Мммм! Таки разделили функции исполнения и контроля!
И это уже не плохо! Но это просто здравые мысли, элементы системы. А методология как раз и позволяет подходить к работе систематически.
Когда скрам тупо не работает
Мы уже определились с тем, что часто то, что мы видим, что называют скрамом — не скрам. Однако, даже если соблюдать все правила, он может не работать:
- Служба поддержки. В этом случае задачи прилетают “внезапно”. И если это тех. поддержка, то задачи в основном исследовательские. Здесь крайне сложно определиться с объёмом работы, запланировать.
- Нет понимания, что нужно делать даже сегодня. Это может быть связано с чайка-менеджментом, управлением грибами и постоянным искусственным авралом. Тут важно, что скрам внедряется не только в команде разработки, а на целом продукте / организации.
- Саботаж. Может быть вызван конфликтом идей, личностей, сопротивлением всему новому.
- Когда всем класть на продукт/услугу. Далее рассмотрим почему.
- Когда его внедряют, не задумываясь (карго-культ).
И тут самое время немного поговорить о методологическом безумии, о том, что виноват не Scrum.
«Методологическое безумие». Безграничная вера руководителя в методологию с большой буквы «М» — всеобъемлющую теорию того, как следует решать весь класс задач, возникающих в процессе производства. «Методологию создавали умные люди, а исполнители некомпетентны!»
Методология принимает все решения, люди не принимают решения вовсе. Многоступенчатая бюрократия. Все процессы регламентированы. Все делается по инструкции. Эксперименты запрещены. Применяемые методы ограничены. Установлен тотальный контроль соблюдения регламентов. Инструкции постоянно разрастаются вследствие попыток учесть все возникающие новые ситуации.
Внедрены всеобъемлющие нормы и метрики. Большая часть времени исполнителей тратится на соблюдение правил и писанину, которую никто никогда не читает. Большая доля «сизифова труда».
Зачем вообще всё это? Чего мы хотим добиться в идеале?
лол. это уже давно индустриальная профессия с отлично налаженными процессами
— Vladimir Starkov (@iamstarkov) 13 июня 2017 г.
И всё же, менеджмент в IT ещё крайне молод и слаб. Мы даже толком не умеем планировать сроки! Говорить о прозрачности работы, слаженности коллектива (продажи/разработка) во многих компаниях вообще не стоит. Обычно это так:
- Менеджеры по продажам вангуют, какие возможности у продукта есть, обещают реализацию того, что нет и ездят подписывать бумажки.
- + Делают вид, что всё хорошо, успокаивают клиента.
- Разработка упарывается грибами, придумывая невероятные кейсы, строя интерфейсы классов абстракций монойдов категорий эндфункторов.
- + Обещают, что “завтра” всё будет.
Но ведь все мы уруру и котики! И не хотим никого подставлять...
- Хочется, чтобы мы понимали, что происходит, как долго это будет.
- Если что-то пошло не так - узнать об этом сразу, управлять проблемами/рисками.
- Чтобы процессы ускорялись,
- а баги не возвращались.
- Чтобы делалось то, что нужно, а не то, что написано в ТЗ!
“Shut up and take my money!”
- Люди и взаимодействие важнее процессов и инструментов
- Работающий продукт важнее исчерпывающей документации
- Сотрудничество с заказчиком важнее согласования условий контракта
- Готовность к изменениям важнее следования первоначальному плану
То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.
Не правда ли, звучит красиво и разумно? Так вот берите эту идеологию и используйте! http://agilemanifesto.org/ 2001 год. Две тысячи, мать его, 1ый год!
А знаете в чём самая весёлая часть этой заметки? Что скрам — это одна из методологий, базирующихся на идеологии Agile! То есть мы пытаемся пропихнуть сразу скрам, даже не подготовив базу из аджайла! Строим дом без фундамента!
Если же мы построим нашу команду по принципам agile, будет не так важно, что вы используете: классические методологии, Scrum, Kanban, да хоть свою придумайте! Если есть:
- понимание: что и зачем,
- чего хотим достичь,
- понимание внутри команды,
- понимание внешнего мира,
- готовность принимать новое
— всё получится!