Какая польза от Agile: несколько кейсов из практики
Мы попросили адептов гибких методологий рассказать конкретные истории, как с помощью Agile удалось повысить эффективность работы или решить проблемы на проекте.
Из хаоса в Скрам
Артем Быковец, Certified Scrum Master, Agile Coach:
Несколько лет назад я пришел на должность Agile PM в Competera. Передо мной стояла задача — улучшить процессы в компании, взрастить культуру адаптивной разработки, а также и вытренировать преемника. На тот момент там не был внедрен Скрам или какой-то другой фреймворк: все существовало в атмосфере стартапа.
Пользовались таск-менеджером Dapulse, в котором лежал бесконечный список неописанных задач. Иногда менялись приоритеты, и этот набор задач резко преображался. К тому же, и от отдела поддержки тоже шел нескончаемый поток заданий.
Первый месяц я занимался изучением окружения, при этом еще ничего не менял и не внедрял. Затем провел 1×1 с каждым членом команды. Спрашивал, чем этот специалист занимался последние 3 месяца, что сделал за это время, что нового отдал пользователям. Ответы были в духе: «Я работал над Competera». Добиться конкретики — какой функционал добавили, какие именно проблемы решили — не удавалось.
Затем я пошел общаться с Sales & Business Developers. Оказалось, что они не могут подписать некоторые контракты, «потому что программисты чем-то своим заняты». То есть продажи и разработка были очень сильно расфокусированы: сейлзы пытались продать то, чего еще нет, а программисты разрабатывали то, что пока еще можно было и не разрабатывать.
В ходе работы в нескольких продуктовых командах мы внедрили максимально чистый Скрам: двухнедельные итерации, планнинг, ревью инкремента с участием представителей бизнеса и, конечно, ретроспективы. Перед планингом я как Скрам-мастер требовал, чтобы владелец продукта пообщался с каждым отделом — маркетингом, продажами, поддержкой и другими. Стояла задача выяснить, что хотят пользователи, что «болит», что мы уже пообещали. Позже мы также создали PAINS Канбан-доску и регулярно просматривали ее во время рефайнментов. Это помогало расставить приоритеты в разработке. В спринт мы брали по кусочку работы из каждой категории.
Также мы начали звать на демо представителей каждого отдела, чтобы все понимали, что именно сделано, чем занималась команда.
В других командах внедрили Скрамбан: мы планировали только около 60% спринта, а остальные 40% времени закладывали для того, чтобы оперативно реагировать на падающие задачи с продакшена. Например, если звонил клиент и говорил, что у него что-то не работает, мы могли сразу разобраться с его вопросами и не угробить планы на спринт. Если нам везло и в течение спринта и с продакшена ничего не прилетало, то мы просто добирали задачи из бэклога.
Как мы сформировали эти 40%? Первые несколько спринтов мы просто брали в работу все срочные задачи и уже по факту разработки оценивали их в сторипоинтах относительно запланированных задач. Спустя месяц-полтора накопилась статистика, сколько задач мы можем планировать, а сколько в среднем влетает с продакшена.
В итоге сформировалась относительно предсказуемая среда. Все отделы компании знали, над чем работает команда разработки и что появится в ближайшее время. Это дало возможность информировать пользователей, анонсировать обновления. Этот шаг повысил лояльность клиентов: они видели, что компания не стоит на месте и постоянно развивается.
Затем к нам даже пришли коллеги из маркетинга и продаж, вдохновились выстроенными процессами в R&D и попросили внедрить подобное и у них. Им хотелось уменьшить хаотичность и добиться прогнозируемости. Правда, на том этапе Скрам в продажах не зашел, но некоторые практики они взяли — к примеру, раз в пару дней стали проводить стендапы, чтобы синхронизироваться, начали делать ретроспективы.
Дальше — еще интереснее. Чтобы как-то стыковать тактические задачи на уровне команд и департаментов и стратегические на уровне всей компании, мы внедрили OKR — Objectives and Key Result. Этот фреймворк популярен в крупных компаниях, таких как Intel, Google, LinkedIn. Он заключается в том, что бизнес задает цели на год, затем годовые цели распадаются на квартальные. Каждый отдел компании думает, какими своими личными целями он может приблизить компанию к этим результатам.
Цели отделов мы трансформировали в эпики. Команда решала, как декомпозировать эпик в конкретные задачи, оценивали их в сторипоинтах и включали в спринты. Каждый квартал во время демо/ревью мы корректировали эпик на следующий период. Это не был железобетонный план, маршрут, а скорее точка назначения, куда мы идем.
Кроме того, у нас появились ежеквартальные ретроспективы всей компании, где мы обсуждали общие проблемы и пути их решения. Проводили и общие демо: программисты показывали свои разработки, маркетологи и продажники демонстрировали свои достижения. Еще ввели практику благодарить друг друга: каждый получал набор медалек и должен был раздать их людям, которым хотел сказать «Спасибо».
Если говорить о сложностях, с которыми пришлось столкнуться — это люди. К сожалению, не все хотят и готовы брать ответственность. И тут я имею в виду мой опыт в целом, а не конкретно этот случай. На определенном этапе развития компании приходится набирать людей «на ходу» — брать тех, кто был способен здесь и сейчас решить какую-то тактическую задачу. Но когда мы приходим к тому, чтобы строить организацию на годы и ориентируемся на стратегические проблемы, то, к сожалению, многие из тех людей, кто вполне подходил нам вчера, уже переставали годиться для работы в командах. Возможно, это умные и творческие ребята, но они одиночки и не желают следовать командным правилам, а хотят, чтобы наоборот — команда работала под них. С такими людьми Скрам-процессы не построишь.
Подведу итоги: Agile-подход и Скрам позволили компании разрабатывать и внедрять стратегические планы, синхронизировать работу департаментов, сплотить все команды. В таком окружении можно эффективно работать, ставить цели и достигать их. Процессы, которые удалось внедрить, используют в компании и сейчас.
Изобретая Скрам
Сергей Семенов, Certified Scrum Master, Certified Facilitator:
«А почему ты выбрал Scrum? Как встал на эту тропу, с чего всё началось?» Отвечая на такие вопросы, я иногда шучу, что так получилось, что когда-то я его изобрёл сам...
5,5 лет назад я даже не слышал о таких словах, как Agile, Скрам, бэклог, ретроспектива. В то время я занимался разработкой и администрированием баз данных в крупной не IT-компании (700+ сотрудников). Тогда и произошел переломный момент в моей карьере.
В то время наш IT-отдел — 6 разработчиков — занимался поддержкой и разработкой ПО для ведения бизнеса компании. Два начальника этого отдела разделили между собой проекты по принципу «веб» и «не веб», и каждый заведовал своей кухней.
Снежный ком тикетов в HelpDesk нарастал. Начальники, мягко говоря, не справлялись с ситуацией и подходили к вопросу творчески. К примеру, говорили так: «Если прилетает новый тикет, то сразу перекидывайте его назад и просите уточнить требования или смоделировать ситуацию. Главное, чтобы на нашем отделе было поменьше тикетов. А если перекидывать назад, у нас будут нормальные показатели».
Когда и этот подход не помогал, изобрели другой — с кодовым названием «Наверняка». Он заключался в том, чтобы принимать запросы на разработку новой функциональности по шаблону, в основе которого был использован ГОСТ 80-90-х годов с вишенкой на торте: обязательный для заполнения раздел об экономической выгоде в случае реализации запрашиваемого функционала. Другими словами, IT-отдел требовал у бизнеса экономическое обоснование на разработку, без которого футболил тикеты. Бизнес был не просто недоволен, он был взбешен такой работой.
Вскоре на работу вышел новый IT-директор.
Так получилось, что я был единственным администратором баз данных в отделе и по совместительству T-SQL разработчиком (с бэкграундом системного аналитика и релиз-инженера). Я отлично ориентировался в технической стороне работы программ, за которые отвечал IT-отдел, поскольку основная часть логики была реализована в виде хранимых процедур и триггеров.
IT-директор проводил беседу с каждым сотрудником IT-отдела, в том числе и со мной. Интересовался, что тут происходит и как мы докатились до такой жизни.
Я рассказал свое видение ситуации, называя вещи своими именами и понимая, что за эти слова меня могут уволить (на тот момент я был в штате всего месяцев 5). Но работать без изменений в этом окружении мне уже не хотелось. К моему удивлению, IT-директор спросил: «А потенции у тебя хватит навести здесь порядок?». Какая тонкая манипуляция! И я ответил, что хватит. Забегая наперед, скажу, что её таки хватило :)
Меня назначили на позицию и. о. начальника IT-отдела, а двоих начальников спустили ко мне в подчинение. Можно догадаться, какой был саботаж и холодная война с их стороны, но это уже отдельная история.
Итак, передо мной стояла задача навести порядок в деливери. Я был не только лидером команды разработки, но и человеком, который легко находил общий язык с бизнесом и мог переложить бизнес-хотелку на язык, понятный для разработчиков.
В команде мы начали с того, что снова и снова задавали себе вопросы: почему некоторые вещи происходят именно так, что нам поможет повысить производительность, что нас тянет на дно. Нам понравилась эта практика, и мы ее использовали в дальнейшем. Сейчас я понимаю, что это и есть ретроспектива, но тогда это была импровизация.
Один из разработчиков в итоге выдал: «Понимаешь Серега, я работаю тут уже 2 года, делаю 3 тикета за неделю, а мне таких еще 5 прилетает. А на мне их и так уже 60, и этот снежный ком постоянно растет. Какой смысл мне вкалывать и стараться — все равно нас никто не ценит и все будут недовольны. А ещё наши заказчики не могут договориться между собой, что приоритетней. Я только начну что-то делать, как кто-то прибегает и требует сделать отчёт, поскольку от него зависят бонусы его отдела, или другую срочную доработку. И стоит над душой, пока я ее не сделаю. А цирк начинается, когда таких заказчиков двое, трое, и они между собой выясняют, чем мне заниматься. Если я беру тикеты в работу по принципу FIFO, то вот и получается, что тикет, который пришел сегодня, попадет в работу через полгода. А потом еще жалуются, что долго ждут. А мне что делать?»
И я предложил: а давайте просто уберем этот снежный ком, начнем с чистого листа. Будем брать в работу немного, скажем, на неделю — вот тут у нас появились спринты. Пусть каждый оценивает и берёт на себя столько, сколько реально сможет сделать — но так, чтобы сделать. Таким образом мы будем прозрачны и предсказуемы. Вопросы, чем занят IT-отдел, исчезнут. Приоритезацию тикетов бизнесом и коммуникацию я возьму на себя, а весь этот снежный ком пусть себе лежит в сторонке. На том и порешили.
Вот только согласно политике компании тикет должен быть на кого-то назначен: потому-то они и накапливались. Вот незадача, что же делать? А что если перевести все тикеты на себя? Тогда я по сути стану хранителем бэклога (правда, такого слова я тогда тоже еще не знал). Нет, не то пальто: в таком случае у меня будет бардак с тикетами в HelpDesk.
И вот оно решение, простое, как пробка, доступное в тех условиях: мы создали фейкового сотрудника в HelpDesk и абсолютно все тикеты перебросили на него. Дали ему имя Герасим, а фамилию придумали айтишную — Софтенко. И наконец-то у разработчиков стало пусто в HelpDesk — красота.
Мы договорились, что с понедельника начинаем работать короткими циклами — недельными спринтами. Перед планированием с представителями департаментов я согласовал единый приоритезированный список задач на ближайшие полторы-две недели. Мы договорились ещё и о том, что от каждого департамента будет только один представитель, который принимает решение о приоритетах. Как оказалось, это было отличное решение.
Также на каждый департамент мы определили некий процент от общего скоупа на спринт. Таким образом, мы смогли брать в спринт как минимум по
Доверие начало расти, департаменты впервые начали нас благодарить за поставки выполненных задач в срок под конец каждой недели. Ребята в команде почувствовали, что их ценят и что они действительно приносят пользу бизнесу.
Поскольку между всеми заинтересованными лицами было определено, над чем конкретно работает IT-отдел в спринте, то и все «шатания» возле разработчиков сошли на нет. Всю коммуникацию по приоритетам, изменениям скоупа в течение спринта я замыкал на себе и не позволял дергать команду. Таким образом, я стал хранителем времени разработчиков и оберегал их от хаоса.
Прошло несколько месяцев, мы выработали устойчивый процесс. Недельные спринты начинались с планирования и заканчивались подведением итогов и определением шагов по улучшению. Мы попадали в коммитмент на
В результате мы не только систематически выполняли обязательства по взятым в спринт задачам, мы ещё и подняли нашу производительность в
Мы подняли customer satisfaction c явного минуса до хорошего плюса. Чтобы убедиться, можете посмотреть отзывы от директоров и начальников департаментов в моем LinkedIn.
Наш успех я связываю со следующими изменениями:
- Мы перенесли все тикеты с разработчиков в сторонку. Накопившаяся гора тикетов больше не давила и не подавляла желание работать на результат.
- Начали работать спринтами и проводили командные встречи.
- Процесс стал прозрачным и для команды разработки, и для бизнеса. Команда сама оценивала и принимала решение, сколько задач брать, чтобы их завершить к концу спринта. В свою очередь департаменты видели, над чем работает IT-отдел, и получали готовый инкремент в конце каждой недели.
- Прекратились «шатания» и «нависания» над столами разработчиков. Ребята были счастливы, что могут просто спокойно делать свою работу, и их больше не отвлекают.
- Разработчикам начали давать положительный фидбэк со стороны бизнеса, их хвалили и ценили. Это давало +100 к мотивации. Команда начала чувствовать, что она приносит пользу бизнесу.
- Команде разработки были присущи ценности: открытость, уважение, доверие, взаимоподдержка, обязательства, работа на результат.
- Дружественная атмосфера в IT-отделе.
- Фокус на сотрудничество с заказчиком, а не игра с ним в футбол.
- Открытость и прозрачность для бизнеса: в любой момент времени каждый мог видеть, над чем работает IT-отдел.
И только через год я открыл для себя Скрам, его ценности, принципы, встречи, роли, артефакты... Как все знакомо, ну кто бы мог подумать! И вот, последние 3 года я помогаю компаниям и командам создавать ценность, используя этот фреймворк.
Канбан внутри «водопада»
Анна Лаврова, PM, Certified Scrum Master, SAFe Agilist:
Расскажу историю о том, как внутри классического «водопада» мы вставили Канбан как способ работы с приоритетами и оптимизации огромного потока входящих задач.
На входе: digital-агентство с 10+ активными проектами. Их средний размер — 3 месяца, в команде 6 человек. К тому же, были короткие и быстрые спецпроекты раз в месяц и промопроекты, которые нужно провернуть за три дня. Вдобавок: запросы от существующих клиентов и их пользователей, а также несколько внутренних проектов «для разминки» и опять же оптимизации всего, что происходит.
Digital-агентство — часть устоявшейся другой медийной компании. Все проекты продаются без утверждения сроков с командой и без готового ТЗ, но с дедлайном. Представьте себе онлайн-версию журнала, типа Forbes. У нас не всегда были готовые сверстанные статьи и фотографии, но было понимание, когда же выйдет новый выпуск и его outline — тема, заглавная идея и наброски основных секций (статей).
Проблема — было очень много задач, из-за чего команды постоянно переключались, теряя фокус. К тому же, было невозможно отследить «простои» и среднюю скорость выполнения задачи — например, ответить на вопрос, когда мы поменяем фотографию в восьмой статье пятого выпуска журнала или когда сделаем новый баннер для главной страницы.
Все работа с клиентом и продуктом была организована по каскадной модели. Работать итеративно инкрементально, получить Скрам-роли было невозможно. Потому, чтобы прекратить переключения, мы приняли решение внедрить Канбан.
Идея: создать доску, на которой будут вертикально отображены процессы, а горизонтально — проекты (в Jira это делается за счет swimlane). Эти проекты будут перетягиваться вверх-вниз и вправо-влево в зависимости от приоритетов. Свои приоритеты будут и у задач внутри каждого проекта.
Я как Digital PM отвечала за эту самую доску и приоритеты. Главным челленджем было правильно описать процессы, чтобы задачи не перескакивали через колонки и не могли возвращаться. По ходу дела колонки перестраивались и переформатировались несколько раз. Важной находкой было вынесение в отдельную колонку арт-ревью — мы быстро поняли, что это и есть основное «узкое место» одной из стадий работы.
Доска в Jira: свимлейн — это проект, а вертикальная колонка — процесс
Каждую неделю команде озвучивали «проект недели» — проект с наивысшим приоритетом. Только после выполнения всех задач по нему можно было приступать ко второму, третьему внутреннему проекту. Также мы сделали супер свимлейн highest urgent important — сюда попадали задачи от клиентов. Например, на мобильной версии сайта потерялся логотип или поломалась картинка, кнопка перестала быть кликабельна и т. п.
Одна из договоренностей, которая очень важна при внедрении Канбана — адекватная работа с приоритетными задачами. То есть если та или иная задача попадает в топ-приоритетность, то первый, кто освободился, берет ее и не говорит: «Не хочу, не буду». Дальше, когда приоритетные задачи выполнены, можно заниматься теми, которые больше по душе.
Сначала договориться с командой было сложно. Но позже все поняли, что когда заказчики быстро получают свои «новые кнопочки» или что-то на ревью, то можно размеренно заниматься интересными штуками для проектов.
Челленджем работы с Jira была автоматизация процессов, которая помогла с метриками. Когда задача перетягивалась в одну из колонок, запускался внутренний таймер, который далее помогал измерить lead time, cycle time, time to production, waste in queue time.
Также мы сделали физическую доску, где писали все ключевые даты по проектам и их стадии.
Что не сделали: не приняли практику ретроспектив. Однако приняли lessons learned как часть процесса и проводили встречи, похожие по формату на lean coffee.
В планах — больше автоматизаций.
В результате получили:
- команду, которая не волнуется и не прерывается;
- проекты, которые сдаются вовремя;
- быстрое решение срочных задач и прозрачность в процессах.
Скрам и несдвигаемые дедлайны
Андрей Троянов, Delivery Lead and Agile PM:
Кейс, о котором я расскажу, произошел в компании, которая занимается разработкой игр. Изначально модель работы была приближена к Waterfall, но по ряду причин заказчики приняли решение внедрить Скрам на одном из основных проектов. Заодно планировали сравнить эффективность предыдущего и нового подходов. Итак, я приступил к внедрению гибкого фреймворка — полностью «с нуля».
Поначалу было довольно сложно. Во-первых, сама индустрия не особо предрасполагает к поставке небольших, итеративных, несущих ценность заказчику фич. Приблизительная длительность проектов компании —
Первый шаг, который я сделал, — провел ряд ознакомительных встреч, показал презентации. Объяснил коллегам, что такое Скрам и для чего нужен. Затем договорился с командой касательно расписания необходимых встреч, обучал участников особенностям церемоний, ценностям и артефактам.
Также я проводил регулярные встречи с владельцами продукта, во время которых мы обсуждали приоритизацию и работу с бэклогом. Я учил их планировать разработку продукта, поставку на основе двухнедельных итераций. Вместе с тем обучал и других менеджеров: рассказывал им об особенностях фреймворка и его принципах.
Проблемных мест в процессе внедрения тоже было немало:
— Спринты. Возник вопрос, как поставлять небольшие фичи за короткий промежуток времени. Постепенно, спустя несколько итераций, команда начала адаптироваться к новому рабочему ритму.
— Груминг. Раньше функциональные требования в компанию разрабатывались на основе объемного технического задания — без этого проекты не запускались. В процессе разработки функциональные требования практически не менялись. Чтобы адаптировать этот момент к гибкому подходу, мы решили, что по окончании старого проекта владелец продукта и дизайнер будут планировать новый проект поэтапно.
Владелец продукта и дизайнер освоили и начали использовать технику Continuous Design. Она заключается в том, что дизайн игры создается и обновляется под каждую фичу. Верхнеуровневые функциональные требования декомпозируются на эпики, потом — на юзер-стори. В результате к грумингу и планированию следующего спринта мы могли похвастаться тем, что все требования писались исключительно в формате юзер-стори с критериями приемки.
— Тестирование. До начала внедрения гибких методологий в компании был принят такой жизненный цикл ПО: сначала итерация разработки всего большого продукта, после — его общее тестирование. Внедряя Скрам, мы перешли на постоянное функциональное тестирование и во время спринта.
Надо сказать, на тот момент совместная командная оценка работ, включая этап тестирования, была крайне непривычной для команды. Как побороть старые привычки? Очень аккуратно я внедрял регулярное, функциональное, модульное и модульно-интеграционное тестирование, а также BDD-подход. Последний оказался применимым после того, как изменили подход работы с требованиями: тестировщики стали подключаться к раннему изучению функциональных требований и писать к ним кейсы.
— Обязательное Code Review. До этого в компании вообще не использовалась такая практика. В итоге удалось договориться с заказчиками, чтобы в каждой задаче отводить на Code Review 30 минут.
Подведу итог. За 2 месяца мы внедрили новый подход к работе с требованиями, перешли на практику Continuous Design, ввели регулярное Code Review. Эти изменения упростили и повысили эффективность работы с отделами разработки и дизайна игры. Вместе с тем, качество поставляемого продукта существенно улучшилось.
Таким образом, за счет роста качества и скорости разработки Скрам оказался эффективнее изначальной модели. Как я уже упоминал, из-за того, что сроки проекта обусловлены, мы немного отступили от стандартов фреймворка: делали довольно детальное изначальное планирование всего проекта с дальнейшей декомпозицией на двухнедельные спринты. За один спринт мы успевали не только разработать все необходимы фичи, а и реализовать дополнительные изменения, запрашиваемые владельцем продукта.
