Slide 1
Slide 1 text
Антихрупкость в IT
Как полюбить изменения
май, 2023
Slide 2
Slide 2 text
● Владелец и IT-архитектор Byndyusoft
● Методолог, эксперт в Agile и Lean
● Спикер на профессиональных IT-
конференциях
● Преподаватель в ВУЗах
● Автор книги «Антихрупкость в IT»
https://byndyu.ru
Александр Бындю
Slide 3
Slide 3 text
Любит ли кружка изменения? Нет.
Становятся ли она сильнее после
изменений? Нет, потому что она
хрупкая, изменения ее разрушают.
Кружка не хочет изменений, она
старается их избегать.
Slide 4
Slide 4 text
Любят ли бактерии изменения?
Вряд ли, потому что многие
погибают.
Становятся ли они сильнее после
изменений? Да.
Бактерии не стараются избежать
изменений.
Эволюцию устойчивых к антибиотикам «супербактерий»
воспроизвели в миниатюре
https://nplus1.ru/news/2016/09/09/megapetridish
0 0
1 1
10 10
100 100
1000
Slide 5
Slide 5 text
Тезисы из мира IT
1. Если на переменах ваш IT-продукт больше
зарабатывает, чем теряет, вам будет хотеться перемен.
В обратном случае обратный эффект.
2. В IT-системе, работающей на пределе возможностей
(качество кода, качество архитектуры, качество
автоматизации,...) и поэтому хрупкой, малейшие
перемены ведут к непредсказуемым последствиям.
3. Хрупкость равно нелюбовь к случайности.
4. Нелюбовь к случайности означает повышенные риски
при неминуемых изменениях.
Slide 6
Slide 6 text
No content
Slide 7
Slide 7 text
No content
Slide 8
Slide 8 text
Какими свойствами должно обладать ПО, процесс и
разработчики, чтобы можно было постоянно делать
повороты?
Slide 9
Slide 9 text
Аксиома:
Вашу систему будут
постоянно менять.
Slide 10
Slide 10 text
Безопасно
и дешево
вносить
изменения
Направления для исследования
антихрупкости в IT:
1. Процессы: ТЗ, инструменты
управления
2. Внутреннее качество IT-систем
3. Отношения Заказчик–
Исполнитель
4. Люди
5. Бизнес
Slide 11
Slide 11 text
1. Процессы
Slide 12
Slide 12 text
Жесткое ТЗ пытается
законсервировать
случайность.
Как следствие, изменения
(случайности) будут
разрушать процесс и систему.
Изменения точно произойдут,
значит всегда будут жертвовать
качеством.
Техническое задании:
методология, риски, ограничения,
варианты оформления
Slide 13
Slide 13 text
ТЗ, которое полюбило случайности
Slide 14
Slide 14 text
Должна быть
визуализация целей
и гипотез, готовая к
изменениям
Заказчики и исполнители:
1. Понимают зачем создаётся IT-
продукт.
2. Принимают бизнес-цели и готовы
взяться за их достижение.
3. Понимают стратегию достижения
результата и приоритеты.
4. Понимают критерии успешности
IT-продукта.
Мастер-класс по нюансам Impact
Mapping
Slide 15
Slide 15 text
1. Целостное видение IT-
продукта.
2. Точки входа, точки выхода и
переходы пользователей.
3. Линии жизни действующих
лиц и точки их
взаимодействия друг с
другом.
Схематизация опыта с CJM и
Service Blueprint. Практика
гибридной нотации
Должна быть
визуализация
клиентского опыта,
готовая к изменениям
Slide 16
Slide 16 text
Должна быть
визуализация функций
системы, готовая к
изменениям
1. Понимание ценности каждой
истории.
2. Визуализация приоритетов.
3. Описание функций системы.
4. Удобная нарезка релиза.
Руководство по сбору требований
в формате User Story Mapping
Slide 17
Slide 17 text
1. Отклоняться от курса можно и нужно, когда это необходимо.
2. Сохраняем открытость к изменениям.
3. Метод управление вторичен, главное, чтобы была дешевая
коммуникация (Kanban, Scrum).
Slide 18
Slide 18 text
Бюджетирование,
готовое к изменениям
1. Объем работы обговаривается в начале
проекта, но является предметом для
изменения.
2. Всё самое важно успеть к сроку.
3. Глубина проработки задач и конечный
список этих задач могут менять во время
работы.
4. Риски делятся поровну между
разработчиками и заказчиком.
5. Внутреннее качество системы становится
очень важным. Поэтому код, тесты,
внутренний дизайн, архитектура и
автоматизация должны быть высокого
качества.
Управление проектом по Fix Time, Fix Budget,
Flex Scope (FFF)
Slide 19
Slide 19 text
2. Внутреннее качество
IT-систем
Slide 20
Slide 20 text
IT-продукты внутри должны быть устроены
так, чтобы изменения в продукте
воспринимались не как проблема, а как
возможность к росту.
Slide 21
Slide 21 text
Управление сложностью
Целенаправленный и постоянный вклад в
управление сложностью:
1. Постоянный рефакторинг кода и
архитектуры для соответствия новым
реалиям бизнеса и нашим знаниям о
системе.
2. Тотальное автоматизированное
тестирование: модульные, нагрузочные,
e2e… тесты.
3. Дробление систем на много мелких
сервисов, чтобы их было удобно
пересобирать в новые логические
структуры.
4. Тотальная автоматизация
инфраструктуры и оценки внутреннего
качества.
Slide 22
Slide 22 text
Микросервисы
Как выбрать IT-архитектуру: от
хаоса до микросервисов
https://blog.byndyu.ru/2020/04/it.ht
ml
Эволюция архитектуры
https://blog.byndyu.ru/2020/04/blog
-post_14.html
Скрытые расходы при переходе на
микросервисы
https://blog.byndyu.ru/2020/12/blog
-post.html
Slide 23
Slide 23 text
3. Отношения Заказчик-
Исполнитель
Slide 24
Slide 24 text
Отношения между заказчиком и
исполнителем должны включать в себя
любовь к изменениям.
Slide 25
Slide 25 text
No content
Slide 26
Slide 26 text
No content
Slide 27
Slide 27 text
4. Люди, которые
строят антихрупкое
ПО
Slide 28
Slide 28 text
Научился печатать код, а что дальше?
Зачем этот код? Кому это всё
надо?
Надо вникать в бизнес, уметь
отвечать на вопрос «чтобы
что?» и понимать каким
образом разработка может
помочь бизнесу.
Slide 29
Slide 29 text
Принимаем осознанные решения
Кнопочное мышление против целостного IT-продукта
Slide 30
Slide 30 text
Доверие – дешевая коммуникация
В квадрате В самая дешевая
коммуникация.
При внешних изменениях это дает:
1. Скорость перестройки в
понимании IT-продукта и
траектории его развития
2. Скорость перестройки
процессов
3. Скорость перестройки
архитектуры и кода
Slide 31
Slide 31 text
Основа для отношений
Заказчик-Исполнитель
Slide 32
Slide 32 text
Характеристики людей,
которые становятся сильнее
от изменений
1. Инженеры, которых хотят использовать
свои головы, а не только руки.
2. Мотивированная и
высококвалифицированная команда, а
значит дорогая.
Считайте заранее будет ли это выгодно в
вашем случае.
3. Высокая вовлеченность Заказчика,
который готов тратить на взаимодействие
свои ресурсы.
Slide 33
Slide 33 text
5. Бизнес
Slide 34
Slide 34 text
Книга «Теория ограничений. Основные подходы, инструменты и решения», Дмитрий Егоров
«Матрица изменений» Голдратта
Slide 35
Slide 35 text
Не любят и не принимают
изменения, даже в ущерб себе
Slide 36
Slide 36 text
Любят и хотят изменений
Slide 37
Slide 37 text
Сколько стоит антихрупкость?
Сравнить ценность достижения бизнес-цели и
накладные расходы.
“Накладные” расходы:
1. Выстраивание процессов и использование
инструментов
2. Вкладывание в управление сложностью и
внутреннее качество IT-систем
3. Выстраивание отношений Заказчик–
Исполнитель
4. Подбор и обучение сотрудников
5. Работа на уровне бизнеса для поддержания
открытости к изменениям
Slide 38
Slide 38 text
Шансы
на успех
Slide 39
Slide 39 text
Давайте вместе собирать практики!
Направления для исследования
антихрупкости в IT:
1. Процессы: ТЗ, инструменты
управления
2. Внутреннее качество IT-систем
3. Отношения Заказчик–Исполнитель
4. Люди
5. Бизнес
Присылайте мне ваши мысли на эту
тему.
0 0
1 1
10 10
100 100
1000
Slide 40
Slide 40 text
Ссылки
1. Сайт книги «Антихрупкость в
IT»
2. Как стать антихрупким, работая
в IT. Интервью с Хекслет.
Slide 41
Slide 41 text
Спасибо за внимание!
Есть вопросы?
Бындю Александр,
IT-архитектор
Byndyusoft
Обратная связь
по докладу