Agile подходит всем!

Есть такая популярная тема для обсуждения – вопрос применимости гибких методологий для разных типов проектов. «Ну да, Agile – это, конечно, очень интересно», – сказал мне недавно мой начальник. – «Но все это теория, а в жизни, увы, так не получается. У нас большой проект, удаленный заказчик и вообще…». Еще один коллега высказался немного конкретнее: «Существует куча проектов, в которых ты никак не применишь гибкие методы. Например, при работе с государственными организациями. Или если у тебя команда из одних новичков…». Существует даже несколько книг на тему того, когда стоит применять гибкие методологии, а когда – нет. Ни в коем случае не претендуя на истину в последней инстанции, хотелось бы поделиться своим взглядом на этот вопрос. Ниже в нескольких абзацах я постараюсь объяснить, почему, по моему мнению, Agile подходит для всех (ну, или для абсолютного большинства) проектов, и что я под этим понимаю.

И все-таки что такое 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

Tags: ,

Post Author

This post was written by who has written 2 posts on Agile.by.

  • Денис Петелин

    Сейчас прибежит куча народа, которая с тобой не согласится 🙂
    Именно по этой самой причине – ключевые идеи и принципы (идеология подхода) многим не заходит.
    У них своя идеология. Именно поэтому они будут против – и спорить с ними будет бессмысленно, потому что концепт, от которого будешь отталкиваться ты и они – будет совершенно разный, у вас будут непересекающиеся системы ценностей.
    Будет примерно как разговор чуваков, один из которых живет в евклидовой геометрии, а другой в геометрии Лобачевского:
    – Итак, раз параллельные прямые не пересекаются…
    – Пааазвольте! Они обязательно пересекутся!
    А дальше говорить уже не о чем 🙂

  • Konstantin Razumovsky

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

    – Нам Agile не подходит!
    – Что именно из Agile вам не подходит?
    – Нам не подходит то, что в Agile формально не документируют требования, а у нас такой проект, что нам обязательно надо хорошо описывать требования.
    – Описывайте требования так подробно, как нужно для вашего проекта, Agile никаким местом не говорит о том, что не надо подробно описывать требования.
    – Ну, как же, вот в Agile же заказчик должен в одной комнате сидеть и устно уточнять требования и все такое….
    – Вы путаете Agile вообще и XP. Это в XP заказчик сидит в одной комнате с командой; это хорошая практика, но это не есть обязательное условие. Главное, чтобы реализовывались принципы и ценности Agile, например, чтобы тот же заказчик активно участвовал в проекте, определял требования и их приоритет, вовлекался в демонстрации и т.п.
    – Ну, что ж, вы меня полностью убедили, я побежден и иду внедрять Agile.

    Последняя фраза, впрочем, может звучать немного по-другому в зависимости от обстоятельств 🙂

  • Денис Петелин

    Три раза ха ха 🙂
    Диалог в интернете как правило выглядит следующим образом (взято с oper.ru как хорошая иллюстрация):

    Goblin: В сантиметре, камрады, 10 миллиметров.
    “оппонент”: Да ладно!
    Goblin: Точно.
    “оппонент”: Не верю.
    Goblin: Не надо.
    “оппонент”: Этого не может быть.
    Goblin: Может.
    “оппонент”: А откуда ты знаешь?
    Goblin: Ну, типа считал.
    “оппонент”: Чё, считать умеешь, что ли?
    Goblin: Умею.
    “оппонент”: Не до хера на себя берешь, а?
    Goblin: Нет.
    “оппонент”: Я так думаю, ты просто не способен правильно сосчитать.
    Goblin: А я знаю, что умею считать. И миллиметров там – десять.
    “оппонент”: А в метре – 1000 миллиметров.
    Goblin: И что?
    “оппонент”: А то, что в метре 1000 миллиметров.
    Goblin: Мы вроде про сантиметр говорили?
    “оппонент”: Про что хочу, про то и говорю. Че, умный, что ли?
    Goblin: Нет, просто знаю.
    “оппонент”: А думать не пробовал – сколько их?
    Goblin: Тут не надо думать. Тут считать надо и запоминать.
    “оппонент”: Сразу видно – тебе в ментовке все мозги отшибли, придурок.
    Goblin: А это здесь при чем?
    “оппонент”: При том, что сперва иди поучись, баран, а потом рот открывай.
    Goblin: От того, что я поучусь – количество милиметров изменится?
    “оппонент”: Слышь, не умничай. И поумнее тебя видали.
    Goblin: я не про ум, а про количество миллиметров.
    “оппонент”: А я слышал, что в других странах миллиметров меньше/больше! Я в кино видел – у них все не так.
    Goblin: Нет, везде одинаково.
    “оппонент”: Слышь, знаток хренов, а ты сам там был?
    Goblin: Нет, не был.
    “оппонент”: Ну тогда молчал бы, блин, не позорился.
    Goblin: Для того, чтобы это знать, не обязательно куда-то ездить.
    “оппонент”: Нет, ну это надо такую херню спороть!
    Goblin: Ты о чем?
    “оппонент”: Ты мне рот не затыкай!!! Тоже мне, выискался!!!
    Goblin: Это ты к чему? Мы про миллиметры или про меня? При чем тут я?
    “оппонент”: Да пошшшел ты…

    Мы конечно стремимся таки вещи в сообществе пресекать, но периодически подтягиваются товарищи с беседами в таком стиле 🙂 Так что готовься на всякий случай 🙂

  • Константин Качановский

    Искренне желаю читателям сего, чтобы у них как можно реже возникала необходимость общаться с морально-искалеченными уродами типа “оппонента”. А когда такая необходимость вдруг возкнет, пусть они с ними разговаривают иначе, чем это делает “Goblin”…