От каждого по потребностям, каждому — по agile

Дерюшкин АлексейAgile Coach, АО «Райффайзенбанк»

О чём этот доклад? 4 года практики внедрений в enterprise 4 команды от 3 до 60+ человек Несколько завершённых проектов Несчётное множество шишек и грабель :)

Хороший консультант

Не очень хороший консультант

Команда А — условия 3 внешних junior/middle java-разработчика 0 тестировщиков внутри команды разработки 1 ведущий разработчик (он же архитектор приложения и системный аналитик) 1 бизнес аналитик (он же системный аналитик и архитектор решения) Классическая методология (три итерации, несколько команд, большая интеграция, нет официального доступа к заказчику)

Команда А — проблемы Экономия бюджета на внешних разработчиков Попадание в оценки по своей части работ Отсутствие бизнес-экспертизы в команде Архитектурный фундамент для будущего приложения

Команда А — решения Протоканбан (визуализация потока работ, стендапы) Нет итераций / сборки «по требованию» Предварительная проработка требований в backlog Оценка в story points на planning poker Большое покрытие автотестами (unit testing) 100% code review (server code) ведущим разработчиком Внутреннее тестирование силами аналитиков

Команда А — результат Много сделали Высокое качество серверного кода Обогнали другие команды Ошибки в архитектуре и требованиях Сделали ненужное Обогнали другие команды

Команда Б — условия 4..5 внешних разработчиков 2 внешних тестировщика 1 ведущий разработчик / аналитик / архитектор приложения 1 аналитик / архитектор решения 1 системный аналитик Fix date production (от ЦБ РФ) Работа по шаблонам форматов, без тестовой среды от ФНС Почти все работы – в одном приложении (плюс интеграция)

Команда Б — проблемы Fix Date Production Гарантировать качество при доработках Быстро реагировать на изменения

Команда Б — решения Предварительная декомпозиция, приоритезация и экспертная оценка требований Proto kanban (визуализация потока, стендапы) Частые (еженедельные) ретроспективы и релизы в test/uat Максимальная автоматизация интеграционного и системного тестирования (junit, selenium) Интерактивная карта проекта, burndown chart Выкидывание низкоприоритетных и неясных требований «на потом» (с доработкой в промышленном использовании)

Команда Б — результат Вовремя вышли в Production. Несколько быстро решённых проблем (увольнение одного разработчика, перевод пользовательского тестирования с uat-сред на test-среды, и т.п.). Безболезненные доработки в Production. Тех.долг, требующий ручной работы для редких и/или низкоприоритетных ошибок. «Выжатая» команда.

Команда В — условия 2-3 внешних проектных разработчика 3-5 внешних проектных тестировщиков Архитектор, тестлид и scrum master (три человека) на 20% занятости Возможность прямой работы с заказчиком и конечными пользователями Существенные доработки существующих приложений

Команда В — проблемы Отсутствие аналитика Отсутствие экспертизы у членов команды Уложиться в фиксированный бюджет (и, как следствие, срок) Контроль нескольких проектов

Команда В — решения Предварительная оценка с учётом максимального количества задач и рисков. Scrum (спринт = 2 недели), первый день спринта полностью посвящён аналитике и оценке задач(всей командой). Командные инструменты (определение целей и ценностей команды, обучение на старте, групповая и персональная обратная связь) для формирования mindset. Несколько burndown графиков, общая доска. User Story Mapping с участием всех заинтересованных сторон. Перебрасывание людей с проекта на проект для усиления. Командное кросс-ревью всех видов работ (оценки, декомпозиции, аналитики, тест-кейсов, кода и пр.).

Команда В — результат Выход в production на два месяца раньше плана. Высокая автономность команды. Разработка идёт медленнее, чем в предыдущих случаях. Достаточное качество оценок (с 4-5 спринтов). Но можно лучше. :)

Команда Г — условия 40+ разработчиков и аналитиков. Несколько приложений на поддержке. Жёсткий график доработок. Распределённость команды на две локации.

Команда Г — проблемы Инертность и низкая вовлечённость команды, fixed mindset, отсутствие инициативы и автономности в принятиях решений. Деманд, в разы превышающий пропускную способности, необходимость ускоряться без увеличения ресурсов. Ключевое требование — делать всё "наживую", чтобы не проседали на момент изменений ни скорость, ни качество.

Команда Г — решения Канбан (разделение доски по командам на свимлейны, стендапы по очереди). Периодические ретроспективы по разным тематикам (релиз, метрики, технические проблемы). Визуализация в зоне видимости команды CFD. Определение узких мест с участием команды. Вовлечение разных частей команды (ИТ и бизнес-владельцы системы) в один процесс, общие стендапы, тренинги, ретроспективы. «Продажа» новых процессов на длинных (масштаба квартал-год) метриках с положительной динамикой. Использование одной, самой «сильной» части команды в качестве «паровоза» изменений с последующей «продажей» результатов другим подкомандам.

Команда Г — результат Ноль падений прода в процессе внедрения. Отсутствие «проседаний» в скорости. Более комфортная работа Более активное участие команды Автономность процесса изменений (пока вовлечена не вся команда, но сформирована активная группа). Найден способ для 2,5-кратного увеличения скорости без доп. вливаний ресурсов. О-о-очень медленная трансформация. :) Гипертрофированное применение метрик

Алгоритм осознанного agile Выявить спонсоров и заинтересованных лиц. Понять, как всё работает сейчас. Определить проблемы, которые надо решить внедрением agile. Подобрать и внедрить метрики и инструменты. Повторять предыдущие 2 пункта по необходимости (раз в 1-3 месяца).

Резюме

Резюме Внедрение agile необходимо для результата, а не для внедрения agile. Всегда надо плясать от текущих проблем. Осознанность подхода – основа успешных изменений. И ещё раз: agile ради agile – это не agile.

О докладчике Дерюшкин Алексей Викторович a.deryushkin@gmail.com +7-985-362-64-36