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