Agile явился миру уже в далеком для нас 2001 году, когда несколько специалистов из ИТ-сферы решили собраться для обсуждения существующих практик разработки программного обеспечения.
Результатом их продуктивной дискуссии стал хорошо известный всем манифест, без которого не может обойтись почти ни одна компания в мире. По сути, это первый «свод правил», который регламентирует нормы производства в ИТ-компаниях.
И пользу в нем заметил не только узкий круг программистов, но и такие значимые игроки рынка, как Facebook и Apple. В обществе разработчиков Agile вызвал настоящий резонанс, а устоявшиеся практики начали пересматриваться в пользу оптимизации процессов разработки.
Но многие забывают, что Agile создавался не как идеология или конкретный набор инструментов для решения той или иной проблемы. В первую очередь, это правила для формирования продуктивной среды внутри команды или компании.
Вы наверняка сталкивались с труднопроходимыми бюрократическими элементами в любой системе. ИТ-сфера – не исключение. Разработчикам приходилось работать в жестких рамках, следуя устаревшим методикам. Но с появлением Agile у многих появилась возможность избавиться от столь существенного препятствия.
Ведь в основу манифеста заложены новые принципы: максимально быстрая разработка, динамичное развитие и внедрение новых механизмов, гибкость за счет создания новых инструментов. С
пустя небольшой промежуток времени, компании начали внедрять Agile в 97% случаев. Это способствовало еще большему развитию методики, которая использовалась уже не только в сфере разработки ПО.
Но многие забывают, что Agile – это не панацея от всех бед. Ведь она даже не приводит какие-либо конкретные инструменты. А все потому, что создатели даже не подозревали, что их детище станет настолько популярным. Тем не менее, энтузиасты решили разнообразить манифест и добавить свои методики, предлагая расширить тем самым имеющиеся возможности.
Например, появились более узконаправленные правила, как Scrum и Kanban. Под руководством этих методик проектировались новые системы, комплексные программные продукты и многое другое.
Одна из компаний, Atlassian, представила сообществу целый пакет различных решений, призванных внедрить Agile как можно быстрее с высоким коэффициентом эффективности. Благодаря этому появились и другие стандарты, как Confluence и Jira. Но хорошо ли капитализация подобного рода сказывается на первоначальной идее?
Во-первых, появилось множество узконаправленных терминов, которые до сих пор трактуются по-разному от случая к случаю. Это не есть хорошо, так как понимание одной и той же методики начинает кардинально отличаться.
Проблемы Agile связаны и с ростом отдельных практик, которые представляются обществу, как «усовершенствованная версия» оригинального манифеста. На сегодняшний день насчитывается огромное количество методик и, как результат, соответствующих специалистов. Наглядная статистика: в одной из всемирно известных компаний количество сотрудников, позиционирующих себя как Agile-разработчиков выросло до 1000!
Самое интересное заключается в том, что ни один специалист не может связать внедрение Agile с ощутимыми конкретными цифрами, из которых можно было бы сделать вывод о ее КПД. То есть, это нечто абстрактное, неосязаемое, но столь желаемое нововведение в компаниях, ставшее чуть ли не гарантом успеха.
Однако, в результате мы имеем тотальное извращение базовых принципов оригинального манифеста. Ведь если посмотреть на современный рынок, то становится ясна четкая картина – проблемы Agile в первую очередь связаны с тотальной капитализацией, формированием продаваемых пакетов услуг и растущим количеством абсолютно ненужных специалистов, которые ответственны за внедрение методологии.
Даже один из основателей Agile Энди Хант посетовал на столь большое количество неправильных трактовок и растущего количества «дополняющих» оригинальную методику идей. Правда в том, что исключение бюрократических механизмов из процесса разработки – это крайне трудная задача. А способы ее решения далеко не всем понятны.
Это и породило множество псевдо-методик. Более того, компании следуют ошибочным правилам и еще больше ограничивают свою команду, пытаясь следовать модным тенденциям.
И что печальнее всего, это способствует еще большему игнорированию проблемы самого процесса разработки, который затмевается созданием целых отделов по внедрению Agile и прочих идей.
Исключение из правил — это Scrum и Kanban, которые пытаются направить компании в нужное русло. Они отстаивают изначально верную идеологию Agile, создавая более развернутые трактовки для узких кругов в ИТ-сфере.
Конечно, и они не могут похвастаться исключительно чистой репутацией, так как различные бюрократические элементы находят свое проявление и здесь. Ведь никто еще не отказывался от заработка, тем более, когда идея легко продается.
Проблемы Agile все чаще заметны в тех компаниях, которые могут похвастаться большим штатом менеджеров, консультантов и посредственных разработчиков, так как такие люди не могут даже внятно объяснить, как новая методика облегчила их работу.
Мания «беспрерывного производства» выливается в «бесконечное внедрение» нашумевших идей. Стоит ли напоминать, что это вовсе не было целью Agile.
В этом и кроется ирония. Созданная методика Agile была призвана для того, чтобы облегчить разработку, создать инструмент для беспрерывного производства, избавить компании от навязчивого микроменеджмента, который ограничивает творчество.
Но в результате, столь большой спрос привел к усугублению ситуации. Благо, не везде. Уже сейчас многие понимают, что нужно предметно подходить к оптимизации, не пуская все на самотек и не стремясь следовать популярным тенденциям.
About The Author
Виктор