Пожалуй, каждый человек, имевший дело с русским IT, слышал об Agile. В свою неопытную бытность я спрашивал у разных людей: "А что же такое этот Agile?" В этот момент часто в помещении повисала неловкая пауза, а затем люди начинали очень заумно размусоливать какую-то бессмыслицу, что служило очевидным маркером полного непонимания предмета.
При этом каждый размусоливал по разному. Ректрутеры важно хвастались наличием в компании Agile. Менеджеры с глубочайшим почтением отмечали высокую эффективность и пользу Agile. Программисты обычно хитро улыбались, мол всё проходили, всё пониманием, Agile - это пузырь. Но нравится/не нравится это отношение, то есть категория субъективная, а здесь я поведаю о конкретных вещах, параллельно пояснив, кто в чем не прав. Итак, начнём.
Перенесемся на 30+ лет назад в Америку и взглянем на ведущие компании, занимающиеся разработкой программного обеспечения. В то время цикл разработки представлял примерно следующее. Отдел аналитики начинает составлять техническое задание, долго и скурпулезно они решают, какой функционал нужен конечному пользователю, и описывают это в соответствии со множеством стандартов, принятых в компании. Затем полученное техническое задание передаётся в отдел проектирования, где создаётся архитектура будущего приложения со схемами и графиками в соответствии с нотацией UML. Затем полученная на предыдущих этапах документация попадает к программистам, начинается разработка, но в какой то момент обнаруживается, что в техническом задании написано такое, что реализовать невозможно. Документ возвращается обратно, работа сильно замедляется.
Уверен, нет смысла продолжать дальше, так как общая идея понятна. Рассматриваемая компания структурно состоит из отделов, имеющих строго определённую функцию, цикл разработки - последовательные шаги, результатом которых становится масштабный законченный продукт.
Но прогресс не стоит на месте. И развитие суждений об управлении и такие технологии, как интернет, развитые системы контроля версий и доставки приложений, привели к новым способам организации труда. Когда работа ведётся небольшими проектными командами, которые включают людей разных квалификаций, что позволяет, осуществлять в рамках команды полный цикл разработки. Сам цикл имеет небольшую продолжительность, что позволяет пользователям быстро получать новые необходимые функции приложений, а команда разработки может оперативно поменять стратегию, оценивая рынок и обратную связь. Такой подход был эффективен для всех сторон, связанных с разработкой программного обеспечения.
В какой то момент подобные способы организации разработки получили название гибких методологий разработки, и видные деятели индустрии опубликовали свой знаменитый манифест Agile. Сейчас, на мой взгляд, этот документ выглядит, как набор пустых лозунгов. Однако представьте, что есть 10+ летняя традиция писать длинные технические задания, но приходят умные дядьки и показывают, что может быть по другому.
Резюмируя, Agile представляет собой набор ключевых принципов, основываясь на которых выстраивается рабочий процесс. Он не регламентирует продолжительность спринта или наличие ретроспектив.
Теперь перейдём к разрушению популярных мифов.
Первое, о чем стоит сказать, что говорить в 2021 об Agile, как о чем-то модном - это вершина пошлости, примерно также, как хвастаться отсутствием в вашей квартире ковра на стене.
Второе - не нужно считать Agile, чем-то плохим. Это инструмент и беда в том, как его используют. Мало кто задумывается, но, например, пресловутые двухнедельные спринты выглядят эффективно при выходе на рынок с каким-то новым продуктом, но какая, например, от них польза, если мы разрабатываем программу архивирования документов по госконтракту, которую мы должны представить через год.
Или, например, планирование сторипоинтами. Изначально красивая идея, что сторипоинты - абстрактная величина, которая сначала просто показывает длительность задач соотносительно друг другу, а затем в ходе работы формируется понимание, сколько сторипоинтов за спринт может закрыть команда. В реальных условиях во множестве команд я наблюдаю, как люди привязывают сторипоинты к дням или часам, оценивают продолжительность выполнения задач, а затем из спринта к спринту не укладываются в сроки.
Вот так эффективные инструменты становятся неэффективными с лёгкой руки людей, не обладающих должной квалификацией. Так извращается суть, так Agile становится мифом, а затем модным словом, которое можно продавать начальникам, которым лень вникать в то, что это такое.
P.S.
Статья написана человеком, поэтому в любом случае является субъективной, поэтому, пожалуйста, пишите, с чем согласны или не согласны, так у нас будет более широкий взгляд об аджайле и прочем, изложенном в статье.