Решение конфликтов в процессе проектирования сложных...

Девятая независимая научно-практическая конференция «Разработка ПО 2013»23 - 25 октября, Москва

Дзюба Дмитрий

Фаза проектирования

без конфликтов

«Энвижн – Программные решения»

NVision Group

«Энвижн – Программные решения»

R&D - центр «Прага»

R&D - центр «Москва»

Москва

Санкт - Петербург

HQ Дивизиона

R&D – центр «Краснодар»

Краснодар

R&D – центр «СПБ»

R&D – центр «Минск»

Центры компетенции:

• Россия: Нижний Новгород, Екатеринбург, Новосибирск, Владивосток

• Украина: Киев

• Индия: Мумбай, Ченнай

• Пакистан: Лахор

IVRCRMPortal

Self care

Inter-connect billing

Work Flow

Media-tion

Billing

SCP

IN plat-form

Resource Inven-tory

Clea-ringHouse

Service Provisionin

g

Monitoring

Bonus Management system

Pay-ment system

Reports

Trouble ticketing

BUS

Наши продукты

Наши клиенты

Россия

Чехия Пакистан

Украина

Беларусь Более 150 млн.

абонентов

Более 5 млн.

платежей в сутки

5 тыс. соединений в

секунду

Индия

У нас есть проекты

Протяженные по времени

проекты

Большое количество

разрабатываемых систем

Даже первая итерация

достаточно трудоемкая!

У проектов бывает заказчик

При разработке

продукта приходится

учитывать

множественные,

иногда

требования заказчиков.

Мы работаем

в распределенной команде

Состав команды:

20+ человек

Территориальная

распределенность

(разные города и

страны)

Для общения

используются

несколько языков

Мы делаем системы

класса

К системе предъявляются

высокие требования

по надежности и

производительности

Неработоспособность

системы - угроза бизнесу

компании.

пристального внимания:

качество проектирования продуктов

Непрерывная проверка

качества решения

на всех этапах

разработки.

Факторы,

усложняющие командную работу

Географическая удаленность членов команды

Языковой барьер

Фаза проектирования стимулирует создание

формальных документов.

Общение становится более формальным!

Бесконечные переписки

Невозможность выбора лучшего решения

Команда делится на «группы»,

отстаивающие свои варианты.

:

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

Конфликты внутри команды.

Причины проблемы

Споры: кто более опытный специалист?

Ролевой конфликт в команде.

Обида за напрасный труд.

Чужой дизайн: тяжело понять (языковой барьер)

и тяжело принять (самолюбие).

Подход к решению задачи

Agile-манифест

Люди и взаимодействие

важнее процессов и инструментов

Работающий продукт

важнее исчерпывающей документации

Сотрудничество с заказчиком

важнее согласования условий контракта

Готовность к изменениям

важнее следования первоначальному

плану

14

Lightweight Architecture Alternative

Assessment Method (LAAAM)

http://blogs.msdn.com/b/jeromyc/archive/2005/08/27/45

7081.aspxJeromy Carriere's WebLog

http://www.infoq.com/news/2011/07/low-ceremony-architectureManuel Pais

Начало: все против

• Нужно время – хотя бы три или пять дней, а мы и

так уже отстаем от плана …

• Метод ничего не гарантирует!

Люди и взаимодействие

Kansas City Shuffle

Позитивные переходы:

от межличностного

конфликта –

к технической дискуссии

от безрезультативного

«чьё решение лучше» -

к конструктивному

обсуждению

критериев выбора

Кадры из фильма: Lucky Number Slevin

выявляем проблемную область

Как делаем:

К ответу на вопросы

принимаем

только технические

причины!

В нашей команде

только отличные

специалисты!

Что делаем:

Локализуем спорную

часть дизайна системы.

Отвечаем на вопрос:

Почему не можем

выбрать одно из двух

решений?

Диагностика проблемы

что-то «не так» со скоростью twitter

что-то «cломалось» в презентации microsoft

Основная причина проблемы:

конфликт производительности и надежности

(сопровождаемости) системы

Шаг 1: Клин-клином вышибают

Делаем описание решений:

Концептуальный дизайн фиксирует основные

моменты решений, концентрируясь на различиях

(architecture tradeoffs).

Создаем небольшой документ нотации,

понятной всей проектной команде.

Время чтения документа: не более 10 минут.

Пример: типовой проект

из жизни биллинговых систем

Есть несколько

биллинговых систем

Бизнес-цель:

предоставить

пользователю один счет

за услуги разных систем

Пользователь делает

один платеж за все!

Единый счет

DATABASE

Billing #01

Сгенерированн

ые счета

Billing # n

Сгенерированн

ые счета

Единый счет

Пример: условие задачи

1. Обеспечить сбор данных из биллинговых систем

один раз в месяц.

2. Убедиться, что абонент не получит один счет два

раза (единый счет и счет из самой биллинговой

системы).

3. Проконтролировать выполнение бизнес-условий,

при которых может выставляться единый счет.

Пример:

решение №1 - «быстрое»

Как только система

в регионе окончила

формирование счета –

данные передаются в

«центр».

Почему: чем быстрее

выставим счет, тем

скорее он попадет

клиенту и его оплатят!

Billing #01

Billing # n

Единый счет

Пример:

решение №2 - «надежное»

Из центра по расписанию

запрашиваем данные

в биллингах и, если счет

выставлен, собираем данные

в единый счет.

Почему: в биллингах данные

могут меняться совершенно

самостоятельно.

Нам не нужны проблемы

с целостностью данных!

Billing #01

Billing # n

Единый счет

Итого

Решение №1

Плюс: кажется,

что работает быстрее за

счет отсутствия задержек.

Минус: контроль

целостности данных

распределен между

системами.

Решение №2

Плюс: кажется,

что работает надежнее

за счет централизации

управления.

Минус: замедление.

Шаг 2:

устанавливаем приоритет требований

Формирование требований в виде сценариев

использования по принципу:

воздействие – реакция на воздействие.

Условие: каждому требованию –

как минимум один сценарий

Сценарии выбираются так, чтобы выявить

расхождения в решениях.

Шаг 3: формируем «вычислимый»

критерий принятия решения

На основе субъективных оценок приоритетов и

субъективных оценок соответствия решения

заявленному требованию делается вычисление.

Это не объективное сравнение,

а «виртуальный арбитр»

Дерево качества

упрощенный пример – упрощенное дерево

Качество

Производительность (0.25) Поддерживаемость (0.75)

Время отклика (0.75)

Масштабирование (0.25)

Гибкость (0.6111)

Обучаемость (0.2778)

Расширяемость (0.1111)

Сценарий 1. (0.25)

-

-

-

-

Сценарий 2. (0.75)

Два ключевых сценария

№ Событие Место Реакция Нагрузка Измерение

1 Выставлены счета Во всех

биллингах

Данные собраны в ЕС 6

биллинговых

систем

10000 единых

счетов

5000

единичных

счетов

в биллинг

1 час

2 Выставлены счета

при условии, что

часть счетов не

соответствует

правилам ЕС

Во всех

биллингах

Данные собраны в ЕС Аналогично

пункту 1.

1 час

Как устанавливаются веса?

Формула веса

Где k – приоритет атрибута,

N – количество сравниваемых атрибутов.

Легко видеть, что сумма таких весов равна 1.

Сравниваем сценарии

Решаем, какая архитектура «лучше»

для данного сценария

Выставляем оценки по критериям:

0 – не реализуется

1 – сценарий трудно достижим

2 – Сценарий реализуем, но с ограничениями

3 – Полностью соответствует

4 – Высшая оценка

Сравнение решений

с точки зрения сценариев

Командная работа в компании Энвижн – Программные решения

Считаем «вес» архитектуры

Сценарий ВесАрхитектура

№1 - оценка

Архитектура №1 -

вес

Архитектура

№2 - оценка

Архитектура

№2 - вес

Сценарий

№1.25*.75*.25 3

3*.25*.75*.25=

0,1406252

2*.25*.75*.2

5=

0,09375

Сценарий

№2.25*.75*.75 2

2*.25*.75*.75=

0,281253

3*.25*.75*.7

5=

0,421875

Сумма 0,421875 0,515625

Правило №1

Создавать дерево до того, как придуман сценарий и

сравнивать решения.

Это дает возможность "обмануть" команду и увести

от сравнения решений к сравнению требований.

Правило №2

При выборе весов пользуйтесь красочными образами,

характеризующими конкретное решение: «если будет

превышено время отклика у протокольного адаптера,

у абонента пропадет связь, он будет страдать» и т.д.

Пусть сценарии придумает человек, который нейтрально

относится к решениям.

«Идеальный сценарист» - архитектор другого проекта.

Правило №3

• Веса сценариев распределяются только по

формуле!

• Иногда мы не могли расставить приоритеты, и

приходилось голосовать.

• В этих случаях у команды было меньше доверия

к результату сравнения.

Правило №4

Необходим Product Owner.

Заказчик, как правило, не требует увеличения

скорости модификации системы и улучшения

удобства эксплуатации

Нужен серьёзный внутренний заказчик.

Итого

Срок подготовки и выбора решения по данному

сценарию - 3-7 рабочих дней.

Иногда требуется делать по 2 итерации выбора.

Мы испытали этот метод на 4 крупных проектах.

Процедура всегда приводила к выбору решения

и снятию конфликтов!

Это не «вычисление лучшей архитектуры»,

это - способ конструктивно договориться!

40

СПАСИБО ЗА ВНИМАНИЕ

ddzuba@nvision-group.com