Привет, Хабр! Сегодня мы хотим поговорить на тему Scrum, а точнее поделиться своим опытом внедрения новых процессов в разработке. Под катом — рассказ о том, как преодолевать проблемы B2B-разработки при внедрении agile, на примере нашего продукта Solar Dozor. Делимся откровениями о жизни до и после Scrum.
Наша история с внедрением Scrum началась пару лет назад. Эта потребность созрела внутри как желание быстрее адаптироваться к окружающим реалиям. В прошлом мы не раз сталкивались с ситуациями, когда в разработке что-то приходилось переделывать просто потому, что функциональный заказчик «имел в виду совсем не это».
Мы уже подготовили релиз, показываем его заказчику, и вдруг возникают вопросы вроде: «Зачем такую таблицу? Почему не окошко?». Если бы мы знали об этом раньше, стоимость исправления была бы значительно ниже. Никто бы не срывал сроки, не приходилось бы «гореть» и сдвигать даты релизов.
Так продолжалось из года в год – все устали, да и недовольство заказчиков росло. Мы решили, что надо что-то менять.
Scrum де-факто является стандартом современной разработки. И мы очень хотели попробовать перейти на agile-разработку, но на практике это оказалось не так-то просто.
Scrum-фреймворк особенно хорошо подходит для процессов, в которых создается новый продукт. Но как любят говорить сами agile-коучи: «Scrum легко понять, но тяжело внедрить».
На конференциях по agile о внедрении Scrum обычно рассказывают лишь крупные компании. Представители среднего бизнеса редко делятся таким опытом. Почему? Потому что это, вообще говоря, дорогое удовольствие.
Крупные компании нанимают готовых специалистов в штат или крутых внешних консультантов. Обычно консультанты приходят в офис, проводят тренинги, организуют процессы, помогают компании мягко перейти в новую парадигму. Но такая услуга стоит миллионы, и что делать, если у вас нет столько денег на сегодня?
У нас их не было. Поэтому я лично прочитал все, что нашел в рунете, но… целостной картины внедрения Scrum так и не получил. Единственное, что мне стало понятно, что без опытного agile-коуча у нас не так уж много шансов успешно завершить процесс. Почему так? Потому что на самом деле очень важно, чтобы процесс возглавлял человек с успешным опытом решения этой задачи. Если опыт был негативным либо его не было вообще, то ничего не выйдет. Может быть поэтому 8 из 10 проектов перехода на agile заканчиваются неудачей?
Нам в каком-то смысле повезло, и мы попали на промо-программу «agile-трекинг» от ScrumTrek. Как я уже говорил, у нас не было бюджета, чтобы нанять консультанта на весь проект. А формат трекинга как раз подразумевал, что вместо постоянного руководства мы раз в неделю получаем задание и отчитываемся о его выполнении. Мы создали у себя внутри команду трансформации, которая занялась внедрением новых практик с подачи консультанта.
Честно говоря, на входе все это было пугающе непонятно. Проще было бы выстраивать agile-разработку с нуля. Ведь менять уже сложившиеся процессы, в которых все точно также «горит» и «кипит», — значит взять на себя серьезную ответственность. Поэтому мы начали постепенно, и первым внедрение Scrum стартовало в одной команде – команде разработки модуля Dozor Web Proxy (сейчас это уже отдельный продукт Solar webProxy).
Сейчас же у нас уже больше 5 успешных команд по разным продуктам.
Согласно Scrum-подходу, внутри каждой команды должны быть все компетенции, чтобы реализовать фичу. До внедрения Scrum — UI-разработчики у нас были в одной команде, бэкендеры в другой, тестировщики в третьей. У каждой команды были свои очереди, и быстро подключаться к решению задач они не могли – после реализации бэка задача попадала в «режим ожидания» в очереди на UI и т.д. После того как были пройдены все очереди разработки, задача переходила в очередь на тестирование.
Когда при такой организации процесса выяснялось, что в коде есть баг – например, на этапе тестирования через месяц, – часто оказывалось, что разработчики к тому времени уже все забыли и делали уже что-то совсем другое. Баг попадал заново в очередь разработчикам на исправление и заново проходил всю цепочку очередей.
Для достижения кроссфункциональности пришлось расформировать существующие отделы и собрать людей в фиче-команды. Наверное, этот процесс был самым пугающим с точки зрения возможности возникновения хаоса. Но он очень быстро оправдал себя.
Кроссфункциональная команда позволяет все делать быстро, практически одновременно, без выстраивания лишних зависимостей и очередей – и UI, бэкэнд, тесты. В бэклоге спринта каждой команды содержится свой список задач, выполнения которых ждет product owner соответствующего продукта. С внедрением нового подхода каждая задача стала возвращаться к владельцу продукта намного раньше, 90% проблем мы закрываем в рамках одного цикла, не прерывая процесса разработки. Благодаря этому очереди на исправления вообще не возникают.
На самом начальном этапе внедрения 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 недели накапливается значительно меньше ошибок – это уже проверено. И эмоциональный фон стал лучше, все участвуют в процессе.
Считается, что Scrum очень хорошо работает, когда выход на заказчика короткий. У B2B с этим сложнее, потому что финальные заказчики — очень занятые люди, и чтобы до них достучаться, нужно пройти по цепочке из нескольких человек.
Теперь у наших аналитиков есть телефоны самых активных и заинтересованных заказчиков. До Scrum мы считали, что это не нужно, что достаточно лишь предположений аналитиков. Но практика показала, что в 50% случаев эти гипотезы не совсем верные. В результате мы пришли к тому, что на фидбек от пользователей уходит не полгода, не месяц, а как раз та самая пара недель. Для этого аналитикам пришлось по-настоящему подружиться с самыми лояльными клиентами. Теперь они общаются намного больше.
Довольны и сами клиенты. Мы стали попадать в свои же назначенные сроки релизов, даже если речь идет о крупных фичах. Например, выпуская MultiDozor — одну из самых сложных историй нашей разработки, в которой были задействованы все функции, какие вообще у нас есть, мы уложились в квартал! После этого релиз выпустили в продуктив, не сорвав сроков.
С тех пор пресейл-менеджеры тоже ходят на спринт-ревью. Они очень заинтересованы в участии, потому что видят, как их пожелания сразу же учитываются, в продукты вносятся исправления. В то же время они очень нужны разработчикам, потому что придают конкретики планам и проектам.
Мой опыт показывает, что Scrum-команда начинает нормально работать только через год. За это время становится понятно, что и как мы делаем, какие процессы нужно налаживать, как готовиться к обзору спринта, кто будет в нем участвовать, что происходит в непредвиденных ситуациях и так далее.
Например, когда мы внедряли практику Scrum для команды, занимающейся endpoint-агентом для Windows – это очень важный в нашей экосистеме, но и очень специфический модуль, то взяли небольшой тайм-аут, чтобы создать кроссфункциональную команду и сформировать все процессы. Но во время большого спринт-ревью по Dozor Core пресейлы начали спрашивать: «Почему не проводятся обзоры спринтов по агенту?», «Как мы узнаем, какую фичу вы делаете сейчас?». В итоге команда была создана, как говорится, по заявкам стейкхолдеров.
А дальше начинается самое интересное. Как внедрять Scrum для тех продуктов, на которых работает несколько команд? Или как создавать супербольшие и не до конца понятные на старте фичи? Именно такие задачи нам пришлось решать при разработке нашего модуля анализа поведения пользователей Dozor UBA. Но практика построения Scrum для трех команд и поэтапная разработка UBA «слепыми» спринтами — это уже тема отдельного поста. Подписывайтесь на наш блог, и я расскажу об этом в одном из ближайших наших постов. Также будет здорово, если вы поделитесь в комментариях своим опытом перехода на agile.
Автор: Андрей Грицевич, руководитель отдела разработки Solar Dozor
С чего всё начиналось...
Наша история с внедрением Scrum началась пару лет назад. Эта потребность созрела внутри как желание быстрее адаптироваться к окружающим реалиям. В прошлом мы не раз сталкивались с ситуациями, когда в разработке что-то приходилось переделывать просто потому, что функциональный заказчик «имел в виду совсем не это».
Мы уже подготовили релиз, показываем его заказчику, и вдруг возникают вопросы вроде: «Зачем такую таблицу? Почему не окошко?». Если бы мы знали об этом раньше, стоимость исправления была бы значительно ниже. Никто бы не срывал сроки, не приходилось бы «гореть» и сдвигать даты релизов.
Так продолжалось из года в год – все устали, да и недовольство заказчиков росло. Мы решили, что надо что-то менять.
Scrum де-факто является стандартом современной разработки. И мы очень хотели попробовать перейти на agile-разработку, но на практике это оказалось не так-то просто.
«Что нам стоит дом построить?» Или как внедрить Scrum в B2B, и вся правда про agile-коучей
Scrum-фреймворк особенно хорошо подходит для процессов, в которых создается новый продукт. Но как любят говорить сами agile-коучи: «Scrum легко понять, но тяжело внедрить».
На конференциях по agile о внедрении Scrum обычно рассказывают лишь крупные компании. Представители среднего бизнеса редко делятся таким опытом. Почему? Потому что это, вообще говоря, дорогое удовольствие.
Крупные компании нанимают готовых специалистов в штат или крутых внешних консультантов. Обычно консультанты приходят в офис, проводят тренинги, организуют процессы, помогают компании мягко перейти в новую парадигму. Но такая услуга стоит миллионы, и что делать, если у вас нет столько денег на сегодня?
У нас их не было. Поэтому я лично прочитал все, что нашел в рунете, но… целостной картины внедрения Scrum так и не получил. Единственное, что мне стало понятно, что без опытного agile-коуча у нас не так уж много шансов успешно завершить процесс. Почему так? Потому что на самом деле очень важно, чтобы процесс возглавлял человек с успешным опытом решения этой задачи. Если опыт был негативным либо его не было вообще, то ничего не выйдет. Может быть поэтому 8 из 10 проектов перехода на agile заканчиваются неудачей?
Нам в каком-то смысле повезло, и мы попали на промо-программу «agile-трекинг» от ScrumTrek. Как я уже говорил, у нас не было бюджета, чтобы нанять консультанта на весь проект. А формат трекинга как раз подразумевал, что вместо постоянного руководства мы раз в неделю получаем задание и отчитываемся о его выполнении. Мы создали у себя внутри команду трансформации, которая занялась внедрением новых практик с подачи консультанта.
Честно говоря, на входе все это было пугающе непонятно. Проще было бы выстраивать agile-разработку с нуля. Ведь менять уже сложившиеся процессы, в которых все точно также «горит» и «кипит», — значит взять на себя серьезную ответственность. Поэтому мы начали постепенно, и первым внедрение Scrum стартовало в одной команде – команде разработки модуля Dozor Web Proxy (сейчас это уже отдельный продукт Solar webProxy).
Сейчас же у нас уже больше 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
