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