Несколько историй внедрения гибких методологий разработки в различных командах АО Райффайзенбанк.

1. От каждого по
потребностям, каждому
— по agile
Дерюшкин Алексей
Agile Coach, АО «Райффайзенбанк»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

39. Резюме

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

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