В ответ на статью про смерть Agile
Часто практики становятся общепринятыми, ибо отвечают на множество вызовов. Например, Unix way проник в другие отрасли и сферы, подобие ООП существует в языках без классов, и прототипирование/тесты применялись в отраслях задолго до TDD/BDD. Редко когда бывают прорывные идеи и подходы, в корне меняющие все, и Agile, на мой взгляд, не из таких.
Вместе с тем, когда какой-то концепт и набор инструментов хорошо упакован и брендирован, он может выстрелить. Особенно если и широкая публика созрела, и момент наступил. Кажется, так было и с Agile. И его постигла судьба любых распространенных инноваций, на которые указал автор статьи - и имитация, переход в ритуал; и превращение в один из инструментов корпоративных тренеров ; и адаптация менеджментом для своих целей; и много других проблем.
Отмечу, что придерживаюсь подхода, что любой инструмент хорош для своей ниши. И Agile, его отдельные компоненты работают только в ряде миров Джоэла Спольски, но явно не во всех.
Почему оно работает
Но что же на самом деле, если дистиллировать, дает применение отдельных практик различными компаниями и командами и почему это может иметь другие названия, но закрепляется и будет жить в ближайшее время?
Вот некоторые обобщения из личного опыта:
Стартапам - низкая стоимость проверки гипотез. Люди страдают когнитивными искажениями - бизнес думает, что знает лучше клиента, разработчики уверены, что могут спроектировать правильно с первого раза. Единственная проверка - рынком (причем выбор метрик тоже непрост), и чем быстрее эволюция, тем выше шанс адаптации.
Командам - защита от бесконечной смены требований. Везде противопоставляют с Waterfall, но я нередко видел ситуации, когда изменения приходят на любой стадии разработки. Наличие двухнедельных или месячных спринтов позволяет фиксировать требования между релизами и повышает качество кода и инфраструктуры.
Разработчикам, тестерам, DevOps - иметь ритмичность работы и видеть результат труда, получать обратную связь. Нередко в хаотичных разработках продукт или делается вечно - а работа в стол демотивирует - или же продукт выходит нерегулярно, что также не дает ощущения стабильности. Регулярная разработка с инкрементальной доставкой результата помогает в большом количестве сфер, если человек интересуется, от роста собственной производительности до повышения скиллов по декомпозиции задач, навыков расстановки приоритетов, навыков командной работы.
Приоритеты. Это одна из самых главных вещей, которые любая ограниченная по времени система организации разработки дает как плюс. Что бизнесу, который учится выбирать главное, так и разработчикам, которые учатся аргументировать , почему данный рефакторинг важен или почему вот этот инструмент лучше два спринта порисерчить, но сэкономить потом год на поддержке, чем велосипед написать .
Эти подходы - ограничение разработки по времени, итерации, регулярные небольшие релизы, обратная связь от заказчика и горизонтальные коммуникации - появляются даже там, где не побывал продаван Agile методологии. К примеру, если вы будете изучать иностранный язык, или новую технологию, или делать сами pet проект, достаточно быстро многие люди приходят к схожим подходам.
Дисциплина и регулярность дают прогресс за счет накопительного эффекта
Инкрементальный результат делает любую ошибку меньшей и позволяет легче подстраиваться
Ограниченность по времени заставляет творчески использовать небольшие ресурсы, которых всегда не хватает
Поэтому, на мой взгляд, после взгляда в суть того, что предложил Agile, его идеи вышли широко за пределы того знаменитого манифеста, сделав жизнь людей гораздо лучше.
А то, что разные коучи сделали его одним из своих продуктов, корпорации сделали шильдик вроде «мы стали бережливыми», а команда джунов называет хаотическое движение стартапом по agile, то, к сожалению, является неизбежным следствием.
Когда не устраняют корень проблем
Очень часто корни проблем лежат не в команде, а в заказчике , в менеджменте, в корпорациях. Нередко это выражается в сломанных коммуникациях (смотри классическую картинку ниже). Вылечить такие проблемы нельзя попыткой внедрения Agile, как верно заметили в комментариях к исходной статье.
Когда Agile in name only
Разработчики, кстати, подстроились к тому, где Agile стали применять не к месту , или называть эджайлом все, что ни попади - появился другой манифест
Но тут остается пожелать следовать тем же заветам манифеста. Если не удается решить вопрос разговором с глазу на глаз, упомянув, что быстрый выпуск - это еще не все, в манифесте упомянуто,
Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
[...]
Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
то следует задуматься о поиске команды, где вопросам качества кода, инфраструктуры, выбора инструментов, и в принципе проектирования уделяется большее внимание. А иногда и подбору людей в команду, если уровень команды далек от профессионалов.
TLDR - практики из Agile в своей основе обобщают успешные паттерны организации людей для ответа на внешние вызовы. Будучи представленными сжато и брендированными, они проникли далеко в ИТ и применяются даже без исходного названия. Однако, в исходном посте есть верный посыл про недостатки и перегибы, когда любой хаос могут назвать Agile или сделать очередной бюрократический процесс "а-ля-ыджайл". Тут уже каждый решает сам, как быть.
