Решение конфликтов в процессе проектирования сложных систем
0 likes354 views
Документ описывает девятую независимую научно-практическую конференцию, посвященную проектированию программных решений, с акцентом на проблемы командной работы, возникающие из географической удаленности и языковых барьеров. Приводится методология для решения конфликтов в команде и выбора архитектурных решений, основанная на принципах Agile, с конкретными примерами из практики. Также рассматриваются ключевые аспекты разработки, включая требования к надежности и производительности систем.
Решение конфликтов в процессе проектирования сложных систем
- 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. Причины проблемы Споры: кто более опытный специалист? Ролевой конфликт в команде. Обида за напрасный труд. Чужой дизайн: тяжело понять (языковой барьер) и тяжело принять (самолюбие).
- 13. Подход к решению задачи
- 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 крупных проектах. Процедура всегда приводила к выбору решения и снятию конфликтов! Это не «вычисление лучшей архитектуры», это - способ конструктивно договориться!