Менеджмент-консультант по внедрению Agile/Lean Тимофей Евграшин — один из старейших практиков Agile в Украине. Имея многолетний стаж консультирования и управления кризисными ситуациями в командах разработки, он активно популяризирует гибкие методы управления проектами, делится опытом и знаниями. В ходе недавнего приезда в Минск аккредитованный тренер ICAgile успел выступить на Agile.by Gathering, провести тренинги для белорусских коллег по цеху, а заодно и поговорить с корреспондентом dev.by Ольгой Цветковой.
«Теперь буду называть это Scrum»
— Мне скоро 38 и в ИT-индустрии я работаю 17 лет, из них более 12 — менеджером. Начинал ёще студентом, когда мы собрались web-артелью делать сайты. Был и веб-мастером, и Java-разработчиком, и архитектором, и менеджером проектов.
Уже тогда мне было интересно организовывать работу команд. И вот в 2002 году, получив опыт в разных проектах, я попал в компанию Ciklum в качестве менеджера проектов. Компания только стартовала, и я оказался в числе первых десяти её сотрудников.
Тогда пользовалась популярностью методология Rational Unified Process (RUP). Но клиент предоставил мне достаточно большую свободу, а один хороший менеджер дал пару советов. Во-первых, не забывай, что ты регулярно, желательно каждые две недели, должен отправлять клиентам результат и требовать от них обратной связи. Во-вторых, RUP — это всего лишь набор шаблонов и рекомендаций: бери только то, что нужно, а остальное без жалости выбрасывай.
Эти простые советы помогли мне наладить рабочие процессы. Иностранный заказчик остался доволен, мы продолжили сотрудничество и со временем из субподрядчика превратились в часть его команды, которая просто сидит в Киеве. Я продолжал экспериментировать с процессами, уже имея поддержку менеджмента компании на той стороне. Зачастую бизнес-менеджмент готов не вмешиваться в процессы разработки, если всё работает хорошо.
Году в 2005-2006-м ко мне приходит знакомый и говорит: «А ты слышал про Scrum?» И начинает описывать то, как мы работаем. «Прикольно, — ответил я, — теперь буду называть это Scrum».
Теория с практикой
Я начал вести тренинги в 2008 году, предварительно подсмотрев, как это делают другие. Мы с Алексеем Кривицким создавали Agile-сообщество в Украине, привозили первых тренеров, но он собирался заниматься только этим, а я хотел практиковать и в результате перешёл в компанию, где мог быть не только менеджером, выстраивающим процессы, но и их Agile-коучем. Именно в JP/Politikens Hus, крупнейшем скандинавском медиахолдинге с весьма визионерскими взглядами, я сумел лучше понять Scrum и Agile.
Перед ИT-подразделением медиахолдинга стояла интересная задача. Стало очевидно, что невыгодно постоянно обращаться к сторонним заказчикам для разработки софта, и они решили создать собственную команду разработки фактически с нуля. ИT-директор холдинга Пэр Палмквист хотел работать по Agile-принципам, так как считал, что медиабизнес должен иметь гибкие методы управления. Я обучил людей, мы построили распредёленную команду. Было непросто, потому что «зелёная», только что собранная команда в Киеве слабо представляла, что писали сторонние разработчики до них. Первые полгода ушло на то, чтобы «выжить» и начать регулярно выдавать результат. И Scrum нам в этом очень помог. Бизнес ценит стабильность, и благодаря тому, что мы смогли выдавать результат каждые две недели, доверие к нам росло.
Сокращая отставание
Agile-методы развивались в Америке ещё в 1980-х — 1990-х, в 2001-м Agile стал отдельным брендом. В Украине же о нём услышали только в 2005-м. К 2010-му мы делали уже многое из того, чем индустрия занималась десятью годами ранее, сокращая отставание семимильными шагами. Во многом нам было проще учиться, ведь мы строили свой опыт на опыте других.
Сейчас мы приближаемся к моменту, когда разница в развитии между «нами» и «ними» составляет 1-2 года.
К сожалению, в странах СНГ иногда долго присматриваются к зарубежному опыту. С другой стороны, за это время у нас появилось качественное обучение, например, та же AgileLAB. По мере того, как местные команды разработки овладевают Agile-методами в достаточной степени, наши компании переходят на новый уровень.
Украинский рынок оказался восприимчив к Agile в тех случаях, когда это необходимо. Иностранные компании потребовали работать по Agile. Это стало модным, и многие аутсорсинговые команды стали использовать Agile как часть PR-стратегии — она помогает продавать.
С другой стороны, появились компании, с самого начала выстраивавшие взаимоотношения по Agile-подходам — и у них это неплохо получалось.
Уже не тренд, а стандарт
В начале десятилетия многие крупные компании гордо говорили: «Мы внедрили Agile». А сегодня этим уже немодно хвастаться — хуже, если вы этого не делаете. Сейчас и Microsoft, и Google работают, используя Agile-практики и стараясь придерживаться основных принципов Agile и Lean, думают над тем, как сделать процессы ещё более эффективными.
Есть компании, использующие Agile-методы как PR-ход для популяризации общей культуры разработки. Например, Spotify. У них, к слову, работает Хенрик Книберг — один из Agile-гуру, который в своей книге очень простыми словами описал, как работают Agile-методы, а заодно популяризовал свою компанию. На примере Spotify видно, как крупная продуктовая компания с распределёнными по всему миру сотрудниками может организовать разработку, свято следуя Agile-принципам. Это хорошая ролевая модель для продуктовых компаний.
Есть и компании заказной разработки, в том числе в Беларуси, которые положили Agile и Scrum в основу бизнес-модели.
С 2010 года крупные банки и корпорации, которые зачастую имели собственные отделы разработки, пришли к повсеместному внедрению Agile-методов. Всё большую популярность набирает Scaled Agile.
У меня был опыт с одним крупным туроператором. Работают давно, умеют делать бизнес, пусть и организован он технически примитивно. И вот они решают всё автоматизировать, приходят к своим разработчикам и просят новую классную систему взамен старой. ИT-отдел уже готов работать по Agile, а бизнес-организация говорит: «Мы собираемся инвестировать хх миллионов евро, хотим чётко видеть бюджет и план проекта на ближайшие два года». То есть предлагают традиционную модель и просят подписаться под каждым этапом, потому что привыкли к бюрократии.
В борьбе с такими несоответствиями в какой-то момент стали говорить про третью волну — Business Agility. Agile — скорее методы разработки, Lean — философия о том, что делать или не делать. Agile без Lean — деньги на ветер. Когда Lean-стартап начал становиться популярной культурой разработки новых продуктов, тогда и бизнес стал относиться по-другому к запуску новых проектов. Если крупная компания хочет создать систему, которая будет отвечать каким-то нуждам, но я ещё не знаю, каким — конечных потребителей или внутренних пользователей, то я должен работать по модели Lean-стартапа: регулярно смотреть на результат и решать, куда идти дальше.
Agile на пальцах
Представьте себе график. У нас есть неопределённость того, что мы делаем и как — это две оси. Можно нарисовать условный квадрант 4 на 4. Левый нижний квадрант — о простых, проектах, когда мы знаем, что и как. Правый верхний — об анархических. Пространство между ними — это как раз и есть зона Agile.
Даже если проект представляет собой хаос неопределённости, то нужно разбивать его на простые и понятные части, чтобы значительно упростить понимание конечной задачи. Комплексные проекты невозможно линейно распланировать, потому мы вынуждены применять Agile-методы. Например, ну как вы можете от начала и до конца спланировать работу R&D-команды, если ничего подобного никто до вас на рынке не делал? Или если у вас работают тысячи сотрудников? Или если речь идёт о клиенто-ориентированном проекте, когда мы в режиме реального времени следим за реакцией пользователей? Для всех подобных проектов отлично подходят Agile-методы, цель которых — упростить процессы и с помощью простых практик привести комплексные проекты к результату.
Про критику Agile
Agile как философия не отменяет практику менеджмента, просто суть Agile-манифеста в том, что существуют и другие методы достижения цели. Это более легковесные практики, которые позволяют организовать все необходимые процессы, потратив меньше сил, сфокусировавшись на ценности результата, который вы предоставляете заказчику.
Никто не говорит, что, например, планирование не нужно. Планы — это дорожная карта, которая намечает точки того, куда мы идём. Другое дело, что с Agile мы заранее учитываем, что маршрут может поменяться: мы лучше поймём, что должно получиться в итоге, на нас повлияет внешний рынок, например, конкуренты что-то выпустят, или мы точнее узнаем, что именно нужно пользователям. Соответственно, мы понимаем, что эту дорожную карту нужно регулярно пересматривать и обновлять. План, основанный на итерациях, принудительно ставит нам точки для пересмотра планов. Мы уточняем маршрут на основе реальных событий.
Хорошая метафора в данном случае — работа GPS-навигатора: он говорит нам ехать прямо, но там всё перекопано, и мы ищем объездные пути, а навигатор уже перестраивает маршрут.
Проводники Agile в жизнь
Agile — это философия, которая внедряется через набор методов, которые все вместе называются Agile Software Development. Есть ряд общеизвестных: Scrum, eXtreme Programming (XP), DSDM (больше популярный в Великобритании и Скандинавии), Kanban. В то же время существует ещё много собственных реализаций, которые, возможно, остаются внутри компаний их практикующих.
Scrum завоевал огромную популярность благодаря двум моментам. Это простота (никаких лишних деталей, ни слова про инженерные моменты) и его активная популяризация. Специально для его распространения был создан Scrum Alliance — сугубо коммерческий проект, который неплохо зарабатывает на тренингах, хотя первоначально создавался как раз для популяризации методологии и формирования сообщества, где практики могут обмениваться опытом.
Другой пример, ещё на заре формулирования Agile-движения, первая группа энтузиастов создала Agile Alliance для популяризации самой философии. Альянс широко известен также благодаря поддержке многих конференций (финансово и материалами) и локальных сообществ, но тренинги не проводит.
Я веду тренинги с 2008 года, но дипломы их участникам, выданные от моего имени, особой ценности в мире иметь не будут. Организации типа International Consortium for Agile создали модель, которая на основе экспертизы всемирно признанных Agile-практиков определяет, что должен знать человек, чтобы стать мастером-аджайлистом. Они аккредитовывают тренинговые организации, как наша AgileLAB, которые должны доказать, что сами в этом разобрались и умеют качественно обучать других. В результате последние получают статус партнёра, а консорциум выступает как независимая посредническая организация, которая подтверждает, что вы прошли качественное обучение.
Подобный принцип работает как международный стандарт качества для обучающих организаций. На мой взгляд, такая модель гораздо более открытая и перспективная, вот почему мы сотрудничаем именно с ICAgile.
Про эффективность Agile-коучинга
Эффективность тренинга можно оценить только спустя какое-то время, увидев, как внедряется Agile-культура. Поэтому в составе консалтинговой группы, где я работал долгое время, мы много внимания уделяли именно внедрению практик. Зачастую тренинг начинался для одной команды, которую затем мы продолжали поддерживать день за днём, и только тогда я мог гарантировать, что отойдя от этой команды, оставил после себя что-то действительно работающее.
Необходимый минимум для первых результатов — прожить с командой одну итерацию, но лучше — три. Если прожить с ними полгода, то можно увидеть качественный скачок продуктивности, потому что никто не гарантирует, что сразу после того, как я ушёл, общая культура организации, не готовой к изменениям, не подавила новые ростки в отдельной команде.
Но чаще всего проблема заключается не в ИT-команде, а в бизнес-части компании. Поэтому мне приходилось заходить со стороны топ-менеджмента. Когда к сотрудникам приходит их босс и говорит: «Наша компания должна либо трансформироваться, либо умереть. Чтобы мы не умерли, я нанял вам человека, который расскажет, что делать». Когда нас позиционировали именно так, то дальше работа с командами шла замечательно.
Фото: Андрей Давыдчик
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.