2. Немного о себе
Антон Наумович
Более 10 лет опыта в IT
● C++ тимлид/ПМ/архитектор в
LogicNow (продукт IASO Backup)
● Консультант в DPI Solutions
● В прошлом – разработчик в
Microsoft (Hyper-V)
● Активист сообщества
COMAQA.BY
3. Что такое крупный проект
Не вдаваясь в методологические споры и
священные войны:
≥ 10 “технарей”
4. Современные методологии
для крупных проектов
Rational Unified Process
>30 ролей
>20 активностей
>70 артефактов
Scaled Agile FrameworkScrum of Scrums
5. Не будем мудрить
Scrum
Если истинно хотя бы
одно из утверждений:
● “Некомпетентный”
заказчик
● Некомпетентный
исполнитель
● Неопределенный или
неформализуемый
домен
Waterfall
Если истинны все
утверждения ниже:
● Компетентный заказчик
● Квалифицированный
исполнитель
● Хорошо
формализованный
домен
7. Полноценный переход
Scrum → Waterfall
Стоит выполнять, когда выполнены все условия:
1. Заказчик стал “компетентным”
2. Исполнитель стал компетентным
3. Домен стал формализованным
Такой переход можно и нужно катализировать, если
он принципиально осуществим
Экономим те самые 20%
8. Ограничения Scrum
Ежедневный митинг: ≤ 15 минут
Итерация: ≤ 4 недель
Размер команды: ≤ 9
Что же делать, если нужно “+1” в
команду, да Scrum-стандарт не велит?
Все ограничения взаимосвязаны
9. Техническое отступление
Microkernel Architecture
Основные свойства
● Разделение на минимальное стабильное “ядро” и
изменчивые “сервисы”
● Адаптация к меняющимся требованиям
● Встроенная поддержка расширений
На практике
● Windows NT
● Symbian
● Mach Operating System
● Amoeba Operating System
● Chorus
10. Microkernel Architecture
Плюсы
● Гибкость
● Расширяемость
● Масштабируемость
● Прозрачность
● Надежность
Минусы
● Производительность (на современном “железе” разница
почти незаметна)
● Сложность дизайна (в книге POSA1 есть четкий
алгоритм декомпозиции)
Pattern-Oriented Software Architecture: Volume 1: A System of Patterns.
11. Почему пример из архитектуры?
Архитектура – один из способов формализовать
внутреннее устройство реальной системы
Архитектура
⇕
Организационная структура организации
⇕
Методология разработки
⇕
Бизнес-анализ
Выберем критерием декомпозиции системы паттерн
Microkernel
12. Разделяй и властвуй
Итак, будем делить систему на:
● “стабильные” части (“ядра”) – их, как правило,
несколько
● “изменчивые” части (“обвеска ядер”)
Цель: выделить стабильные части и
разрабатывать их по Waterfall. По Scrum получим
проблему “инкрементального дизайна”.
Изменчивые части по своей природе непригодны
для разработки по Waterfall
13. Техническая реализация
Изменчивая часть хорошо подходит для реализации через паттерн
Business Rule Engine на основе Domain-Specific Languages (DSL).
DSL – простой язык для решения задачи в одном достаточно узком
домене, например:
● регулярные выражения
● XML, JSON
● SQL
● HTML
● XSLT
● LaTex
● Excel
Парадигма “Расходящаяся разработка” или “Языково-
ориентированное программирование”
15. Что дает DSL?
1. Разделение сложностей на:
○ машино-ориентированную часть кода (низкоуровневую
функциональность)
○ человеко-ориентированную часть кода (собственно
решение прикладной задачи)
2. DSL существенно повышает уровень абстрактности кода
3. DSL исключает экспоненциальный рост результирующей
сложности разработки всего проекта
4. DSL решает проблему сложности как фундаментальную
проблему программирования, описанную Фредериком
Бруксом
16. Пример 1. Биллинг/страхование
Ядро: бизнес-объекты “юр. лицо”, “физ лицо”, предметы
страхования, страховая сумма, налоги и их базовые
отношения. Сам “движок” вычисления страховой суммы.
Обвеска:
● конфигурация правил начисления страховых взносов
● скидки в зависимости от возраста, стажа, объема услуг,
истории сотрудничества
bill = volume * price.PerVolume + instances * price.PerInstance
bill -= bill * price.AnnualDiscount
bill < price.MinimalBill => bill = price.MinimalBill
bill += bill * country.Tax
17. Пример 2. Распределение
данных в облаках
Ядро: “движок” отвечающий за выделение места для
хранения данных в различных датацентрах по миру
Обвеска:
конфигурация движка в зависимости от:
● купленных лицензий
● предпочтений пользователя
● законодательства стран в которых находятся
датацентры
country is Belarus => (Belarus:5, Russia:3, Kazakhstan:2)
country in EU => (Germany:7, France:2, Italy:1)
country in (Asia, Oceania) => (China:8, Indonesia:2)
fallback => (Germany)
18. Что мы имеем в итоге?
● Гибкость архитектуры и методологии
● Универсальный простой критерий
декомпозиции системы
● Разбиение на небольшие команды
● Отсутствие лишнего формализма в работе
● Соответствие методологии технической
части и организационной структуре
● Экономия человекочасов там, где возможно