разработка собственной Agile методологии для управления...

Разработка собственной 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)

Что мы имеем в итоге?

● Гибкость архитектуры и методологии

● Универсальный простой критерий

декомпозиции системы

● Разбиение на небольшие команды

● Отсутствие лишнего формализма в работе

● Соответствие методологии технической

части и организационной структуре

● Экономия человекочасов там, где возможно

Антон Наумович

naumovich@dpi.solutions

DPI Solutions

www.dpi.solutions

Belarus QA Automation Community

www.comaqa.by

Спасибо! Вопросы?