Всё чаще можно услышать мнение о том, что методология разработки Agile мешает достижению стратегических целей, не подходит для работы над большими комплексными системами, и вообще уже потеряла свою актуальность. Мы спросили, что об этом думают наши эксперты и основатели портфельных проектов ФРИИ.


Mediacenter_Orlov.jpg

Анатолий Орлов, руководитель лаборатории больших данных ФРИИ

Хайп вокруг методологий Agile начался с книжки Extreme Programming (XP), написанной Кентом Бэком. Этот подход к разработке был придуман и опробован автором во время работы над проектом Chrysler C3 — попыткой переписать старую систему начисления зарплат, адаптировав её к «проблеме 2000 года». Проблема в том, что методология XP не предполагает длительного планирования, поэтому вовремя новую систему разработать не успели, а старая не сгорела синим пламенем 1 января 2000 года, как ожидалось. В результате Chrysler C3 был закрыт; а если верить «Википедии», то после этого использования Extreme Programming в DaimlerChrysler было запрещено. Тем не менее, неудачный опыт не помешал авторам написать мегапопулярную книгу, и эта ситуация довольно точно иллюстрирует суть методологий Agile.

С другой стороны, если относиться к методологиям Agile без хайпа, то это вполне полезная вещь. Не-agile предполагает, что ты заранее точно знаешь, что именно тебе нужно, и твое понимание в процессе не меняется, поэтому ты можешь предсказать темп разработки на месяцы или годы вперед. Если подумать, то это ограничивает область применения схемы довольно консервативными компаниями, у которых бизнес не меняется годами. Часто им бывают нужны обычные бизнес-системы, которые просты технологически, но довольно объемны в разработке, которым тяжеловесные методологии отлично подходят.

Люди, которые говорят «мы используем Agile», обычно имеют в виду следующее: «у нас есть некий бардак в разработке, но нас это не сильно беспокоит». В некоторых компаниях «бардак» просто должен быть. Ты не можешь запланировать развитие стартапа на два года вперед, потому что в то время у тебя будет совершенно другая ситуация. Так что команды, которые используют agile не в качестве карго-культа, а с пониманием своих потребностей, вполне имеют право на существование. Более того, в стартапах таких команд большинство.

 

alex_belozerov.jpg

Александр Белозёров, CEO и основатель проекта КОТ 

Если разобраться с содержанием статьи, то в ней речь идет об Enterprise-проектах, сложных, больших и важных. Со своими стандартами к программированию, приемке, тестированию, развертыванию и т.п. В таких проектах применение Agile действительно кажется маловероятным. Ну нельзя делать итеративно проект, у которого только процесс внедрения изменений занимает 3-4 недели. И программисты там сидят немножко другого толка. Общаться с клиентом? Да их на пушечный выстрел к клиентам нельзя подпускать. Ну и так далее, по всем пунктам манифеста Agile большой проект найдет по десятку, вполне даже обоснованных, возражений. 

Другое дело — стартап. MVP — сам по себе уже поделка, которую надо сделать быстро, не особо заморачиваясь с качеством кода. Важно, прежде всего, быстро проверить идею. И постоянно ее менять, общаясь с клиентом. На первый план у нас выходят сроки создания и скорость реакции на запросы рынка в ситуации, когда продукт находится в стадии высокой неопределенности. Agile в данном случае – панацея от миллионных трат на проект. Не может себе стартап позволить тратить 3 месяца на маркетинговые исследования, 6 месяцев на разработку, и 3 месяца на развертывание. Ну нет у него таких бюджетов. Именно поэтому стартапу важно иметь какое либо подобие продукта как можно раньше.

Agile не мертв. Он, как и любой инструмент, работает для определенного круга задач. И подобные статьи — лишь этап вызревания, когда продукт занимает свою нишу, а не является затычкой для любой задачи. К сожалению, универсальных инструментов не существует. Пользуйтесь, и вовремя переключайтесь с него, когда уходите от MVP к полноценному продукту.

 

mediacenter_kaloshin.jpg

Александр Калошин, CEO проекта Last Backend

Наш опыт говорит, что в чистом виде Agile, как и все методологии, довольно сложно внедрить и его придерживаться. Поэтому мы используем около-agile тип разработки ПО.

Судя по тому, как быстро происходят изменения в IT, стратегических целей как таковых уже, наверное, не существует. В нашем случае они очень гибко меняются, в зависимости от происходящего на рынке и развития технологий. Хотя Agile позволяет быть гибким в плане создания продукта и как раз-таки помогает достичь стратегической цели — вряд ли она будет той, что была запланирована изначально.

Зато эта методология позволяет получить не тот продукт, что был запланирован, а тот, который нужен рынку. А это играет огромное значение.