Какая польза от 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 во многих случаях позволяет не делать лишней работы, особенно в плане бюрократической волокиты с документациями, согласованиями, утверждениями и т. д. и т. п.
Что касается недостатков, то я бы их разделил на три группы:
- Объективные недостатки.
- Выход за границы применимости методик.
- Когда 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 мені довелось розгортати проекти різного масштабу — від
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 больше часа объясняет задачу — это малоэффективно. Задачу поймут плохо и, как следствие, реализуют ее лишь бы отстали. Скорее всего, стори должна быть раздроблена.
- Презентацию разработанного функционала делают все члены команды. Исключений просто не должно быть.
В самом начале пути наш бэклог содержал один проект, и мы не справлялись. Сейчас у нас
