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

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

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

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

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

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

• что-то про гибкость в разработке программного обеспечения,
• что-то про быструю адаптацию по ситуации,
• что-то про короткие фазы работы над задачей.

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

На деле же все немножко (множко) по-другому. Итак, 3 года назад мы уже начали внедрять 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 года
• Дейли должны быть обязательным ритуалом каждого рабочего дня. Как почистить зубы или выпить кофе. Это было неэффективно, когда все в одном кабинете, но очень актуально для удаленных команд.
• Нужно больше формата коучинга, особенно для скрам мастеров и/или продактов.