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

диверсияконтрмера

Вопросы

Жуков Антон