- Многие организации устали от 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)
helions8
23.06.2019 19:56Всё, что я вынес за годы практики и разного вида «у нас тут свой аджайл» сводится буквально к одному – хорошей команде при адекватном менеджменте аджайл (плюс другие фреймворки, позволяющие сделать процесс разработки и доставки управляемым) поможет стать еще лучше, остальным не поможет ничего.
InOdinWeTrust
24.06.2019 08:39Потому что принципы agile не реализуемы без дотошного высокоуровневого менеджмента.
InOdinWeTrust
26.06.2019 10:01Господам, наминусовавшим без контраргументов, и молчаливым читателям поясню:
Аджайл это ценности.
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, когда команда просто переходит, к примеру, на спринты, оставив при этом все старые плохие привычки в процессах, и считает что этого достаточно. А потому статьи пишут, какие эти ваши скрамы с аджайлами говно.
Аджайл это хорошо, потому что это работа на результат. Чем слаженней команда, чем устойчивее процессы в ней и чем лучше дисциплина, тем больше подобные принципы помогают достичь желаемого результата. Потому что за гибкостью стоит слаженная работа, которая невозможна без дисциплины, хорошего менеджмента, планирования.DrPass
26.06.2019 17:50Эти ценности буквально говорят, что главное — качественный продукт кастомеру.
Ну тогда правильного аджайла практически не существует на практике, как по мне. Современный аджайл в основном направлен на продажу часов кастомеру, а не на решение его проблем.
UnclShura
25.06.2019 11:26хорошей команде при адекватном менеджменте аджайл (плюс другие фреймворки, позволяющие сделать процесс разработки и доставки управляемым)
… просто не нужны!
Kanut
25.06.2019 11:59Процессы нужны. Потому что какая бы классная не была бы команда, но люди например болеют или увольняются. И в такой ситуации если у вас сыгранная команда, но нет процессов, то Вам надо каждый раз «сыгрывать» команду заново когда приходят/уходят люди.
Или например такие вещи как увеличение фирмы/отдела. Что вы например будете делать если у вас вдруг из одной команды нужно сделать две, три, пять, десять потому что фирма растёт и растёт обьём работ?UnclShura
25.06.2019 14:11Если такое происходит часто — уволюсь. Нет, правда уволюсь. Разбивать сыгранную команду — преступно. Перемешивать разработчиков для «распространеня знаний» просто глупо. На выходе вы полцчите две несыгранные команды и издерганых разработчиков.
Чтоб два раза не вставать… Вам не кажется, что автор статьи пришел из какого-то культа? Там характерные фразы про завоевание, присвоение успехов и соответственно сваливание вины за неудачи, неприятие прямо противоположной точки зрения просто потому, что она явно противоречит его принципам и т.д.
Насчет правильноги и неправильного agile… Не, ребята, так не пойдет. Методология или есть или нет. Если есть, что отвественность за неудачи лежит именно на методологии, а не на том, что «ее неправильно применили». Неправильно применили потому, что методология допускает неправильное применение.
Ответ на вопрос почему программисты не хотят больше играть в agile прост — наигрались. Мы любим играть. Это в натуре у нас — пробовать все новое. Но так-же как и у детей как только стало понятно что это и зачем — разобрать, сломать и выбросить за ненадобностью. Так и с agile — новизна ушла, магия кончилась, интерес пропал. На самом деле разработчики гораздо больше понимают в разработке ПО, чем все эти мастера, коучи и консалтеры вместе взятые. Поэтому впарить то, что не дает весомых приимуществ, очень сложно. Оно может таже в итоге выгладеть «как положено» (зомби agile), но внутри все равно будет именно тот процесс, что выбран программистами.
По всему вышесказаному, считаю, что единственая методология — отсутствие таковой. Точнее команда всегда сама выбирает как ей работать. Очень правильно все описано в оригинальном варианте «programming mother...» / «пиши код...» (русский перевод настолько искажен, что лучше его вообще не читать).Kanut
25.06.2019 14:34Разбивать сыгранную команду — преступно
Это может быть насколько угодно преступно, но это происходит повсеместно, даже в самых лучших фирмах. И часто действительно из необходимости и не по желанию самой фирмы. Люди болеют, увольняются, уходят на повышение и т.д. и т.п.
Фирма конечно может надеяться что сыгранная команда останется сыгранной на протяжении десятилетий, но как минимум по моему опыту каждые полтора-два года происходят какие-то изменения.
Насчет правильноги и неправильного agile… Не, ребята, так не пойдет. Методология или есть или нет.
Методология Agile как такового на самом деле очень гибкая и «разрешает» многое. Поэтому Аgile-процесс может быть кривым до невозможности и всё равно оставаться в рамках Аgile.
Ответ на вопрос почему программисты не хотят больше играть в agile прост — наигрались.
А вот тут надо говорить за себя. Я например всё ещё хочу в это играть. Потому что Agile далеко не идеален, но лучшей альтернативы я лично пока не вижу.
По всему вышесказаному, считаю, что единственая методология — отсутствие таковой. Точнее команда всегда сама выбирает как ей работать.
Извините, но это и есть Agile. И в нормальном Agile команда подстраивает процессы под себя. Но процессы всё равно есть все в команде должны и им следовать. Ну или совместно их менять.
a1111exe
23.06.2019 22:24+4Знаком с компанией, в которой, по сути, разработка идёт по принципу "х**к, х**к, и в продакшн". Менеджмент гордо называет это аджайлом. Нет, есть Git, Bitbucket (правда, совсем не везде), есть код-ревью (правда, совсем не всегда), есть дев-сервера (на которых из-за специфики некоторые вещи не обкатываются)… TDD нет от слова "совсем". Кодовая база на миллионы строк кода (не считая библиотечного). Маленькая команда разработчиков, человек 6-7. Не все старожилы (самые старожилы давно куда-то улетели), не все сениоры и даже миддлы. А компания с 90-х растёт и процветает. У разработчиков работы всегда много, но почти никогда никто не стоит за спиной, допрашивая насчёт дедлайна. Никто не перерабатывает (супер-серьёзные деплои делают ночью, но это очень редко). В целом, все довольны жизнью. Такое, вообще, возможно, или они в сказку попали?
Sergery8205
24.06.2019 13:45Есть такая штука — как человеческий фактор. Его нельзя полностью формализовать, несбыточна мечта менеджмента. Человек может горы свернуть, если правильно мотивировать, а можно излишней формалистикой вообще все ростки убить, даже самые последние. От себя могу сказать, что в период, когда этих умных «фраз» было меньше — делали больше: и заказчик был доволен и у нас клиентура росла. Может моложе были, не знаю. Не буду судить. Сейчас же, менеджмент все хочет контролировать и, в результате, «выплескивает из корыта и ребенка» — сам продукт собственно. То, что сам процесс формализовали — это хорошо. Но то, как по факту массово применили — плохо. Надо подходить ко всему, взвешивая за и против.
Beshere
23.06.2019 23:59+2Agile — это просто неумеренно раздутый слон, которого пытаются продать даже в блошиный цирк. И пока продают, увы.
НАСТОЯЩИЙ AGILE НИКОГДА НЕ БЫЛ ПОСТРОЕН!eugenvz
24.06.2019 06:53Очень много букв :-), но, в общем, соглашусь.
Ещё добавлю фразу-вопрос одного топ-менеджера про то, зачем Agile'ом называть здравый смысл.
На мой взгляд, различные фреймворки (XP, Scrum, DSDM и т.п.) — это способы понять, о чём Agile, но беда в том, что некомпетентность всё развращает.InOdinWeTrust
24.06.2019 08:40На мой взгляд, различные фреймворки (XP, Scrum, DSDM и т.п.) — это способы понять, о чём Agile
Скорее все эти методологии для того, чтоб не дать увалить процессы аджайлом.
SKudelya
24.06.2019 09:34-2Всё по делу. Менеджмент ничего не понимает в разработке, но при этом ему нужно показывать свою значимость и видимость, а это реструктуризация, изменение системы управления. Поиграются на компании, и уходят в другую с повышением. Модная тема, которую топы используют в своих интересах. А вокруг консультанты рубят капусту. Хорошую идею Agile, как и социализм, испоганили и превратили в что-то нарицательное.
reinvent
24.06.2019 10:30Организовать удачный agile — это как постичь Дзен: куча нюансов и тонкостей, бесполезно копировать чужой опыт и упражняться, всегда нужно помнить о сути. Коммерсанты развели ересь.
lotse8
24.06.2019 12:12Agile — это слово маркетологов для привлечения клиентов. Как раньше .com, недавно биткоин и другие всем известные «волшебные» слова, от которых рука инвестора или топ-менеджера тянется к кошельку.
В основополагающих принципах Agile нет ничего нового и ранее до Agile никому неизвестного. А некоторые из них противоречат один другому согласно принципу выбери два из трех: Качественно — Быстро — Дешево.
Все ищут волшебную таблетку, которой в реальности нет и никогда не было. Думать надо самостоятельно и организовывать работу в соответствии с решаемыми задачами. Если есть для этого уже готовые подходящие методики и инструменты, их надо использовать. Только смотреть насколько они подходят именно вам, а не пихать всех подряд в прокрустово ложе одного из многих методов.
cross_join
24.06.2019 13:31Есть лишь два метода разработки: хорошо организованный и дезорганизованный.
mad_nazgul
24.06.2019 15:00Революцию задумываются романтики. Реализуют фанатики. А плодами пользуются негодяи.
Так же используется agile.
Благими намерениями выстелена дорого в ад.
В ад похоже уже пришли.
DrunkBear
24.06.2019 15:09+1Agile стал мантрой: говори вслух про гибкую разработку и твори фигню!
У нас Agile — поэтому мы внесём критические правки в задачи спринта за 2 дня до релиза.
У нас Agile — средняя загрузка разработчиков по оцененому времени за спринт 600%.
У нас Agile — поэтому нет времени на документацию.
У нас Agile — и мы будем делать по 5-7 часовых встреч в день, работать — в любое остальное время.
Раньше это называлось «у нас хреновый руководитель».Kanut
24.06.2019 16:11Симптомы знакомы, но если по честному, то проблема не в том что Agile или Scrum это что-то плохое, а в том что люди делают непонятно что и называют это Agile/Scrum :)
П.С. По хорошему всё что Вы описали в нормальном Agile/Scrum не прокатывет потому что команда говорит на это всё четкое «нет» и делает по своему. А если команде не дают делать по своему и какой-то «руководитель» со стороны командует вам что делать, то какой это тогда Scrum?DrunkBear
24.06.2019 17:41И я о том же.
Наверное, скоро будут флажки выпускать, и чую, у всех компаний над входом в HRрню будет висеть одинаковый набор «корпоративные ценности, стрессоустойчивость, нацеленность на результат, Agile»
PS Причём, флажки будут грязными, потому что их повесят и забудут до Дня Компании.
А о сути флажков забудут ещё в процессе крепления этих флажков.
DrunkBear
25.06.2019 10:30То, что я описал — это практически любой кровавый энтерпрайз с руководителем команды, который смирился.
Зайдите в крупный банк, процентов 70 любых проектов будет именно такими, заодно посмотрите на забавный жизненный цикл:
1. выпуск-без-тестов новых фич под «личную ответственность бизнеса»
2. критические ошибки на проде из-за 1 пункта
3. грязные разборки, где оказывается виновата виновата команда, потому что бизнес не мог оценить масштабов трагедии, команда должна была настоять на своём
4. смещение слишком принципиальных руководителей в замы и постановка своего человека, который будет выжимать команду
5. уходы ключевых людей из команды из-за п.4, про реальные роли которых новый руководитель не успел/не захотел узнать
6. goto 1
Нет, есть и хорошие команды, с правильными процессами и руководством, которое умеет показать бизнесу, что если мы ускоримся — будет писец, поэтому мы будем дальше работать по согласованному плану, но это явление не частое.Kanut
25.06.2019 10:40Ну на мой взгляд с опытом приходит понимание когда в фирме, в которую тебе предлагаю вакансию, так обстоят дела. Или когда фирма начинает двигаться в этом направлении. И если такое ощущение есть, то надо сразу начинать искать другую работу.
На мой взгляд Scrum/Agile вполне себе работают если люди хотя бы пытаются чтобы они работали. То есть я нигде не видел 100% Scrum, но я вполне себе видел варианты, когда то что было вполне себе работало. И работало лучше чем «водопад» или отсутствие любых нормальных процессов.
iago
24.06.2019 17:29Статью не осилил, после фразы
Многие уроки можно извлечь из таких гуманитарных наук, как позитивная психология, направленное самосовершенствование и решение-ориентированная терапия
подступил ком к горлу, но комменты на удивление позитивные — никто не стал лить воду в стиле эджайл-коучей и скрам-мастеров
evocatus
25.06.2019 01:55+1Потому что вложить своё знание в чужие головы невозможно, как ни старайся. Можно писать книги, можно говорить афоризмы, можно прибивать к дверям тезисы или издавать манифесты — не работает.
Единственный способ прийти к тем же ценностям, к которым пришли те 15 человек в 2001 году — это пройти путь, похожий на тот, который прошли они.irod87
25.06.2019 10:01Золотые слова! (безотносительно Agile) Недавно понял, что книги где даются готовые мысли/решения для меня в основном бесполезны (особенно если тема книги для меня новая). А вот что полезно — так это книги где описан ПУТЬ как прийти к нужному пониманию.
Ivan_Ivanovich
25.06.2019 11:29Кто-нибудь слышал об успешном применении гибких методов разработки (Agile) в любой не IT-шной компании? Ну скажем в отрасли машиностроения, энергетики, космоса. Или может кто слышал об успешном применении хотя бы в hardware-компаниях?
DrPass
25.06.2019 11:32Agile предназначены для работы в условиях постоянно изменяющихся требований. Вы слышали о существовании инженерных команд в машиностроении, энергетике или космической промышленности, работающих в условиях постоянно изменяющихся требований? :)
Am0ralist
25.06.2019 11:50Хм, мой любимый пример! Мебель на заказ (по индивидуальным проектам)! )))
Ivan_Ivanovich
25.06.2019 14:10Спасибо, я кажется понял — почти все маленькие частные компании в любой отрасли работают применяя гибкие методы (иногда сами того не зная). Иначе им не выжить. Вопрос в том есть ли успешный опыт применения в больших компаниях (сотрудников>100).
DrPass
25.06.2019 14:20почти все маленькие частные компании в любой отрасли работают применяя гибкие методы (иногда сами того не зная)
Скорее нет, чем да. Agile — это не про «делать разные мелкие задачи», а про «делать одну крупную задачу, не имея полной проектной документации». Индивидуальный проект по изготовлению мебели, он не эджайл. Вы пришли к клиенту, согласовали проект, получили предоплату, и делаете в точности по проекту. Изготовили, отдебажили (где что не влезает или не совпадает с ожиданиями клиента), запустили в продакшен, получили оплату. Это просто короткоживущий, но ни разу не гибкий проект.
evocatus
25.06.2019 12:37Почитайте Сазерленда (первую книгу). Он приводит пример компании, которая делает автомобили на заказ и работает по гибкой методологии. Я уже не говорю про то, что все эти практики в IT вдохновлены опытом Toyota, а Сазерленд выводит свою методику из того, чему его учили к военного летчика.
Ivan_Ivanovich
25.06.2019 14:00За подсказку о Сазерленде спасибо, про Toyota слышал и еще тогда добавлю производителей смартфонов. Однако, надеюсь услышать свежие примеры. И особенно актуальны отечественные примеры.
DrPass
Тут сложно не согласиться. По сути, изначально простой посыл «гибко подстраиваться под изменяющиеся требования» сейчас превратился в кучу ритуалов, участники которых зачастую нифига уже и не помнят, зачем оно всё создавалось.
eefadeev
Вы описали классический путь религии :)