Agile: крупнейшая идеологическая проблема в IT

Автор оригинала: Кэмерон Хенди
  • Перевод
image

В 2001 году группа технологов и программистов, разделявших небанальные теории о том, как следует управлять разработкой ПО, встретились на горнолыжном курорте Сноубёрд, чтобы письменно изложить некоторые из этих концепций. Так родился «манифест Agile» — обманчиво простой документ, призванный пересмотреть догмы разработки ПО. Разработка ПО в стиле Agile превратилась в новый стандарт организации труда программистов в организации. Такие компании как Facebook, Amazon, Apple, Google и Netflix выстроили свои внутренние процессы разработки в соответствии с базовыми положениями этого манифеста. Учитывая абсолютные масштабы Agile и его общественный резонанс среди сторонников, легко убедиться, что Agile — самая влиятельная из всех когда-либо формализованных трактовок разработки ПО. Однако, Agile — это идеология. Нормативная система ценностей и убеждений, практически до основания впитавшихся в дело разработки ПО. Таким образом, софтверная индустрия сегодня дает интересную возможность оценить, как номинальные цели некоторой идеологии согласуются с ее воплощением на практике.

В сущности, Agile была бунтом против корпоративного засилья в разработке ПО. Впервые было признано, что разработка ПО – сложный и зачастую таинственный процесс, который обязательно нужно уберечь от корпоративной забюрократизированности. Изменения, переизобретение, гибкость, динамизм – вот красные нити, проходящие через манифест Agile. Они показали себя бесконечно привлекательными: согласно одному глобальному исследованию, около 97% всех организаций в той или иной форме практикуют принципы Agile. Благодаря такому повсеместному распространению, Agile достигла в теории управления разработкой ПО тотальной номинализации: сегодня термином «аджайл» именуют идеологию, методы работы и даже системы, используемые для разработки ПО в современной организации. Agile даже распространяется за пределы программерских команд и все чаще практикуется в других командах, отвечающих, например, за финансы или управление человеческими ресурсами. Agile, трактуемая как универсальная теория менеджмента, оказалась исключительно доступной и популярной – несмотря на скудость эмпирических подтверждений ее эффективности и полезности.

Интересно, что в манифесте Agile не делается попыток артикулировать какие-либо конкретные методы работы, правила, процессы, системы или структуры, которые помогали бы разрабатывать ПО в стиле Agile. Это и неудивительно: ведь манифест Agile никогда и не претендовал на подробное описание того, как достичь целей этого манифеста. Такая явная размытость ничуть не убавила популярности Agile: фактически, стремительный рост спроса на конкретные методы и инструменты Agile привел к возникновению метаиндустрии на основе ресурсов Agile. Этот интерес стимулировал внедрение Agile, проникновение в новые отрасли самой идеологии Agile и ее производных. Наиболее отчетливо проявили себя тщательно определенные методологии Agile (например, Scrum и Kanban—т.e., детализированные описания процессов, которых нужно придерживаться для воплощения принципов манифеста Agile) и специализированные софтверные платформы, специально разработанные для поддержки Agile-разработки. Австралийская технологическая компания Atlassian продает целый ряд таких продуктов, предназначенных для поддержки процессов разработки ПО в стиле Agile; особого упоминания заслуживают Confluence и Jira, уже де-факто ставшие стандартами в индустрии. Для тех, кто не варится в технологическом сообществе, такие продукты кажутся весьма таинственными. Появился целый ряд поясняющих статей, прежде чем Atlassian попала в списки NASDAQ и непосредственно после этого. Статьи были призваны объяснить, что же именно продает Atlassian, и почему компания добилась такой высокой рыночной капитализации.

Подобно программным продуктам Atlassian, лексикон, описывающий процессы Agile и повседневные рабочие приемы, также стал все более непроницаемым для непосвященных. Практикующие Agile говорят о спринтах, досках Kanban, диаграммах сгорания задач, скоростях, пользовательских историях, эпиках и ретроспективах — значение всех этих слов зачастую меняется в зависимости от контекста, а сами эти термины могут быть аффилированы с одной или несколькими явно определенными методологиями Agile. Стоит ли удивляться, что, по мере усложнения методологии Agile, множится и когорта специалистов-консультантов, помогающих все это осмыслить. В Bain & Company к услугам клиентов – около 1000 практиков Agile. Пожалуй, это самый надежный индикатор, демонстрирующий, какой прибыльной стала индустрия Agile-консалтинга. Однако, если манифест Agile столь прост, каким кажется на первый взгляд, то зачем же столько консультантов? Насколько ощутимо услуги любого из них отражаются на качестве и эффективности работы в типичной технологической компании?

Несмотря на лексикон, специализированные инструменты и колоссальный корпус ресурсов, доступных для каждого, кто желает практиковать в своей компании разработку ПО в стиле Agile, зачастую сложно отследить, насколько точно Agile реализуется на практике – то есть, соответствует духу и букве, зафиксированными авторами в манифесте Agile. Манифест Agile намеренно и неизбежно сделан абстрактным. Вероятно, это и привело к постепенному извращению методологии Agile и, как следствие, всей культуры менеджмента в софтверной индустрии как таковой. На, казалось бы, простых основах было выстроено нечто колоссальное – механизм, крайне разочаровавший тех, кто заложил основу для его первой итерации. Более того, по причине долгой популярности Agile специалисты, не имеющие формальной Agile-квалификации, стали проигрывать конкуренцию коллегам, которые в Agile якобы профессионально разбираются. Множество карьерных бонусов ждет тех, кто заявляет, что понимает устройство Agilr и умеет его применять. Такая реальность стимулирует конформизм и топит любые попытки усомниться в доминировании Agile или поставить ребром вопрос о ее эффективности.

Энди Хант, один из авторов-основателей манифеста Agile, жалуется, что из-за абстрактной формулировки оригинального Манифеста появились и распространились бесконечные правила, используемые вне контекста и якобы образующие основу разработки в стиле Agile. Со временем такие правила кодифицируются в виде специализированных методологий, которым требуется бездумно следовать, забывая при этом об исходных руководящих принципах Манифеста. Иными словами, идеология Agile оказалась исключительно сложна для изучения, усвоения и практики. Поэтому некоторые персонажи опираются на жестко определенные правила или эвристику, которые выдают за Agile, а потом продолжают подменять этими правилами (часто вырванными из контекста) практику Agile, соответствующую целям Манифеста. В большинстве организаций никакого постепенного оттачивания процесса разработки не происходит; вместо этого менеджеры впадают в заблуждение, считая, что процесс не допускает изменений, отказываются от пошагового улучшения продукта, а стремятся содрать с разработчиков по три шкуры, оперируя при этом в основном взятыми с потолка и жестко зафиксированными канонами. Организациям, которым не удается извлечь никакой реальной пользы из Agile (а таких много) закономерно тяготеют к отслеживанию реализации некого Agile-процесса, игнорируя при этом более размытые, но при этом и более важные результаты процесса – то есть, поставку работоспособного ПО.

Расцвет Scrum и Kanban – это, в лучшем случае, попытка формализовать и распространить идеологию Agile. В худшем же случае все эти методологии – не более чем дополнительная бюрократия, порождающая все новые необоснованные правила и метрики, которым должны следовать разработчики. Все это навязывается по причинам, зачастую совершенно не подкрепленным эмпирически. Посредственные менеджеры, консультанты, разработчики и даже целые организации в таких условиях благоденствуют: становится проще зацикливаться на номинальных правилах идеологии, и постепенно это оказывается приоритетнее достижения реальных целей. В принципе, в индустрии разработки ПО наблюдается мания с измерением «вклада» и «отдачи» от Agile на уровне отдельных сотрудников. Такая мания привела к пренебрежению исходной этикой Agile, смещению приоритетов к сбору статистики по каждому отдельному сотруднику, тогда как на самом деле нужно постепенно улучшать процессы на уровне всей организации.

Величайшая ирония подобного вырождения заключается в том, что исходная философия Agile была призвана освободить среднего программиста от тирании микроменеджмента и ненужного бюрократического надзирательства. Вместо этого сама суть этой идеологии в ее нынешнем виде уже с трудом узнаваема для тех, кто ее создавал. В более общем плане судьба Agile как софтверной методологии – горький пример того, как лаконичная и абстрактная идеология постепенно перевирается и искажается, по мере того, как ее влияние растет, и предпринимаются все новые попытки воплотить ее на практике.
Издательский дом «Питер»
209,00
Компания
Поделиться публикацией

Похожие публикации

Комментарии 27

    +7
    Если читать любую нормальную книгу по аджайлу то внезапно оказывается что методология это 10% успеха. а 90% успеха применения аджайла — это мотивация людей, чтобы каждый грубо говоря «выкладывался на 100%». Зачем контролировать людей если они замотивированы выдать максимум того что могут, как будто они и есть владелец продукта (фактически, выгодоприобретатель). Поэтому аджайл так всем нравится. Но как можно замотивировать работника ощущать себя владельцем продукта если он им не является? Отсюда и ключевое противоречие аджайла, а сюда еще накладывается и расслоение по заработным платам.
    Вот, например, возмем тестировщика, как ему ассоциировать себя с владельцем продукта если у них с реальным владельцем продукта соотношение получаемых от этого денег 1/5 или даже 1/10? Только вымыть ему мозги «тимбилдингом» и «коучингом». Чтобы он аж по 12 часов в день работал. Да еще и по выходным.
    Мы же гибкие, надо что-то добавить? Сейчас наши разработчики выходные посидят и все будет. Потому что схема взаимодействия между юридическими контрагентами она никуда не делась. Есть конкретные сроки и есть неустойка по ним.
      0
      >Зачем контролировать людей если они…

      Что бы интегрировать их деятельность максимально эффективно по отношению к критериям успеха.
        +1
        Контроль подразумевает постоянную корректировку к критериям успеха. Правильно замотивированные люди делают это самостоятельно. Ты их замотивировал на эти критерии успеха и дальше они уже сами выбирают лучший вариант движения к ним, который командно видят. Ключевое здесь командно, т.к. ни тимлид ни менеджер не обладают компетенциями всей команды. И на самом деле это отличная схема когда все участники команды являются владельцами продукта, чего на самом деле нет.
          0
          >Ключевое здесь командно, т.к. ни тимлид ни менеджер не обладают компетенциями всей команды.

          В группе необходим человек со стратегическим видением будущего в составе навыков ведения программ/кейсов/проектов.

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

          Людей с такими способностями и навыками мало.

          Остальные танцуют свой танец, это ньансы какой, но если если есть толковый стратег и все будут к нему прислушиваться, то танцы сойдуться в продукт.
            0

            В скрам-командах такой человек, прежде всего, PO. Он осуществляет целеполагание команды как на ближайшие пару недель, так и, иногда, на годы вперёд.

        0
        Зачем контролировать людей

        А как же направление сил/мотивации в нужном направлении?
        Толку-то от замотивированного спеца, если он делает не то, что нужно бизнесу? А рискует свою собственную новейшую СУБД, просто потому что ему это интересно. Но не потому что это нужно.

          0
          Наивысшим приоритетом для нас является удовлетворение потребностей
          заказчика

          Кроме того, короткие (по отношению с классическим проектнім управлением) длительности итераций позволяют быстро заметить то делает или не то. Никто не говорит, что контроль вообще не нужен, но обычно в аджайл подразумевается прежде всего самоконтроль команды. Очень, грубо, команда должна давать по рукам спецу, который начал пилить собственную СУБД, не обсудив и получив согласия от всей команды, включая PO.

        +1
        Трудно представить себе мотивацию программистов, пилящих скучную ERP для банка. Мобильную игру — возможно, какую-нибудь дополненную реальность или управление автомобилем — могу поверить. А систему, которую никто не увидит кроме тысячи сотрудников банка — вряд ли. Там могут спасти только новейшие технологии, но банки обычно консервативны в этом плане, повсюду до сих пор Windows 7 и Java 6. И я с трудом себе представляю прямое общение раба на галерах с вицепрезидентом банка — все изменения утверждаются абстрактным комитетом под надзором внутреннего аудита.

        Получается в области, где платят больше всего, аджайл применим меньше всего. И это относится к аутсорсу в том числе. А новые методологии — удел стартапов, где заказчик и владелец — одно лицо. Пока разумеется на продадут.
          +2
          Ну и такие банки проиграют конкуренцию со временем всяким финтех стартапам, либо будут вынуждены их за большие-большие деньги покупать. Раб на галерах и хозяин с плеткой априори обречены, потому что не эффективны (наемный труд, внезапно, намного эффективнее рабского, как и творческий подход эффективнее подхода из под палки).
            0

            Как только "финтех стартап" выйдент на IPO, а значит попадёт под власть финансовых органов по надзору конкретных стран — так сразу их прыгание с Библиотека/Фреймворк 1.0 на Библиотеку/Фреймворк 1.1, а потом сразу же по выходу — Библиотеку/Фреймворк 1.2… 1.3… 1.4 и т.д. — закончится и начнётся банальная финансовая рутина, которая на каждое изменение требует 20 апрувментов и 30 финансовых менеджеров, которые непонятно как в туалет друг без друга ходят.
            Альтернатива — отчуждение лицензии и закрытие рынка финансов в стране на неопределённый срок, а в худшем случае — обвинение в финансовых преступлениях. Или не дай боже — уклонение от уплаты налогов (которое в некоторых странах карается сильнее чем убийства и изнасилования: как же поимел государство — на тебе!)

          +1
          Небольшой оффтопик. Решил на этот раз оформить у вас покупку бумажных книг и столкнулся с непонятной ситуацией. На шаге выбора варианта доставки перешел днём (часа в два) по ссылке «Выберите пункт самовывоза». Открылась карта и пустой список пунктов … вверху надпись «Технологии ИПОЛ» с таким необычным шрифтом (и ссылка ведет на ipolh.com). А в разделе «Пункты самовывоза» пусто и крутится кружочек с большой скоростью … сейчас уже пол-шестого, а он до сих пор крутится. Сколько же обычно нужно ждать, чтобы появились пункты самовывоза для выбора?
            0

            Эджаил… Скрум…
            Всякие красивые бизворд. Если с головы не идёт установка "мы все как один и один за всех" — хоть обаджаился.
            Переживал 2 внедрения этого счастья в крупных компаниях… Ну теперь мы постоянно сидим на коротких встречах или лепим бумажки на стенку, а бюрократия так и осталась как была.
            Если сотрудникам не интересно, если они "последний козел отпущения" в пищевой цепи… Ну — удачи.


            Хотя сама по себе концепция интересная и наводит на старую мысль — 13 человек это предел эффективно группы.

              0
              Подобно программным продуктам Atlassian, лексикон, описывающий процессы Agile и повседневные рабочие приемы, также стал все более непроницаемым для непосвященных. Практикующие Agile говорят о спринтах, досках Kanban, диаграммах сгорания задач, скоростях, пользовательских историях, эпиках и ретроспективах — значение всех этих слов зачастую меняется в зависимости от контекста, а сами эти термины могут быть аффилированы с одной или несколькими явно определенными методологиями Agile. Стоит ли удивляться, что, по мере усложнения методологии Agile, множится и когорта специалистов-консультантов, помогающих все это осмыслить

              Ну так это, один из признаков секты — свой особенный язык.


              исходная философия Agile была призвана освободить среднего программиста от тирании микроменеджмента и ненужного бюрократического надзирательства

              Хаха! Скрам — это нечто противоположное такой свободе.

                –2
                Вы неверно понимаете скрам (как и многие). Скрам это не про «обсуждаем раз в день project state из под палки», а про «все могут высказать свое мнение, помочь друг другу найти лучшее решение». Скрам — это про поощрение инициативы и инноваций, гибкое принятие решений исходя из наиболее полной информации + всеобщее понимание «что» за продукт они разрабатывают.
                  0

                  О, сертифицированный скрам мастер нашелся

                    –2
                    Срам-мастер.
                0
                О, сертифицированный скрам мастер нашелся.
                промахнулся, коммент был направлен веткой выше
                  +1
                  Либеральная и демократическая идеология может стать идеологической основой тоталитарной системы. А может и не стать.

                  Идеология «освобождения крестьян» может стать основой принудительной коллективизации.

                  Agile-антибюрократическая идеология легко превращается в формально-бюрократическое обоснование процедур ИБД, замкнутых на самих себя.
                    0
                    бюрократизировать можно что угодно и даже без аджайла.
                    +1

                    Как по мне, то проблема не идеологическая, а терминологичнская. Аджайлом и скрамом в частности называют формальные процессы, способ организации работ, забыв или не зная даже о том, что собранные под одним начальником люди и "гибкие" процессы — это не достаточное основание называть их аджайл! Скрам командой

                      0
                        +1
                        Мне кажется в экстремуме agile не освобождает программистов, а навешивает на них кучу обязанностей, на которые они условно говоря не подписывались. Все эти ежедневные митинги, планирование, выбор задач… Выглядит так, как будто менеджер перекладывает свои обязанности на других, причём остаётся при той же (а то и выше — если скрам мастер) зарплате.

                        Программист должен программировать — этому он обучался и это его мотивирует, всё остальное — не его проблемы. Если так хочется поиграться в карточки — соберите себе команду скрам-мастеров и играйте в удовольствие — не мешайте только программисту работать.

                        Если так хочется сделать что-то модное чтобы программисту понравилось — дайте ему час в день на саморазвитие и железо для экспериментов, которые могут и не относиться к непосредственной деятельности компании. Всё на пользу пойдёт. А всякие аджайлы для программиста могут заключаться только в выборе среди равноважных задач. А важность ставит начальник на основе информации, полученной от заказчика. Как-то так.
                          0
                          > Программист должен программировать

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

                          А вот роль менеджера-тимлида в Скраме отсутствует. Можете считать, что бизнес при внедрении скрама эту роль сокращает и навешивает большинство обязанностей на владельца продукта и команду.
                            0
                            Программист должен программировать

                            Программировать что именно?
                            Координироваться-то с другими надо.
                            0
                            Agile это своего рода обман. Как бы все вовлечены в продукт и даже что-то решают, начинают ощущать себя собственниками продукта и соответственно работают больше. А на деле никакими собственниками они не являются, их могут уволить/сократить когда реальный собственник решит.
                              0
                              Из разряда «меня обманывать не надо — я сам обманываться рад?»
                                0
                                не «работают больше», а «работают нормально».

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

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