ݺߣ

ݺߣShare a Scribd company logo

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

•
•
Dima Dzuba
Dima Dzuba

Презентация доклада с конференции CEE SECR 2013 (http://2013.secr.ru/) о методе принятия решений по выбору архитектуры ПО.

1 of 40
Download to read offline
Девятая независимая научно-практическая конференция «Разработка ПО 2013» 23 - 25 октября, Москва Фаза проектирования без конфликтов Дзюба Дмитрий «Энвижн – Программные решения» NVision Group
«Энвижн – Программные решения» R&D – центр «СПБ» R&D – центр «Минск» Санкт - Петербург HQ Дивизиона Москва R&D - центр «Москва» Краснодар R&D - центр «Прага» R&D – центр «Краснодар» Центры компетенции: • Россия: Нижний Новгород, Екатеринбург, Новосибирск, Владивосток • Украина: Киев • Индия: Мумбай, Ченнай • Пакистан: Лахор
Наши продукты CRM Pay-ment system Interconnect billing Billing Bonus Manageme nt system Mediation Portal Self care IVR Work Flow Resource Inven-tory Monitorin g Clea-ring House BUS IN platform SCP Trouble ticketing Service Provisionin g Reports
Наши клиенты Россия Украина Беларусь Чехия Пакистан Индия  Более 150 млн. абонентов  Более 5 млн. платежей в сутки  5 тыс. соединений в секунду
У нас есть проекты  Протяженные по времени проекты  Большое количество разрабатываемых систем  Даже первая итерация достаточно трудоемкая!
У проектов бывает заказчик  При разработке продукта приходится учитывать множественные, иногда требования заказчиков.
Мы работаем в распределенной команде  Состав команды: 20+ человек  Территориальная распределенность (разные города и страны)  Для общения используются несколько языков
Мы делаем системы класса  К системе предъявляются высокие требования по надежности и производительности  Неработоспособность системы - угроза бизнесу компании.
пристального внимания: качество проектирования продуктов  Непрерывная проверка качества решения на всех этапах разработки.
Факторы, усложняющие командную работу  Географическая удаленность членов команды  Языковой барьер  Фаза проектирования стимулирует создание формальных документов. Общение становится более формальным!
 Бесконечные переписки  Невозможность выбора лучшего решения  Команда делится на «группы», отстаивающие свои варианты. :  Сдвиг плана создания проектной документации  Конфликты внутри команды.
Причины проблемы  Споры: кто более опытный специалист?  Ролевой конфликт в команде.  Обида за напрасный труд.  Чужой дизайн: тяжело понять (языковой барьер) и тяжело принять (самолюбие).
Подход к решению задачи
Agile-манифест  Люди и взаимодействие важнее процессов и инструментов  Работающий продукт важнее исчерпывающей документации  Сотрудничество с заказчиком важнее согласования условий контракта  Готовность к изменениям важнее следования первоначальному плану 14
Lightweight Architecture Alternative Assessment Method (LAAAM)  http://blogs.msdn.com/b/jeromyc/archive/2005/08/27/45 7081.aspx Jeromy Carriere's WebLog  http://www.infoq.com/news/2011/07/low-ceremony-architecture Manuel Pais
Начало: все против • Нужно время – хотя бы три или пять дней, а мы и так уже отстаем от плана … • Метод ничего не гарантирует!
Люди и взаимодействие Kansas City Shuffle Позитивные переходы:  от межличностного конфликта – к технической дискуссии Кадры из фильма: Lucky Number Slevin  от безрезультативного «чьё решение лучше» к конструктивному обсуждению критериев выбора
выявляем проблемную область Что делаем:  Локализуем спорную часть дизайна системы.  Отвечаем на вопрос: Почему не можем выбрать одно из двух решений? Как делаем:  К ответу на вопросы принимаем только технические причины!  В нашей команде только отличные специалисты!
Диагностика проблемы Основная причина проблемы: конфликт производительности и надежности (сопровождаемости) системы что-то «не так» со скоростью twitter что-то «cломалось» в презентации microsoft
Шаг 1: Клин-клином вышибают Делаем описание решений:  Концептуальный дизайн фиксирует основные моменты решений, концентрируясь на различиях (architecture tradeoffs).  Создаем небольшой документ нотации, понятной всей проектной команде.  Время чтения документа: не более 10 минут.
Пример: типовой проект из жизни биллинговых систем  Есть несколько биллинговых систем  Бизнес-цель: предоставить пользователю один счет за услуги разных систем  Пользователь делает один платеж за все! Billing #01 Единый счет Сгенерированн ые счета DATABASE 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.6111) Сценарий 1. (0.25) - Сценарий 2. (0.75) Обучаемость (0.2778) - Масштабирование (0.25) Расширяемость (0.1111) - -
Два ключевых сценария № Событие Место Реакция Нагрузка Измерение 1 Выставлены счета Во всех биллингах Данные собраны в ЕС 6 биллинговых систем 10000 единых счетов 5000 единичных счетов в биллинг 1 час 2 Выставлены счета при условии, что часть счетов не соответствует правилам ЕС Во всех биллингах Данные собраны в ЕС Аналогично пункту 1. 1 час
Как устанавливаются веса? Формула веса Где k – приоритет атрибута, N – количество сравниваемых атрибутов. Легко видеть, что сумма таких весов равна 1.
Сравниваем сценарии  Решаем, какая архитектура «лучше» для данного сценария  Выставляем оценки по критериям:  0 – не реализуется  1 – сценарий трудно достижим  2 – Сценарий реализуем, но с ограничениями  3 – Полностью соответствует  4 – Высшая оценка
Сравнение решений с точки зрения сценариев Командная работа в компании Энвижн – Программные решения
Считаем «вес» архитектуры Сценарий Сценарий №1 Сценарий №2 Сумма Вес .25*.75*.25 .25*.75*.75 Архитектура №1 - оценка Архитектура №1 вес 3 3*.25*.75*.25= 0,140625 2 2*.25*.75*.75= 0,28125 0,421875 Архитектура №2 - оценка Архитектура №2 - вес 2 2*.25*.75*.2 5= 0,09375 3 3*.25*.75*.7 5= 0,421875 0,515625
Решение конфликтов в процессе проектирования сложных систем
Правило №1  Создавать дерево до того, как придуман сценарий и сравнивать решения.  Это дает возможность "обмануть" команду и увести от сравнения решений к сравнению требований.
Правило №2  При выборе весов пользуйтесь красочными образами, характеризующими конкретное решение: «если будет превышено время отклика у протокольного адаптера, у абонента пропадет связь, он будет страдать» и т.д.  Пусть сценарии придумает человек, который нейтрально относится к решениям.  «Идеальный сценарист» - архитектор другого проекта.
Правило №3 • Веса сценариев распределяются только по формуле! • Иногда мы не могли расставить приоритеты, и приходилось голосовать. • В этих случаях у команды было меньше доверия к результату сравнения.
Правило №4  Необходим Product Owner.  Заказчик, как правило, не требует увеличения скорости модификации системы и улучшения удобства эксплуатации  Нужен серьёзный внутренний заказчик.
Итого  Срок подготовки и выбора решения по данному сценарию - 3-7 рабочих дней.  Иногда требуется делать по 2 итерации выбора.  Мы испытали этот метод на 4 крупных проектах. Процедура всегда приводила к выбору решения и снятию конфликтов!  Это не «вычисление лучшей архитектуры», это - способ конструктивно договориться!
СПАСИБО ЗА ВНИМАНИЕ ddzuba@nvision-group.com 40

More Related Content

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

  • 1. Девятая независимая научно-практическая конференция «Разработка ПО 2013» 23 - 25 октября, Москва Фаза проектирования без конфликтов Дзюба Дмитрий «Энвижн – Программные решения» NVision Group
  • 2. «Энвижн – Программные решения» R&D – центр «СПБ» R&D – центр «Минск» Санкт - Петербург HQ Дивизиона Москва R&D - центр «Москва» Краснодар R&D - центр «Прага» R&D – центр «Краснодар» Центры компетенции: • Россия: Нижний Новгород, Екатеринбург, Новосибирск, Владивосток • Украина: Киев • Индия: Мумбай, Ченнай • Пакистан: Лахор
  • 3. Наши продукты CRM Pay-ment system Interconnect billing Billing Bonus Manageme nt system Mediation Portal Self care IVR Work Flow Resource Inven-tory Monitorin g Clea-ring House BUS IN platform SCP Trouble ticketing Service Provisionin g Reports
  • 4. Наши клиенты Россия Украина Беларусь Чехия Пакистан Индия  Более 150 млн. абонентов  Более 5 млн. платежей в сутки  5 тыс. соединений в секунду
  • 5. У нас есть проекты  Протяженные по времени проекты  Большое количество разрабатываемых систем  Даже первая итерация достаточно трудоемкая!
  • 6. У проектов бывает заказчик  При разработке продукта приходится учитывать множественные, иногда требования заказчиков.
  • 7. Мы работаем в распределенной команде  Состав команды: 20+ человек  Территориальная распределенность (разные города и страны)  Для общения используются несколько языков
  • 8. Мы делаем системы класса  К системе предъявляются высокие требования по надежности и производительности  Неработоспособность системы - угроза бизнесу компании.
  • 9. пристального внимания: качество проектирования продуктов  Непрерывная проверка качества решения на всех этапах разработки.
  • 10. Факторы, усложняющие командную работу  Географическая удаленность членов команды  Языковой барьер  Фаза проектирования стимулирует создание формальных документов. Общение становится более формальным!
  • 11.  Бесконечные переписки  Невозможность выбора лучшего решения  Команда делится на «группы», отстаивающие свои варианты. :  Сдвиг плана создания проектной документации  Конфликты внутри команды.
  • 12. Причины проблемы  Споры: кто более опытный специалист?  Ролевой конфликт в команде.  Обида за напрасный труд.  Чужой дизайн: тяжело понять (языковой барьер) и тяжело принять (самолюбие).
  • 14. Agile-манифест  Люди и взаимодействие важнее процессов и инструментов  Работающий продукт важнее исчерпывающей документации  Сотрудничество с заказчиком важнее согласования условий контракта  Готовность к изменениям важнее следования первоначальному плану 14
  • 15. Lightweight Architecture Alternative Assessment Method (LAAAM)  http://blogs.msdn.com/b/jeromyc/archive/2005/08/27/45 7081.aspx Jeromy Carriere's WebLog  http://www.infoq.com/news/2011/07/low-ceremony-architecture Manuel Pais
  • 16. Начало: все против • Нужно время – хотя бы три или пять дней, а мы и так уже отстаем от плана … • Метод ничего не гарантирует!
  • 17. Люди и взаимодействие Kansas City Shuffle Позитивные переходы:  от межличностного конфликта – к технической дискуссии Кадры из фильма: Lucky Number Slevin  от безрезультативного «чьё решение лучше» к конструктивному обсуждению критериев выбора
  • 18. выявляем проблемную область Что делаем:  Локализуем спорную часть дизайна системы.  Отвечаем на вопрос: Почему не можем выбрать одно из двух решений? Как делаем:  К ответу на вопросы принимаем только технические причины!  В нашей команде только отличные специалисты!
  • 19. Диагностика проблемы Основная причина проблемы: конфликт производительности и надежности (сопровождаемости) системы что-то «не так» со скоростью twitter что-то «cломалось» в презентации microsoft
  • 20. Шаг 1: Клин-клином вышибают Делаем описание решений:  Концептуальный дизайн фиксирует основные моменты решений, концентрируясь на различиях (architecture tradeoffs).  Создаем небольшой документ нотации, понятной всей проектной команде.  Время чтения документа: не более 10 минут.
  • 21. Пример: типовой проект из жизни биллинговых систем  Есть несколько биллинговых систем  Бизнес-цель: предоставить пользователю один счет за услуги разных систем  Пользователь делает один платеж за все! Billing #01 Единый счет Сгенерированн ые счета DATABASE Billing # n Сгенерированн ые счета Единый счет
  • 22. Пример: условие задачи 1. Обеспечить сбор данных из биллинговых систем один раз в месяц. 2. Убедиться, что абонент не получит один счет два раза (единый счет и счет из самой биллинговой системы). 3. Проконтролировать выполнение бизнес-условий, при которых может выставляться единый счет.
  • 23. Пример: решение №1 - «быстрое» Как только система в регионе окончила формирование счета – данные передаются в «центр». Почему: чем быстрее выставим счет, тем скорее он попадет клиенту и его оплатят! Billing #01 Billing # n Единый счет
  • 24. Пример: решение №2 - «надежное» Из центра по расписанию запрашиваем данные в биллингах и, если счет выставлен, собираем данные в единый счет. Почему: в биллингах данные могут меняться совершенно самостоятельно. Нам не нужны проблемы с целостностью данных! Billing #01 Billing # n Единый счет
  • 25. Итого Решение №1 Решение №2 Плюс: кажется, что работает быстрее за счет отсутствия задержек. Плюс: кажется, что работает надежнее за счет централизации управления. Минус: контроль целостности данных распределен между системами. Минус: замедление.
  • 26. Шаг 2: устанавливаем приоритет требований  Формирование требований в виде сценариев использования по принципу: воздействие – реакция на воздействие.  Условие: каждому требованию – как минимум один сценарий  Сценарии выбираются так, чтобы выявить расхождения в решениях.
  • 27. Шаг 3: формируем «вычислимый» критерий принятия решения  На основе субъективных оценок приоритетов и субъективных оценок соответствия решения заявленному требованию делается вычисление.  Это не объективное сравнение, а «виртуальный арбитр»
  • 28. Дерево качества упрощенный пример – упрощенное дерево Качество Производительность (0.25) Поддерживаемость (0.75) Время отклика (0.75) Гибкость (0.6111) Сценарий 1. (0.25) - Сценарий 2. (0.75) Обучаемость (0.2778) - Масштабирование (0.25) Расширяемость (0.1111) - -
  • 29. Два ключевых сценария № Событие Место Реакция Нагрузка Измерение 1 Выставлены счета Во всех биллингах Данные собраны в ЕС 6 биллинговых систем 10000 единых счетов 5000 единичных счетов в биллинг 1 час 2 Выставлены счета при условии, что часть счетов не соответствует правилам ЕС Во всех биллингах Данные собраны в ЕС Аналогично пункту 1. 1 час
  • 30. Как устанавливаются веса? Формула веса Где k – приоритет атрибута, N – количество сравниваемых атрибутов. Легко видеть, что сумма таких весов равна 1.
  • 31. Сравниваем сценарии  Решаем, какая архитектура «лучше» для данного сценария  Выставляем оценки по критериям:  0 – не реализуется  1 – сценарий трудно достижим  2 – Сценарий реализуем, но с ограничениями  3 – Полностью соответствует  4 – Высшая оценка
  • 32. Сравнение решений с точки зрения сценариев Командная работа в компании Энвижн – Программные решения
  • 33. Считаем «вес» архитектуры Сценарий Сценарий №1 Сценарий №2 Сумма Вес .25*.75*.25 .25*.75*.75 Архитектура №1 - оценка Архитектура №1 вес 3 3*.25*.75*.25= 0,140625 2 2*.25*.75*.75= 0,28125 0,421875 Архитектура №2 - оценка Архитектура №2 - вес 2 2*.25*.75*.2 5= 0,09375 3 3*.25*.75*.7 5= 0,421875 0,515625
  • 35. Правило №1  Создавать дерево до того, как придуман сценарий и сравнивать решения.  Это дает возможность "обмануть" команду и увести от сравнения решений к сравнению требований.
  • 36. Правило №2  При выборе весов пользуйтесь красочными образами, характеризующими конкретное решение: «если будет превышено время отклика у протокольного адаптера, у абонента пропадет связь, он будет страдать» и т.д.  Пусть сценарии придумает человек, который нейтрально относится к решениям.  «Идеальный сценарист» - архитектор другого проекта.
  • 37. Правило №3 • Веса сценариев распределяются только по формуле! • Иногда мы не могли расставить приоритеты, и приходилось голосовать. • В этих случаях у команды было меньше доверия к результату сравнения.
  • 38. Правило №4  Необходим Product Owner.  Заказчик, как правило, не требует увеличения скорости модификации системы и улучшения удобства эксплуатации  Нужен серьёзный внутренний заказчик.
  • 39. Итого  Срок подготовки и выбора решения по данному сценарию - 3-7 рабочих дней.  Иногда требуется делать по 2 итерации выбора.  Мы испытали этот метод на 4 крупных проектах. Процедура всегда приводила к выбору решения и снятию конфликтов!  Это не «вычисление лучшей архитектуры», это - способ конструктивно договориться!