[Информационная безопасность, Управление разработкой, Управление продуктом, Софт] Жизнь до и после Scrum в разработке B2B продуктов

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
10-Ноя-2020 11:32

Цитировать

Привет, Хабр! Сегодня мы хотим поговорить на тему Scrum, а точнее поделиться своим опытом внедрения новых процессов в разработке. Под катом — рассказ о том, как преодолевать проблемы B2B-разработки при внедрении agile, на примере нашего продукта Solar Dozor. Делимся откровениями о жизни до и после Scrum.

С чего всё начиналось...
Наша история с внедрением Scrum началась пару лет назад. Эта потребность созрела внутри как желание быстрее адаптироваться к окружающим реалиям. В прошлом мы не раз сталкивались с ситуациями, когда в разработке что-то приходилось переделывать просто потому, что функциональный заказчик «имел в виду совсем не это».
Мы уже подготовили релиз, показываем его заказчику, и вдруг возникают вопросы вроде: «Зачем такую таблицу? Почему не окошко?». Если бы мы знали об этом раньше, стоимость исправления была бы значительно ниже. Никто бы не срывал сроки, не приходилось бы «гореть» и сдвигать даты релизов.
Так продолжалось из года в год – все устали, да и недовольство заказчиков росло. Мы решили, что надо что-то менять.
Scrum де-факто является стандартом современной разработки. И мы очень хотели попробовать перейти на agile-разработку, но на практике это оказалось не так-то просто.
«Что нам стоит дом построить?» Или как внедрить Scrum в B2B, и вся правда про agile-коучей

Scrum-фреймворк особенно хорошо подходит для процессов, в которых создается новый продукт. Но как любят говорить сами agile-коучи: «Scrum легко понять, но тяжело внедрить».
На конференциях по agile о внедрении Scrum обычно рассказывают лишь крупные компании. Представители среднего бизнеса редко делятся таким опытом. Почему? Потому что это, вообще говоря, дорогое удовольствие.
Крупные компании нанимают готовых специалистов в штат или крутых внешних консультантов. Обычно консультанты приходят в офис, проводят тренинги, организуют процессы, помогают компании мягко перейти в новую парадигму. Но такая услуга стоит миллионы, и что делать, если у вас нет столько денег на сегодня?
У нас их не было. Поэтому я лично прочитал все, что нашел в рунете, но… целостной картины внедрения Scrum так и не получил. Единственное, что мне стало понятно, что без опытного agile-коуча у нас не так уж много шансов успешно завершить процесс. Почему так? Потому что на самом деле очень важно, чтобы процесс возглавлял человек с успешным опытом решения этой задачи. Если опыт был негативным либо его не было вообще, то ничего не выйдет. Может быть поэтому 8 из 10 проектов перехода на agile заканчиваются неудачей?
Нам в каком-то смысле повезло, и мы попали на промо-программу «agile-трекинг» от ScrumTrek. Как я уже говорил, у нас не было бюджета, чтобы нанять консультанта на весь проект. А формат трекинга как раз подразумевал, что вместо постоянного руководства мы раз в неделю получаем задание и отчитываемся о его выполнении. Мы создали у себя внутри команду трансформации, которая занялась внедрением новых практик с подачи консультанта.
Честно говоря, на входе все это было пугающе непонятно. Проще было бы выстраивать agile-разработку с нуля. Ведь менять уже сложившиеся процессы, в которых все точно также «горит» и «кипит», — значит взять на себя серьезную ответственность. Поэтому мы начали постепенно, и первым внедрение Scrum стартовало в одной команде – команде разработки модуля Dozor Web Proxy.
Сейчас же у нас уже больше 5 успешных команд по разным продуктам.
Кроссфункциональные команды
Согласно Scrum-подходу, внутри каждой команды должны быть все компетенции, чтобы реализовать фичу. До внедрения Scrum — UI-разработчики у нас были в одной команде, бэкендеры в другой, тестировщики в третьей. У каждой команды были свои очереди, и быстро подключаться к решению задач они не могли – после реализации бэка задача попадала в «режим ожидания» в очереди на UI и т.д. После того как были пройдены все очереди разработки, задача переходила в очередь на тестирование.
Когда при такой организации процесса выяснялось, что в коде есть баг – например, на этапе тестирования через месяц, – часто оказывалось, что разработчики к тому времени уже все забыли и делали уже что-то совсем другое. Баг попадал заново в очередь разработчикам на исправление и заново проходил всю цепочку очередей.
Для достижения кроссфункциональности пришлось расформировать существующие отделы и собрать людей в фиче-команды. Наверное, этот процесс был самым пугающим с точки зрения возможности возникновения хаоса. Но он очень быстро оправдал себя.
Кроссфункциональная команда позволяет все делать быстро, практически одновременно, без выстраивания лишних зависимостей и очередей – и UI, бэкэнд, тесты. В бэклоге спринта каждой команды содержится свой список задач, выполнения которых ждет product owner соответствующего продукта. С внедрением нового подхода каждая задача стала возвращаться к владельцу продукта намного раньше, 90% проблем мы закрываем в рамках одного цикла, не прерывая процесса разработки. Благодаря этому очереди на исправления вообще не возникают.

Бэклог продукта, и как его готовить. Немного про PBR
На самом начальном этапе внедрения Scrum первое, что вам нужно сделать, — это понять, что в вашем случае является продуктом. И только после этого можно что-то начинать. Нет продукта — нет Scrum-а.
После того как вы определились с тем, что является у вас продуктом, вам необходимо составить план по его развитию. По сути этим и является бэклог продукта. Туда попадает не только roadmap, но и все-все остальные фичи, которые вы хотите реализовать. Хотите устранить технический долг или есть технические доработки, которые влияют на пользователя? Их тоже туда же, в бэклог продукта. Наверху бэклога — самые ценные на данный момент фичи, которые хотим брать в разработку в ближайший спринт.
Но есть момент! Разработка ПО находится в комплексной среде по Модели «Кеневин». А мы хотим реализовать функционал в рамках одной итерации (спринта). Поэтому важно, чтобы элемент бэклога продукта был проработан так, чтобы его можно было реализовать за время одного Спринта.
Мы стараемся держать проработанный бэклог вперед на 2-3 спринта. Больше просто нет смысла, потому что за время спринтов все может измениться, и потребуется все перепланировать заново. Верхнеуровневый план разработки делается на год, а конкретные запросы клиентов аналитики обсуждают на встречах с клиентами каждые 2 месяца.
Продолжительность спринта у нас 2 недели — стандартный параметр.
Но проработка бэклога — отдельная нетривиальная задача. Мы решаем этот вопрос методом «Встречи трех амиго» — разработчика, человека от бизнеса (аналитика) и тестировщика. Нормально провести проработку каждой фичи по бэклогу можно, только если все трое присутствуют.
Аналитик понимает, что нужно заказчику, разработчик понимает ограничения, тестировщик знает о corner case и других нюансах. В результате происходит так называемое уточнение бэклога продукта (Product Backlog Refinement – PBR).
Аналитик теперь рассказывает историю, которая интересна с точки зрения бизнеса. Раньше он просто отдавал разработчику свое видение и эскизы до спринта, а при запуске разработки выяснялись нюансы, благодаря которым сроки съезжали. Сейчас это делается на встрече по построению Example Mapping – с разбором и обсуждением конкретных примеров, что позволяет проработать краевые случаи, заранее обнаружить сложности.
За год работы в режиме Scrum мы пришли к тому, что нам нужно от 4-х до 8ми таких встреч в течение двухнедельного спринта. На первых встречах накидывается куча вопросов, на следующих на них предлагаются ответы. Потом происходит оценка стоимости разработки, тестирования, оценивается приоритет фичи.

На фото — мы довольные после хорошей сессии проработки бэклога, которая дала нам возможность хорошо поработать в несколько следующих спринтов :-)
Интересно, что переход к Scrum увлек и аналитиков, они почувствовали, что участвуют в процессе, что от них многое зависит. Они стали не просто работать с гипотезами, но показывать скриншоты и эскизы потенциальным заказчикам, активным пользователям.
Самое важное — спринты и их ревью
С бэклогом работает Product Owner (PO). Он решает судьбу элементов бэклога – делать, не делать и когда делать – относительно своего видения рынка. Он же решает, что должно быть реализовано к концу спринта и показано на ревью.
После диалога между PO и командой разработки (DevTeam) на Планировании спринта (Planning) и определения списка элементов бэклога, которые должны быть готовы к ревью к концу спринта, начинается командная работа.
Разработчики пишут код, тестировщики сразу начинают готовить test-кейсы. За две недели мы стараемся довести истории до состояния, когда выполняются наши критерии готовности (DoD). В результате аналитики понимают, что делают разработчики и насколько это соответствует тому, что им нужно.
В конце спринта, когда всё (или не всё :-)) готово, все собираются на обзор спринта. На обзор спринта мы приглашаем всех стейкхолдеров, сейчас стабильно приходят до 70-80 человек. Команды показывают, что они сделали: интерфейс, формы, логику, графики. Производится оценка сделанного, хорошо у нас получается или нет. Коллеги высказывают пожелания и помогают скорректировать траекторию разработки.
Раньше петля обратной связи составляла один квартал. Инженеры получали отзывы только с выпуском релиза. Соответственно, было очень много негатива, приходилось переделывать то, что казалось очевидным.
За 2 недели накапливается значительно меньше ошибок – это уже проверено. И эмоциональный фон стал лучше, все участвуют в процессе.
Проблемы B2B
Считается, что Scrum очень хорошо работает, когда выход на заказчика короткий. У B2B с этим сложнее, потому что финальные заказчики — очень занятые люди, и чтобы до них достучаться, нужно пройти по цепочке из нескольких человек.
Теперь у наших аналитиков есть телефоны самых активных и заинтересованных заказчиков. До Scrum мы считали, что это не нужно, что достаточно лишь предположений аналитиков. Но практика показала, что в 50% случаев эти гипотезы не совсем верные. В результате мы пришли к тому, что на фидбек от пользователей уходит не полгода, не месяц, а как раз та самая пара недель. Для этого аналитикам пришлось по-настоящему подружиться с самыми лояльными клиентами. Теперь они общаются намного больше.
Довольны и сами клиенты. Мы стали попадать в свои же назначенные сроки релизов, даже если речь идет о крупных фичах. Например, выпуская MultiDozor — одну из самых сложных историй нашей разработки, в которой были задействованы все функции, какие вообще у нас есть, мы уложились в квартал! После этого релиз выпустили в продуктив, не сорвав сроков.
С тех пор пресейл-менеджеры тоже ходят на спринт-ревью. Они очень заинтересованы в участии, потому что видят, как их пожелания сразу же учитываются, в продукты вносятся исправления. В то же время они очень нужны разработчикам, потому что придают конкретики планам и проектам.
Сложно начать… невозможно остановиться!
Мой опыт показывает, что Scrum-команда начинает нормально работать только через год. За это время становится понятно, что и как мы делаем, какие процессы нужно налаживать, как готовиться к обзору спринта, кто будет в нем участвовать, что происходит в непредвиденных ситуациях и так далее.
Например, когда мы внедряли практику Scrum для команды, занимающейся endpoint-агентом для Windows – это очень важный в нашей экосистеме, но и очень специфический модуль, то взяли небольшой тайм-аут, чтобы создать кроссфункциональную команду и сформировать все процессы. Но во время большого спринт-ревью по Dozor Core пресейлы начали спрашивать: «Почему не проводятся обзоры спринтов по агенту?», «Как мы узнаем, какую фичу вы делаете сейчас?». В итоге команда была создана, как говорится, по заявкам стейкхолдеров.
А дальше начинается самое интересное. Как внедрять Scrum для тех продуктов, на которых работает несколько команд? Или как создавать супербольшие и не до конца понятные на старте фичи? Именно такие задачи нам пришлось решать при разработке нашего модуля анализа поведения пользователей Dozor UBA. Но практика построения Scrum для трех команд и поэтапная разработка UBA «слепыми» спринтами — это уже тема отдельного поста. Подписывайтесь на наш блог, и я расскажу об этом в одном из ближайших наших постов. Также будет здорово, если вы поделитесь в комментариях своим опытом перехода на agile.
Автор: Андрей Грицевич, руководитель отдела разработки Solar Dozor
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_upravlenie_razrabotkoj (Управление разработкой), #_upravlenie_produktom (Управление продуктом), #_soft (Софт), #_razrabotka (разработка), #_scrum, #_agile, #_sprint (спринт), #_beklog (бэклог), #_stejkholdery (стейкхолдеры), #_v2v (в2в), #_krossfunktsionalnost (кроссфункциональность), #_example_mapping, #_fichi (фичи), #_product_owner, #_blog_kompanii_rostelekomsolar (
Блог компании Ростелеком-Солар
), #_informatsionnaja_bezopasnost (
Информационная безопасность
), #_upravlenie_razrabotkoj (
Управление разработкой
), #_upravlenie_produktom (
Управление продуктом
), #_soft (
Софт
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 23-Ноя 00:43
Часовой пояс: UTC + 5