Коллеги,
По дороге домой меня накрыло просветление и я едва не стал Ботхисатвой. Оно и хорошо, что не стал, иначе бы мне по дефолту открылся весь BPMN и я бы сюда уже не вернулся, а так еще повоюем.
Короче, мы несколько не дожали … и я могу найти только одно оправдание – очарованные нашей прекрасной … задачей, поставленной нашей несравненно более прекрасной Предводительницей, мы её вообще не слушали. Кого её ? Предводительницу конечно.
А ведь Наталья нам минимум трижды вдалбливала очевидное.
1. Приоритетами всех разработок рулят Злобные Методологи и только они. Причем занимаются они этим в рамках некоторого внешнего процесса, не имеющего собственно к разработке никакого отношения. Назовем этот процесс «Управление приоритетами».
2. Живет себе «некто», которому приходит в голову что-нибудь автоматизировать и он становится Заказчиком КОНКРЕТНОГО ЭКЗЕМПЛЯРА процесса «Разработка ПО». В реальности экземпляров может быть сколько угодно, причем как от того же Заказчика, так и от других. Жизнь и работа заказчика во всем, что не касается нашей разработки - также внешний процесс. Внутри же КОНКРЕТНОГО ЭКЗЕМПЛЯРА процесса "Разработка ПО" заключается в том чтобы:
2.1 инициировать процесс
2.2.согласовать требования, первичный приоритет и сроки разработки,
2.3.принять работу
Эти и только эти его действия будут учитываться нами в экземляре процесса
Также возможно воздействие видя "я тебя породил - я и убью". Об этом - ниже …
3. Методологи устанавливают приоритеты и сроки КОНКРЕТНОГО ЭКЗЕМПЛЯРА процесса разработки ВНУТРИ согласования этого самого экземпляра. При этом планируют безжалостно сдвинуть приоритеты и сроки других ранее согласованных процессов, о чем сами себе должны сообщить из недр подпроцесса «Согласование» в процесс "Управление приоритетами", откуда в свою очередь сообщить «подвинутым» процессам об этом.
Далее.
3.1. Мы живем в рамках базовой модели мира, в которой Методологи являются людьми адекватными, то есть сообщив сами себе что-то, они готовы сами от себя это услышать. Поэтому в BPMN мы будем пользоваться «Сигналом» для описания этого потока.
3.2. Зная о существовании Методологов и их способности перекраивать приоритеты, мы должны быть готовы в любой момент отложить работы по любой задаче по требованию извне. В принципе в жизни это нормально. Программирование – не Производство. Переключиться из одного окна среды разработки в другое – это не станок перенастроить. Качество кода конечно страдает, но это не обсуждается. Используем ожидающие события «Сообщение».
3.3. Вообще говоря, Методологам мы доверяем, но не совсем. Поэтому мы не будем полагаться них полостью и предусмотрим самостоятельное оповещение Заказчика в случае изменения сроков или отмены его задачи извне. Не помешает.
4. Тут есть хитрый попендопль. Получив от нас оповещение о том, что его задача отложена в долгий ящик, Заказчик вполне может побежать к Методологам на разборки. В результате этих разборок может наступить как очередная реприоретизация задач, так и вовсе отмена каких то задач, причем как со стороны Методологов, так и со стороны Заказчика. К этому мы тоже готовы и тоже ждем входящих сообщений. Вероятность сдвига приоритета и сроков со стороны самого заказчика есть, но она исчезающе мала и мы не будем захламлять схему этим потоком. Собственно, сам процесс драки за приоритеты нам не интересен, но мы его учитываем и помним о нем, поэтому его тоже обозначим, Просто потоками между внешними пулами
В итоге как-то так:
