Summary with most interesting presentations of "Agile Days 2016" conference

1. VietnamThailandSingaporePhilippinesMalaysiaIndonesia Russia
Agile Days ’16 Summary

2. Структура презентации
- банковский сектор
- техническая часть
- техническая организационная часть
- организационная часть

3. Банковский сектор

4. Банковский сектор
Кто внедрял аджайл:
• Raiffeisen Bank
• Сбербанк
• Альфа Банк

5. Enterprise. Agile нельзя Waterfall (Сбербанк)
Иерархии и амбиции
-страх потерять место
-страх потерять свою значимость
-неприятие нового подхода
Дурной “корпоративный” тон - 150% загрузки
-резиновые спринты
-переработки
Плохой признак!
Неприятие децентрализации
-убивает мотивацию
-создает бутылочное горлышко

6. Применимость SAFe в фин. организации (Raiffeisen)
- внедрили Scaled-Agile Framework
- сейчас самый актуальный SAFe 4.0 стандарт
• Business Requirements Documents (BRD)
• User Story Mapping
10.5 мес -> 6 мес.
Периодичность релизов

7. Техническая часть

8. Enterprise. Agile нельзя Waterfall (Сбербанк)
• SAFe базируется поверх Scrum/XP
• Максимально тестировать все в dev-
среде (не дожидаясь test-среды)
• Github - verigreen

9. Digital, Agile, DevOps, микросервисы
Digital - не надо общаться с людьми, чтобы
получить услугу. Пример: carsharing, gettaxi
В схеме технологических компаний отсутствует
операционный уровень. У них нет прямого
контакта с клиентами в офисе. Пример: yandex

10. Технологическая компания
Цель:
сокращать time
to market

11. Автоматизация vs Цифровизация
vs
• проигрывает музыку
• держит аудио картотеку
• следит что слушают друзья
• предлагает новинки

12. Автоматизация vs Цифровизация

13. Новый IT
• сетевая организационная структура компании
• большое количество взаимодействия
• бешеная скорость взаимодействия
• в operations - devops - скорость изменений предельная
• в разработке - agile - скорость разработки предельная
• сетевые технологии распределенные
• железные сервера уходят, появляются облака

14. Архитектура
Application
Middleware
Database

15. Микросервисы
- самодостаточен и изолирован
- один сервис - одна agile-команда
- API
- build, release, run
- сервис становится автоматически обнаруживаемый
для других сервисов

16. Docker
- не система контейнеризации
- не система виртуализации
- Docker - система автоматизации поставки ПО
- Docker - замах стать целой эко-системой

17. Микросервисы
• Datacenter Operating System
• Service Discovery - знает, какие сервисы должны быть
запущены
• CI - собирает docker-контейнеры
• новые языки, меньше ООП, функциональные языки

18. Частые проблемы
• монолит пытаются перевести на continuous delivery
• трехзвёнка (app, middle, db) в цифровом проекте
• agile, devops для нецифрового бизнеса

19. Техническая и организационная часть

20. DDD (smart step group)
• Ubiquitous language
• Bounded Context

21. Проектирование по модели
Классический процесс:
• проектирование архитектуры начинается с
проектирования базы данных. Так, там будет табличка
заказы, товар, покупатель…
• архитектура кода - от архитектуры БД

22. Проектирование по модели
Путь DDD:
• спроектировать объектную модель
• Persistence Ignorance
• технические специалисты + эксперты предметной
области
• написание кода по модели
• проектирование инфраструктуры (бд, таблички)

23. Ubiquitous Language
• DeleteAllLines
• SetStatus(Status.Approved)
• CreateUser
• Customer.Address = new
Address();
• CancelOrder
• Approve
• EnrollCustomer
• Customer.RelocateTo(new
Address());

24. Bounded Context (ограниченный контекст)
one model to rule them all
маленькие под-модели
применительно к контексту

25. Как разделять контексты
Пример: интернет-магазин, 4 контекста:
- для покупателя
- для продажников
- для поставщика
- для бухгалтерии
1. В рамках одного проекта - 4 папки применительно к
каждому контексту
2. Разделять контексты по базам данных, по модулям
3. Разбивать контексты по сервисам

26. Как разделять контексты
• Важно определить главный контекст, и именно вокруг него будет
строиться предметная область (core domain)
• Физически разделять контексты
• Anti-Corruption Layer у сервисов
• Заказчик должен быть доступен
• Итеративная модель разработки
Там, где объектная модель не подходит, используем:
- events
- CQRS
- функциональное программирование

27. Поток поставки (DevOps)
Официант в кафе не приносит все блюда сразу!

28. Бережливое производство
Поток ценности:
- идея и дизайн
- разработка
- стенд
- качество (QA)
- выкладка
ценность
потери
Объявите войну
потерям!

29. Магическая формула
• Посадите их вместе
• дайте им полномочия и права
• пусть возьмут ответственность

30. Непрерывная поставка
Необходим continuous delivery!
dev -> CI process -> staging -> tests -> deploy
50% features have never been used
Надо быстро проверять свои гипотезы!

31. Непрерывная поставка
Post-coordination
- code review
- feature branches
Pre-coordination
- design sessions
- pair programming
- only trunk (коммитим в одну ветку)

32. По опросам ведущих 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

33. Стейджинг
инвестиции в стейджинг всегда оправданы!
кнопка “превратить staging в prod”
репетиция деплоя на staging

34. Release process
Blue Green Deployment:
Canary releases:

35. Обязательно
• Monitoring
• Log aggregation
• Alerting

36. Организационная часть

37. Топ 10 не могу (Аутсорсинговая компания)
1. Я видимо читал не ту версию ТЗ
2. А это Андрей в курсе, это он с заказчиками говорил
3. Мы решили переписать ядро на Java
4. Было много задач, не успели протестировать (Тестирование
всегда нужно!)
5. В задаче этого не сказано
6. Она была так настойчива (Заказчик, которые постоянно пушит)
7. Проще сделать самому, чем учить (Отсутствие кадрового
потенциала)
8. Завтра приемка? А Иван уже уехал домой (Проблема
приверженности, отсутствие командного духа)
9. А где можно об этом почитать?
10. Не хватило времени (Неверное планирование работ)

38. Топ 10 не могу (Аутсорсинговая компания)
Пути решения:
- описание бизнес-процессов
- единое информационное пространство
- автоматизация производства
- мотивация на результат
- обучение/подготовка кадров

39. Роль вирусов в поедании слонов
Три слагаемых успешной стратегии:
1. евангелизм, а не внедрение
2. искать возможность, есть по частям
3. зрелость процессов и команд

40. Вирусный подход
• нельзя внедрять административно
• заинтересованность и готовность от участников

41. Внедрение по частям
• “все или ничего” под запретом
• не стоит пытаться охватить все сразу, брать по частям

42. Разработка проекта
• Impact mapping
• Customer journey map
• User Story mapping
• UX/UI прототипы
• разработка
• QA
• выпуск

43. Провал предыдущих команд
• жесткий вотерфолл
• описали требования и ушли в работу
• требования не вынесли испытания
реальностью
• созданной системой невозможно
пользоваться
слабая обр.
связь
результат
слабой обр.
связи

44. Простые практики в сложных условиях
• демо без слайдов
• от лица пользователя
Демо:
• регулярные
• работающий продукт
• ранняя интеграция

45. Процесс разработки
Межкомандное планирование релиза:
• use cases по командам
• release board
• межкомандные стендапы
Архитектурные сессии:
- командные 1р/неделю (1-2 часа)
- межкомандные 1-3р перед планированием
(присутствие всех участников)
Рисуем маркером на флипчарте, чтобы увидеть всего слона в
целом!

46. С чего начать борьбу
• демо
• введение демо снизу-вверх
• межкомандные планирующие сессии
• межкомандные архитектурные сессии
• работать в командах
Распределенные команды:
• skype с видео (эффект присутствия)
• парное программирование

47. Как не уснуть на ретро
Боль:
- скучное ретро
- затянутое ретро
- распределенная команда

48. Как не уснуть на ретро
Решение боли:
- Amazon Review
- кино отзывы
- Poster Session
ключевое событие
нарисовать кто выиграл?
кто проиграл?
- Speed Dating
- The worst we could do
диверсия
контрмера

49. Вопросы
Жуков Антон