Все верно, NoCode платформу можно сделать только для очень простых задач, шаг вправо или влево = расстрел. Вот с low code платформами можно гораздо больше, если обычному разработчику убрать с помощью нее рутину, тогда открываются интересные возможности...
Обычно все эти платформы сыпятся на элементарной задаче, а покажите мне в этой формочки данные из этого rest....
В общем для себя я отметил, что Camundа используем в исключительных случаях, если можно не использовать, не используем.
хмм, очень интересное дистанцирование, как архитектор я реально почти не вижу в ней пользы, так как без разработчика нельзя ничего изменить, а разработчику она только мешает. Для разработки бизнес логики, хорошо описанной аналитиком, требуются разработчики уровня верх jun или middle, ни каких сеньеров и тем более архов там не требуется (java, phyton,... тут все равно).
Аналитикам бы не понимающим нафига им разрабы, неплохо бы понять, что те 20% которые они не могут сделать, занимают 80% времени :), поэтому пусть лучше пишут доку... Кубики можно и в другом редакторе рисовать...
Как мне кажется, камунда подходит только для условного роутинга скана по какому-то БП, во всех остальных случая - это лишняя хрень, которая очень дорого обходится в саппорте...
к вопросу, а зачем тогда комунда и зачем размазывать все на 2 системы в которых разные роли что то правят... ИМХО они не сойдутся, пока это не будет один человек?
Отладка в камунде это боль, так как контекстом то она не рулит, а рулят микросервисы и действительно это превращается в туже боль отладки микросервисов, особенно если кто то решил намельчить и использовал один паттерн микросервис- одна таблица. А по хорошему то надо, чтобы вся бизнес логика жила в одном sub домене core домена, тогда и проблемы не будет.
Тесты писать безусловно надо, поделитесь как на камунду вы тесты пишите?
Чтобы хранить в камунде данные, надо чтобы они там как то оказались из более надёжного источника данных, вы периодически синхронизируете кучу данных из другой бд?
Ценность Camunda для меня сомнительная, ещё в 2013ом мы послали в урну Activity, мама камунды, ибо все это выглядело не используемо. Тогда мы сделали свой движок, который обладал контектом, а Bmpn движки обладают недоконтекстом, а набором переменных, которые надо как то туда собрать, в итоге более менее серьёзный процесс выпадает в какой-то плохо сопровождаемый проект, где сложно понять почему процесс оказался тут... ( кто поставил значения переменным, на основе которых принималось решение).
Сейчас используем Camunda, для банков это плюс, они типа её знают и поэтому заносят в плюсы.
Что по факту:
Ни какой гибкости камунды нет, любое изменение, потребует знания не только сложной Camunda, но и java, python... Где реализуется ServiceTask. Да, визуально выглядит просто, но на деле, помимо аналитика, это всегда требует разработчика, например в приведеном примере надо до клуба сбегать за пивком..
Это поражает другую проблему - у вас знания, как эта штука работает, разделяется на 2 системы и 2 головы и возникает необходимость синхронизация этого.
Отладка, это боль и страдания, когда ты не можешь вначале понять где проблема, отдебажить все это, а пытаешься понять, как такой контекст переменных образовался.
Ещё +1 система отказа и головной боли, для админов
Какие мысли по этому, лучше все написать на одной системе или на java/... или на Camunda, звучит странно, но большую часть проблем тогда удастся решить.
Но в Camunda нельзя видеть историю и её nocode движок очень слабо развит, т. е технически задачу не решить без code.
На java/... , не будет визуальности диаграммы и типа лёгкости внесения изменений,что "типа" надо архитектору/аналитику банка.
Кто как решает эту проблему?
Кто и как управляет контекстом Camunda? (устанавливаете все переменные непосредственно перед принятием решения? Или где придётся) или может как то по другому?
Идеального решения у меня нет, есть видение, кнопок возможно придётся реальзовать
можно, но вся проблема RnD задач, что он не декомпозируются до дня, на практике неделю запросто, а поэтому смысла в дейли не очень много. Но если удастся раздробить все по 8 часов, то тогда конечно скрам может подойти..
можно так делать и можно даже сделать так, чтобы это почти соответствовало скраму, но вот оценки скорее будут сильно завышены. Если нужно чтобы технология Х дала нужный результат... я обычно делаю цель, а вот сроки очень размазанные и daily не имеют смысла, скорее раз в несколько дней, т.е. это уже не скрам. А так да через спринт поймем куда дальше грести.
жаль, что вы приняли моя слова на свой счет, вообще я под распи..ями имел ввиду некоторых особ, которые могут забухать за пару дней до демо... т.е. они не держат commitment, ну забухал я , не смог....
цель в RnD конечно есть, но как ее достичь никто не знает, даже декомозировать иногда нельзя и результат спринта, должен быть потенциально готовым к проду. Да иногда в RnD садишься и с утра и до обеда ищешь выход, я понимаю, что вы клоните к исследовать такой то ресурс, попробовать то, написать нейронку... но по большому счету, результата нет, так как можно месяц эксперименты ставить, а удовлетворительного результата не найти. А цель попробовать "технологию akjdakds" нафиг бизнесу не нужна. Или когда берешь тему, потянул ниточку, а там еще вывалилось на год вперед... Конечно можно за уши притянуть, но это все не про задачи на 8 часов...
Погрешность оценки будет сильно большой, поэтому такое прогнозированию поддается плохо. Но если на половину вещей закрыть глаза, то можно.
Теплое с мягким путаете. Я даже не хочу общаться с распиз...ями, которые не берут commitment , мне "ехать", нет результата - до свидания.
Теперь про гибкость, гибкость заключается в том, что не надо выполнять все задачи спринта, это лишь доп фичи.. Более того, если у кого то задача сильно больше, то ему помогут, если задача важна.
Я вам это говорю, так как я не теоретик с треннингов, а практик.
разница все же значительна, в Scrum нужно достичь цели спринта, т.е. сделать что то, визуальное-функицональное, чтобы показать заказчику.
А в RnD такой цели нет, там копаем, пока не выкапаем, как заказчику достанет, он прибьет этот проект.
В 99% обычных задач, я сразу скажу сколько попугаев/маек и буду достаточно близок, а вот с RnD очень непонятно время, даже для очень опытных разрабов... Т.е. подход "копаем с утра и до обеда"
Хорошо, kanbanом я назвал просто доску, где сверху самое важное, его и делаем, оценки могут быть на задачи, но общие сроки непонятны. Конечно это не канбан тойоты
Все верно, NoCode платформу можно сделать только для очень простых задач, шаг вправо или влево = расстрел. Вот с low code платформами можно гораздо больше, если обычному разработчику убрать с помощью нее рутину, тогда открываются интересные возможности...
Обычно все эти платформы сыпятся на элементарной задаче, а покажите мне в этой формочки данные из этого rest....
В общем для себя я отметил, что Camundа используем в исключительных случаях, если можно не использовать, не используем.
хмм, очень интересное дистанцирование, как архитектор я реально почти не вижу в ней пользы, так как без разработчика нельзя ничего изменить, а разработчику она только мешает. Для разработки бизнес логики, хорошо описанной аналитиком, требуются разработчики уровня верх jun или middle, ни каких сеньеров и тем более архов там не требуется (java, phyton,... тут все равно).
Аналитикам бы не понимающим нафига им разрабы, неплохо бы понять, что те 20% которые они не могут сделать, занимают 80% времени :), поэтому пусть лучше пишут доку... Кубики можно и в другом редакторе рисовать...
Как мне кажется, камунда подходит только для условного роутинга скана по какому-то БП, во всех остальных случая - это лишняя хрень, которая очень дорого обходится в саппорте...
Вот прям в точку. Можно не писать код, но знать как он пишется обязан
а на каком количестве TPS у вас это просиходило?
к вопросу, а зачем тогда комунда и зачем размазывать все на 2 системы в которых разные роли что то правят... ИМХО они не сойдутся, пока это не будет один человек?
спасибо, этого для понимания достаточно.
Если я правильно понял, у вас тесты на камунду пишет разработчик сервисов, а не разработчик BPMN(Аналитик)?
И что будет с тестами, если аналитик стрелочку в другое место направит, потому что так бизнес решит?
Отладка в камунде это боль, так как контекстом то она не рулит, а рулят микросервисы и действительно это превращается в туже боль отладки микросервисов, особенно если кто то решил намельчить и использовал один паттерн микросервис- одна таблица. А по хорошему то надо, чтобы вся бизнес логика жила в одном sub домене core домена, тогда и проблемы не будет.
Тесты писать безусловно надо, поделитесь как на камунду вы тесты пишите?
Чтобы хранить в камунде данные, надо чтобы они там как то оказались из более надёжного источника данных, вы периодически синхронизируете кучу данных из другой бд?
А можно чуть подробнее?
В смысле процессы падали?
Да, заливайте bpmn файл в гит, это xml
Ценность Camunda для меня сомнительная, ещё в 2013ом мы послали в урну Activity, мама камунды, ибо все это выглядело не используемо. Тогда мы сделали свой движок, который обладал контектом, а Bmpn движки обладают недоконтекстом, а набором переменных, которые надо как то туда собрать, в итоге более менее серьёзный процесс выпадает в какой-то плохо сопровождаемый проект, где сложно понять почему процесс оказался тут... ( кто поставил значения переменным, на основе которых принималось решение).
Сейчас используем Camunda, для банков это плюс, они типа её знают и поэтому заносят в плюсы.
Что по факту:
Ни какой гибкости камунды нет, любое изменение, потребует знания не только сложной Camunda, но и java, python... Где реализуется ServiceTask. Да, визуально выглядит просто, но на деле, помимо аналитика, это всегда требует разработчика, например в приведеном примере надо до клуба сбегать за пивком..
Это поражает другую проблему - у вас знания, как эта штука работает, разделяется на 2 системы и 2 головы и возникает необходимость синхронизация этого.
Отладка, это боль и страдания, когда ты не можешь вначале понять где проблема, отдебажить все это, а пытаешься понять, как такой контекст переменных образовался.
Ещё +1 система отказа и головной боли, для админов
Какие мысли по этому, лучше все написать на одной системе или на java/... или на Camunda, звучит странно, но большую часть проблем тогда удастся решить.
Но в Camunda нельзя видеть историю и её nocode движок очень слабо развит, т. е технически задачу не решить без code.
На java/... , не будет визуальности диаграммы и типа лёгкости внесения изменений,что "типа" надо архитектору/аналитику банка.
Кто как решает эту проблему?
Кто и как управляет контекстом Camunda? (устанавливаете все переменные непосредственно перед принятием решения? Или где придётся) или может как то по другому?
Идеального решения у меня нет, есть видение, кнопок возможно придётся реальзовать
все верно, но в действительно сложны RnD задачах другие слабо могут помочь, там в контекст можно пару дней углублятся
можно, но вся проблема RnD задач, что он не декомпозируются до дня, на практике неделю запросто, а поэтому смысла в дейли не очень много.
Но если удастся раздробить все по 8 часов, то тогда конечно скрам может подойти..
можно так делать и можно даже сделать так, чтобы это почти соответствовало скраму, но вот оценки скорее будут сильно завышены. Если нужно чтобы технология Х дала нужный результат... я обычно делаю цель, а вот сроки очень размазанные и daily не имеют смысла, скорее раз в несколько дней, т.е. это уже не скрам. А так да через спринт поймем куда дальше грести.
жаль, что вы приняли моя слова на свой счет, вообще я под распи..ями имел ввиду некоторых особ, которые могут забухать за пару дней до демо... т.е. они не держат commitment, ну забухал я , не смог....
цель в RnD конечно есть, но как ее достичь никто не знает, даже декомозировать иногда нельзя и результат спринта, должен быть потенциально готовым к проду. Да иногда в RnD садишься и с утра и до обеда ищешь выход, я понимаю, что вы клоните к исследовать такой то ресурс, попробовать то, написать нейронку... но по большому счету, результата нет, так как можно месяц эксперименты ставить, а удовлетворительного результата не найти. А цель попробовать "технологию akjdakds" нафиг бизнесу не нужна. Или когда берешь тему, потянул ниточку, а там еще вывалилось на год вперед... Конечно можно за уши притянуть, но это все не про задачи на 8 часов...
Погрешность оценки будет сильно большой, поэтому такое прогнозированию поддается плохо. Но если на половину вещей закрыть глаза, то можно.
Теплое с мягким путаете. Я даже не хочу общаться с распиз...ями, которые не берут commitment , мне "ехать", нет результата - до свидания.
Теперь про гибкость, гибкость заключается в том, что не надо выполнять все задачи спринта, это лишь доп фичи.. Более того, если у кого то задача сильно больше, то ему помогут, если задача важна.
Я вам это говорю, так как я не теоретик с треннингов, а практик.
разница все же значительна, в Scrum нужно достичь цели спринта, т.е. сделать что то, визуальное-функицональное, чтобы показать заказчику.
А в RnD такой цели нет, там копаем, пока не выкапаем, как заказчику достанет, он прибьет этот проект.
В 99% обычных задач, я сразу скажу сколько попугаев/маек и буду достаточно близок, а вот с RnD очень непонятно время, даже для очень опытных разрабов... Т.е. подход "копаем с утра и до обеда"
Хорошо, kanbanом я назвал просто доску, где сверху самое важное, его и делаем, оценки могут быть на задачи, но общие сроки непонятны. Конечно это не канбан тойоты