» » » О’Жаль: Что не так с гибкими методологиями

 

О’Жаль: Что не так с гибкими методологиями

Автор: admin от 13-02-2018, 12:45, посмотрело: 108

Используя термин Agile, люди часто имеют в виду не что-то конкретное, но то что они правы. Например, не написал тесты — не Agile, не провел митинг с командой — не Agile, не заполнил тайм-трекинг — опять не Agile. Тому, что каждый трактует термин Agile по-своему, есть объективные причины, связанные с его происхождением.



О’Жаль: Что не так с гибкими методологиями
2001 года на горнолыжном курорте в штате Юта. Как выразился Robert C. Martin, зачинщик мероприятия, там собралась группа умных людей, которые никогда не встречались ранее и не планировавших встретиться в будущем. Цель собрания была одна — выразить нечто общее, что объединяло бы всех присутствующих.



О том, как создавался Agile манифест, есть много статей написанных самими участниками процесса [1], [2], [3]. Суть происходящего была в следующем: каждый из участников выписал на карточки идеи выражающие его точку зрения, и после того как карточки были организованы по категориям, стали очевидны четыре пункта, в которых все были единодушны. Далее они были красиво сформулированы:




  • Люди и взаимодействие важнее процессов и инструментов.

  • Работающий продукт важнее исчерпывающей документации.

  • Сотрудничество с заказчиком важнее согласования условий контракта.

  • Готовность к изменениям важнее следования первоначальному плану.

  • То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.



Документу нужно было придумать название, для которого голосованием было выбрано слово Agile, как признает Martin Fowler — не слишком подходящее слово.



Несущественное дополнение



Далее Agile манифест был расширен 12 принципами, но на их финальное согласование ушло еще несколько месяцев переписки по e-mail, что наводит на мысль о их второстепенной важности.



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



С другими пунктами тоже не все гладко, вот еще один пример: “Рабочее программное обеспечение — это главная мера прогресса проекта”. Это сомнительная метрика уже потому, что протестированное и выпущенное приложение совсем не означает, что оно окажется хоть кому-то полезным.



Неожиданные последствия



В событии участвовало семнадцать далеко не ординарных человек. Краткий список их достижений и вклада в индустрию можно посмотреть



Если визуализировать список создателей 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 позволил нам открыто говорить о проблемах и обсуждать небанальные варианты их решения.

    Источник: Хабрахабр

    Категория: Программирование » Game Development

    Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь.
    Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.

    Добавление комментария

    Имя:*
    E-Mail:
    Комментарий:
    Полужирный Наклонный текст Подчеркнутый текст Зачеркнутый текст | Выравнивание по левому краю По центру Выравнивание по правому краю | Вставка смайликов Выбор цвета | Скрытый текст Вставка цитаты Преобразовать выбранный текст из транслитерации в кириллицу Вставка спойлера
    Введите два слова, показанных на изображении: *