Кризис Agile. Что делать?

Автор оригинала: Maurice “Mo” Hagar
  • Перевод
Ключевые моменты
  • Многие организации устали от Agile
  • Часть проблемы — в существовании большой коммерческой отрасли Agile
  • Нужно вернуться к основам: простоте Манифеста и 12 принципов
  • Примеры базовых и простых фреймворков: Heart of Agile и Modern Agile
  • Многие уроки можно извлечь из таких гуманитарных наук, как позитивная психология, направленное самосовершенствование и решение-ориентированная терапия

«Agile agile Agile agile agile agile Agile agile».

Мантра? Не совсем, хотя это может вызвать изменённое состояние сознания.

«Ответ на главный вопрос жизни, вселенной и всего такого?» (Дуглас Адамс, «Путеводитель для путешествующих автостопом по галактике»). Может быть, смотря кого спросить.

Это омонимы. Слова, которые выглядят и звучат одинаково, но имеют разные значения. Как это грамматически правильное предложение, состоящее из трёх совершенно разных слов: «Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo», Дмитрий Боргманн, «За пределами языка: путешествие слова и мысли» (фразу можно перевести так: «Буффальские бизоны, которых пугают буффальские бизоны, пугают других буффальских бизонов» — прим. пер.).

Риск чрезмерной омонимизации заключается в том, что слова начинают означать всё и вся, в то же время не означая ничего конкретного. Это психологический феномен, известный как «семантическое насыщение», форма ментальной усталости.

Как описывает психолог Леон Джеймс:

Это называется реактивным торможением: когда нейрон срабатывает первый раз, то для второго импульса требуется больше энергии, и ещё больше в третий раз, и, наконец, в четвёртый раз он даже не ответит, если вы не подождёте несколько секунд… если повторять слово, значение продолжает повторяться, а затем становится невосприимчивым или более устойчивым к повторному вызову.

Сегодня «Agile» означает всё и вся. Всё чаще это ничего не значит. Многие организации стали трудновосприимчивы или невосприимчивы к термину, как в предложении «Agile agile Agile agile agile agile Agile agile».

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

Я был на конференции Agile Africa в ЮАР, ко мне кто-то подошёл и сказал: «Мы хотим заниматься разработкой программного обеспечения, но мы просто не можем выдержать все эти церемонии и штуки Agile. Мы просто хотим написать несколько программ». Я чуть не заплакал… как могло случиться, что мы вернулись на двадцать лет назад? (личная переписка, цитируется с разрешения).

Это хороший и важный вопрос. И поднимает другие важные вопросы, например, «Что делать дальше?» Недавно Рон Джеффрис представил очень реальную возможность:

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

Что бы мы ни решили, давайте начнём с признания: многие из нас, активистов Agile, усугубляют ситуацию. Как Пого сказал Поркипайну: «Мы встретили врага — и оказалось, что это мы сами» (Уолтер Келли, «Пого»). Мартин Фаулер так выразился на конференции Agile Australia 2018:

… Индустрия Agile (Agile Industrial Complex), навязывающая методы людям… это абсолютная пародия. Я собирался сказать «трагедия», но думаю, что «пародия» лучше подходит, потому что, в конце концов, в разработке программного обеспечения нет универсального подхода. Даже сторонники Agile говорят, что эта методология подходит не всем. Всё должна решать команда разработчиков. Это фундаментальный принцип Agile. Это даже означает, что если команда не хочет работать гибким способом, то Agile ей уже не подходит, а [отказ от Agile] — это для неё самый гибкий способ разработки, в каком-то странно искажённом мире логики. Итак, это первая проблема: индустрия Agile и навязывание одного самого лучшего способа работать. Это то, с чем мы должны бороться.

Индустрия Agile. Тёмный Agile. Поддельный Agile. Зомби-Agile. И становится ещё хуже. Вот что говорит мой друг, организационный психолог:

Agile — это вирус, распространяющийся по всему предприятию. И вы не должны удивляться растущему сопротивлению. Потому что это то, что антитела естественно делают, когда вторгается антиген. (личная переписка)

Чего?

Вот на что это похоже: вторжение. Потому что ваши «эксперты» по трансформации бизнеса на удивление мало знают об организационной динамике и психологии изменений. Один вопиющий пример: понимаете ли вы, какое сопротивление вы мгновенно создаёте — на нескольких уровнях — когда объявляете кого-то «мастером»? Особенно, когда единственное мастерство, которое у него есть, — это двухдневные курсы! (оттуда же)

Ох. Я не посмел сказать ей, что «тренеров» тоже назначают после двухдневных курсов. Недавно я слышал, как один из этих «тренеров» спросил: «Для Agile нужен очень хороший менеджер проектов?»

«Да, конечно, нужен первоклассный менеджер проектов, менеджер итераций, скрам-мастер, как бы вы его ни называли, который говорит тихо, но ходит с очень большой палкой!»

Просто слёзы на глаза наворачиваются.

Один из моих клиентов, изучив обширный ландшафт сертификации, открыл собственный сервис. Теперь десятки скрам-мастеров и владельцев продуктов с гордостью показывают его в своих кабинетах: Agile Yahoo.

Что дальше?

Внутренняя политика — в мире Agile


Внутренняя политика — это широкая и всеобъемлющая стратегия, или конкретный план, или даже простой принцип управления внутренними делами.

В эпоху экспансии Agile — трансформации бизнеса — давайте сначала проясним, что мы подразумеваем под «Agile agile agile».

Чтобы сформулировать то, что должно быть очевидным, вот простой принцип: любой Agile должен явно или неявно ссылаться на четыре базовые ценности и 12 принципов Манифеста Agile. Он должен содержать «подсказки» Agile.

Мы должны вернуться к основам. Agile нуждается в перезагрузке. «Гибкие» команды должны регулярно пересматривать Манифест и 12 принципов: что это значит? Как у нас дела? Как продолжать двигаться в этом направлении?

Частично это означает постоянно ограничивать собственные гибкие практики, чтобы они оставались гибкими. «Простота крайне необходима» (12 принципов) является «ключом» Agile, и мы обязаны следовать собственным принципам.

Всё действительно просто, очень просто, говорит Дэйв Томас:

Узнайте, где вы находитесь. Сделайте маленький шаг к цели. Скорректируйте своё понимание на основе того, что вы узнали. Повторите.

Точно так же Heart of Agile Алистера Кокберна — это агностический подход, основанный на простой структуре: сотрудничать, доставлять, отражать и улучшать. Modern Agile Джошуа Кериевского основан на четырёх простых принципах: сделать людей удивительными, сделать безопасность обязательным условием, быстро экспериментировать и учиться и постоянно приносить пользу.

Внешняя политика — за пределами мира Agile


Внешняя политика — широкая и всеобъемлющая стратегия, или конкретный план, или даже простой принцип управления внешними делами.

В эпоху экспансии Agile — трансформации бизнеса — давайте сначала проясним, что мы подразумеваем под «Agile agile agile».

Когда группы людей, такие как активисты Agile, отправляются в другие страны, неизбежно происходит столкновение культур.

Первые экспедиции Agile характеризовались дипломатией канонерок. Например, покорение Управления Проектами почти завершено.

Теперь мы сталкиваемся со странными новыми странами, такими как Человеческие Ресурсы и встречаемся с группами людей, которые называют себя организационными психологами, и у них больше сертификатов, чем у нас.

Какова наша дипломатическая политика? Мы считаем себя рейдерами или торговцами?

Давайте остерегаться наивного — и обречённого на провал — колониализма, предполагающего, что мы превосходим аборигенов, коих следует окультурить для их же блага и прибыли.

Более того, следует остерегаться собственной ассимиляции, подобно некогда грозным викингам, исчезнувшим в тумане легенд. Например, я принадлежу к растущему всемирному движению за интеграцию Agile с позитивной психологией, направленным самосовершенствованием (Appreciative Inquiry) и решение-ориентированной терапией (Solution Focused Brief Therapy), см. мою статью по решение-ориентированному Agile. В то же время, всё больше моих коллег вообще убирают слово «Agile», поскольку полностью ассимилировались в другой мир.

В целом, наша внешняя политика заключается в том, чтобы работать не в плавильном котле, а в смеси компонентов.

Этот подход иллюстрирует простая матрица разрешения конфликтов (адаптировано отсюда). Наша позиция — не конкуририровать (Agile выигрывает) и не поддаваться (Agile проигрывает), а сотрудничать (выигрывает бизнес).



Это пример действия эффекта Медичи. Одноимённая книга Франса Йоханссона 2006 года сильно повлияла на моё мышление. Эффект Медичи, названный в честь итальянской семьи 14-го века, которая вызвала европейский Ренессанс, упоминает прорывное мышление и прорывные инновации, которые часто образуются из большого взрыва на стыке различных дисциплин, культур и отраслей промышленности. Я сразу уловил идею, потому что проводил эксперименты со взрывами ещё с набором юного химика в детстве.

Эффект Медичи отвечает на вопрос, который мне иногда задают: почему я редко посещаю Agile-мероприятия? Сообщество Agile имеет важное значение. Но эффект Медичи заставил меня постоянно выходить за пределы того, что я уже знаю. И я быстро обнаружил, что для меня просветление и прорывы чаще вызваны взаимодействием с военными офицерами, религиозными лидерами, поэтами, философами, биологами и психологами. Большая часть работы в моей жизни стала соединением точек между этими связанными, иногда не связанными дисциплинами и экспериментированием с новыми и различными способами работы.

Вывод


Междисциплинарные исследования, принципы и практика — это будущее Agile. Именно поэтому настолько важно не терять связи с корнями, пока мы продолжаем использовать слово Agile. Пожалуйста, прекратите это «Agile Agile Agile бла-бла-бла».
Поддержать автора
Поделиться публикацией

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

    +6
    Тут сложно не согласиться. По сути, изначально простой посыл «гибко подстраиваться под изменяющиеся требования» сейчас превратился в кучу ритуалов, участники которых зачастую нифига уже и не помнят, зачем оно всё создавалось.
      0
      Вы описали классический путь религии :)
      +4
      Всё, что я вынес за годы практики и разного вида «у нас тут свой аджайл» сводится буквально к одному – хорошей команде при адекватном менеджменте аджайл (плюс другие фреймворки, позволяющие сделать процесс разработки и доставки управляемым) поможет стать еще лучше, остальным не поможет ничего.
        –3
        Потому что принципы agile не реализуемы без дотошного высокоуровневого менеджмента.
          0
          Господам, наминусовавшим без контраргументов, и молчаливым читателям поясню:

          Аджайл это ценности.

          Individuals and interactions over processes and tools
          Working software over comprehensive documentation
          Customer collaboration over contract negotiation
          Responding to change over following a plan

          Эти ценности буквально говорят, что главное — качественный продукт кастомеру. Если ваши процессы мешают созданию продукта, то подвиньте их. Потому что «Working software is the primary measure of progress».

          В хороших командах эти ценности позволяют в спорных моментах принимать правильные решения в пользу проекта.
          В плохих командах эти ценности используют для защиты собственных интересов членами команды при срывах сроков и прочих проблемах.

          Если представить все это как уравнение, то ценности и принципы — это коэффициент. Что умножаешь на этот коэффициент, то и получаешь в итоге, только в большем количестве.

          Если команде с плохим менеджментом (менеджмент это не только менеджеры, которые ставят тасочки, это в целом культура и процессы в команде, уровень планиварония, отношение к проекту, понимание своих обязанностей), просто так взять и начать работать руководствуясь принципами гибкой разработки, то это чаще приведет к еще большему бардаку. Если в команде отсутствовало грамотное планирование, оно не появится, если просто поддержать эти ценности. Если у членов команды были проблемы с ответственностью и налаживанием процессов, то «individuals and interactions over processes and tools» будет использоваться как оправдание.

          Как же придерживаться этих ценностей на практике и получать хороший результат?

          Для этого можно посмотреть на вполне рабочий Scrum, который «аgile framework» — набор готовых инструментов, позволяющий работать, придерживаясь вышеуказанных ценностей. Набор описанных процессов и правил, следуя которым, вы будете делать продукт быстрее и с лучшим контролем качества, регулярнее доставлять продукт кастомеру и более гибко реагировать на изменения.
          Почему Скрам позволяет работать по принципам Agile, можно понять, взглянув на его «внутренности». Там вдруг оказывается куча правил, которые нельзя нарушать, множество ограничений, ежедневные строгий контроль результата, постоянные митинги, тщательное планирование, ответственность каждого члена команды за результат. Скрам — это про хороший, внимательный к мелочам менеджмент.

          Да, есть еще «пацанский» Scrum, когда команда просто переходит, к примеру, на спринты, оставив при этом все старые плохие привычки в процессах, и считает что этого достаточно. А потому статьи пишут, какие эти ваши скрамы с аджайлами говно.

          Аджайл это хорошо, потому что это работа на результат. Чем слаженней команда, чем устойчивее процессы в ней и чем лучше дисциплина, тем больше подобные принципы помогают достичь желаемого результата. Потому что за гибкостью стоит слаженная работа, которая невозможна без дисциплины, хорошего менеджмента, планирования.
            0
            Эти ценности буквально говорят, что главное — качественный продукт кастомеру.

            Ну тогда правильного аджайла практически не существует на практике, как по мне. Современный аджайл в основном направлен на продажу часов кастомеру, а не на решение его проблем.
          +1
          хорошей команде при адекватном менеджменте аджайл (плюс другие фреймворки, позволяющие сделать процесс разработки и доставки управляемым)
          … просто не нужны!
            +1
            Процессы нужны. Потому что какая бы классная не была бы команда, но люди например болеют или увольняются. И в такой ситуации если у вас сыгранная команда, но нет процессов, то Вам надо каждый раз «сыгрывать» команду заново когда приходят/уходят люди.

            Или например такие вещи как увеличение фирмы/отдела. Что вы например будете делать если у вас вдруг из одной команды нужно сделать две, три, пять, десять потому что фирма растёт и растёт обьём работ?
              0
              Если такое происходит часто — уволюсь. Нет, правда уволюсь. Разбивать сыгранную команду — преступно. Перемешивать разработчиков для «распространеня знаний» просто глупо. На выходе вы полцчите две несыгранные команды и издерганых разработчиков.

              Чтоб два раза не вставать… Вам не кажется, что автор статьи пришел из какого-то культа? Там характерные фразы про завоевание, присвоение успехов и соответственно сваливание вины за неудачи, неприятие прямо противоположной точки зрения просто потому, что она явно противоречит его принципам и т.д.

              Насчет правильноги и неправильного agile… Не, ребята, так не пойдет. Методология или есть или нет. Если есть, что отвественность за неудачи лежит именно на методологии, а не на том, что «ее неправильно применили». Неправильно применили потому, что методология допускает неправильное применение.

              Ответ на вопрос почему программисты не хотят больше играть в agile прост — наигрались. Мы любим играть. Это в натуре у нас — пробовать все новое. Но так-же как и у детей как только стало понятно что это и зачем — разобрать, сломать и выбросить за ненадобностью. Так и с agile — новизна ушла, магия кончилась, интерес пропал. На самом деле разработчики гораздо больше понимают в разработке ПО, чем все эти мастера, коучи и консалтеры вместе взятые. Поэтому впарить то, что не дает весомых приимуществ, очень сложно. Оно может таже в итоге выгладеть «как положено» (зомби agile), но внутри все равно будет именно тот процесс, что выбран программистами.

              По всему вышесказаному, считаю, что единственая методология — отсутствие таковой. Точнее команда всегда сама выбирает как ей работать. Очень правильно все описано в оригинальном варианте «programming mother...» / «пиши код...» (русский перевод настолько искажен, что лучше его вообще не читать).
                0
                Разбивать сыгранную команду — преступно

                Это может быть насколько угодно преступно, но это происходит повсеместно, даже в самых лучших фирмах. И часто действительно из необходимости и не по желанию самой фирмы. Люди болеют, увольняются, уходят на повышение и т.д. и т.п.
                Фирма конечно может надеяться что сыгранная команда останется сыгранной на протяжении десятилетий, но как минимум по моему опыту каждые полтора-два года происходят какие-то изменения.

                Насчет правильноги и неправильного agile… Не, ребята, так не пойдет. Методология или есть или нет.

                Методология Agile как такового на самом деле очень гибкая и «разрешает» многое. Поэтому Аgile-процесс может быть кривым до невозможности и всё равно оставаться в рамках Аgile.

                Ответ на вопрос почему программисты не хотят больше играть в agile прост — наигрались.

                А вот тут надо говорить за себя. Я например всё ещё хочу в это играть. Потому что Agile далеко не идеален, но лучшей альтернативы я лично пока не вижу.

                По всему вышесказаному, считаю, что единственая методология — отсутствие таковой. Точнее команда всегда сама выбирает как ей работать.

                Извините, но это и есть Agile. И в нормальном Agile команда подстраивает процессы под себя. Но процессы всё равно есть и все в команде должны и им следовать. Ну или совместно их менять.
          +7

          Знаком с компанией, в которой, по сути, разработка идёт по принципу "х**к, х**к, и в продакшн". Менеджмент гордо называет это аджайлом. Нет, есть Git, Bitbucket (правда, совсем не везде), есть код-ревью (правда, совсем не всегда), есть дев-сервера (на которых из-за специфики некоторые вещи не обкатываются)… TDD нет от слова "совсем". Кодовая база на миллионы строк кода (не считая библиотечного). Маленькая команда разработчиков, человек 6-7. Не все старожилы (самые старожилы давно куда-то улетели), не все сениоры и даже миддлы. А компания с 90-х растёт и процветает. У разработчиков работы всегда много, но почти никогда никто не стоит за спиной, допрашивая насчёт дедлайна. Никто не перерабатывает (супер-серьёзные деплои делают ночью, но это очень редко). В целом, все довольны жизнью. Такое, вообще, возможно, или они в сказку попали?

            +1
            Есть такая штука — как человеческий фактор. Его нельзя полностью формализовать, несбыточна мечта менеджмента. Человек может горы свернуть, если правильно мотивировать, а можно излишней формалистикой вообще все ростки убить, даже самые последние. От себя могу сказать, что в период, когда этих умных «фраз» было меньше — делали больше: и заказчик был доволен и у нас клиентура росла. Может моложе были, не знаю. Не буду судить. Сейчас же, менеджмент все хочет контролировать и, в результате, «выплескивает из корыта и ребенка» — сам продукт собственно. То, что сам процесс формализовали — это хорошо. Но то, как по факту массово применили — плохо. Надо подходить ко всему, взвешивая за и против.
            +6
            Agile — это просто неумеренно раздутый слон, которого пытаются продать даже в блошиный цирк. И пока продают, увы.
              +9
              НАСТОЯЩИЙ AGILE НИКОГДА НЕ БЫЛ ПОСТРОЕН!
                +1
                Agile Yahoo
                так толсто, что даже тонко.
                  –1

                  Очень много букв :-), но, в общем, соглашусь.
                  Ещё добавлю фразу-вопрос одного топ-менеджера про то, зачем Agile'ом называть здравый смысл.
                  На мой взгляд, различные фреймворки (XP, Scrum, DSDM и т.п.) — это способы понять, о чём Agile, но беда в том, что некомпетентность всё развращает.

                    –2
                    На мой взгляд, различные фреймворки (XP, Scrum, DSDM и т.п.) — это способы понять, о чём Agile

                    Скорее все эти методологии для того, чтоб не дать увалить процессы аджайлом.
                    +2
                    Всё по делу. Менеджмент ничего не понимает в разработке, но при этом ему нужно показывать свою значимость и видимость, а это реструктуризация, изменение системы управления. Поиграются на компании, и уходят в другую с повышением. Модная тема, которую топы используют в своих интересах. А вокруг консультанты рубят капусту. Хорошую идею Agile, как и социализм, испоганили и превратили в что-то нарицательное.
                      +3
                      Организовать удачный agile — это как постичь Дзен: куча нюансов и тонкостей, бесполезно копировать чужой опыт и упражняться, всегда нужно помнить о сути. Коммерсанты развели ересь.
                        +1
                          +2
                          Agile — это слово маркетологов для привлечения клиентов. Как раньше .com, недавно биткоин и другие всем известные «волшебные» слова, от которых рука инвестора или топ-менеджера тянется к кошельку.
                          В основополагающих принципах Agile нет ничего нового и ранее до Agile никому неизвестного. А некоторые из них противоречат один другому согласно принципу выбери два из трех: Качественно — Быстро — Дешево.
                          Все ищут волшебную таблетку, которой в реальности нет и никогда не было. Думать надо самостоятельно и организовывать работу в соответствии с решаемыми задачами. Если есть для этого уже готовые подходящие методики и инструменты, их надо использовать. Только смотреть насколько они подходят именно вам, а не пихать всех подряд в прокрустово ложе одного из многих методов.
                            +3
                            Есть лишь два метода разработки: хорошо организованный и дезорганизованный.
                              +3
                              Революцию задумываются романтики. Реализуют фанатики. А плодами пользуются негодяи.
                              Так же используется agile.
                              Благими намерениями выстелена дорого в ад.
                              В ад похоже уже пришли.
                                +6
                                Agile стал мантрой: говори вслух про гибкую разработку и твори фигню!
                                У нас Agile — поэтому мы внесём критические правки в задачи спринта за 2 дня до релиза.
                                У нас Agile — средняя загрузка разработчиков по оцененому времени за спринт 600%.
                                У нас Agile — поэтому нет времени на документацию.
                                У нас Agile — и мы будем делать по 5-7 часовых встреч в день, работать — в любое остальное время.
                                Раньше это называлось «у нас хреновый руководитель».
                                  –1
                                  Симптомы знакомы, но если по честному, то проблема не в том что Agile или Scrum это что-то плохое, а в том что люди делают непонятно что и называют это Agile/Scrum :)

                                  П.С. По хорошему всё что Вы описали в нормальном Agile/Scrum не прокатывет потому что команда говорит на это всё четкое «нет» и делает по своему. А если команде не дают делать по своему и какой-то «руководитель» со стороны командует вам что делать, то какой это тогда Scrum?
                                    +1
                                    И я о том же.
                                    Наверное, скоро будут флажки выпускать, и чую, у всех компаний над входом в HRрню будет висеть одинаковый набор «корпоративные ценности, стрессоустойчивость, нацеленность на результат, Agile»
                                    PS Причём, флажки будут грязными, потому что их повесят и забудут до Дня Компании.
                                    А о сути флажков забудут ещё в процессе крепления этих флажков.
                                      +1
                                      То, что я описал — это практически любой кровавый энтерпрайз с руководителем команды, который смирился.
                                      Зайдите в крупный банк, процентов 70 любых проектов будет именно такими, заодно посмотрите на забавный жизненный цикл:
                                      1. выпуск-без-тестов новых фич под «личную ответственность бизнеса»
                                      2. критические ошибки на проде из-за 1 пункта
                                      3. грязные разборки, где оказывается виновата виновата команда, потому что бизнес не мог оценить масштабов трагедии, команда должна была настоять на своём
                                      4. смещение слишком принципиальных руководителей в замы и постановка своего человека, который будет выжимать команду
                                      5. уходы ключевых людей из команды из-за п.4, про реальные роли которых новый руководитель не успел/не захотел узнать
                                      6. goto 1
                                      Нет, есть и хорошие команды, с правильными процессами и руководством, которое умеет показать бизнесу, что если мы ускоримся — будет писец, поэтому мы будем дальше работать по согласованному плану, но это явление не частое.
                                        +1
                                        Ну на мой взгляд с опытом приходит понимание когда в фирме, в которую тебе предлагаю вакансию, так обстоят дела. Или когда фирма начинает двигаться в этом направлении. И если такое ощущение есть, то надо сразу начинать искать другую работу.

                                        На мой взгляд Scrum/Agile вполне себе работают если люди хотя бы пытаются чтобы они работали. То есть я нигде не видел 100% Scrum, но я вполне себе видел варианты, когда то что было вполне себе работало. И работало лучше чем «водопад» или отсутствие любых нормальных процессов.
                                    0
                                    Статью не осилил, после фразы
                                    Многие уроки можно извлечь из таких гуманитарных наук, как позитивная психология, направленное самосовершенствование и решение-ориентированная терапия
                                    подступил ком к горлу, но комменты на удивление позитивные — никто не стал лить воду в стиле эджайл-коучей и скрам-мастеров
                                      +1
                                      Потому что вложить своё знание в чужие головы невозможно, как ни старайся. Можно писать книги, можно говорить афоризмы, можно прибивать к дверям тезисы или издавать манифесты — не работает.
                                      Единственный способ прийти к тем же ценностям, к которым пришли те 15 человек в 2001 году — это пройти путь, похожий на тот, который прошли они.
                                        0
                                        Золотые слова! (безотносительно Agile) Недавно понял, что книги где даются готовые мысли/решения для меня в основном бесполезны (особенно если тема книги для меня новая). А вот что полезно — так это книги где описан ПУТЬ как прийти к нужному пониманию.
                                        0
                                        Кто-нибудь слышал об успешном применении гибких методов разработки (Agile) в любой не IT-шной компании? Ну скажем в отрасли машиностроения, энергетики, космоса. Или может кто слышал об успешном применении хотя бы в hardware-компаниях?
                                          0
                                          Agile предназначены для работы в условиях постоянно изменяющихся требований. Вы слышали о существовании инженерных команд в машиностроении, энергетике или космической промышленности, работающих в условиях постоянно изменяющихся требований? :)
                                            +1
                                            Хм, мой любимый пример! Мебель на заказ (по индивидуальным проектам)! )))
                                              0
                                              Спасибо, я кажется понял — почти все маленькие частные компании в любой отрасли работают применяя гибкие методы (иногда сами того не зная). Иначе им не выжить. Вопрос в том есть ли успешный опыт применения в больших компаниях (сотрудников>100).
                                                0
                                                почти все маленькие частные компании в любой отрасли работают применяя гибкие методы (иногда сами того не зная)

                                                Скорее нет, чем да. Agile — это не про «делать разные мелкие задачи», а про «делать одну крупную задачу, не имея полной проектной документации». Индивидуальный проект по изготовлению мебели, он не эджайл. Вы пришли к клиенту, согласовали проект, получили предоплату, и делаете в точности по проекту. Изготовили, отдебажили (где что не влезает или не совпадает с ожиданиями клиента), запустили в продакшен, получили оплату. Это просто короткоживущий, но ни разу не гибкий проект.
                                            0

                                            Почитайте Сазерленда (первую книгу). Он приводит пример компании, которая делает автомобили на заказ и работает по гибкой методологии. Я уже не говорю про то, что все эти практики в IT вдохновлены опытом Toyota, а Сазерленд выводит свою методику из того, чему его учили к военного летчика.

                                              0
                                              За подсказку о Сазерленде спасибо, про Toyota слышал и еще тогда добавлю производителей смартфонов. Однако, надеюсь услышать свежие примеры. И особенно актуальны отечественные примеры.

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

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