Создаем IT-продукты на заказ

За 5 лет мы создали продукты с топовыми e-commerce компаниями, ритейлом, банками и другими бизнесами по всему миру.

Специализируемся на SaaS-решениях на архитектуре микросервисов, делаем аналитику IT-проекта перед стартом.

Посмотрите, что говорят о нас клиенты и как комфортно мы стартуем проекты.

Для обсуждения проекта пишите на ceo@byndyusoft.com или звоните +7 (904) 305 5263

вторник, 10 февраля 2015 г.

Модель принятия решений

Когда-то меня вдохновило выступление Евгения Кривошеева Design & Process Models. В нём рассматривается много аспектов разработки ПО, рекомендую выделить 2 часа и посмотреть видео целиком. Сейчас я хочу остановится на взаимодействии связанных между собой моделей и том, как это можно использовать в повседневной работе:

  • Business Model — бизнес заказчика, на чём он зарабатываем деньги.
  • Process model — как должен быть устроен процесс формирования ценности: этапы, фазы, роли, артефактры для получения ценности. Описывает также порядок появление нижележащих моделей и их взаимодействие. Например, пишем код и рефакторим до хорошего дизайна или сначала делаем дизайн (upfront) и потом пишем код.
  • Requirements Model + Domain Model — какие требования есть к продукту/проекту, тексты, UML-диаграммы и т.д.
  • Design Model — архитектура, шаблоны проектирования и т.п.
  • Implementation Model — исходный код

Один из возможных результатов выбора на каждом уровне:

Мы ежедневно принимаем решения по проекту. Например, надо решить будем добавлять кэш в инфраструктуру или нет? Будем применять IoC-контейнер или нет? Сделаем Big Design Up Front или начнем создавать архитектуру по ходу работы над проектом? Напишем подробное ТЗ в начале проекта или будем реализовывать самые важные User Story итеративно? Построим процесс по Waterfall или по Agile? Любое решение имеет свои плюсы и минусы, нужно постоянно искать компромиссы.

Основные идеи, о которых говорит Евгений:

  1. Какое бы ни было решение в любом случае довольно сложно попасть им во все требования вышестоящей модели. Возникает конфликт и приходится искать компромисс. В нашей отрасли такие конфликты типичны, потому что по Cynefin framework разработка ПО обычно лежит в квадрате Complex.
    Яркий пример компромисса — это теорема CAP. В зависимости от требований вам придётся выбрать для архитектуры две характеристики из трёх возможных.
  2. Зависимость моделей проявляется не только сверху вниз. Нижележащие модели также могут оказывать влияние на вышележащие.
    Например, не факт, что под требования к системе можно подобрать архитектуру. Вполне реальная ситуация, когда приходится изменять требования, чтобы можно было создарть жизнеспособную архитектуру.
  3. Мы не можем решить проблему на том же уровне абстракции, на котором она возникла, ответ нужно искать на уровень выше.
    Типичный выбор Гибкость или Простота. Сейчас заплатить больше и сделать изначально гибко или сейчас делать проще, а потом выплачивать технический долг. Какое-то решение принять придётся, для этого идём на уровни выше и пытаемся найти ответ там.
  4. Нужно уметь обосновывать свои решения на каждому уровне через вышестоящие модели.
  5. Нет плохих или хороших решений, за всё приходится платить.
В примерах мы говорим в основном о паре Requirements Model <-> Design Model, но все утвеждения справедливы для любой другой пары моделей.

В итоге, получается, что каждый член команды должен понимать бизнес-модель заказчика (для начала надо уметь явно формировать цели). Как бы это странно ни звучало, но в конечном итоге от бизнес-модели зависит какой вы сделаете метод/класс/интерфейс в коде. Если внимательно отнестить к этой модели принятия решений, то в результате получите снижение стоимости разработки и снижение рисков.

Комментариев нет:

Отправить комментарий

Создаем IT-продукты на заказ

За 5 лет мы создали продукты с топовыми e-commerce компаниями, ритейлом, банками и другими бизнесами по всему миру.

Специализируемся на SaaS-решениях на архитектуре микросервисов, делаем аналитику IT-проекта перед стартом.

Посмотрите, что говорят о нас клиенты и как комфортно мы стартуем проекты.

Для обсуждения проекта пишите на ceo@byndyusoft.com или звоните +7 (904) 305 5263