Conference for DevOps, Software Architects and Engineers. Register until August, 22!
×Закрыть

Какая польза от Agile: мнение ИТ-специалистов

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

Олег Карякин, Senior Java Developer, GlobalLogic Ukraine

Agile, Scrum и прочие гибкие методологии разработки хороши в теории, но почти нежизнеспособны на практике.

В моем опыте лишь на одном из проектов было успешное применение Agile. Было это достигнуто благодаря грамотному, проницательному и осторожному руководству, выражалось это в следующем:

  • адекватный product-owner, который идеально знал продукт и всегда был готов ответить и подсказать;
  • стори в спринте на 80% были понятны;
  • синьйорная команда программистов и тестировщиков;
  • в спринт затаскивали от трети до половины реальной капасити, иными словами мы могли сделать 100 поинтов за спринт, а брали 30-40-50;
  • осторожный и адекватный скрам-мастер (см. пункт выше);
  • из 8 спринтов на релиз было не более 5 девелоперских, остальные hardening и регрессия;
  • доброжелательная атмосфера, никто не выпендривался, не игрался в пуп-земли, все были готовы помочь друг другу.

Во всех остальных проектах Agile, по сути, использовался, чтобы перекидывать камни в чужие огороды за 5 минут до дейли-скрама, затем выпучивать круглые глаза и требовать пофиксить баг, который валялся в бэклоге 2 года, и приоритет ему повысили ровно 5 минут назад.

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

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

Сергей Лобода, Senior Software Developer, Access Softek, Inc

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

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

Agile позволяет эксперименты. Одна итерация — это относительно быстро и относительно дёшево. Если эксперимент удался, то развиваем успех. Не удался — откатываем изменения назад, это не больно.

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

Что касается недостатков, то я бы их разделил на три группы:

  1. Объективные недостатки.
  2. Выход за границы применимости методик.
  3. Когда Agile превращается в карго-культ.

Собственно, последние две группы — не недостатки самого Agile-подхода, а результат неправильного применения этого инструмента людьми.

Об объективном. Если мы позволяем заказчику менять требования, то вполне вероятна ситуация, когда изменившиеся требования вступят в конфликт с уже наработанной архитектурой продукта. В итоге переделки, аврал, всплеск количества багов, снова аврал.

Всегда есть соблазн сделать быстро, по-простому и закрыть задачи. В итоге костыли и технический долг.

Во всю используются способности команды к самоорганизации. Значит команда должна состоять из мотивированных профессионалов сравнимого уровня. Причем сохранять тонус придется довольно продолжительное время. А люди все разные и не роботы.

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

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

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

К сожалению, иногда приходится наблюдать совсем несчастные случаи, когда под воздействием Agile-хайпа люди пытаются совсем уж «натянуть сову на глобус». В итоге процесс разработки, по сути своей, Agile не является (как правило получается просто waterfall короткими циклами), но при этом неукоснительно соблюдаются все ритуалы. Это я имею в виду, когда говорю о карго-культе Agile.

Анна Мамаева, Delivery Manager, DataArt

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

При этом нам не предлагают ничего революционного:

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

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

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

Только задумайтесь, какое количество дельных идей и обратной связи пропадает в вашей компании. Главное — не относиться к Agile-техникам как к формальному набору обрядов, которым необходимо «следовать с религиозным бездумием».

Михайло Фльорко, Senior Delivery Director, Intellias

За понад 20 років в IT Outsourcing мені довелось розгортати проекти різного масштабу — від 2-3 інженерів до команди в майже 500 людей. І мені, напевно, важко знайти ще одну таку тему, як Agile, котра була б настільки обговорюваною, мінливою і в той же час настільки ж корисною. Agile дозволяє нам дати раду зі змінами, які виникають усюди, — замовник змінює своє бачення, менеджер продукту намагається передбачити потреби ринку і змінює вимоги після випуску MVP (мінімальний життєздатний продукт), команда розробників ефективно опрацьовує зміни у вимогах і часто переглядає свої підходи...

Agile походить з ІТ-проектів, але вже не є їхнім виключним правом. І досі різні реалізації можна побачити в ІТ-компаніях під час розробки продуктів, в тому числі і в аутсорсі, коли йдеться про невелику команду, скажімо, до 10-12 людей. Scrum, Kanban, Scrumban, XP-практики, Scrumbut... Гнучкі підходи можуть значно відрізнятися і в той же час можуть підняти ефективність команди та мотивацію учасників, зменшити марнотратство і допомогти досягнути очікуваних результатів з мінімумом затримок та помилок. Часто керівник команди чи один з її учасників може самостійно побудувати гнучкий процес на проекті. В такому масштабі втрати від неправильної реалізації Agile будуть незначними. Сьогодні різновиди Agile застосовуються поряд зі строгим плануванням та бюджетуванням для проектів, де потрібне чітке дотримання термінів, висока якість кінцевого продукту, галузева сертифікація тощо.

З ростом ІТ-проектів, де команди налічують десятки, а часом і сотні учасників, побудови Agile в окремих підкомандах вже недостатньо. Команди мають взаємодіяти, узгоджувати і гнучко адаптувати свої плани та випускати спільний якісний продукт. Не-Agile підходи (waterfall, unified process) також не допомагають.

ІТ-компанії намагаються переосмислити гнучкі методології і адаптувати їх до рівня підприємства для великих проектів. Найчастіше використовуються такі фреймворки, як SAFe, LeSS та Spotify. Побудову правильних процесів зазвичай покладають вже не на керівників цих проектів та програм, а на досвідчених та сертифікованих Agile-коучів. Вони працюють зі всіма командами і можуть завчасно виявити потенційні проблемні місця. Важливу роль в цьому процесі відіграє корпоративне навчання, налагоджена передача знань та ефективні канали комунікації. Уніфіковані процеси, ролі та система метрик, а також спільні програмні інструменти та дорожня карта збільшують ефективність як окремої інженерної команди, так і всього проекту чи програми, забезпечуючи прозорість роботи як для замовників, так і для керівництва ІТ-компанії.

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

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

Анастасия Киселева, Test Group Manager, Luxoft

Для меня Agile — не только методология разработки, а отдельный вид философии и некий образ мышления, который, как и другие направления, многим подходит, но в тоже время многим может не подходить. Идеальная для работы среда складывается тогда, когда для все участники процесса принимают Agile как образ мышления.
Agile, как и любое другое философское направление, не может быть хорошим или плохим — он может быть правильно или не правильно применен. В случае некорректного использования такой подход приносит больше вреда, нежели пользы.

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

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

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

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

Большим плюсом Agile-методологии является то, что при правильном соблюдении всех условий — все отлично работает. С точки зрения недостатков — этот подход очень зависит от личностных качеств и уровня коммуникации в команде. Успешную команду необходимо подобрать таким образом, чтоб люди подходили не только с точки зрения профессиональных качеств, но и их soft skills.

Agile очень сильно зависим от ключевой его ценности — прозрачности. Как только исчезает прозрачность и доверие в команде — начинают рушиться все остальные процессы.

Алексей Мироненко, QA Engineer, MacPaw

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

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

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

В работе тестировщики часто находят баги функциональности. Если команда использует другой, «негибкий» подход, то нельзя точно знать, когда эти баги устранят. Наш метод итеративный. В одном спринте мы находим проблему, а на планировании мы решаем, чем стоит заняться, и видим приоритеты задач. Так как у багов приоритет высокий, то они точно будут внесены в следующий спринт. Соответственно, не нужно на чем-то настаивать и что-то доказывать. Есть четко определенные приоритеты, которые помогают быстро принимать решения.

Сам Agile предусматривает демо, ретроспективы и прочее. Это такие моменты, которые уже оговорены заранее, и все понимают, что в конце итерации мы проведем демо, поделимся результатами работы. Все посмотрят, что так, а что не так. На ретроспективе мы обсудим, какие были плюсы, какие минусы, что нужно изменить. То есть не нужно каждый раз команде договариваться, когда нужно встретиться и обсудить рабочие вопросы. Мы знаем, что раз в две недели мы в любом случае встретимся, чтобы со всем разобраться.

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

Если у Agile команды есть жесткий набор правил — это неправильно. Бывают такие моменты, что Scrum-мастера или компания навязывают определенные практики, когда это должно исходить из команды. В идеале, каждая команда подстраивает Agile под себя. Взаимодействие разработчиков с разработчиками, разработчиков с тестировщиками, взаимосвязь с дизайнерами, связь разработчиков с маркетингом... Таким образом, проблемы каждого будут услышаны. Agile говорит о том, что можно что-то менять как в отношении к разработке, так и во взаимодействии между членами команды. Вообще Agile прекрасен, если он гибкий.

Владимир Пеньков, Senior Database Developer, LogNet

Несколько лет назад в компании произошли достаточно весомые изменения, и все понимали, что сейчас самое подходящее время для того, чтобы меняться. Scrum был выбран как вектор дальнейшего движения. Было больно, но слово Team Lead было забыто, и на смену ему, как казалось многим сначала, пришли Scrum Master и Product Owner. Однако прошло время и все поняли, что это было глубочайшим заблуждением. Первое — если вы попали, по своей воли или нет, в команду с Agile-подходами — не надо искать аналогий — это вас погубит. Я рассматриваю Scrum как набор рекомендаций, а не жестких правил для исполнения, и если что-то надо менять — не нужно этого бояться.

Мы продолжали плыть по течению спринтов, коммитменты которых регулярно заваливали. Мы были далеки от идеала, но начала появляться положительная динамика. Достаточно важный, как по мне, момент — нельзя поменяться лишь части сотрудников. У нас были прецеденты, когда «стейкодержатель» пытался развалить спринт (на тот момент он был недельный) — впихну туда еще одну задачу, или PO на деме решил поменять требования к стори и отправить ее снова в девелопмент. Передача части ответственности за стори в другую команду — сущий ад. Все это порой приводило к нервным срывам и ссорам. Время шло, и становилось все лучше и лучше. На полугодовой ретроспективе было принято решение немного изменить вектор — scrumban. Переходной период был практически безболезненным, но свои коррективы были внесены. Сейчас, на мой взгляд, все отлично, так как все осознали, как именно надо применять этот подход и пришли к единому пониманию. При работе в любой из Agile-реализаций все ваши проблемы и недочеты становятся более критичными. Научитесь о них говорить и решать, но главное это делать командой, а не отдельно взятыми личностями.

Я вынес из пройденного пути для себя несколько важных идей:

  • Работает — не ломай. Не надо внедрять Agile там, где все и так работает идеально. Вы наживете себе новых проблем, а возможно, и не все сотрудники, важные компоненты уже налаженного процесса, захотят с вами остаться.
  • Нет команды без высокого уровня коммуникации. Члены команды должны понимать друг друга как пожилые супруги. Особенно критично на переходных этапах.
  • Командная ответственность и самоорганизация. Если раньше я видел как тимлиды бегали и давили на людей, напоминали, то в Agile это не прокатит — не кому. Даже если в данный момент еще есть кто-то, кто согласен это делать (например, Scrum Master), то ему скоро надоест, так как микроменеджмент — не его прямая обязанность.
  • Взаимозаменяемость. Да, это громкое слово, но это ключ к успешной команде, который нельзя игнорировать, даже если пока все хорошо.
  • Грамотно составленная и презентованная стори — 90% ее реализации.
  • Грумминг — одна наиболее важных частей! Вовлечение всех членов команды в обсуждение подходов к реализации функционала позволяет избежать проваленных сроков.
  • Грумминг не длится больше часа! Когда Product Owner больше часа объясняет задачу — это малоэффективно. Задачу поймут плохо и, как следствие, реализуют ее лишь бы отстали. Скорее всего, стори должна быть раздроблена.
  • Презентацию разработанного функционала делают все члены команды. Исключений просто не должно быть.

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

LinkedIn

21 комментарий

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Все заметили разницу между мнением менеджеров и инженеров ;-?

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

Процеси свторюються задля ефективності, ефективність потрібна для отримання результату, а тепер варто задуматись чи у вашій команді Agile використовується для ефективності чи просто для процесів:)

Разработка короткими итерациями и быстрый фидбэк от заказчика действительно позволяет адаптироваться к (хаотически) меняющимся требованиям.

«Сделай мне то — не знаю что».

Да, но пока успеваешь сделать до того, как заказчик передумал — он доволен

помогает избежать «сделай мне все, и еще вот это и это в те сроки, о которых мы договорились ранее».

Хорошая статья и спасибо авторам за взгляд со стороны представителей архитектурных групп и команд разработки, а не только адептов Agile вроде меня и контрибьюторов прошлой статьи :) Из очевидного — инструмент/фреймворк не может быть хорошим или плохим. Все упирается в людей и контекст к которому его пробуют применять (+как это делают по факту...)

Я раскрывал тему того «почему Agile/Scrum так часто критикуют» в одном из своих последних докладов (например на PM Framework Days)

Кому интересно, вот ссылка на видео:
www.facebook.com/...​/1579937648737522/?type=1

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

Згоден. Я знаю Маніфест ще з 2003 року, чого люди тільки зараз почали з ним бігати — хз...

В 2008 вже аутсорс працював за срамом, і усі матюкались

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

Найбільше дивує не розуміння цієї філософії зі сторони девелоперів.

Eсли ты думаешь что ты ее пониваешь то ты ошибаешься.

Але ця філософія виведена саме девами, таким як Фовлер та дядько Боб

А эта фраза доказывает мое предыдущее утверждение.

Agile, Scrum и прочие гибкие методологии разработки хороши в теории, но почти нежизнеспособны на практике.

можливо такий досвід через

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

аджайл підхід саме і хоче зробити

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

Практика собеседований показывает что в представлении многих Agile = Scrum = daily standup.
Некоторые мамкины анархисты критикуют Agile даже не понимая принципов.
Порадовало интервью вот этого человека: Сергей Лобода, Senior Software Developer. Очень правильное понимание.

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

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

Занавіс, аплодисменти

Insight direct from heaven — никакой. Вместо того чтоб работать — люди говорят , устраивают митинги, занимаются ерундой все это приводит в микроменеджменту. Agile и Scram в частности применят компании у которых проблемы: с деньгами, с инвесторами, с менеджерами. И в конечном итоге от этого становится только хуже: компанию покидают лучше, остаются одни отстающие середняки, что приводит к гибели изба отсутствия инноваций и инициативы. В итоге компанию закрывают или продают. Все finite la com media.

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

Алилуя!

Толковая статья. Большое спасибо тем людям, которые высказались о ситуации «как есть», без придыхания и закатывания глаз, а написали реальные требования «чтобы это заработало»

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