Натуральна, галоўнай цяжкасцю пры перакладзе было знайсці добры беларускі адпаведнік для тэрміну agile. Хацелася знайсці беларускае слова:
а) максімальна блізкае па значэнні да ангельскага арыгіналу (а не да перакладу кшталту “гибкий” )
б) максімальна аўтэнтычнае, унікальнае для беларускай мовы

У выніку на ваш суд мы прапануем Маніфест Шпаркага праграмавання і Прынцыпы да яго.

P.S. Хацелася б падзякаваць праекту Беларуская IT-тэрміналогія ў межах якога прафесійныя лінгвісты, праграмісты і проста добрыя людзі ствараюць нацыянальную IT-тэрміналогiю. У нашай працы мы скарысталіся знойдзенным імі тэрмінам “апраграмаванне” для перакладу фундаментальнага слова “software”. Гэты варыянт здаецца значна лепшым за традыцыйны русізм “праграмнае забеспячэнне”.

Ганна і Канстанцін Разумоўскія.

И все-таки что такое Agile?
Очевидно, что для того, чтобы рассуждать о том, когда можно применять Agile, а когда – нет, надо четко понимать, что вообще стоит за этим словом. По моим наблюдениям, большинство людей, с удовольствием обсуждающих гибкие методологии, весьма приблизительно знакомы с происхождением и наполнением слова «Agile» (я уже не говорю про то, что лишь единицы знают, что ударение в этом слове надо бы ставить на первый слог . Нередко можно услышать, например, следующие утверждения. «Гибкие методы – это когда не документируют требования». «В Agile сначала всегда пишут тесты». «Если ты применяешь Agile – заказчик должен сидеть с тобой в одной комнате». Безусловно, каждое из приведенных утверждений имеет какое-то отношение к теме гибких методологий, но все они, строго говоря, ложны.

Позволю себе в двух словах напомнить историю появления гибких методологий. В течение нескольких последних десятилетий 20-го века в качестве основного подхода для разработки программного обеспечения использовались так называемые инженерные (они же основанные на плане, они же предиктивные) методологии. В основе этих методологий лежало (вообще говоря, ложное) представление о том, что процесс разработки программного обеспечения является детерминированным инженерным процессом, который можно спланировать от начала и до конца и выполнить в соответствии с планом, используя формальные инженерные подходы к разработке требований, проектированию и т.д. В качестве основного варианта построения жизненного цикла использовался водопадный жизненный цикл, предполагающий однократный проход по фазам анализа требований, проектирования, кодирования, тестирования и т. д. Ближе к концу 90-х годов в противовес тяжеловесным инженерным методологиям (которые так и не смогли сделать процесс разработки предсказуемым и успешным) появилось целое семейство «легковесных» методологий, таких как Scrum, XP, DSDM, Crystal и т.д. Сотрудничество авторов и лидеров этих направлений привело к созданию в феврале 2001 года Манифеста гибкой разработки программного обеспечения , а чуть позже – Принципов гибкой разработки программного обеспечения .

Agile Methods = Agile Manifesto + Agile Principles
Итак, в наличии имеются 4 ценности из манифеста, а также 12 принципов гибкой разработки. Именно эти 16 утверждений и определяют то, что называется гибкими методологиями. Важно понять, что все остальные свойства, приписываемые гибким методологиям, либо являются их производными (как например, «В гибких методах уделяется повышенное внимание коммуникациям»), либо имеют отношение к каким-то конкретным методологиям типа XP, но не к Agile вообще («Заказчик должен сидеть в одной комнате с командой»), либо просто-напросто являются заблуждениями («Гибкие методы – это когда не документируют требования»).

Важно отличать общие принципы, применимые ко всем гибким методологиям, заложенные в манифест, и принципы гибкой разработки, от особенностей, присущих конкретным представителям семейства гибких методологий (таким, как XP, Scrum, Crystal и т.п.). Да, в XP вначале пишут тесты, но не надо переносить это свойство на все семейство гибких методологий в целом. Всякий раз, когда мы упоминаем слово «Agile» без дополнительных оговорок, мы, прежде всего, должны понимать базовый набор ценностей и принципов, но никак не специфические особенности каких-то конкретных методологий. Чаще всего те, кто говорит о «неприменимости» гибких методов, некорректно отождествляют их с какой-то конкретной гибкой методологией (обычно XP).

«К нашему проекту Agile не применим»
Итак, как мы уже разобрались, если вы осознанно утверждаете, что Agile не применим к вашему (или какому-то другому) проекту, вы фактически утверждаете, что среди ценностей и принципов гибкой разработки есть такие, которые по каким-то причинам не подходят для данного проекта.

Попробуем разобраться, какие же из ценностей и принципов могут оказаться неподходящими для нашего гипотетического проекта. Даже беглый просмотр позволяет убедиться, что ценности и принципы гибкой разработки определены достаточно общо, что и не удивительно: методологии, породившие Agile, в значительной степени отличались друг от друга и найти общую почву они могли лишь на уровне самых базовых подходов. По сути, в эти 2 списка попали только проверенные лучшие подходы к организации разработки, подтвердившие свою полезность на практике. При этом они отнюдь не содержат (да и не могут содержать по определению) детальных рекомендаций типа присутствия заказчика в общей комнате проекта, предварительного написания тестов или, тем более, отсутствия или низкой степени формализации требований. Развивая мысль одного из авторов этих документов, Мартина Фоулера, предположу, что на самом деле фундаментальных общих особенностей, объединивших легковесные подходы, было не 16 и даже не 4, а всего лишь две:

• Осознание человеческого фактора как ключевого фактора успеха при разработке программного обеспечения.
• Выбор адаптивного итерационного подхода вместо водопадного жизненного цикла.

Ниже я остановлюсь на этих двух аспектах чуть подробнее.

Человеческий фактор и итерационный жизненный цикл
Может ли быть неприменимым или нежелательным для какого-то проекта признание исключительной важности человеческого фактора и связанных с ним проблем (коммуникации, доверие, прямое общение, комфортные условия труда, отсутствие переработок и т.д.)? И практика, и теория (прежде всего, в лице легендарной Peopleware) убеждают нас в том, что человеческий фактор действительно является наиважнейшим аспектом при разработке, и гибкие методологии всего лишь документально оформили этот факт. Трудно представить проект, в котором признание принципа главенствования человеческого фактора будет играть отрицательную роль.

Обратимся теперь ко второму базовому аспекту гибких методов – итерационной разработке. Как афористично написал все тот же Мартин Фоулер в книге UML Distilled – «вам следует применять итерационный подход только к тем проектам, которые вы хотите завершить успешно». Думаю, излишним будет очередной раз доказывать преимущества итерационного жизненного цикла перед водопадным. И статистика завершенных проектов, и теория управления проектами доказывают преимущество последнего для подавляющего большинства проектов. Даже такая крупная и инерционная организация, как министерство обороны США, еще более 10 лет назад инициировала отказ от водопадной и переход к итерационной модели.

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

Резюме
Использовать гибкие методы разработки – совсем не обязательно означает использовать практики XP, Scrum или какой-то другой конкретной методологии. Это, прежде всего, означает руководствоваться общими ценностями и принципами, заложенными в Манифест и Принципы гибкой разработки программного обеспечения.

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

Константин Разумовский, krazumov at gmail com