Велик и могуч... термин «agile»
Из серии «Об agile по-русски».
Прозрачность и осознанность — одни из чуть ли не главных особенностей agile-подходов в разработке программного обеспечения, поэтому наличие адекватного русского термина сделало бы очевидным их преимущества над другими подходами и методологиями.Но начнем пока с «начала».
«Начало начал». Притча.
Сначала программистов было мало, их ценили. Но также ценили компьютерное время, так как компьютеров было ещё меньше, чем программистов. Поэтому так важно было не отпускать программиста далеко от себя, общаясь с ним, выясняя и проясняя требования к программному продукту по ходу его разработки, чтобы таким образом уменьшить количество подходов к компьютеру, сэкономив компьютерного и программистское время. Это были время, когда программисты работали тесно с заказчиками.По мере увеличения числа компьютеров и программистов, ценность компьютерного времени, а также и личного времени программистов упала. Заказчики стали все реже общаться с программистами, и в самых экстремальных случаях это свелось к описанию требований в бумажном варианте. Эти изменения в отношениях привели к осложнению кооперации между программистами и заказчиками, и вылились в тяжелые переговоры в начале проекта по согласованию всех требований и сроков.
Появились контракты.
Программиста обязали разрабатывать программные продукты так, чтобы продукт отвечал всем функциональным и нефункциональным требованиям, обговоренным до подписания проекта, дать точные оценки времени и, к тому же, выполнить свои обещания по требованиям и срокам. Программисты в свою очередь, зная изменчивость желаний заказчиков и пытаясь обезопасить свои обещания, стали требовать того, чтоб заказчики подписывались под тем, что они не будут вносить изменений в требования.
Таким образом ситуация пошла против природной нестабильности требований к ПО.
И.. и вместо того чтобы попытаться не терять связь с заказчиком и попробовать вернуть ситуацию в адекватное русло, большинство проектных команд стали усложнять контракты, растягивая фазы согласования требований, и в самых экстремальных случаях это свелось к тому, что требования устаревали ещё не будучи согласованными.
Так пришла эпоха тяжеловесных методологий, как их теперь называют, базирующихся на финализированных спецификациях и подписанных контрактах.
Так работало множество проектных команд. Проекты закрывались, погрязнув в согласованиях и уточнениях спецификаций, так ничего полезного в итоге и не разработав.
Но было и меньшинство, которое пыталось адаптировать процесс разработки под динамику рынка, сохранив тесные и конструктивные отношения с заказчиками. Эти команды понимали ценность подобного подхода, ибо в условиях развития рынка, повышения конкурентной борьбы, усложнении технологий и требований к ПО, гибкость и динамичность в согласованном принятии решений были единственным выходом.
Прошло 20 лет, технологии усложнились на порядки; толерантность к стабильности требований уменьшилась и стала измеряться неделями; глобализация
Необходимость тесного общения стала ещё острее за последнее десятилетие в рамках оффшорной разработки, где эти методы уже успели доказать свою компетентность.
В поисках крепкого словца...
Сегодня на территории русскоговорящих стран работают сотни команд, которые ценят и следуют вышеописанным принципам и подходам, поэтому наличие термина, который бы охарактеризовывал ценности agile-подходов (дабы этот смысл не был утерян) был бы весьма полезен.Если попробовать охарактеризовать разные стороны этих подходов, то выйдет нечто следующее:
«Облегченность» (или «Легковесность»)
Agile подходы — облегченные подходы в сравнении в тяжеловесными методологиями, которые базируются на различных спецификациях, планах, протоколах, отчетах, утяжеляя тем самым и без того нелёгкую работу проектных команд.
«Гибкость»
Agile подходы гибки, потому что, вместо выставления порой невыполнимых условий по замораживанию требований к продукту, они принимают неустойчивость требований как факт и делают все, чтобы заказчик в любой момент мог изменить курс проекта, базируясь на оценке эффективности финансовых вложений.
«Адаптивность»
Эти подходы адаптивны (в противовес детерминированным подходам), потому как они не пытаются предсказать все наперед, оградив себя от реальности, — они принимают далёкое будущее как неизвестность, ограничивая горизонт принятия решений до обозримых сроков, чаще всего измеряемых от пары недель до пары месяцев. Они прокладывают себе дорогу в будущее короткими но контролируемыми перебежками, учась на своих ошибках и адаптируя общее понимание проблем и решений под наиболее острые сегодняшние нужды.
«Прозрачность»
Из-за акцентирования внимания участников проекта на ощутимых результатах вместо замыливания внимания различными моделями, расчетами, статистикой, эти подходы делают прогресс проекта видимым и понятным, давая заказчикам полный контроль над курсом проекта ради оптимизации финансовых выходов. Проблемы и риски становятся видимыми, позволяя быть вовремя решёнными совместными усилиями проектных команд и заказчиков.
«Проворность»
Они проворны, расторопны, шустры и подвижны, так как в отличие от предопределенных процессов, которым порой нужны долгие месяцы для решения сложных и порой весьма абстрактных задач, они прикладывают все усилия команды и заказчика на решение наиважнейших задач, демонстрируя реальные результаты в максимально короткие сроки.
«Осмысленные»
Весь процесс принятие решений в этих подходах базируется только на здравом смысле. Устаревшие планы, обещания, политические прения — все это вытесняется здравыми решениями, базирующимися на реальных данных.
Итого
«Облегченногибкие адаптивнопроворные прозрачныеосмысленные методологии разработки программного обеспечения»...Похоже тяжело найти подходящий термин в русском языке (я не говорю, что это невозможно), который бы передал все ценности и значения, вкладываемые в слово «agile» в контексте подходов к разработке ПО.
Но если пока не существует адекватного термина, который бы напоминал о многосторонней сути agile-подхода, то, следуя «здравому смыслу, который базируется на реальных данных», стоит использовать существующее множество терминов, варьируя различные аспекты agile для той или иной ситуации.
Вы хотите помочь команде, которая тонет в бюрократии и бумагообороте, не сдвигаясь с места в разработке ПО? Попробуйте объяснить преимущества agile-подхода, базируясь на аспекте «облегченности».
Вам жалуются на то, что команда отклоняет изменения в требованиях, ссылаясь на контракт и указывая на утвержденную процедуру change request management, из-за чего разрабатываемых продукт не будет максимально полезен заказчикам и пользователям? Поговорите с ними об аспекте «гибкости».
Вам говорят, что нужно все предусмотреть сразу и спланировать наперед, иначе наступит хаос? Адаптивность — возможно самый важный аспект, который нужно понять данной команде, чтобы осознать преимущества agile.
У заказчиков проблемы с пониманием прогресса проекта — команда говорит, что разрабатывает какой-то «каркас» и сможет перейти к запрошенной функциональности только к концу квартала? Проворность подхода, пожалуй убедит заказчиков попробовать что-то другое.
Заказчики жалуются на задержки в поставках со стороны команды, которые становятся известны не раньше, чем за день до согласованной даты? Прозрачность agile-подходов поможет предотвратить похожую ситуацию в будущем.
Команда жалуется на отсутствие логики в решениях заказчика — применения agile-подходов придаст осмысленности всем принимаемым решениям, решения станут базироваться на реальных данных, известных всем.
P.S.
Нахождение адекватного термина в русском языке — это дело времени. Но важность сохранения многосмысловой нагрузки agile-подходов останется задачей, которая пожалуй будет актуальной всегда.-----------------------
Автор: Кривицкий Алексей, [email protected]
Опубликованно также на www.krivitsky.com/2007/02/blog-post.html
Все про українське ІТ в Телеграмі — підписуйтеся на канал редакції DOU
anonymous
Александр Локшин
2 коментарі
Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.