Содержание слайдов

1. 1. Совершенствование потока разработки ПО

   Пять идеалов для архитектуры, процессов и культуры

2. 2. Александр Поломодов

   Технический директор · архитектура и управление поставкой

   Архитектура помогает локализовать изменения

   Процессы делают движение работы видимым

   Практики и культура превращают улучшение в привычку

3. 3. Четыре книги складываются в одну систему

4. 4. Поток держится на пяти взаимосвязанных идеалах

5. 5. 01. Locality & Simplicity

   Архитектура локализует изменения и сложность

6. 6. Архитектура повторяет коммуникации

   Закон Конвея

   Структура системы отражает связи между командами

   Обратный манёвр

   Спроектируйте команды под желаемую архитектуру

7. 7. Инвестируйте по сложности и отличимости бизнеса

8. 8. Сначала модель — потом паттерны

   Тип поддомена и структура данных определяют следующий выбор

   Core требует предметной модели

   Supporting / Generic допускают простые сценарии

   Число моделей влияет на архитектурный паттерн

   Стратегия тестирования следует за архитектурой

9. 9. Хорошая граница прячет сложность за малым интерфейсом

10. 10. Bounded context — не размер сервиса

    Bounded context ограничивает модель

    Subdomain ограничивает бизнес-возможность

    Aggregate ограничивает транзакцию

    Несколько сервисов могут жить в одном контексте

11. 11. События требуют явных допущений о сбоях

12. 12. Транзакции и аналитика оптимизируются по-разному

    Транзакционная модель

    Предсказуемые запросы

    Согласованность операций

    Аналитическая модель

    Сложные запросы

    Гибкость чтения

13. 13. Data Mesh переносит владение данными в домены

    DWH

    Централизованная команда

    Единое хранилище

    Data Mesh

    Доменные владельцы

    Данные как продукт

14. 14. 02. Focus, Flow & Joy

    Сделайте движение работы видимым

15. 15. Пять похитителей времени разрушают поток

16. 16. Обзор потока отвечает на четыре вопроса

    Сколько работы завершили?

    Сколько времени заняло движение?

    Что и почему заблокировано?

    Какой похититель съел время?

17. 17. Смотрите на распределение, а не на среднее

    Перцентили lead time показывают риск

    Delivery rate показывает темп

    WIP выявляет накопление работы

    Спектр lead time показывает хвост

18. 18. 03. Improvement of Daily Work

    Инженерные практики должны работать каждый день

19. 19. Скорость поставки не требует жертвовать стабильностью

20. 20. Пять принципов непрерывной поставки

    Встраивать качество

    Работать малыми партиями

    Автоматизировать повторяемое

    Улучшать непрерывно · отвечают все

21. 21. Конвейер связывает специалистов общим результатом

22. 22. Работающий код — ещё не хороший дизайн

    John Ousterhout · A Philosophy of Software Design

    Главная цель — создать отличный дизайн, который к тому же работает

23. 23. Платформа выращивает paved road для разработки

24. 24. 04. Psychological Safety

    Культура определяет, что команда делает с ошибками

25. 25. Эффективной команде нужны пять условий

26. 26. Зрелость видна по реакции на плохие новости

27. 27. Разбор инцидента должен менять систему

    Зафиксировать инцидент

    Понять все сопутствующие причины

    Назначить действенные меры

    Снизить вероятность или ущерб повторения

28. 28. 05. Customer Focus

    Результат для клиента важнее объёма выпуска

29. 29. Свяжите бизнес-результат с клиентским потоком

30. 30. Можно идеально построить не то

    Mary Poppendieck · Lean Software Development

    Крупнейшая причина провала программных систем — не технический сбой, а создание неправильного продукта

31. 31. Книги и схемы из оригинала

    IT Revolution: Phoenix · DevOps Handbook · Accelerate · Unicorn

    Learning DDD · A Philosophy of Software Design

    Making Work Visible · Google SRE Book

    Полная подборка: t.me/book_cube/1440

32. 32. Спасибо!

    polomodov.tech

    Слайды, заметки и другие выступления — на сайте

    Александр Поломодов, Технический директор и Fellow, Т-Технологии

    @ai4sdlc