Велик и могуч... термин «agile»

Прозрачность и осознанность — одни из чуть ли не главных особенностей agile-подходов в разработке программного обеспечения, поэтому наличие адекватного русского термина сделало бы очевидным их преимущества над другими подходами и методологиями.

Но начнем пока с «начала».

Сначала программистов было мало, их ценили. Но также ценили компьютерное время, так как компьютеров было ещё меньше, чем программистов. Поэтому так важно было не отпускать программиста далеко от себя, общаясь с ним, выясняя и проясняя требования к программному продукту по ходу его разработки, чтобы таким образом уменьшить количество подходов к компьютеру, сэкономив компьютерное и программистское время. Это были время, когда программисты работали тесно с заказчиками.

По мере увеличения числа компьютеров и программистов, ценность компьютерного времени, а также и личного времени программистов упала. Заказчики стали всё реже общаться с программистами, и в самых экстремальных случаях это свелось к описанию требований в бумажном варианте. Эти изменения в отношениях привели к осложнению кооперации между программистами и заказчиками, и вылились в тяжелые переговоры в начале проекта по согласованию всех требований и сроков.

Появились контракты. Программиста обязали разрабатывать программные продукты так, чтобы продукт отвечал всем функциональным и нефункциональным требованиям, обговоренным до подписания проекта, давать точные оценки времени и, к тому же, выполнять свои обещания по требованиям и срокам. Программисты, в свою очередь, зная изменчивость желаний заказчиков и пытаясь обезопасить свои обещания, стали требовать того, чтобы заказчики подписывались под тем, что они не будут вносить изменений в требования.

Таким образом ситуация пошла против природной нестабильности требований к ПО. 

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

Так пришла эпоха тяжеловесных методологий, как их теперь называют, базирующихся на финализированных спецификациях и подписанных контрактах.

Так работало множество проектных команд. Проекты закрывались, погрязнув в согласованиях и уточнениях спецификаций, так ничего полезного в итоге и не разработав.

Но было и меньшинство, которое пыталось адаптировать процесс разработки под динамику рынка, сохранив тесные и конструктивные отношения с заказчиками. Эти команды понимали ценность подобного подхода, ибо в условиях развития рынка, повышения конкурентной борьбы, усложнения технологий и требований к ПО, гибкость и динамичность в согласованном принятии решений были единственным выходом.

Прошло 20 лет, технологии усложнились на порядки; толерантность к стабильности требований уменьшилась и стала измеряться неделями; глобализация 21-го века заставила команды стать распеделенными ...

Эти и прочие факторы повлияли на увеличение популярности подходов, которые в противовес контрактам, спецификациям, долгосрочному планированию, сложным метрикам оценки качества и прогресса ставили во главу угла кооперацию, профессионализм, доверие к людям и конечный результат труда — сам программный продукт.

Необходимость тесного общения стала ещё острее за последнее десятилетие в рамках оффшорной разработки, где эти методы уже успели доказать свою компетентность.

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

Если попробовать охарактеризовать разные стороны этих подходов, то выйдет нечто следующее:

«Облегченность» (или «Легковесность»)

Agile подходы — облегчённые подходы в сравнении в тяжеловесными методологиями, которые базируются на различных спецификациях, планах, протоколах, отчётах, утяжеляя тем самым и без того нелёгкую работу проектных команд.

«Гибкость»

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

«Адаптивность» 

Эти подходы адаптивны (в противовес детерминированным подходам), потому как они не пытаются предсказать всё наперед, оградив себя от реальности, — они принимают далёкое будущее как неизвестность, ограничивая горизонт принятия решений до обозримых сроков, чаще всего измеряемых от пары недель до пары месяцев. Они прокладывают себе дорогу в будущее короткими, но контролируемыми перебежками, учась на своих ошибках и адаптируя общее понимание проблем и решений под наиболее острые сегодняшние нужды.

«Прозрачность»

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

«Проворность»

Они проворны, расторопны, шустры и подвижны, так как в отличие от предопределённых процессов, которым порой нужны долгие месяцы для решения сложных и часто весьма абстрактных задач, они прикладывают все усилия команды и заказчика на решение наиважнейших задач, демонстрируя реальные результаты в максимально короткие сроки.

«Осмысленные»

Весь процесс принятия решений в этих подходах базируется только на здравом смысле. Устаревшие планы, обещания, политические прения — всё это вытесняется здравыми решениями, базирующимися на реальных данных.

Что мы имеем?

«Облегчённогибкие, адаптивнопроворные, прозрачноосмысленные методологии разработки программного обеспечения».

Похоже, тяжело найти подходящий термин в русском языке (я не говорю, что это невозможно), который бы передал все ценности и значения, вкладываемые в слово «agile» в контексте подходов к разработке ПО.

Но, если пока не существует адекватного термина, который бы напоминал о многосторонней сути agile-подхода, то, следуя «здравому смыслу, который базируется на реальных данных», стоит использовать существующее множество терминов, варьируя различные аспекты agile для той или иной ситуации.

Вы хотите помочь команде, которая тонет в бюрократии и бумагообороте, не сдвигаясь с места в разработке ПО? Попробуйте объяснить преимущества agile-подхода, базируясь на аспекте «облегченности».

Вам жалуются на то, что команда отклоняет изменения в требованиях, ссылаясь на контракт и указывая на утвержденную процедуру change request management, из-за чего разрабатываемых продукт не будет максимально полезен заказчикам и пользователям? Поговорите с ними об аспекте «гибкости».

Вам говорят, что нужно всё предусмотреть сразу и спланировать наперед, иначе наступит хаос? Адаптивность — возможно, самый важный аспект, который нужно понять данной команде, чтобы осознать преимущества agile.

У заказчиков проблемы с пониманием прогресса проекта — команда говорит, что разрабатывает какой-то «каркас» и сможет перейти к запрошенной функциональности только к концу квартала? Проворность подхода, пожалуй, убедит заказчиков попробовать что-то другое.

Заказчики жалуются на задержки в поставках со стороны команды, которые становятся известны не раньше, чем за день до согласованной даты? Прозрачность agile-подходов поможет предотвратить похожую ситуацию в будущем.

Команда жалуется на отсутствие логики в решениях заказчика — применение agile-подходов придаст осмысленности всем принимаемым решениям, решения станут базироваться на реальных данных, известных всем.

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

Статья от 02/2007

Заинтересовала статья? Тогда почитайте ещё это и это.

И немного про вот это.