Используя термин Agile, люди часто имеют в виду не что-то конкретное, но то что они правы. Например, не написал тесты — не Agile, не провел митинг с командой — не Agile, не заполнил тайм-трекинг — опять не Agile. Тому, что каждый трактует термин Agile по-своему, есть объективные причины, связанные с его происхождением.
Не секрет, что истоком всех Agile движений был митинг, произошедший в феврале 2001 года на горнолыжном курорте в штате Юта. Как выразился Robert C. Martin, зачинщик мероприятия, там собралась группа умных людей, которые никогда не встречались ранее и не планировавших встретиться в будущем. Цель собрания была одна — выразить нечто общее, что объединяло бы всех присутствующих.
О том, как создавался Agile манифест, есть много статей написанных самими участниками процесса [1], [2], [3]. Суть происходящего была в следующем: каждый из участников выписал на карточки идеи выражающие его точку зрения, и после того как карточки были организованы по категориям, стали очевидны четыре пункта, в которых все были единодушны. Далее они были красиво сформулированы:
То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.
Документу нужно было придумать название, для которого голосованием было выбрано слово Agile, как признает Martin Fowler — не слишком подходящее слово.
Далее Agile манифест был расширен 12 принципами, но на их финальное согласование ушло еще несколько месяцев переписки по e-mail, что наводит на мысль о их второстепенной важности.
К слову, одним из принципов является релиз с частотой от двух недель до двух месяцев, что по сравнению с современными нормами — пара релизов в день — звучит архаично.
С другими пунктами тоже не все гладко, вот еще один пример: “Рабочее программное обеспечение — это главная мера прогресса проекта”. Это сомнительная метрика уже потому, что протестированное и выпущенное приложение совсем не означает, что оно окажется хоть кому-то полезным.
В событии участвовало семнадцать далеко не ординарных человек. Краткий список их достижений и вклада в индустрию можно посмотреть
Если визуализировать список создателей Agile по их отношению к технологиям и методологиями, получается любопытная картина:
В общем участников можно разделить на три категории:
Удивительно ли, но наибольшую пользу от появления Agile получили именно менеджеры.
Инженеры-менеджеры с XP и другими подобными методологиями проиграли, чуть подробнее об этом далее.
Интереснее всего то, что в итоге инженеры встали в оппозицию и даже начали бороться с Agile. Например, несмотря на то, что Robert C. Martin был одним из основных организаторов мероприятия, теперь он не только выступает против, но и составил свой Software Craftsmanship Manifesto. Гибкость гибкостью, но мы профессионалы и должны работать как подобает профессионалам, не скатываясь до халтуры и спешки.
Тому что подходы XP, ASD или Crystal потерпели неудачу, есть вполне разумные причины, и более того, их много. У этих методологий много общего, поэтому посмотрим, что с ними не так на примере XP, поскольку в отличие от остальных он хотя бы еще всплывает в памяти.
Пожалуй, главная проблема XP в том, что он слишком подробный. Книга по XP содержит 160 страниц: трудно представить, что такого объема руководство может быть в полной мере реализовано в массовой разработке, ведь в каждом проекте есть своя специфика.
Кроме того, в дополнении к принципам организации работы, XP навязывает огромное количество способов ее выполнения, причем дорогих способов. Парное программирование — вполне осмысленная техника, но это лишь средство достижения определенного уровня качества и владения кодом. А вдруг можно добиться тех же результатов с меньшими усилиями? А что если работая другим способом, например, быстро исправляя проблемы, можно добиться большего?
Зато отдельные технические концепции, представленные в XP, стали стандартами индустрии. Сейчас уже никого не удивишь Continuous Integration или Daily Deployment. Но в том-то и дело, что это есть у всех.
Из всех Agile методологий в широкое обращение вошел только Scrum, и его распространенность по большому счету оправдана. Да, это сложная методология. Да, очень часто Scrum реализуют неправильно, получается черт-те что. Да, работа по Scrum склонна приводить к росту технического долга. Да еще много чего. Но все же Scrum — это лучшее, что есть на рынке. Если применять его осмысленно и целенаправленно, результат будет.
Проблема в том, что для Scrum нет хороших альтернатив, конкуренция отсутствует. А это нездоровая ситуация как для индустрии в целом, так и для Scrum сообщества в частности.
Под флагом Agile придумано множество частных методологий, и, вероятно, они неплохо работают для авторов, но применимы ли они для индустрии в целом? Почему для Scrum нет хороших альтернатив? При том что Scrum появился до Agile, есть ли причины ожидать, что на базе Agile будут созданы методологии того же уровня?
Agile — это четыре утверждения, выражающие общие мысли нескольких умных и успешных людей. Но каждый из них имеет существенно большую картину ценностей, и это лишь тот минимум, в котором они сошлись исходя из их личного опыта на тот момент времени. Не удивительно, что в манифесте видится много проблем.
Неполнота — если из двух хороших идей, скажем, “пойти в кино” или “пойти в театр”, попытаться механически выделить общее, получится “пойти куда-нибудь”, что уже не кажется хорошей идеей. В своей работе каждый из участников руководствовался большим количеством принципов, так что вполне разумно предположить, что того минимума с которым согласились все, недостаточно для достижения успеха.
Поверхностность — код важнее документации, сразу видно, что собрались инженеры. Решение задач клиента важнее соблюдения бюрократических формальностей, возможно, так было бы правильнее.
Неопределенность — только на первый взгляд все кажется понятно, но как только эти принципы ложатся на конкретную ситуацию, правильное решение становится далеко не очевидно. Более того, при желании можно найти статью, подтверждающую любую из возникших точек зрения.
Наивный альтруизм — сотрудничество важнее согласования условий только до тех пор, пока не пришли штрафные санкции. Требование подписаться под манифестом подразумевает, что нужно согласится со всеми четырьмя утверждениями. Но что если обстоятельства не позволяют? Могу ли я следовать только трем из них без лишнего чувства вины за несоблюдения четвертого?
Узкая аудитория — обращение манифеста идет к разработке, а как же клиенты? Наивно надеяться, что правила можно поменять только со стороны разработки, если клиенты продолжают работать по-старому.
Ключевой целью манифеста было показать индустрии разработки, что процессы, методологии и саму разработку можно вести по-другому, заставить людей задуматься об этом. В этом смысле за манифестом следует признать полный успех. Что касается содержания, это скорее любопытный документ, отражающий наболевшие проблемы разработки начала нулевых, нежели фундаментальные принципы, которым мы все должны следовать.
Главным достижением Agile-инициативы стал посыл — работать можно по-другому. Можно искать другие пути достижения целей, пробовать нестандартные варианты решения проблем, творчески подходить к организации работы, смотреть на вещи шире своей специализации, пробовать, ошибаться.
Все это можно было и до Agile, но нужно было иметь большую смелость и авторитет, для того чтобы предложить что-то новое. Agile позволил нам открыто говорить о проблемах и обсуждать небанальные варианты их решения.
Слова на доске
Не секрет, что истоком всех Agile движений был митинг, произошедший в феврале 2001 года на горнолыжном курорте в штате Юта. Как выразился Robert C. Martin, зачинщик мероприятия, там собралась группа умных людей, которые никогда не встречались ранее и не планировавших встретиться в будущем. Цель собрания была одна — выразить нечто общее, что объединяло бы всех присутствующих.
О том, как создавался Agile манифест, есть много статей написанных самими участниками процесса [1], [2], [3]. Суть происходящего была в следующем: каждый из участников выписал на карточки идеи выражающие его точку зрения, и после того как карточки были организованы по категориям, стали очевидны четыре пункта, в которых все были единодушны. Далее они были красиво сформулированы:
- Люди и взаимодействие важнее процессов и инструментов.
- Работающий продукт важнее исчерпывающей документации.
- Сотрудничество с заказчиком важнее согласования условий контракта.
- Готовность к изменениям важнее следования первоначальному плану.
То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.
Документу нужно было придумать название, для которого голосованием было выбрано слово Agile, как признает Martin Fowler — не слишком подходящее слово.
Несущественное дополнение
Далее Agile манифест был расширен 12 принципами, но на их финальное согласование ушло еще несколько месяцев переписки по e-mail, что наводит на мысль о их второстепенной важности.
К слову, одним из принципов является релиз с частотой от двух недель до двух месяцев, что по сравнению с современными нормами — пара релизов в день — звучит архаично.
С другими пунктами тоже не все гладко, вот еще один пример: “Рабочее программное обеспечение — это главная мера прогресса проекта”. Это сомнительная метрика уже потому, что протестированное и выпущенное приложение совсем не означает, что оно окажется хоть кому-то полезным.
Неожиданные последствия
В событии участвовало семнадцать далеко не ординарных человек. Краткий список их достижений и вклада в индустрию можно посмотреть
под катом
- Kent Beck — XP co-founder, TDD, xUnit, Software Design Patterns.
- Mike Beedle — 2nd Scrum Adopter.
- Arie van Bennekum — Pragmatic.
- Alistair Cockburn — Crystal Methods, Software Design Patterns.
- Ward Cunningham — developed first Wiki, Design patterns, XP co-founder, invented Framework for integrated tests.
- Martin Fowler — Code Refactoring & Dependency Injection, UML, design patterns, XP.
- James Grenning — trains, coaches and consults worldwide, TDD for embedded systems.
- Jim Highsmith — Adaptive Software Development (methodology).
- Andrew Hunt — The Pragmatic Programmer book co-author.
- Ron Jeffries — XP co-founder.
- Jon Kern — in general respectable person.
- Brian Marick — The Craft of Software Testing (book).
- Robert C. Martin — SOLID principles, Software craftsmanship, Clean Code (book).
- Steve Mellor — developer of the Shlaer–Mellor method and Executable UML.
- Ken Schwaber — Scrum co-founder, www.agilealliance.org.
- Jeff Sutherland — Scrum co-founder.
- Dave Thomas — The Pragmatic Programmer book co-author.
Если визуализировать список создателей Agile по их отношению к технологиям и методологиями, получается любопытная картина:
В общем участников можно разделить на три категории:
- Инженеры: Robert C. Martin, для примера — те, кто в первую очередь повлияли на развитие технологий.
- Менеджеры: Ken Schwaber, Jeff Sutherland — внесли существенный вклад в развитие методологий, но не в технологии.
- Инженеры-Менеджеры: Kent Beck и Ward Cunningham — повлиявшие как на технологии, так и на методологии.
Удивительно ли, но наибольшую пользу от появления Agile получили именно менеджеры.
Инженеры-менеджеры с XP и другими подобными методологиями проиграли, чуть подробнее об этом далее.
Интереснее всего то, что в итоге инженеры встали в оппозицию и даже начали бороться с Agile. Например, несмотря на то, что Robert C. Martin был одним из основных организаторов мероприятия, теперь он не только выступает против, но и составил свой Software Craftsmanship Manifesto. Гибкость гибкостью, но мы профессионалы и должны работать как подобает профессионалам, не скатываясь до халтуры и спешки.
XP и другие устаревшие методологии
Тому что подходы XP, ASD или Crystal потерпели неудачу, есть вполне разумные причины, и более того, их много. У этих методологий много общего, поэтому посмотрим, что с ними не так на примере XP, поскольку в отличие от остальных он хотя бы еще всплывает в памяти.
Пожалуй, главная проблема XP в том, что он слишком подробный. Книга по XP содержит 160 страниц: трудно представить, что такого объема руководство может быть в полной мере реализовано в массовой разработке, ведь в каждом проекте есть своя специфика.
Кроме того, в дополнении к принципам организации работы, XP навязывает огромное количество способов ее выполнения, причем дорогих способов. Парное программирование — вполне осмысленная техника, но это лишь средство достижения определенного уровня качества и владения кодом. А вдруг можно добиться тех же результатов с меньшими усилиями? А что если работая другим способом, например, быстро исправляя проблемы, можно добиться большего?
Зато отдельные технические концепции, представленные в XP, стали стандартами индустрии. Сейчас уже никого не удивишь Continuous Integration или Daily Deployment. Но в том-то и дело, что это есть у всех.
Всем Scrum
Из всех Agile методологий в широкое обращение вошел только Scrum, и его распространенность по большому счету оправдана. Да, это сложная методология. Да, очень часто Scrum реализуют неправильно, получается черт-те что. Да, работа по Scrum склонна приводить к росту технического долга. Да еще много чего. Но все же Scrum — это лучшее, что есть на рынке. Если применять его осмысленно и целенаправленно, результат будет.
Проблема в том, что для Scrum нет хороших альтернатив, конкуренция отсутствует. А это нездоровая ситуация как для индустрии в целом, так и для Scrum сообщества в частности.
О’Жаль
Под флагом Agile придумано множество частных методологий, и, вероятно, они неплохо работают для авторов, но применимы ли они для индустрии в целом? Почему для Scrum нет хороших альтернатив? При том что Scrum появился до Agile, есть ли причины ожидать, что на базе Agile будут созданы методологии того же уровня?
Agile — это четыре утверждения, выражающие общие мысли нескольких умных и успешных людей. Но каждый из них имеет существенно большую картину ценностей, и это лишь тот минимум, в котором они сошлись исходя из их личного опыта на тот момент времени. Не удивительно, что в манифесте видится много проблем.
Неполнота — если из двух хороших идей, скажем, “пойти в кино” или “пойти в театр”, попытаться механически выделить общее, получится “пойти куда-нибудь”, что уже не кажется хорошей идеей. В своей работе каждый из участников руководствовался большим количеством принципов, так что вполне разумно предположить, что того минимума с которым согласились все, недостаточно для достижения успеха.
Поверхностность — код важнее документации, сразу видно, что собрались инженеры. Решение задач клиента важнее соблюдения бюрократических формальностей, возможно, так было бы правильнее.
Неопределенность — только на первый взгляд все кажется понятно, но как только эти принципы ложатся на конкретную ситуацию, правильное решение становится далеко не очевидно. Более того, при желании можно найти статью, подтверждающую любую из возникших точек зрения.
Наивный альтруизм — сотрудничество важнее согласования условий только до тех пор, пока не пришли штрафные санкции. Требование подписаться под манифестом подразумевает, что нужно согласится со всеми четырьмя утверждениями. Но что если обстоятельства не позволяют? Могу ли я следовать только трем из них без лишнего чувства вины за несоблюдения четвертого?
Узкая аудитория — обращение манифеста идет к разработке, а как же клиенты? Наивно надеяться, что правила можно поменять только со стороны разработки, если клиенты продолжают работать по-старому.
Ключевой целью манифеста было показать индустрии разработки, что процессы, методологии и саму разработку можно вести по-другому, заставить людей задуматься об этом. В этом смысле за манифестом следует признать полный успех. Что касается содержания, это скорее любопытный документ, отражающий наболевшие проблемы разработки начала нулевых, нежели фундаментальные принципы, которым мы все должны следовать.
И все же Agile
Главным достижением Agile-инициативы стал посыл — работать можно по-другому. Можно искать другие пути достижения целей, пробовать нестандартные варианты решения проблем, творчески подходить к организации работы, смотреть на вещи шире своей специализации, пробовать, ошибаться.
Все это можно было и до Agile, но нужно было иметь большую смелость и авторитет, для того чтобы предложить что-то новое. Agile позволил нам открыто говорить о проблемах и обсуждать небанальные варианты их решения.