agile days `16 summary
TRANSCRIPT
VietnamThailandSingaporePhilippinesMalaysiaIndonesia Russia
Agile Days ’16 Summary
Структура презентации
- банковский сектор- техническая часть- техническая организационная часть- организационная часть
Банковский сектор
Банковский сектор
Кто внедрял аджайл: • Raiffeisen Bank • Сбербанк • Альфа Банк
Enterprise. Agile нельзя Waterfall (Сбербанк)
Иерархии и амбиции-страх потерять место-страх потерять свою значимость-неприятие нового подхода
Дурной “корпоративный” тон - 150% загрузки-резиновые спринты-переработкиПлохой признак!
Неприятие децентрализации-убивает мотивацию-создает бутылочное горлышко
Применимость SAFe в фин. организации (Raiffeisen)
- внедрили Scaled-Agile Framework- сейчас самый актуальный SAFe 4.0 стандарт
• Business Requirements Documents (BRD)
• User Story Mapping 10.5 мес -> 6 мес.
Периодичность релизов
Техническая часть
Enterprise. Agile нельзя Waterfall (Сбербанк)
• SAFe базируется поверх Scrum/XP• Максимально тестировать все в dev-
среде (не дожидаясь test-среды)• Github - verigreen
Digital, Agile, DevOps, микросервисы
Digital - не надо общаться с людьми, чтобы получить услугу. Пример: carsharing, gettaxi
В схеме технологических компаний отсутствует операционный уровень. У них нет прямого контакта с клиентами в офисе. Пример: yandex
Технологическая компания
Цель: сокращать time
to market
Автоматизация vs Цифровизация
vs
• проигрывает музыку• держит аудио картотеку • следит что слушают друзья • предлагает новинки
Автоматизация vs Цифровизация
Новый IT
• сетевая организационная структура компании • большое количество взаимодействия • бешеная скорость взаимодействия • в operations - devops - скорость изменений предельная • в разработке - agile - скорость разработки предельная • сетевые технологии распределенные • железные сервера уходят, появляются облака
Архитектура
ApplicationMiddlewareDatabase
Микросервисы
- самодостаточен и изолирован
- один сервис - одна agile-команда
- API
- build, release, run
- сервис становится автоматически обнаруживаемый
для других сервисов
Docker
- не система контейнеризации
- не система виртуализации
- Docker - система автоматизации поставки ПО
- Docker - замах стать целой эко-системой
Микросервисы
• Datacenter Operating System
• Service Discovery - знает, какие сервисы должны быть запущены
• CI - собирает docker-контейнеры• новые языки, меньше ООП, функциональные языки
Частые проблемы
• монолит пытаются перевести на continuous delivery• трехзвёнка (app, middle, db) в цифровом проекте• agile, devops для нецифрового бизнеса
Техническая и организационная часть
DDD (smart step group)
• Ubiquitous language• Bounded Context
Проектирование по модели
Классический процесс: • проектирование архитектуры начинается с проектирования базы данных. Так, там будет табличка заказы, товар, покупатель…
• архитектура кода - от архитектуры БД
Проектирование по модели
Путь DDD:• спроектировать объектную модель• Persistence Ignorance• технические специалисты + эксперты предметной области
• написание кода по модели• проектирование инфраструктуры (бд, таблички)
Ubiquitous Language
• DeleteAllLines
• SetStatus(Status.Approved)
• CreateUser
• Customer.Address = new
Address();
• CancelOrder
• Approve
• EnrollCustomer
• Customer.RelocateTo(new
Address());
Bounded Context (ограниченный контекст)
one model to rule them allмаленькие под-модели
применительно к контексту
Как разделять контексты
Пример: интернет-магазин, 4 контекста:- для покупателя- для продажников- для поставщика- для бухгалтерии
1. В рамках одного проекта - 4 папки применительно к каждому контексту2. Разделять контексты по базам данных, по модулям3. Разбивать контексты по сервисам
Как разделять контексты
• Важно определить главный контекст, и именно вокруг него будет строиться предметная область (core domain)
• Физически разделять контексты• Anti-Corruption Layer у сервисов
• Заказчик должен быть доступен• Итеративная модель разработки
Там, где объектная модель не подходит, используем:- events- CQRS- функциональное программирование
Поток поставки (DevOps)
Официант в кафе не приносит все блюда сразу!
Бережливое производство
Поток ценности:- идея и дизайн- разработка- стенд- качество (QA)- выкладка
ценность
потери
Объявите войну потерям!
Магическая формула
• Посадите их вместе
• дайте им полномочия и права
• пусть возьмут ответственность
Непрерывная поставка
Необходим continuous delivery!
dev -> CI process -> staging -> tests -> deploy
50% features have never been used
Надо быстро проверять свои гипотезы!
Непрерывная поставка
Post-coordination- code review- feature branches
Pre-coordination- design sessions- pair programming- only trunk (коммитим в одну ветку)
По опросам ведущих DevOps инженеров
VCS мордочки- github 70%- bitbucket 20%- gitlab 8%
CI сервера- jenkins 56%- TC 28%- Travis 16%
Conf. management- ansible 50%- docker 26%- bash 23%- chef 20%- puppet 5%- soldstack 5%
Virtualise your infrastructure- virtualisation- containers- clouds
Logs- logstash
Платформы- kubernetes- heroku- mesos- helios
Monitoring- zabbix
Стейджинг
инвестиции в стейджинг всегда оправданы!
кнопка “превратить staging в prod”
репетиция деплоя на staging
Release process
Blue Green Deployment:
Canary releases:
Обязательно
• Monitoring
• Log aggregation
• Alerting
Организационная часть
Топ 10 не могу (Аутсорсинговая компания)
1. Я видимо читал не ту версию ТЗ2. А это Андрей в курсе, это он с заказчиками говорил3. Мы решили переписать ядро на Java4. Было много задач, не успели протестировать (Тестирование
всегда нужно!)5. В задаче этого не сказано6. Она была так настойчива (Заказчик, которые постоянно пушит)7. Проще сделать самому, чем учить (Отсутствие кадрового
потенциала)8. Завтра приемка? А Иван уже уехал домой (Проблема
приверженности, отсутствие командного духа)9. А где можно об этом почитать?10. Не хватило времени (Неверное планирование работ)
Топ 10 не могу (Аутсорсинговая компания)
Пути решения:- описание бизнес-процессов- единое информационное пространство- автоматизация производства- мотивация на результат- обучение/подготовка кадров
Роль вирусов в поедании слонов
Три слагаемых успешной стратегии:
1. евангелизм, а не внедрение
2. искать возможность, есть по частям
3. зрелость процессов и команд
Вирусный подход
• нельзя внедрять административно
• заинтересованность и готовность от участников
Внедрение по частям
• “все или ничего” под запретом
• не стоит пытаться охватить все сразу, брать по частям
Разработка проекта
• Impact mapping• Customer journey map• User Story mapping• UX/UI прототипы• разработка• QA• выпуск
Провал предыдущих команд
• жесткий вотерфолл• описали требования и ушли в работу
• требования не вынесли испытания
реальностью• созданной системой невозможно
пользоваться
слабая обр. связь
результатслабой обр. связи
Простые практики в сложных условиях
• демо без слайдов• от лица пользователя
Демо:• регулярные• работающий продукт• ранняя интеграция
Процесс разработки
Межкомандное планирование релиза:• use cases по командам• release board• межкомандные стендапы
Архитектурные сессии:- командные 1р/неделю (1-2 часа)- межкомандные 1-3р перед планированием
(присутствие всех участников)
Рисуем маркером на флипчарте, чтобы увидеть всего слона в целом!
С чего начать борьбу
• демо• введение демо снизу-вверх• межкомандные планирующие сессии• межкомандные архитектурные сессии• работать в командах
Распределенные команды:• skype с видео (эффект присутствия)• парное программирование
Как не уснуть на ретро
Боль:
- скучное ретро
- затянутое ретро
- распределенная команда
Как не уснуть на ретро
Решение боли:- Amazon Review- кино отзывы- Poster Session
ключевое событиенарисовать кто выиграл?кто проиграл?
- Speed Dating- The worst we could do
диверсияконтрмера
Вопросы
Жуков Антон