×

Чому майже нікому в Україні не потрібен agile і що з цим робити

[Про автора: Богдан Онищенко — Senior Product Owner в Intellias, product-ентузіаст, викладач Lviv IT School, любитель брюховицьких чебуреків]

З agile я вперше познайомився у 2012, коли долучився до scrum-команди. Протягом 2 років працював розробником. 1,5 роки — на посаді scrum майстра; 4 останні — на позиціях product owner/product manager в Україні, Польщі, Німеччині. За цей час встиг переконатися, що в agile далеко не все залежить від професіоналізму та наполегливості людей, що його розвивають. У цій статті вирішив поділитися спостереженнями за вітчизняним ІТ-ринком. Маю надію, що вони будуть цікавими тим, хто щодня стикається з agile.

Для початку розставлю крапки над «і»:

  • Agile працює і є дієвим набором інструментів для розробки продуктів чи управління проектами як в ІТ, так і в інших сферах. Це вже давно мейнстрім.
  • Правильно впровадити agile, у будь-якій його формі, доволі складно, оскільки це вимагає єдиного розуміння та злагоджених дій практично усіх складових частин організації, починаючи з самої верхівки.
  • Agile — не панацея. Він має обмежений діапазон дії та здатний завдати чималої шкоди, якщо недоречно його застосовувати чи невміло впроваджувати.

А тепер — поїхали.

Прозорість процесу розробки

Пам’ятаєте тренінги зі скраму? Transparency — Inspection — Adaptation. Для вдосконалення процесу розробки та збільшення продуктивності, усі елементи процесу мають бути прозорими, однаково зрозумілими та доступними для всіх учасників. Але чи настільки самі учасники в цьому зацікавлені?

Сьогодні більшість ІТ-компаній України працює за аутсорс-моделлю. І, щиро кажучи, в цих стосунках, типу Замовник — Підрядник, мало кому цікава прозорість.

Якщо розробник здатен виконати 8-годинний обсяг роботи за 4, а решту — витратити на власний розсуд, то навряд ця людина буде зацікавлена в тому, щоб на рівному місці працювати більше. З іншого боку, розробники, що з тих чи інших причин досиджують ночами, щоб встигнути все завершити вчасно, не будуть зацікавлені у тому, щоб робити цю інформацію більш публічною, аніж вона вже є.

Менеджменту характерні інші типи проблем: плани, що реалістичні лише в Power Point чи Excel, невраховані ризики, квола комунікація, через яку на розробку нікому не потрібних речей ідуть тижні. Такий менеджер не буде зацікавлений у тому, щоб його гріхи стали відомими широкому загалові.

Під лозунгами захисту розробників від зайвого стресу та політичних ігор менеджер не говорить розробникам всього, що чує від замовника, і навпаки, не інформує замовника про все, що трапляється з командою та планами. Під цими лозунгами заганяється черговий цвях у труну прозорості.

Деякі компанії грішать тим, що продають джуніорів за ціною сіньйорів або годину роботи розробника за ціною 8-ми. Тут додаткові коментарі зайві.

На стороні замовника теж не завжди зустрічаються відповідальні професіонали. Боротися з проблемами, котрі ці люди спричиняють, складніше. Ми рідко бачимо повну картину речей на стороні замовника; людей на Заході захищає трудове законодавство, тому і найпроблемніших буває складно звільнити. Нерідко менеджмент ІТ-компанії використовує відмазки на кшталт: «Замовник завжди правий, бо він платить гроші». Шкода лише, що при цьому частенько забувають, що саме працівники, котрі більше інших страждають від такої поведінки, — це найцінніший ресурс будь-якої компанії.

Завдяки непрозорому/неефективному/відсутньому процесу доволі просто приховати проблеми, некомпетентність чи банальну лінь. І, якщо у ланцюжку від менеджменту замовника до розробників ІТ-компанії знайдеться принаймні декілька осіб, зацікавлених у саботажі процесу — вони знайдуть спосіб це зробити. Чим ширшими повноваженнями володітимуть ці люди — тим більш нищівні наслідки це матиме. На превеликий жаль, кінцевий ефект відчуватиме на собі здебільшого команда розробників у вигляді відсутності плану, овертаймів і постійного хаосу.

Специфіка проектів

Абсолютна більшість проектів, якими займається ІТ в Україні, — це легасі, шаблонки або стартапи. До того ж компанії рідко повноцінно працюють з продуктом, здебільшого — реалізують проекти.

Коли тривалий час колупаєшся в легасі-продукті, то основною твоєю задачею є підтримувати на плаву коричневий шматок коду незрозумілої консистенції, котрий якимось дивом і досі генерує прибуток. 80% часу ти витрачаєш на виправлення багів і допилювання милиць, а написання нових фічерів буває можливим хіба на Різдво чи Великдень. За таких умов середньостатистичну людину від розмов про ініціативність, інновації та agile починає цілком виправдано нудити.

Значна частина веб-розробки функціонує на шаблонах, що вже існують. Для реалізації невеликих проектів достатньо одного чи пари-трійки розробників. Додаткової складності у простий та ефективний процес ніхто з керівництва вносити не збирається. А розробники, що звикли до формошльопства і роками лишаються в таких компаніях, на жаль, не надто зацікавлені у змінах на краще.

Стартапи ж оперують в умовах високої невизначеності, коли невідомого більше, ніж відомого. Сьогоднішній план дій може кардинально різнитися зі вчорашнім. До того ж, коли основною метою є пошук власного сегмента ринку і боротьба за нього, то формалізувати процес розробки або накладати на нього якийсь фреймворк чи методологію — все одно, що пиляти гілку, на котру лише збираєшся сісти.

Відсутність конкуренції

Сьогодні на вітчизняному ринку клієнт переважно тримається однієї ІТ-компанії. Якщо справи йдуть кепсько, то малоймовірно, що замовник змінить компанію. Зазвичай відбуваються звільнення та заміна керівного складу з однієї чи обох сторін. Така взаємозалежність виникає через те, що чим довше замовник співпрацює з ІТ-компанією — тим потужніша в останньої акумуляція фахівців, досвіду у відповідних технологіях і доменних знань. Відтак розірвання замовником стосунків з ІТ-компанією і пошук нових партнерів відбувається лише у дійсно катастрофічних випадках.

При моделі взаємин Замовник — Підрядник, на стороні останнього рівень ініціативності та заангажованості з часом буде наближатися до 0. Бо навіть відверто халтурне виконання власних обов’язків не переважить ризиків, пов’язаних із розірванням взаємин, що склалися.

На противагу при моделі взаємин Партнер — Партнер до думок та зауважень формальних виконавців дослухаються. Коли виконавець отримує автономію та несе відповідальність за прийняті рішення, — то тенденція з ініціативністю буде прямо протилежною.

Очікування результатів уже й одразу

Agile-трансформація організації — надзвичайно складний процес. Вона має відбуватися з ініціативи/за згоди керівництва, що свідомо інвестує суттєві ресурси. Трансформація повинна проходити поетапно та під невпинним контролем, щоб не відхилитися від поставлених цілей, не втратити темпу чи не допустити регресу вже здобутих результатів; може тривати місяцями або й роками, залежно від розмірів організації.

На цьому тернистому шляху неминучі помилки та невдачі. Розв’язання певних проблем є часоплинним, що у свою чергу може вилитись у недовіру до змін, постійний скептицизм чи саботаж. Люди часто забувають, що суть agile — постійно розвиватися та вчитися, нехай і на помилках. Абсолютно нормально щодня припускатися помилок, за умови, що кожного разу це будуть нові помилки.

Нерідко agile-трансформації закінчуються крахом або зупиняються на півдорозі. Багато з тих, хто пробував і в кого не вийшло, тричі замислиться чи пробувати знов.

Що з цим робити

  • Глобально — нічогісінько. Чекати, доки ринок не розвинеться самостійно і доросте до рівня, коли компанії, настільки ж сильно, як і розробники, будуть зацікавлені у роботі з цікавими, інноваційними продуктами. Зокрема, Centers of Excellence, котрі пропонують з ідеї та грошей замовника створити готовий продукт і розвивати його, є правильним кроком у цьому напрямку.
  • Брати активну участь у житті української agile-спільноти. На сьогодні вона ще доволі слабо розвинена, порівнюючи з європейськими країнами з потужним ІТ-сектором. Конференції та мітапи — не лише хороша можливість для вивчення нового, нетворкінгу, а й нагода отримати інсайдерську інформацію про те, як насправді влаштовані процеси у компанії/на проекті, що вас цікавлять, від людей, котрі там працюють.
  • Навіть якщо ваше робоче середовище не сприяє впровадженню жодного з agile-підходів, то навіть їхні окремі складові частини (щоденні стендапи, ітеративне планування, інкрементальна розробка тощо) можна використати собі на користь. Не бійтеся експериментувати, зробіть це для себе і для команди.
  • Якщо процес для вас так само важливий, як і результат — то, можливо, варто почати шукати нову роботу, де буде цікавіше, буде більше можливостей реалізувати свій запал та здобути новий досвід.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному1
LinkedIn



50 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Любой Заказчик хочет знать не только ЧТО он получит, но КОДА он это получит, и СКОЛЬКО это будет стоить. В Аджайл-манивесте изложены прекрасные принципы. Плохо, когда за этими принципами неумелые ПМ-ы прячут свою неспособность или нежелание отвечать на вопросы КОГДА и СКОЛЬКО?

Agile це не методологія управління проектами, Agile — це система процесів і способів управління задачами в середині проекту. Задачі, які з’являються у backlog повинні бути результатом чіткої бізнес-стратегії помноженої на проектне планування, з урахуванням проектних ризиків, пріоритетів, тощо.

Не варто говорити що Agile не працює. Jira board, стендапи та спринти це ще не Agile. Це лише початок. Що таке Agile можна послухати тут soundcloud.com/...​dlodka/podlodka-98-kanban

Хм

потому что они не аутсорс и там нет никаких заказчиков

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

И особенно смешно это слышать, наблюдая Google Cemetery. Уверенные заказчики, ага-ага.

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

Даже на ежечасных билдах на таком есть что делать.
По-моему, ответчик, мягко говоря, лукавит.

скорей всего, будет использоваться подмножество принципов из манифеста, но почти никогда не будет чистого agile

Это и не так важно. Важно изначально понять, где имеет смысл вообще применять agile, а где просто надо писать по готовой спеке.

Аджайл и скрам — это как религия, и если отталкиваться от этого, то все встает на свои места.

Давайте рассмотрим очевидные параллели. Время от времени люди собираются на собрания, слушают проповеди скрам-мастеров, обсуждают рутину, просят фидбеки от господа своего. Ну и собственно участники процесса получают ощущение причастности к чему-то большому, духовному, ну и всевышний(е) тоже вроде как участвуют в процессе.

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

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

таинство сожжения проповедников, уличённых в аджайле?

Уличенных в проповедывании Cкрама там где он не нужен. Но начала бы я с тех кто путает Agile и Scrum...

Богдане привіт) А які KPI ти можеш назвати для визначення якості Agile процесів? І як ти думаєш чи є звязок Agile з маркетингом і продажами. Чи це внутрішня штука для управління тех. спеціалістами, а що там з бізнесом, то це не стосується Agile процесів.

хороший уровень менеджмента, мотивация команды и главное реальная потребность в Agile (для продуктов, стартапов — да, для поддержки — нет) — это предусловия для применения Agile, если этого нет — не нужно пенять на зеркало )

Аджайл не работает потому что Аджайл это не методология разработки, а общее название нескольних методологий с фокусом на быстрый фидбек И культуру разработки.
Когда вы не получаете фитбек быстро — аджайл не работает.
Аджайл нельзя сделать усилиями только менеджеров.
Вы не можете просто так сократить цикл разработки, если вы не уверены в том, ЧТО вы деливерите.
Если вместо тестов у вас митинг — ваш аджайл не работает.
Если вместо СИ у вас митинг — ваш аджайл не работает.
Скрам не работает без ХП

Статья гавно, каменты гавно. Вот почему аджайл не работает

типичный такой говно-коммент ))))

Agile — это имя прилагательное, а не существительное. Советую посмотреть это видео от одного из тех, кто стоял у истоков небезызвестного манифеста: youtu.be/a-BOSpxYJ9M.

4 картинки дилберта в одной статье: круто, лицензия даже на год недешевая там такая.

не потрібен agile і що з цим робити

Ответ же в самом вопросе: не нужен — не использовать.

Agile — це тактичне рішення до досягнення цілей. Якщо з стратегії у вас пустота, продати більше голів чи ще гірше нічого не значуще «ми будемо Agile» то й виходитиме фігня на виході. Garbage in, garbage out.
2018-й рік. Agile penetration досягає 90% і все одно ми маємо великі проблеми. Ті хто не хоче робити свою роботу так само не робить, інші займаються надуванням власного его і продукують одні відходи називаючись scrum master/scrum owner.
Для успішної роботи потрібна достатня зрілість з обох сторін і щира зацікавленість в результаті теж з обох сторін. Це відносно працює лише для середніх розмірів замовників (умовно до 100 млн USD). Великим до сраки ваш процес, вони хочуть низької вартості, взаємозамінності контракторів і мінімум ризиків. А в малих замовників на людей з розумінням немає часу і грошей.

Пам’ятаю була історія (не знаю чи правдива) про те, як Генрі Форд платив механікам-ремонтникам не за відпрацьований час, а за час, коли вони нічого не робили, бо все і так працювало. Так от, скрам/аджайл запрацює тоді, коли всім цим скрам майстрам/овнерам почнуть платити не за кількість проведених мітингів, а за кількість тих, що вдалось не провести, бо всім і так все зрозуміло.

Дякую, цікава спроба заохотити зацікавленість гнучкими методологіями. Автор не став конкретизувати, чому це взагалі може принести користь, коли слід застосовувати виходячи, наприклад, з власного досвіду. Так, якщо вас примушують використовувати аджайл тому, що це трендово, подумайте, як він може допомогти досягнути бажаних цілей, або спитайте, експериментуючи з запалом чи ні...

Возможно Agile не работает — потому это не работает в принципе ? Потому что снимать время людей по 20 раз на день и заниматься ерундой в виде а вот тут у нас стендап, тут планинг покер а вот тут у нас итерация. И обязательно нужно сидеть и разбирать это всей тимой. Что в итоге приводит к тому что половина рабочего времени тратится на игры в Agile. Может стоит просто начать работать ? Делать то что нравится, и перестать заниматься микро-менеджентом называя его Agile/Scrum?

Может стоит просто начать работать ?

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

Хватит путать понятия: Agile разработка — это следование методологии, которая ставит людей и результат выше процессов (как раз то, о чем вы говорите когда хотите просто работать, а не просиживать кучу времени на бесполезных митингах «потому что так надо»). Смысл такого подхода не в том, чтобы слепо следовать определенному процессу, а в том, чтобы учиться на своих ошибках и адаптировать процесс под проект и команду. Ничего особенного в этом нет — это просто здравый смысл.
Scrum/Kanban — это фреймворки, и они очень нишевые. Есть случаи в которых они работают идеально, но часто на волне хайпа их пытаются применять тех условиях, для которых они не предназначены, и потому от них там будет только вред. Но они могут быть полезны поначалу как стартовая точка, с которой можно начать пересмотр процессов для каждого конкретного проекта и команды.

«Заказчик хотел совсем не то..» — это когда нет чётких договорённостей о том, как будет выглядеть конечный результат. Сама по себе парадигма/методология решит этот вопрос?

«Заказчик хотел совсем не то..» — это когда нет чётких договорённостей о том, как будет выглядеть конечный результат.

А вам часто попадались заказчики которые знают в подробностях, как конечный результат должен выглядеть?
Многие решения приходится принимать в ходе разработки.

Сама по себе парадигма/методология решит этот вопрос?

А сам по себе кодинг?
Agile разработка подразумевает коммуникацию.

Первый раз столкнулся с Agile 15 лет тому назад друзья из США, через год — ушли искать новую работу
Второй раз уже другой товарищ тоже из США ( 12 лет тому ) , тоже компания начала внедрять Agile со серам мастером и всей остальной ерундой — уже через 9 месяцев снова рассылал свое резюме
8 лет тому компания в которой я работал начала применять Agile — через год компания сдола и все пошли искать новую работу

Случайность ?

Что за компании/проекты, насколько хорошо они закрепились на рынке прежде чем начали экспериментировать с Agile? Какая вообще была ситуация на рынке для этих компаний/проектов? Как в них был изначально налажен процесс и какой фреймворк они пытались при этом внедрить? Что имено пошло не так — процесс не работал, или сотрудники даже не попытались ему следовать?
Без контекста и подробностей с тем же успехом можно сказать что неудачи произошли, к примеру, из-за лично вас — так как вы и ваши друзья там работали. Но это же звучит как бред, не так ли?

Вот основная часть Agile манифеста:

Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану

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

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

Есть случаи когда обвешанный ритуалами фреймворк Scrum пытаются внедрить там, где подробная документация и планирование наперед наоборот критически важны — и это действительно катастрофа. Но в большинстве случаев ситуация не такая суровая, и для меня Agile (не Scrum или Kanban!) это просто синоним здравого смысла.

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

Случайность ?

все как по видосу
youtu.be/2u0sNRO-QKQ?t=2724

нет конечно — это отражение вашего выбора, это талант находить такие компании ))))

Дякую за статтю, Богдане! Мої думки резонують з вашими.

Аджайл маніфест — це констатація цінностей довіри, постійного самовдосконалення, ефективної комунікації та готовності до змін. Якщо брати їх за ідеологічну основу бізнесу, то матеріальні вигоди зазвичай вони приносять лише в достатньо тривалій перспективі. На мою думку, горизонт планування українських бізнесів часто є недостатнім для того, щоб побачити матеріальну користь у слідування цінностям маніфесту. А бізнеси дуже рідко роблять щось, що не принесе матеріальну вигоду.

Проте більшість IT-бізнесів говорить, що вони аджайл (при цьому іноді не знаючи навіть про існування аджайл маніфесту), бо це стільна-модна-маладьожна і людям подобається це чути. А часто це «аджайл» насправді означає постійні хаос в процесах і зміни вимог (це може бути тимчасовою нормою лише для стартапів на початових етапах), і цим «аджайлом» часто випарвдовують більшість трешу, який відбувається на проектах. Мені колись керівник сказав, що я не аджайл, коли я попросила попереджати про необхідність підготовки звіту хоча б за день до його презентації. І я не зрозуміла, це він серйозно чи пожартував)

любитель брюховицьких чебуреків

cs5.pikabu.ru/...​4-04_1/13963575439401.jpg

между прочим чуть ли не культовая точка

Абсолютна більшість проектів, якими займається ІТ в Україні, — це легасі, шаблонки або стартапи. До того ж компанії рідко повноцінно працюють з продуктом, здебільшого — реалізують проекти.

Сюрприз-сюрприз. Кожен більш менш успішний продукт з часом — це легасі, принаймні, зсередини. І стартап тут не виключення, а навпаки, він стадії легасі часто сягає ще не народившись.

Коли тривалий час колупаєшся в легасі-продукті, то основною твоєю задачею є підтримувати на плаву коричневий шматок коду незрозумілої консистенції, котрий якимось дивом і досі генерує прибуток.

До цього по всякому можна ставитись. Якщо код не переписаний вчора на Go, Rust, Шпалу, чи що там зараз модно, а як був написаний і відтестований роки назад, хай навіть на C++98, так з того часу живе і стабільно виконує свою задачу, — це хороший код. Якщо продукт при цьому генерує прибуток — це хороший продукт.

..Люди часто забувають, що суть agile — постійно розвиватися та вчитися, нехай і на помилках..

Додам — за рахунок клієнта.

Agile — це просто реалізація методу Монте-Карло. Робимо аби шо, навмання і рандомно. Те, на що клієнт починає особливо голосно верещати — перероблюємо у той же рандомний спосіб. Як тільки подальша розробка зрівнюється по ціні з розробкою заново з нуля — завершаємо проект.

Все це можливе лише тому, що ТСО аутсорсера вп’ятеро нижче за ТСО місцевого програмера , то нехай собі організує процес, як хоче. Косо-криво, аби живо та дешево. А коли та сама ботва пропонується місцевому ж ринку, де ТСО=const , то вся ідея втрачає і без того не дуже великий сенс.

Здається, саме через усі причини, які Ви наводите вище, Україні й потрібен аджайл, але не як набір інструментів, а як світобачення, підхід до організації бізнесу. Думаю, що нам потрібно більше розмовляти й про bunsiness agility, а не тільки про аджайл в рамках проектів. Аджайл дійсно не панацея і трансформація займатиме певний час (як і будь-яка велика трансформація), однак при здоровому підході до неї вона може приносити хороші результати навіть в рамках аутсорсу/аутстафу.
А скільки, на Вашу думку потрібно почекати, щоб ринок розвинувся самостійно? Можливо, все ж треба докладати більше зусиль?

Господи спаси від agile-бачення. Я думав вже всі перехворіли на agile в 2012-му, але ці зомбі ніяк не вспокояться.
Чи чули ви що-небуть про agile в google чи apple чи facebook? Ні. І навіть в Microsoft теж немає на рівні стратегії компанії.
Бо Agile це є сране тактичне рішення для організації роботи невеликих команд — все.
Якщо ваша бізнесова стратегія «ми будемо agile» — то у вас немає стратегії.
На ринку розплодилося тисячі маленьки аутсотсерів. Всі agile, всі lean у всіх печеньки в офісі.
Чим ви курча відрізняєтесь від інших? В чому ваша особливість?
Як ви будете продавати і кому? Чому замовник має обрати вас, а не Васю за два квартали нижче?
Чому розробник має піти до вас? Бо ви дасте +$100, а завтра Вася дасть +$200.

Диференційся, або здохни. Де якесь бачення?
В ЕПАМА воно наприклад є. І на investor call ніякого сраного agile ви не почуєте.
Це недоПееМи раптом роздули власне его і значимість і з рядового одного з можливих процесів організації розробки невеликих команд(я знаю про їб..тий SAFe) зробили цілу релігію і ідеологію.
Є як мінімум одна велика компанія якій Agile добре посприяв піти на дно швидше і ефективніше — Nokia.
Власне як Agile як продукт купи консультантів і інстутуцій які на всяких тренінгах заробляють купу бабла цілком успішний. Але по впливу на індустрію розробки і на баланс шкоди/користі який він приніс то його результат хз.

вы просто не умеете их готовить ...)

Після «крапок над „і“» далі читати якось м-м-м і нє особо є що :( - констатація фактів, і ще чотири крапки в кінці :)

Моє ІМХО:
1. старші пацани від agile-а чекають дуже багато при тому, що вважають що для того аби його впровадити, досить вимовити три рази «аджайл,аджайл,аджайл».
2. надалі нема повного розуміння того, що agile — це дуже загальне поняття, набір методик, світогляд якщо хочете. В т.ч. в даній статті автор ІМХО декілька разів використовує термін agile там, де доречніше було би писати напевно про scrum. І само собою, що «якщо ваше робоче середовище не сприяє впровадженню жодного з agile-підходів, то навіть їхні окремі складові частини (щоденні стендапи, ітеративне планування, інкрементальна розробка тощо) можна використати собі на користь». Можна і варто, і це шлях до agile-зації :)
3. нарешті, якщо agile виник швидше «знизу» як реакція на вимоги змін ринку і був покликаний спростити відносини «замовник-виконавець», то впроваджують його як правило зверху і як правило для полегшення життя і планування топ-менеджменту. Ясєн пєнь, що суть від того слєхка їде від слова agile до слова management.

Я бачу толкування agile підходу в agile manifesto. Для мене це не так підхід чи модель розробки, як філософія. Філософія яка говорить — більше спілкуйся з колегами, міняйся і будь готовий до змін. Не бачу тут пунктів які суперачать чи заважають аутсорсу, легасі чи стартапам

Що таке agile у вашому розумінні ?

Сколько можно обсасывать одну и ту же тему, уже столько было написано и переписано про agile и скрам, неужели нет более важных тем ?

если на проекте завелся agile coach значит пришла пора обновлять резюме

Чому автор так вирішив і хто його навчив писати маніпуляційні заголовки?
За моїми спостереженнями у нас agile пхають всюди куди хочуть — найяскравіший приклад RFP на систему електронних декларацій НАЗК в якому прямо був прописаний agile. І дуже люлять називати свій бардак agile або ще краще скрамом в той час коли ні процессів, ні артефактів властивих agile і близько не має.

Соглашусь. Удивляет когда fixed price с четчайшими требованиями пытаются по Scrum вести.
Понимания что Agile-подходы хороши именно в проектах с большой непредсказуемостью мало.

Підписатись на коментарі