Бизнес требует от ИТ постоянно ускорять обороты. Сроки выхода на рынок постоянно сокращаются.
Применение гибких методологий в небольшой команде позволяет значительно уменьшить Time-to-Market.
Однако в крупной компании прямое использование Agile/Scrum затруднено: даже простое на первые взгляд изменение бизнес процесса может затрагивать несколько систем, за которые отвечают разные команды. Выпуск релиза приходится координировать с большим количеством заинтересованных лиц. Это сильно замедляет и проектирование и финальное интеграционное тестирование. В результате добиться снижения Time-to-Market кажется очень непростой задачей, осложненной к тому же непростой политической ситуацией, типичной для крупной организации.
Мы поговорим о системном подходе к снижению Time-to-Market для сложных задач координации релиза, характерных для крупных организаций
8. Почему может быть долго?
Продукт
Очередь здесь
Ждет начала
работы
Очередь здесь
С начала работы до
окончания
9.
10. Закон Литтла
• Среднее время ожидания = размер
очереди / скорость обслуживания
• Lead Time = WIP / Average Completion Rate
200 человек / 20 чел в час = 10 часов
21. Scrum и Kanban
• Таймбокс • WIP Limit
Очередь Разработка Тест Готово
3 2
Готово
22. Разбиение работ на
Пользовательские Истории
Интеграция с онлайн-банком
Свободный платеж
Оплата мобильного телефона
Оплата ЖКХ
База данных Server Side Front end
30. Service Team, Functional
Teams
• Service Team
– Помогает другим командам
– Не несет прямой ценности пользователю
– Заказчики — другие команды
• Functional Team
– Команда специалистов сходной
компетенции
31. Flow
Design
Web
WinPhone iOS Android
Core Lib
Backend
Video Encoding
Testing
40. Теория ограничений
• Identify. Определить ограничение
• Exploit. Использовать по максимуму
• Subordinate. Подчинить работу
ограничению
• Elevate. Расширить ограничение по
максимуму
41. Identify
Type I
• Быстрая реакция
• Работа на
пределе,
переработки
• Некогда улучшать
качество
Type II
• Долгие ожидания
результата
• Длина очереди
заявок со стороны
других команд
Type III
• Долгая реализация
42. Exploit
• Передать все
работы, которые
возможно, другим
командам
• Освободить от
лишних митингов,
добавить PM для
административной
работы
50. Узкое место может
измениться
• Фича может затронуть
любое количество
команд
• «Путь» фичи через
команды может быть
различным
• Количество фич разного
типа меняется
52. Releases и Portfolio Kanban
• Короткие релизы • WIP Limit
Очередь Business Case Development Готово
Готово
Список
фич
Релиз
53. Tiger Team
• Временная
• Команда
формируется вокруг
таска
• Небольшая
• Сложнее
балансировать
• Проще набрать
Feature Team
• Постоянная
• Таски выдаем
команде
• Крупная
• Проще
балансировать
нагрузку
• Сложнее набрать
54. 4 keystone habits (by Ahmed
Sidky)
1. Коммуникации и
взаимопомощь
2. Поставлять
эволюционными
улучшениями
3. Интегрировать как можно
раньше
4. Собирать обратную связь
на всех уровнях как можно
раньше
56. Специальные роли
• Subject Matter Expert
– Консультант
– Присоединяется где нужен
• System Owner
– Отвечает за качество и целостность
компонента
57. Summary
• Functional Team
• Feature Team
• Tiger Team
• Service Team
• Virtual Team
• SME
• System Owner
Очередь Разработка Интеграция Готово
В
работе
Готово
Очередь Разработка Ревью Готово
3 2
Готово
Концепт
Доска задач продукта
Очередь Разработка Ревью Готово
3 2
Готово
Очередь Разработка Ревью Готово
3 2
Готово
Доски команд