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

1. Антон Немчинов
РайффайзенБанк

2. Зачем нужно внедрять гибкие практики разработки?

3. 1960ые
Раз в 10 лет
2010ые
Каждые 2-3
месяца
1980ые
Каждые
2-3 года

4. При постоянном увеличении скорости
и высокой конкуренции на рынке
классические методы управления
разработкой становятся…
Узким горлом

5. • Наделенная
полномочиями
• Самомотивированная
• Кросфункциональная
• Нацеленная на
постоянное
усовершенствования
• Команда из 6-8 участников
• Владелец продукта постоянно
доступен для обратной связи
• Удачные примеры внедрения чаще
всего встречаются в компаниях
выпускающие продукты для
конечных пользователей

6. Внедрение Kanban и гибких практик разработки
в агрессивной среде крупной организации
История базируется на реальных событиях

7. • 20-30 человек
• Очень хочет быть
эффективнее
• Хочет стать бизнесу
партнером
• Сократить Time to Market
• Находится под
распределённой
трансформацией
Команда

8. Бизнес Заказчик
• Тоже хочет быть
эффективным
• Наивысший приоритет -
её KPI
• Не вовлекается в
развитие продукта
• Считает, что все
происходить очень
медленно

9. • Имеет те же цели, что и
Команда
• Верит в «железный
треугольник»
• Чувствует себя комфорта,
когда контролирует все и всех
• Есть свои KPI. Изменение
параметров проекта -1 в карму
• Планирование работ =
commitment
Руководитель проектов

10. Мы уже пытались работать по Agile, но
ничего не вышло
Мы не знаем по чему
У нас нет времени
В этой организации это не возможно
Давайте внедрять Agile!
Кто за?

11. Конец

12. Конец?

13. Почему команде не удалось даже
начать?
• У нас все отлично. Зачем что-то менять?
• Даже если кто-то голосует «ЗА», то делает это эмоционально
или под влиянием. В итоге, до дела тоже не доходит
• У отдельных членов команды есть устойчивое
сопротивление, вызванное ранее не удачным опытом
• Команде нужно помощь

14. • Это проектная команда
• Внутренние сотрудники
• Внешние консультанты
• Линейные руководители
так же являются
членами проектной
команды
• Все остальные активно
участвуют
Agile Coach

15. Ребята, Agile - это круто
Зачем???

16. • Показать команде, что изменения
назрели
• Помочь команде «подсветить» ключевые
проблемы
• Для этого собрать информацию, сделать
анализ и выявить ключевые зоны
развития
• В итоге, дать команде определить самой
с чего начать

17. Коммуникации Планирование Изменение скоупа
Зоны развития

18. • Канбан доска
• Общий бэклог
• Многоуровневое планирование
• Приоретизация и оценка требований
• 2-х недельные итерации
• Метрики
• Continues integration
• Continues improvement

19. Мы задерживаем релиз
Нам нужно назвать новые сроки
Мы опять не попали в сроки…
Заказчик эскалирует проблему и
увеличивает давление на команду

20. Вы в планах на следующий год

21. • Ты будешь управлять нашим
бэклогом
• Ты сможешь говорить что и
когда тебе нужно
• Но ты должна быть доступна
для быстрой обратной связи
• У нас будут 2-х недельные
итерации
• И мы будем строить свои
планы на исторических оценках

22. • Повышена прозрачность потоков
работы для команды и заказчиков
• Больше не страшны не детальные
требования. Команда и заказчик
научились общаться
• Команда доставляет самое важное в
начале, тем самым сократив Time to
Market
• Собираемые метрики позволяют
планировать точнее и быстрее
реагировать на события

23. Прошло 2-3 месяца…

24. Команда, у вас проблемы!
0
15
30
45
60
75
April May June July
WIP
Cycle-Time

25. Анализ ситуации
• В мае команда начала декомпозировать задачи
• Предыдущий релиз принес много инцидентов
• Заказчик стал активнее накидывать задачи
• Закон Литтла сработал во весь рост
• Команда демотивирована

26. WIP лимиты

28. • Имеет те же цели, что и
Команда
• Верит в «железный
треугольник»
• Чувствует себя комфорта,
когда контролирует все и всех
• Есть свои KPI. Изменение
параметров проекта -1 в карму
• Планирование работ =
commitment
Руководитель проектов

29. Мне нужены оценки сроков для плана
и вы должны закомититься
???

30. • Команда хорошо умеет
планировать не более чем на 3
месяца
• Развести задачи команды и
проекты помогают квоты
• Опыт команды подсказывает ей,
что в ходе проекта многое может
поменяться

31. • Оценки нужны для бюджета
• Ему нужны комиты, потому, что от
него требуют точных оценок в
начале проекта
• Изменения негативно влияют на
KPI
• PMBOK guide позабыт…

32. 0
23
45
68
90
113
1 месяц 2
месяца
3
месяца
4
месяца
5
месяцев
6
месяцев
7
месяцев
8
месяцев
9
месяцев
10
месяцев
11
месяцев
12
месяцев
Индекс вероятности

33. Подведем итог

34. • Распределенная трансформация имела положительное влияние
• Мы не внедряем Agile. Мы внедряем тип мышления и подход к
работе.
• Agile, Kanban, SCRUM, Lean и т.п. всего лишь инструменты
• Внедрение идет снизу в вверх при полной поддержки руковдства
• Успешность таких трансформация тяжело измерить
• А еще, люди очень долго меняются. Запаситесь терпением.

35. Спасибо!
LinkedIn: https://ru.linkedin.com/in/anemchinov
Email: Anton.Nemchinov@raiffeisen.ru