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 как софтверной методологии – горький пример того, как лаконичная и абстрактная идеология постепенно перевирается и искажается, по мере того, как ее влияние растет, и предпринимаются все новые попытки воплотить ее на практике.

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

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

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

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

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

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

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

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

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

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

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

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

      • НЛО прилетело и опубликовало эту надпись здесь
          +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
                      • НЛО прилетело и опубликовало эту надпись здесь
                          0
                          > Программист должен программировать

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

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

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

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

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

                              Самое читаемое