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

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

Недавно я прошла тренинг Certified Agile Professional вместе с такими же ребятами, которым, как и мне, пришлось или захотелось самостоятельно столкнуться с этим явлением. И чтобы получить именной сертификат от международного консорциума ICAgile. В первый же день у нас возник спор о том, что принципы гибкой разработки из Agile-манифеста устарели. Некоторые участники даже заявили, что половина убеждений оттуда не подходит для их сферы деятельности изначально.

Agile-манифест был подписан аж в 2001 году, и неужели за прошедшие 25 лет, никто не захотел в нём что-то поменять?

Всё упирается в контекст

Я предлагаю посмотреть на «12 принципов» с точки зрения того, как гибкие подходы могут адаптироваться к управлению проектами в зависимости от масштаба задач и стадии готовности продукта. Это не просто моё мнение — 3 дня обучения бок о бок с другими руководителями проектов из разных сфер только убедили меня в том, насколько важна эта тема.

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

Но вместо того чтобы говорить «agile мёртв» или «отменять agile», давайте подумаем, можем ли мы избежать хаоса и получать более управляемые результаты?

Как удовлетворить запрос клиента

Как я уже говорила, agile теперь применяется не только в IT, но и в производстве, маркетинге и даже в госструктурах, так что фраза «поставка ценного ПО» для нас точно устарела. Её можно заменить например на «продукт, который решает задачу клиента» или просто на «ценный продукт».

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

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

Когда изменения идут во вред

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

Именно ради гибкости agile манипулирует параметрами «сроки», «стоимость» и «функционал» из проектного треугольника.

Но действительно ли мы должны рассматривать и брать в работу все желания заказчика? Или нам всё таки нужна какая-то система приоритезации и ответственный за неё?

Да, для этого есть Product Owner — он формирует актуальный бэклог продукта и вносит туда только те задачи, которые по его мнению принесут максимум пользы.

Поставлять часто не равно поставлять для галочки

Казалось бы, для любой гибкой организации это базовый принцип — регулярные итерации и быстрый фидбэк. Но частые релизы далеко не всегда оправданы. Что, если любой релиз требует согласований и тестирования? Тогда выпускать новую версию продукта каждые 1–2 недели было бы нецелесообразно.

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

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

Ещё существует вариант, при котором заказчик и пользователи довольны вашим продуктом и им не особо важно, когда у вас выходит обновление. Да, так бывает. Если релиз никому не нужен в моменте, то нет смысла торопиться с его выпуском. Например, если это сезонное ПО для расчёта налоговых вычетов, зачем внедрять новые фичи вне налогового периода?

Полезны ли ежедневные встречи

В IT нужно хотя бы пару дней, чтобы освоить требования заказчика. Да и в производстве также — обычно это не один день. Зачем тогда нам нужна постоянная коммуникация? Принцип «ежедневно работать вместе» стоит воспринимать не как указание, а как рекомендацию.

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

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

Доверие в команде

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

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

Уйти из проекта может кто угодно, даже самый замотивированный специалист. Если бы в командах всегда всё было хорошо, люди бы не уходили, и, возможно, принцип «полного доверия» действительно бы работал. Но в крупных проектах постоянная текучка — одна из главных проблем. Если как руководитель вы не смогли удержать команду, то и вам доверять уже будет некому.

Способы общения в команде

Сложно поспорить с тем, что донести вашу мысль правильно можете только вы сами.

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

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

Показатели прогресса

Когда продукт работает, но не развивается — насколько это прогресс?

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

«Взять тот же Explorer — технически он работает, но из-за отставания от других браузеров, им почти никто не пользуется, — а значит, он не развивается», — сказал один из участников моей команды, когда мы объясняли, как справились с одним из заданий на тренинге.

Работающий — ещё не значит актуальный. Вот не понятно, обновляется он или не обновляется? Одно дело, когда продукт отвечает актуальным потребностям рынка, а другое — когда его покупают, потому что, например, нет аналогов. Проблема этого принципа в том, что в нём мало контекста. Кто как понял, тот так и интерпретировал, от этого и возникают разночтения.

Почему этот пункт вообще появился? В классическом проектном подходе прогресс измеряется в количестве закрытых задач, из-за чего может возникнуть такая ситуация, что проект формально выполнен на 60%, а у нас ещё ничего не работает.

Непрерывная разработка

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

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

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

Изменения на рынке

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

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

Не делайте лишнюю работу

Это актуальный пункт, и здесь мне нечего добавить.

Самоорганизация или самоуправство

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

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

Самоорганизация — это финальное состояние, к которому мы хотим прийти.

Повышение эффективности

Да, всё верно, для этого существуют ретроспективы. Когда-нибудь я напишу про них отдельную статью.

Не ищите сложных решений — ищите простые

Чистый agile в его изначальном виде сложно и бессмысленно пытаться внедрить, не учитывая контекст. Это не универсальное решение, поэтому у многих и получается такой «недоаджайл» или «недоскрам» с оговорками.

Если настолько сложно делать agile правильно, то может, и не стоит начинать? Я попытаюсь дать определение тому, о чём услышала на тренинге, с учётом того, что до подписания манифеста оно не было чётко сформулировано, а скорее передавало общий смысл:

«Аджайл — это набор методов и практик, которые были созданы до подписания agile-манифеста, продолжают формироваться в наши дни и не противоречат ценностям, описанным в agile-манифесте».

То есть, это не методология сама по себе, а некое мировоззрение, в основе которого лежат 4 ценности:

Именно поэтому agile и называют «гибким» методом, потому что он позволяет применять разные подходы к управлению проектами, а не только один конкретный. Главное, чтобы они не противоречили основным ценностям. Отсюда и разнообразие практик, которые можно считать гибкими. Например, Scrum и Kanban — это фреймворки с четкими ограничениями, но они тоже являются частью agile-подхода, потому что соответствуют его главным ценностям.

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

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

Как вы думаете, пора ли пересмотреть Agile-манифест или его принципы всё ещё актуальны? Насколько они работают в вашей компании?