Этой проблеме уже несколько тысяч лет. Есть, условно, падишах, который принимает решения и есть его умный, но не ответственный, советник-визирь. Как падишаху принять правильное решение? Оказывается он должен управлять! Управлять, в том числе, рисками, задавая правильные вопросы визирю для более точной их оценки. В условиях тумана войны нет возможности принять единственно правильное решение - всегда есть риск и оценка его стоимости. Ошибки при оценке рисков всегда рано или поздно приводят к проигрышу.
Рабство пока не разрешили. Если в Липецке есть пара неплохих ВУЗов (понятие относительное), то чем потом удержать выпускников? Шестью сотками под огород?
Совет по ИИ при правительстве, настройка IVR при записи в поликлинику, преподаватели-1Сники в местном ПТУ (простите, колледже) и в ЛГТУ - какие-то настораживающие успехи.
То, что московские компании открывают в Липецке офисы продаж (пока только одна Интаро, но уже есть прецедент!) и есть свое областное ГБУ, которое занимается хостингом сайта администрации области - это, наверное, прорыв, но, по-моему, цели цифровизации надо ставить немножко амбициознее - уже почти середина XXI века все-таки.
Может быть автор про что-то забыл? Может быть уже прокат на НЛМК роботы местного производства осваивают, а не только надоедливые москвичи MES на RFID для завода разрабатывают? Ну или какой-нибудь липецкий контроллер для трактора или хотя бы тостера соседняя область приобрела? Интересно почитать мнение о цифровизации Липецкой области от самих жителей Липецкой области. Может быть действительно есть ИТ-жизнь за МКАДом? Может быть действительно пора ИТ релоцироваться из Москвы в липецкое село?
- назначить ответственных за актуальность архитектурных решений ;
- "сделать" ведение ADR частью процесса - это же и есть цель!
Отличный рецепт. Именно так обычно "внедряют" "аджайл" (да и любые другие модные слова). Нужен еще комитет по контролю соответствия проектных решений записям ADR.
Спасибо, пойду издам приказ о создании рабочей группы по внедрению и назначу совещание.
Это всё так, если у всех одна цель - успешное завершение проекта. Но реальность в том, что цели у всех разные - кому-то за державу обидно, а кому-то надо выделиться перед начальством.
РП "не айтишник" на ИТ-проекте - паразит. ИТ-проект обречен, если его не будет вытягивать "айтишник" делая работу за РП. Такой РП не сможет управлять заинтересованными сторонами, требованиями (содержанием) и ресурсами проекта. То есть валится еще на Уставе.
Если, по-вашему рассуждению, теоремЫ Гёделя о неполноте (об ограничениях) арифметики делают несостоятельной логику Аристотеля, то по тем же теоремам Гёделя "несостоятельны" вообще любые ограниченные системы, включая вас.
Статья о том, что когда у вас команда из шести человек, без заказчика, с которым по манифесту сотрудничество важнее требований (SLA же - "бюрократия"), да еще и без разработчиков (devops без dev - отличный подход) - вам ничего не остается, как только "митапить" друг-дружку канбан-доской. Один управляет релизами, другой координирует релизы, а того, кто их, собственно, создает и того, для кого он это создает - никто не спрашивает. Хороший "Agile подход". Главное, чтобы в спринте первая линия поддержки участвовала (ваш "Support Engineer"), да?
Ну и как вы считаете, Федоров привел все цели событий? "В-третьих" - очень неуклюжая цель. Есть throw и catch ивенты - те, которые catch еще можно натянуть на цель "В-третьих". Но это придирка. Ждать от отечественного экономиста какой-то корректной классификации - все равно, что ждать от соседа, что он споет Шаляпина без фальши.
в статье приведена классификация по типу события
так вот она неправильная. То, что у вас с ромбиком - это не событие ошибки, а событийный шлюз (Event based gateway).
туториал не имеет своей целью охватить все элементы и аспекты
никто и не ожидает, что вы сможете охватить все аспекты - в bpmn есть полно экзотики, даже пример применения которой придумать очень сложно. Но упомянуть о существовании, как минимум, ссылочных и условных событий стоило бы.
Со шлюзами - в нотации "или" бывает с пустым ромбиком и с косым крестом. Вы описываете пустой, а на диаграмме (обреченный пациент с подозрением ЗНО) с косым крестом. Что мешало помесить упоминание ранее? Жадность?
Пациент обречен потому, что он никогда не дождется завершения обслуживания - не пройдет параллельный шлюз с двумя входами, но с единственным токеном в процессе.
Событие - элемент управления потоком, который указывает на состояние, влияющее на выполнение процесса
Событие - это то, что произошло. Всё. В нотации все элементы указывают на состояние, все влияют на выполнение БП (зачем рисовать что-то, что не влияет?) и полно элементов управления - все, которые не элементы данных. Это "определение" вы, вероятно, подрезали у каких-то консалтеров "не умеешь сам - учи других": очень сложно и пусто. Сообщение же - это вид событий. Еще бывают события старта/конца, таймера, ошибок, отмены, сигнала, условия и, конечно, ссылки на другой процесс (если кого-то забыл, простите меня, события).
Ко всем создаваемым диаграммам в обязательном порядке идет аннотация с описанием
Про аннотации я писал к задачам, не ко всей диаграмме. Диаграмма-то как раз может быть в идеале самоописана.
Про технические термины - нотация не запрещает писать любой текст, даже матом. Но если вы говорите про подход, при котором вы составляете схему бизнес-процесса, то нужно оставаться на одном уровне абстракции - слое бизнес-процессов, а не скакать со слоя на слой.
Например. Задачу - в глагольной форме в терминах бизнеса, пояснения - в аннотацию. Запись в БД и элементы данных - это артефакты задач: стрелки только на них, а ИЗ них запретите себе что-то рисовать - только запутаетесь. Приводить на схеме БП "записать", "прочитать", "сохранить" и т.п - перегружают схему. Это само собой - у каждой задачи обязательно есть свои входы и выходы, логи и метрики - сохраняется всё. Слой данных, в котором их жизненный цикл, синхронные, асинхронные операции, процессы управления данными и т.д. - это другой архитектурный слой, не надо всё тащить в бизнес-процессы - получится каша - описывайте отдельно. Если уж так хочется (ну, например, основное требование - какое-то единство БД и надо его подсветить), то лучше поместите в аннотации эти функции задач, но не надо при этом из аннотаций создавать "войну и мир", как и создавать схемы больше, чем на 7-10 элементов - надо бить на подпроцессы. Вот это я коротко описал подход в парадигме многоуровневой архитектуры. Любопытно как может выглядеть другой. Жду новую статью ;)
Писать надо - это помогает структурировать собственные знания. А публиковать что-то или нет - это уже вопрос целеполагания и этики. Публиковать, чтобы (главное!) наследить на 50 лет - это так себе цель - с такой целью наследие в лифтах оставляют. Этично делиться чем-то полезным, спам - не этично. Это же так просто!
В статье приведен ошибочный подход с ошибками в нотации. Разбор ошибок и неточностей займет больше самой статьи. Базовые - задачи должны быть в терминах предметной области, а не технических терминов вроде "сохранение", БД и элементы данных не могут выступать в качестве задач. Путаница в нотации между сообщениями (вид событий) и событиями. Учитесь пользоваться аннотацией для пояснения задач процесса вместо некорректных представлений связей между элементами данных и БД. Процесс с событиями таймеров ожидания между параллельными шлюзами - вообще иллюстрация как делать не надо никогда.
Сводить всё к требованиям материальной мотивации – это трейдюнионизм, с которым товарищи всегда боролись: важно не только требовать прибавки к ЗП, а непосредственно влиять на условия и даже писали как.
Ошибка выжившего. Обычно ваши кубики не выстраиваются в последовательность - все кубики (разве что, кроме бюджета) меняются постоянно и непрерывно, с сингулярностями – это такое колесо сансары. «Отменена» - это лишь одно из состояний задачи, при котором в карму команды добавляется выгорания пропорционально потраченному времени.
Этой проблеме уже несколько тысяч лет. Есть, условно, падишах, который принимает решения и есть его умный, но не ответственный, советник-визирь. Как падишаху принять правильное решение? Оказывается он должен управлять! Управлять, в том числе, рисками, задавая правильные вопросы визирю для более точной их оценки. В условиях тумана войны нет возможности принять единственно правильное решение - всегда есть риск и оценка его стоимости. Ошибки при оценке рисков всегда рано или поздно приводят к проигрышу.
Это машинный перевод что ли?
рабочую группу при правительстве региона и комитет при администрации
Регион нуждается в советах или предложениях?
Рабство пока не разрешили. Если в Липецке есть пара неплохих ВУЗов (понятие относительное), то чем потом удержать выпускников? Шестью сотками под огород?
Совет по ИИ при правительстве, настройка IVR при записи в поликлинику, преподаватели-1Сники в местном ПТУ (простите, колледже) и в ЛГТУ - какие-то настораживающие успехи.
То, что московские компании открывают в Липецке офисы продаж (пока только одна Интаро, но уже есть прецедент!) и есть свое областное ГБУ, которое занимается хостингом сайта администрации области - это, наверное, прорыв, но, по-моему, цели цифровизации надо ставить немножко амбициознее - уже почти середина XXI века все-таки.
Может быть автор про что-то забыл? Может быть уже прокат на НЛМК роботы местного производства осваивают, а не только надоедливые москвичи MES на RFID для завода разрабатывают? Ну или какой-нибудь липецкий контроллер для трактора или хотя бы тостера соседняя область приобрела? Интересно почитать мнение о цифровизации Липецкой области от самих жителей Липецкой области. Может быть действительно есть ИТ-жизнь за МКАДом? Может быть действительно пора ИТ релоцироваться из Москвы в липецкое село?
вас тоже передернуло от довольства жителей голосовым помощником при записи к несуществующим врачам?
https://tass.ru/obschestvo/20724271
"Внедрять" ADR без нагрузки на команду:
-назначить ответственных за внедрение ADR;
-назначить ответственного за ведение ADR;
- назначить ответственных за актуальность архитектурных решений ;
- "сделать" ведение ADR частью процесса - это же и есть цель!
Отличный рецепт. Именно так обычно "внедряют" "аджайл" (да и любые другие модные слова). Нужен еще комитет по контролю соответствия проектных решений записям ADR.
Спасибо, пойду издам приказ о создании рабочей группы по внедрению и назначу совещание.
Это всё так, если у всех одна цель - успешное завершение проекта. Но реальность в том, что цели у всех разные - кому-то за державу обидно, а кому-то надо выделиться перед начальством.
По тексту больше похоже на геосинхронные.
и сколько их?
РП "не айтишник" на ИТ-проекте - паразит. ИТ-проект обречен, если его не будет вытягивать "айтишник" делая работу за РП. Такой РП не сможет управлять заинтересованными сторонами, требованиями (содержанием) и ресурсами проекта. То есть валится еще на Уставе.
Если, по-вашему рассуждению, теоремЫ Гёделя о неполноте (об ограничениях) арифметики делают несостоятельной логику Аристотеля, то по тем же теоремам Гёделя "несостоятельны" вообще любые ограниченные системы, включая вас.
Статья о том, что когда у вас команда из шести человек, без заказчика, с которым по манифесту сотрудничество важнее требований (SLA же - "бюрократия"), да еще и без разработчиков (devops без dev - отличный подход) - вам ничего не остается, как только "митапить" друг-дружку канбан-доской. Один управляет релизами, другой координирует релизы, а того, кто их, собственно, создает и того, для кого он это создает - никто не спрашивает. Хороший "Agile подход". Главное, чтобы в спринте первая линия поддержки участвовала (ваш "Support Engineer"), да?
Для чего используется - это не определение.
Ну и как вы считаете, Федоров привел все цели событий? "В-третьих" - очень неуклюжая цель. Есть throw и catch ивенты - те, которые catch еще можно натянуть на цель "В-третьих". Но это придирка. Ждать от отечественного экономиста какой-то корректной классификации - все равно, что ждать от соседа, что он споет Шаляпина без фальши.
так вот она неправильная. То, что у вас с ромбиком - это не событие ошибки, а событийный шлюз (Event based gateway).
никто и не ожидает, что вы сможете охватить все аспекты - в bpmn есть полно экзотики, даже пример применения которой придумать очень сложно. Но упомянуть о существовании, как минимум, ссылочных и условных событий стоило бы.
Со шлюзами - в нотации "или" бывает с пустым ромбиком и с косым крестом. Вы описываете пустой, а на диаграмме (обреченный пациент с подозрением ЗНО) с косым крестом. Что мешало помесить упоминание ранее? Жадность?
Пациент обречен потому, что он никогда не дождется завершения обслуживания - не пройдет параллельный шлюз с двумя входами, но с единственным токеном в процессе.
Событие - это то, что произошло. Всё. В нотации все элементы указывают на состояние, все влияют на выполнение БП (зачем рисовать что-то, что не влияет?) и полно элементов управления - все, которые не элементы данных. Это "определение" вы, вероятно, подрезали у каких-то консалтеров "не умеешь сам - учи других": очень сложно и пусто. Сообщение же - это вид событий. Еще бывают события старта/конца, таймера, ошибок, отмены, сигнала, условия и, конечно, ссылки на другой процесс (если кого-то забыл, простите меня, события).
Про аннотации я писал к задачам, не ко всей диаграмме. Диаграмма-то как раз может быть в идеале самоописана.
Про технические термины - нотация не запрещает писать любой текст, даже матом. Но если вы говорите про подход, при котором вы составляете схему бизнес-процесса, то нужно оставаться на одном уровне абстракции - слое бизнес-процессов, а не скакать со слоя на слой.
Например. Задачу - в глагольной форме в терминах бизнеса, пояснения - в аннотацию. Запись в БД и элементы данных - это артефакты задач: стрелки только на них, а ИЗ них запретите себе что-то рисовать - только запутаетесь. Приводить на схеме БП "записать", "прочитать", "сохранить" и т.п - перегружают схему. Это само собой - у каждой задачи обязательно есть свои входы и выходы, логи и метрики - сохраняется всё. Слой данных, в котором их жизненный цикл, синхронные, асинхронные операции, процессы управления данными и т.д. - это другой архитектурный слой, не надо всё тащить в бизнес-процессы - получится каша - описывайте отдельно. Если уж так хочется (ну, например, основное требование - какое-то единство БД и надо его подсветить), то лучше поместите в аннотации эти функции задач, но не надо при этом из аннотаций создавать "войну и мир", как и создавать схемы больше, чем на 7-10 элементов - надо бить на подпроцессы. Вот это я коротко описал подход в парадигме многоуровневой архитектуры. Любопытно как может выглядеть другой. Жду новую статью ;)
Писать надо - это помогает структурировать собственные знания. А публиковать что-то или нет - это уже вопрос целеполагания и этики. Публиковать, чтобы (главное!) наследить на 50 лет - это так себе цель - с такой целью наследие в лифтах оставляют. Этично делиться чем-то полезным, спам - не этично. Это же так просто!
В статье приведен ошибочный подход с ошибками в нотации. Разбор ошибок и неточностей займет больше самой статьи. Базовые - задачи должны быть в терминах предметной области, а не технических терминов вроде "сохранение", БД и элементы данных не могут выступать в качестве задач. Путаница в нотации между сообщениями (вид событий) и событиями. Учитесь пользоваться аннотацией для пояснения задач процесса вместо некорректных представлений связей между элементами данных и БД. Процесс с событиями таймеров ожидания между параллельными шлюзами - вообще иллюстрация как делать не надо никогда.
Сводить всё к требованиям материальной мотивации – это трейдюнионизм, с которым товарищи всегда боролись: важно не только требовать прибавки к ЗП, а непосредственно влиять на условия и даже писали как.
Ошибка выжившего. Обычно ваши кубики не выстраиваются в последовательность - все кубики (разве что, кроме бюджета) меняются постоянно и непрерывно, с сингулярностями – это такое колесо сансары. «Отменена» - это лишь одно из состояний задачи, при котором в карму команды добавляется выгорания пропорционально потраченному времени.