Ложь, п#здеж и Agile
Что будет если вас укусит за срамное место SCRUM-мастер или почему у меня дергается глаз, при чтении новостей о внедрении Agile в оборонке и Росатоме.
Начну как обычно с конца — с результатов.
Давайте подумаем вместе, что же именно вы в итоге собираетесь получить:
предположу, что ожидаемым результатом вашей работы является программный продукт либо некий законченный сервиc. Но в любом случае это что-то осязаемое и работающее. И конечное.
Некоторые конечно приходят на работу «закрывать таски в трекере» за пайку риса зарплату, но речь сейчас про нормальных людей а не про говорящих животных, окончивших айтишные курсы.
Еще вам как-то надо уложиться в сроки, которые легко могут быть выдуманными, в бюджет, который может быть прикинут «на глаз» и все это в условиях «страшной неопределенности» и меняющихся требований — вроде все страшилки аджайло#бов собрал, нет?
Вообщем увы, но это все п#здеж ложь в пользу бедных, с которым вам обычно приседают на уши дорогие инфоцыгане сектанты консультанты.
Под соусом «новой и прогрессивой методологии», отправляющей проекты сразу в космос, разумеется.
Реальность как обычно проще и банальней.
Дрочьба как процесс
Святая троица (Agile-SCRUM-Kanban) — про процесс, а не про результат.
Суть всех гибких методологий — выстроить настолько гибкий, мощный и предсказуемый процесс разработки, чтобыни капли не пролилось мимоничего никогда нигде не сломалось.
Быстрые правки, быстрые изменения, быстрые релизы, быстрые оргазмы — одним словом все что угодно, кроме результатов.
Конечно же построение такого процесса это сложно, долго и что самое страшное — рано или поздно такой вот отлаженный процесс становится важнее конечного результата.
Каждый кто отправлял «pull request» в большой публичный проект — поймет о чем я ;)
Заканчивается это обычно тем, что проект просто замирает в развитии. Коммиты становятся все проще и меньше по объему, зато с идеальным оформлением и форматированием.
Все внутренние процессы обрастают какими-то дикими бюрократическими ритуалами:
Попробуйте как-нибудь оформить "feature request" для любого популярного проекта — ох#еете через неделю правок.
Формальности убивают производительность. Это закон. Помните об этом.
Какие еще замечательные бизнес-процессы мы с вами знаем?
«имитация бурной деятельности», «очковтирательство» и «пинание х#ев» — типичные замечательные рабочие процессы, которые встречаются повсеместно.
И все они просто идеально реализуются через аджайл, можно сказать в нем живут.
Творить х#йню, имитировать и бесконечно развлекаться на проекте с аджайлом — выгоднее чем нормально работать.
Воообщем где-то тут начинаются вещи, которые в приличном обществе стараются не обсуждать. Примерно как венерические заболевания и гемморой. Но рассказать о них все же стоит, благо на Хабре вы такое точно не прочтете ;)
У семи нянек дитя без глаза
Когда «все равны» и решения принимаются коллегиально — это замечательно, вдохновляет и дарует веру в людей и человечество в целом. Пока не доходит до ответственности за принятые решения.
И в случае аджайла постоянно получается так, что виноватых нет. Их почему-то никак не найти.
Вот кто гипотетически может отвечать за то что проект скатился в говно испытывает трудности?
Владелец продукта (Product Owner)? — а я только обрисовываю идею и даю перспективу: как мы всех победим, но в далеком будущем. Когда-нибудь.
Менеджер проекта? — а я только про сроки и бюджет знаю.
Бюджет из расчета « кол-во часов в неделю х часовую ставку программиста», разумеется. Риски? Риски знаю — дайте плюс 30% на риски и шоколадку.
Программисты? — (не смешите) проект не наш, мы только дорабатываем. Аналитики? — это не я, так хотели пользователи/заказчик.
В итоге стабильно получается, что ни ответственных ни виноватых на проекте нет. А жопа — есть.
Хотя сие далеко не самое страшное что вам может подарить увлечение гибкими методологиями.
Едем быстро но не туда
Самая частая проблема для проектов, где внедрена гибкая методология — отсутствие серьезных глобальных результатов:
Есть разработка, есть программисты, есть беклог и таски. Каждый день они что-то делают, закрывают таски, выкатывают релизы с обновлениями.
Вроде «по бумагам» все здорово и есть прогресс. А вот движения вперед — нет, ощущение что проект топчется на месте.
В этом и заключается главная подстава аджайла:
Дальше оказывается, что оценить положение дел на проекте, где есть только бесконечные спринты с нарезкой задач — затруднительно, если вообще реально.
Поэтому очень скоро этот проект готовится к земле и все начинается снова, но уже в другом месте.
Как только вы встали на рельсы аджайла — все, конец. Даже банальное обновление используемых ключевых библиотек становится кошмаром, поскольку часто не укладывается в логику и сроки «быстрых и коротких изменений», пропагандируемых в гибких методологиях.
Я видел это много много много раз:
как затираются или откатываются глобальные изменения, как теряется сложный рефакторинг, просто потому что не удалось уложиться во временные рамки, выделенные под такого рода задачи.
Вообщем запущенный проект на аджайле — эдакий летящий вперед паровоз, сметающий все на своем пути.
Быстро, мощно и предсказуемо — пока едет по проложенным рельсам и в нужном направлении.
А если рельсы кончатся или окажется что вы едете не в том направлении?
Реальная жизнь ведь сильно сложнее езды по накатанной колее — нужно изучать новые веяния на рынке, новые технологии. Нужно собирать фидбек от пользователей и постоянно выдавать что-то новое.
Временами при этом перекраивая проект как бог черепаху.
И никакие методологии, никакой даже трижды стабильный процесс разработки вам тут не помогут, будут только мешать.
Нет способа однозначно оценить риски и затраты на рефакторинг или еще какую сложную задачу. Всегда будет определенный риск и непредсказуемость.
Часто нет даже способа разбить ее на части и по-частям же реализовать:
Попробуйте например переехать с одной СУБД на другую в живом проекте, в качестве примера.
Но тем не менее, такие задачи тоже приходится делать, если вы хотите чтобы проект жил и развивался.
И мы это делаем, под вопли скрам-мастеров и треск аджайла ;)
Лучшие мировые практики
Ну ок, давайте теперь расскажу как это происходит в больших компаниях. Допустим есть существующий проект, с командой и этим вашим аджайлом — пилят некий софт, у которого давно есть пользователи.
Вообщем-то все работает хорошо и стабильно, но чего-то не устраивает:
не та ключевая технология, устаревший интерфейс, косой горб, недостаточная производительность, низкий выхлоп.
Словом, есть некий реальный или воображаемый дефект, «родовая травма», которую так просто не исправить.
Сажают рядом еще одну команду, которая не пересекаясь с первой, начинает писать новый проект с нуля — уже на нужных технологиях, с новым интерфейсом и без горба.
Новый проект точно также делается на гибких методологиях, но без старой кодовой базы, т.е с чистого листа.
Очень характерно для внутренних и B2B проектов на Java и .NET:
«выкинуть и написать с нуля» — практически девиз.
План, выполнение, результат
Возможно удивлю, но с точки зрения руководства, выделяющего ресурсы и оплачивающего весь этот цирк с конями — абсолютно все поставленные глобальные задачи конечны и имеют конечные сроки.
Не бывает такого на высшем уровне, чтобы кто-то платил за процесс достижения, а не за полученный результат.
Поэтому любые гибкие методологии живут с точки зрения «биг боссов» где-то глубоко в жопе внутри проекта. И проходят они по статье бюджета «сопровождение этого говна», но никак не там где «развитие проекта» и новые горизонты.
Не интересно вообщем занятым людям с деньгами слушать про «гибкие изменения» и «быстрые правки» — на верху речь всегда идет про конечный результат, требуемые ресурсы и их соотношение.
Поэтому у меня весь этот мусорный движ вокруг аджайла вызывает в основном печальную улыбку и тоску.
Какие ваши предложения
У меня нет для вас однозначного решения, как нет и 100% работающей замены гибким методологиям.
Нет также готового варианта действий для случаев из серии «вот тебе сто программистов — сделай из них армию победителей с их помощью крупный проект».
И даже гарантий на успех или хотя-бы попадание в сроки — тоже нет.
Потому что разработка это сложно, а развитие и обновление существующего проекта — многократно сложнее. Но делать это все равно надо, невзирая на какие-то там методологии.
Потому что только так достигается реальный результат и реальная а не нарисованная в отчетах победа.