Привет, Хабр! Где-то года три назад мы начали переходить с обычного вотерфольного процесса, присущего большинству продуктов энтерпрайз-сегмента, на «гибкие подходы». Стартовали с одной команды и одного подпродукта. На данный момент у нас шесть полноценных Scrum-команд. О том, почему это было необходимо, как проходила agile-трансформация, какие подходы мы тестировали, чтобы научиться делать по-настоящему большие и малопонятные на старте фичи, читайте подробнее в посте.
Одним из основных продуктов, который разрабатывает наша компания, является Solar Dozor. Это DLP для корпоративных и государственных заказчиков. Команда разработки состоит из примерно 80-ти человек, включая аналитиков, разработчиков, тестировщиков и технических писателей.
Продукту около 20 лет, за спиной как большой багаж знаний и уникальных технологий, так и того, что хотелось бы исправить :)
Три года назад мы начали смотреть в сторону гибких подходов. Протестировав их на одной команде и одном модуле DLP, поняли, что надо масштабировать. Сегодня у нас шесть полноценных Scrum-команд, а также отдельная команда Product Owner. Последняя живет в чем-то ближе к Kanban, в так называемом процессе Discovery, предшествующем этапу Delivery. В Delivery наши команды реализуют их задумки уже в полноценном Scrum-процессе.
Мы продолжаем серию материалов «Как мы создаем продукт» (#1, #2). В этой статье мы хотим поделиться историей, как проходила наша agile-трансформация. Подробнее остановимся на том, как мы научились делать по-настоящему большие и малопонятные на старте фичи. Расскажем про два новых подхода, которые мы для этого опробовали. Для тех, кто знаком с терминологией, речь пойдет о Take a bite и «Команде Тигров».
1. MultiDozor
1.1 Короткая предыстория
Вот представьте, у вас есть продукт, который создавался около 20 лет, он умеет держать на разных серверах разные сервисы, но имеет одну точку входа. Весь пользовательский интерфейс системы заточен на управление одной организацией, все сотрудники которой работают в одном территориальном подразделении.
В то же время у нас растет число крупных территориально распределенных заказчиков, которые хотят более удобный для себя user experience. Основное требование – инкапсуляция данных для каждой организационной единицы. Поиск в системе должен быть возможен как по всей организации, так и по каждой организационной единице отдельно. А еще нужна расширенная система прав, где есть как общие, так и локальные админы и пользователи.
1.2 У нас проблема…
Такая фича, очевидно, требовала серьёзного архитектурного перестроения всего продукта. Первым делом нужно было понять, как к этой работе подступиться, так как общей картины бизнес-пожеланий у нас не было.
Для так называемого подготовительного процесса мы собрали специальную исследовательскую команду из бизнес-аналитиков, архитекторов и специалистов по UI /UX. Их основной задачей было собрать с рынка ожидания клиентов от распределенных DLP и как-то приземлить их на реалии Solar Dozor. Начался процесс, который в Agile называется Discovery: исследуем потребности клиента, выдвигаем гипотезы, как закрыть их с помощью нашего продукта, получаем по ним обратную связь. В процессе мы выкидываем большую часть гипотез, оставляя в сухом остатке процентов 20. Где-то через два-три месяца такой работы туман стал рассеиваться. Начали вырисовываться очертания конечного решения. Фича выглядела все объемней и объемней, а ведь мы даже не начали ее детальную проработку. Ничего столь грандиозного по масштабу изменений в продукте мы никогда не делали. Проблема создания модуля MultiDozor была в том, что он технически очень сложный. Помимо проработки аспектов для решения бизнес-задач заказчиков, перед нами вставало много технических вопросов, принять однозначное решение по ряду которых не могла даже наша команда опытных архитекторов.
1.3 Решение – «есть по частям»
Так исторически сложилось, что системные аналитики обычно выкатывают объемные требования. Глядя на размер задачи, мы понимали, что классический водопадный процесс в данном случае гарантированно закончится провалом. Мы полгода будем только писать подробные требования, а в силу технической сложности задачи все равно не учтем всех деталей, многие из которых вполне могут заставить нас переделать все заново.
Поэтому мы решили пойти другим путем. Воспользовались подходом, который в Agile рекомендуют в таких случаях — Take a Bite.
Согласно концепции Take a Bite, лучше отказаться от сильного дробления большой и малопонятной на начальном этапе Истории. Вместо этого — взять небольшую и относительно понятную ее часть и реализовать за спринт. Логика в том, что во время этой работы мы больше узнаем о сопутствующих и связанных проблемах и их решении. После окончания работы можем показывать результаты стейкхолдерам и получать раннюю обратную связь. Наш горизонт как технических, так и бизнес-знаний за этот спринт расширится, и в следующий мы сможем взять еще один кусочек небольшой и понятной работы. Таким образом мы ориентируемся на как можно более раннее снижение технических рисков (мы технически не можем сделать то, что от нас хотят) и бизнес-рисков (мы сделаем то, что клиенту реально не надо). Мы можем совершать корректировки движения относительно «дешево» — потенциальные потери окажутся не больше работы, проделанной за один двухнедельный спринт.
Собственно, в истории с MultiDozor мы пошли таким путем. После того, как аналитики сформулировали базовую концепцию нового модуля и первый пул основных потребностей заказчиков (для начала мы выбрали трех самых крупных и активных с точки зрения получения обратной связи), мы стартанули первые спринты.
1.4 Ура, мы были правы…
Мы очень быстро убедились в правильности выбранного подхода. Где-то в середине второго спринта глядя на то, что получается, мы заметили, что то решение, которое мы начали реализовывать, не согласуется с потребностями одного из заказчиков. В его конфигурации потоков данных были существенные особенности. Определенные данные должны были храниться в центральном подразделении, а еще часть — в распределенных. И при этом должна обеспечиваться связанность между ними. Мы оценили, что эти особенности потенциально могут быть присущи и другим важным клиентам, и решили все-таки скорректировать свое движение к конечному результату...
И остановили спринт…
За оставшуюся неделю спринта после активных споров было выработано решение, позволяющее минимальной корректировкой достигнуть заданной цели. Это решение было оперативно провалидировано у соответствующего заказчика.
И в третий спринт мы уже начали его реализацию. При этом стоит отметить, что только около половины написанного ранее кода нам удалось сохранить в новой концепции. Остальное пришлось выкинуть.
Но, как ни странно, мы были очень рады, так как понимали, что в случае водопадного подхода, который мы практиковали еще не так давно, понимание, что что-то пошло не так, пришло бы к нам уже ближе к концу релиза. Пришлось бы выпускаться или с тем, что есть (и терять большой сегмент клиентов) или переписывать уже гигантски разросшийся мультидозорный код. И в том, и в другом случае потери были бы колоссальными.
1.5 Что еще нам помогло?
Коротко отмечу, что помимо изменения работы с требованиями системных аналитиков в рамках работы над MultiDozor мы изменили также способ организации нашего труда. Перешли к многокомандному Scrum. Для масштабирования выбрали фреймфорк Less (подробнее о нем можно почитать по ссылке). Если коротко, то у нас появилось Общее Планирование, Общие PBR (встречи, где мы вместе прорабатываем истории для будущих спринтов), Общий Обзор Спринта и, конечно, Общая Ретроспектива. Подробно останавливаться на всем этом не буду, отмечу, что, например, без Общих PBR мы не смогли бы так эффективно делиться знаниями и брейнштормить, а без Общих Ретроспектив — оперативно решать вопросы коммуникации.
Мы сфокусировались на том, чтобы команды научились самостоятельно коммуницировать между собой и стейкхолдерами, научились решать свои проблемы. И все это происходило бы без привлечения менеджеров разного уровня. Что-то у нас получилось, что-то нет, но очевидный рост самоорганизации точно помог нам сделать такую крайне сложную фичу, как MultiDozor, и уложиться в сроки, которые ставило перед нами руководство.
2. UBA
2.1 Короткая предыстория
Вторая наша история – про Dozor UBA. Про эту систему мы уже несколько раз вам рассказывали тут и тут. Если коротко, то наши коллеги-математики придумали крутую модель, как автоматизировать обнаружение отличий в поведении людей от своих собственных паттернов и от паттернов отдела или всей организации. Коллеги построили прототип на питоне, доказавший корректность их гипотез. А дальше нам надо было все это интегрировать в работающий продукт Solar Dozor с его многочисленными сервисами, потоками данных и устоявшимся UI. Причем сделать так, чтобы понятные только математикам концепции были визуализированы доступно и прозрачно для наших основных пользователей – специалистов по безопасности.
2.2 У нас проблема…
Если честно, понимания, как это все должно выглядеть и работать, ни у кого не было. Что было – так это железобетонная уверенность, что эта фича позволит нам далеко обогнать конкурентов и решать много полезных для информационной и экономической безопасности задач, для которых не подходят старые и привычные методы.
2.3 Решение – «Команда тигров»
Мы пошли путем создания «Команды Тигров» (Tiger team). Это временная scrum-команда, которая собирается для решения «нерешаемых» задач.
Нам этот термин попался на глаза в книжке по Less, но появился изначально, кажется, из космонавтики — если перевести примерно определение, данное в 1964-м году, – это «команда технических специалистов, отобранных за их опыт, энергию и воображение, которым поручено выявить и устранить все возможные источники сбоев в подсистемах космического корабля» (источник).
В общем, мы взяли лучшего UI-щика, лучшего бэкендера, аналитика, тестировщика, человека из бизнеса, добавили к ним архитектора и спеца по СУБД. В результате в одной команде оказались люди с самой большой экспертизой по каждому вопросу.
Команда именно временная — в нашем случае «Тигры» проработали около двух кварталов, но об этом чуть позже.
Итак, команда собрана, пора стартовать…
2.4 И снова «едим по кусочку»
Мы еще раз воспользовались подходом «кусать по кусочкам» и, затаив дыхание, ринулись в этот омут с головой. Поначалу было очень страшно, так как очень непонятно.
Единственное, что было ясно, так это то, что без расчетов функций нам не обойтись. Прикинули, какие нужны первые данные для расчетов, продумали под это архитектуру и сервисы – и начали.
На первом Sprint Review мы могли показать в интерфейсе только пару цифр, полученных как результат предварительных расчетов для показателей (как и на чем мы считали, подробнее описано в статье про СlickHouse). Но это уже лучше, чем в начале, когда не было ничего. Это уже был успех! Во «внутрянке» для показа этой цифры уже крутились нужные шестереночки-сервисы. И это многого стоило.
К концу двух недель появились мысли, что еще можно сделать. Процесс разработки начал набирать обороты.
Расчеты и внутренние сервисы – это хорошо, но пришло время задуматься и о UI.
Для визуализации показателей UBA на первом этапе мы решили использовать Grafana. Мы понимали, что визуальные представления будут меняться от спринта к спринту. Grafana же была очень адаптивным инструментом и позволила нам быстро визуализировать и многократно перестраивать визуальное представление.
Так во втором спринте у продукта появился первичный интерфейс. А после пятого руководитель департамента разработки с восхищением вскрикивал: «Вы уже четвертый раз поменяли весь интерфейс, и он снова стал гораздо лучше!»
А вот и несколько этапов его эволюции:
Со второго спринта начались уже более бурные обсуждения ожиданий бизнеса, на Sprint Review появилась обратная связь совершенно другого уровня – а это очень важно для адаптации.
Оценка промежуточных результатов помогла подойти не только к перестроению UI и поиску наиболее удобного и понятного интерфейса, но также к рождению новых моделей. Оказалось, что первичные гипотезы, как считать, оценивать и показывать поведение пользователей, были неоптимальными. Выяснилось, что нужно выбирать другие точки, находить больше аномалий, использовать другое количество итераций и так далее.
На всех последующих Sprint Review было также много вопросов и обсуждений. Например, мы столкнулись с проблемой, что рассказывать о сложной математической модели, которая лежит в основе модуля, на понятном бизнесу языке оказалось непросто. Мы прошли длинный путь из тестирований формулировок и данных, которые показывали на графиках. Но они пригодились и стали подсказками для пользователя в интерфейсе.
2.5 Куда делись тигры?
Примерно через квартал мы успешно выпустили модуль на рынок.
Grafana так и осталась в первой версии. Изначально она чуть-чуть выбивалась из общего стиля интерфейса, но после подбора цветов дизайнерами очень даже вписалась и в итоге уверенно ушла в прод :-)
Команду Тигров мы распустили, и они ушли в команды распространять знания о UBA, как эксперты и менторы компонента. Если честно, было очень грустно, так как за это время мы все вместе по-настоящему сработались и сблизились. Ничто не сближает сильнее, чем решаемая командой плечом к плечу нерешаемая задача.
Если говорить о текущем состоянии, то мы продолжаем развитие модуля, каждый релиз выходят все новые и новые фичи. Мы активно коммуницируем с конечными пользователями, которые, кажется, распробовали предложенные нами новые подходы.
Отработав основные этапы визуализации, позже, в следующих релизах, мы начали переходить с Grafana на Angular в качестве UI-фреймворка и на продвинутую графическую библиотеку. Grafana начали убирать «кусочками», так как она н е позволяла нам визуализировать данные достаточно гибко.
При развитии модуля мы уже не собирали «тигров», а дорабатывали его существующими командами, используя для передачи знаний экспертов подход «моб-программирования» — своего рода «расширение» парного программирования. Но не буду про это сейчас подробно – это отдельная тема :-)
Выводы
Agile и большие фичи/истории совместимы и даже очень хорошо.
Описанный подход Take a bite позволяет экономить кучу времени и денег.
Чем «малопонятней» фича на входе, тем Take a bite эффективнее по сравнению с традиционным водопадом.
Этот подход позволяет готовить к релизу именно то, что нужно клиенту, а не то, что получилось и уже тяжело исправить.
Стартовать разработку продукта можно и зачастую даже нужно без толстенного талмуда проработанных требований. Но важно при этом установить оперативные и доверительные отношения с заказчиками.
Ну, и, наверное, самое главное — это эмпирический процесс (Scrum является только одним из подходов, использующих этот процесс), а не жесткий регламент или методология. Не бойтесь проводить различные эксперименты, пробовать разные подходы и оставляйте то, что сработало, выкидывая, то, что не оправдало ожиданий. И то, и другое – успех! У вас в любом случае остается багаж накопленного опыта и знаний.
Рано или поздно эта жажда постоянных улучшений через эксперименты проникнет в культуру вашего подразделения и даже организации.
