Опыт внедрения Agile в команде 1С: у самурая нет цели, есть только путь

Вакансия

Олег Филиппов, СТО WiseAdvice.Tech, рассказал, как в его команде проходила Agile трансформация, с какими трудностями пришлось столкнуться и как работает Agile система для команды в Wiseadvice.Tech сейчас.

Наш путь к тому, чтобы стать гибкой организацией с современным подходом и стеком (об этом, кстати, есть отдельная статья) начался примерно три года назад. Давайте сразу на берегу определимся. Agile – это культура. Её нельзя одним махом «внедрить», оставить и оно само «прорастет». Это пояснение своего рода спойлер – мы продолжаем работать над Agile процессами по сей день.

У нас так принято

Итак, обратимся к терминологии, чтобы быть в одном инфополе.

Agile – это обобщающий термин для целого ряда подходов и практик, основанных на ценностях Манифеста гибкой разработки программного обеспечения и 12 принципах, лежащих в его основе. Метод характеризуется разделением задач на короткие фазы работы и частой переоценкой и адаптацией планов.

Что из этого следует? Agile – это:

что-то про гибкость в разработке программного обеспечения;

что-то про быструю адаптацию по ситуации;

что-то про короткие фазы работы над задачей.

Звучит все просто и даже фэнтезийно. Вроде как вот она – культура мечты. Внедрил и все: проекты сделаны, задачи щелкаются как семечки, команда счастлива и ничего нигде не горит. Если вы впечатлительны – остановитесь здесь и не читайте дальше. Иногда лучше просто верить.

На деле же все немножко (множко) по-другому. Итак, 3 года назад мы уже начали внедрять Agile. Сейчас у нас очередной виток – стремимся к большей системности.

Три года назад мы неспешно решили перейти на Agile. Руководство компании не препятствовало решению, однако и дело, откровенно говоря, было не в нем.

Первый момент: люди привыкли к тому, что существуют сроки. Большая часть: заказчики, которые привыкли к дедлайнам. В Agile дедлайн – это когда делать уже ничего не надо. Для всего остального есть приоритеты. Объяснять было мучительно долго и сложно как некоторым членам команды, так и заказчикам.

Второй момент – водопадные элементы, которые в некоторых эпиках и проектах по тем или иным причинам проблематично перевести в нашу новую реальность. Какие-то нам удалось перевести самостоятельно.

Третий момент: внедряя Agile, нужно понимать, что конечного результата не будет. С общепринятым образом мышления осознать это сложно, но действительно вам вряд ли удастся когда-нибудь указать в резюме «Полностью внедрил Agile в ООО «Прогресс близок».

Наверное, в нашем случае мы приблизились к желаемому результату, когда мы отменили проектные премии. А точкой невозврата стало искоренение водопадных элементов. В этом, кстати, нам здорово помог сторонний Agile-коуч.

«Делать» Agile, а не «говорить» об Agile

Для того, чтобы что-то заработало, обычно необходимо две составляющих: тот, кто делает и то, чем делают. Первое – это люди. Второе – те или иные инструменты. Это могут быть встречи, софт, метрики – все, что помогает процессу.

По крайней мере, наш Kanban получился именно так.

Люди

Коуч у нас появился не сразу. Часть каденций KANBAN, как и основные процессы у нас прижились достаточно неплохо без посторонней помощи. Были попытки внедрить в команды роль скрам мастера, но пока они не очень успешны. Сейчас же Agile коуч регулярно проводит встречи с командами. Нескольких человек мы отправляли на курсы KANBAN, и это было максимально правильным решением – такой подход работает как фрактал. Человек обучается, транслирует это своим подопечным, те транслируют дальше.

Параллельно этому коуч в режиме реального времени проводит сессии, отвечает на вопросы и обучает лучшим практикам. И-инфополе должно быть одинаковым у всех членов команды.

Встречи, софт, метрики

Трудно представить Agile, да и в принципе любой рабочий процесс без них, правда? Расскажу в разрезе частоты встреч.

Ежедневно команды проводят 15-минутные дейли – короткая встреча, где участники обсуждают, что сделали вчера и сделают сегодня. Дейли обеспечивают прозрачность рабочего процесса и поддерживает эффективность и продуктивность команды.

Раз в две недели есть встреча по наполнению, где мы берем задачи, которые должны сделать – обязательства перед бизнесом, по сути. Мы не называем это спринтом, потому что мы ближе к Kanban, чем к Scrum.

Есть два: change и run стримы. Change stream – это новые фичи, которые меняют наш продукт к лучшему. После встреч обычно берем несколько «юзерстори». Таким образом, продукт регулярно дорабатывается и в нем появляются вещи, которые нужны пользователям, но не очевидны с точки зрения разработки.

Run stream – это про поддержку качества работы продукта на должном уровне. Есть еще стрим инфраструктурных задач, который мы обычно выделяем. Мы стараемся поддерживать баланс между рановыми, ченджовыми и инфраструктурными задачами. Для этого на встречах по наполнению присутствуют представители разных подразделений: одним нужны новые фичи для продажи потенциальным клиентам, другим стабильность работы и отсутствие ошибок, ну а мне лично инфраструктурные таски, которые повлияют и на то и на другое. Таким образом, ожидания стейкхолдеров и работа команды синхронизируются и пользователи получают комфортный для них продукт.

У нас, по сути, есть одна доска с помощью которой мы управляем загрузкой команды. По прошествии двух недель видим, что сделали, и выбираем новые стори для реализации, наиболее приоритетные. Встречу совмещаем с обзором поставки.

Раз в месяц мы проводим ретроспективу. Это отличный способ разобрать по полочкам, что команда сделала хорошо, а что не очень. И нет, это не «разбор полетов», о точка роста. Если где-то проседаем, становится понятно, какую задачу нужно выполнить, чтобы перфоманс вырос. Также приходит понимание, всего ли нам хватает для того чтобы деливерить качественные фичи в востребованные продукты.

Кстати, мы не сразу научились проводить ретроспективу хорошо и качественно. Сейчас мы поняли, что для нее обязательно нужна доска в Miro, для того чтобы организовать совместную работу в распределенной команде. Все делают по стандартизированному формату. Что хорошо, что не очень,идеи, предложения – каждый сотрудник накидывает стикеры, и мы их дружно обсуждаем.

Ретроспектива, при которой один человек пишет отчет по итогу, не имеет права на существование.

Все стори формируем в явном виде на PBR (Product Backlog Refinement) Почему? В смутные времена были случаи, когда мы ошибались с ролью в юзер стори из за этого могли действовать от изначально неверных предпосылках, в итоге сделать не то что нужно.. Обязательно описываем в сторях также блок «для того, чтобы» - иногда правильная его формулировка помогает отказаться от реализации стори в принципе. Живёт это всё в Miro до встречи по наполнению, потом переносим в Jira.

Что на выходе? Считаем капасити команды количество внедренных фич. Диаграмму потока стараемся отслеживать, но тут пока получается не очень красиво, как и с WIP лимитами, которые пока что регулярно превышаем. Так что работы нам ещё предстоит много.

Советы новичкам

Мы прошли большой путь Agile, но останавливаться не собираемся. Если материал показался вам интересным, пишите в комментах и мы будем дальше рассказывать о нашем опыте. А если вы решитесь на свой собственный путь, то вот несколько советов, которые здорово бы помогли три года назад.

Исправлять сложнее, чем сразу все сделать нормально.

Берите консультанта сразу, иначе запутаетесь и сделаете только хуже.

Не используйте Redmine, сразу переходите на Jira.

Заведите привычку использовать виртуальные доски: физические хороши, если вы из 1793 года.

Дейли должны быть обязательным ритуалом каждого рабочего дня. Как почистить зубы или выпить кофе. Это было неэффективно, когда все в одном кабинете, но очень актуально для удаленных команд.

Нужно больше формата коучинга, особенно для скрам мастеров и/или продактов.

Опубликовано на vc.ru