1Совцы все-таки пишут код. Мышкой они интерфейс рисуют. Это ближе к классическому RAD. По возможностям и скорости разработки любому low code до 1С как до Китая…
CUBA поддерживает кластера на уровне web и middleware слоев. Микросервисы вполне на CUBA пишутся. Возможно для каких-то сценариев они будут «жирноваты», но в общем случае это не проблема.
Спасибо! На самом деле Vaadin (построенный на GWT) — основной UI. Polymer клиент — альтернатива нестандартных интерфейсов, например порталов для внешних пользователей.
Если только ооочень издалека )) Drupal — CMS, строить на нем учетную систему с сотней-другой экранов и справочников например вы врядли станете. Скорее уж с 1С сравнение ближе. Или с Delphi.
Совсем нет. Confluence — это упрощенно говоря внутренняя вики, то есть средство хранения и совместной работы над статьями. ТЕЗИС — это ECM-система, призванная в первую очередь автоматизировать и регламентировать бизнес-процессы организаций.
Сейчас это ограничение контролируется только в среде разработки — CUBA Studio. Бесплатная версия просто не открывает проекты большего размера. Никаких ограничений на сущности или сессии в рантайме больше нет — после того, как вы написали приложение, вы можете делать с ним все что хотите. Собственно, избавить конечные приложения от лицензионных ограничений и было основной целью изменения политики.
Аналогично, организации не всегда нужно автоматизировать все и сразу мегавнедрением ECM (waterfall). Такие внедрения часто заканчиваются плачевно в силу разных причин. Лучше решать задачи постепенно, итерациями — но понимая общую цель и стратегию.
REvseev, я думаю, что частично ответил в комментарии выше. Конечно, процессы должны быть формализованы, Станислав не предлагает заменить процессы свободным общением. Но желательно, чтобы они отражали реальные эффективные рабочие процессы, сохраняя возможность изменений с минимальными трудозатратами — как с организационной, так и с технической точки зрения.
zhavoronok, статья в первую очередь о том, что стандартные agile практики ИТ могут также хорошо подходить не-ИТ бизнесу. И если вы внедряете у себя ECM систему, нужно в первую очередь смотреть не на стандарты, а на то, что реально происходит в вашей организации, автоматизировать то, что даст наибольший эффект, и так, чтобы людям стало работать проще, чтобы взаимодействия на всех уровнях были максимально простыми и эффективными, а не «по стандарту» или «по вертикали». Кроме того, и люди и софт должны быть готовы к изменениям процессов вместе с развитием бизнеса (что не отменяет необходимость их формализации).
Мы помогаем заказчикам выявить первоочередные задачи, и сформировать наилучшее решение. В результате мы часто внедряем систему итеративно (agile), так, чтобы решить наиболее насущные задачи в максимально короткий срок. При этом далеко не всегда при внедрении ТЕЗИС классический модуль канцелярии (входящие-исходящие, ОРД и прочее) является наиболее востребованным. Для бизнеса формальный документооборот редко является действительно критичной задачей. Например для Российского Регистра Морского Судоходства мы в первую очередь реализовали процедуры прохождения заявок на освидетельствование судов, освидетельствования в промышленности и флоте и только потом стандартное согласование договоров и канцелярию.
staskin1, правильным ответом будет «и то и то».
И agile, и waterfall — это концепции, реализация которых может сильно отличаться на практике. Если говорить упрощенно, для небольших проектов — например простое внедрение ТЕЗИС — мы используем waterfall модель. Требования понятны, можно легко написать спецификацию и рассчитать конечную цену внедрения. Очевидно, что это максимально комфортный вариант для заказчика. Необходимость изменений в таком случае обычно невелика, и формальный процесс управления ими (change requests) не слишком трудоемок.
Для крупных проектов — в основном это сложное корпоративное ПО, или масштабные внедрения продуктов ТЕЗИС или Sherlock — такой подход уже плохо работает. В большинстве случаев (скажу больше — во всех) на начальном этапе заказчик может сформировать лишь высокоуровневые требования к решению. Понимание деталей приходит по мере развития проекта, когда становятся понятными возможности системы и то, как они используются на практике. В таких проектах мы используем agile методологию. Детальное планирование и анализ требований осуществляются лишь на короткий горизонт ближайшей итерации — спринта (в нашей практике 1-2 месяца). Параллельно с разработкой ведется планирование следующего и т.д. Это дает гибкость в управлении изменениями и позволяет минимизировать ненужную работу. Например, детальное планирование всего проекта, когда мы наверняка знаем, что большая часть требований изменится. Или формальную реализацию функциональности по спецификации (она ведь подписана!), когда уже очевидно несоответствие спецификации реальным потребностям. В итоге мы экономим время и деньги заказчика.
С другой стороны, мы не можем применять «экстремальные» варианты agile процессов, в которых долгосрочное планирование отсутствует в принципе (хотя я думаю они хорошо подходят например для разработки компактных, но массовых продуктов на рынке b2c). И заказчик, и мы должны понимать конечную цель проекта, его архитектуру, основные принципы работы и взаимодействия компонентов. Поэтому обычно мы создаем roadmap, а также функциональную спецификацию на весь проект, покрывающую основные требования без деталей реализации. Это дает нам возможность примерно оценить общие сроки и бюджет проекта (с некоторой вилкой), и таким образом управлять ожиданиями заказчика.
Станислав, здравствуйте!
По поводу публикаций в блоге. Вы безусловно правы, мы преследуем определенные PR и маркетинговые цели. Как и 100% зарегистрированных здесь компаний. Спасибо за теплые слова про предыдущие статьи, но на мой взгляд данная публикация также вполне соответствует правилам и принципам Хабра.
Это не копипаст — статья публикуется впервые. Да, она написана не нашими сотрудниками, что честно указано в начале статьи. Мы хотели, чтобы статья получилась достаточно интересной широкому кругу читателей, и действительно полезной тем, кто стоит перед выбором системы — поэтому и обратились к Станиславу, обладающему и широчайшим опытом в данной области, и литературным талантом. Я считаю, что это было правильное решение и не вижу здесь ничего предосудительного.
Это не реклама (хотя обратите внимание — формально она разрешена в корпоративном блоге!) — статья достаточно объективна и никаким образом не выделяет какой-то продукт, надеюсь вы не будете это отрицать. Да, взгляд Станислава на стандарты или другие моменты может не совпадать с вашим (и кстати, с нашим) — но ведь это нормально, в споре рождается истина, не так ли?
В связи с этим мне непонятна ваша сентенция про «то что проходит на ура на многих известных площадках с заказным контентом и на сайтах собственных компаний тут мало кому интересно». Впрочем, для этого есть объективный показатель — отзывы пользователей Хабра.
Мы серьезно рассматривали вариант Open Source. Но вы совершенно правы, значительно легче поддерживать ограниченный круг клиентов. Ведь всегда останется бесплатная поддержка в виде ответов на форуме и т.п., и она требует много сил если делать качественно. По ценам мы ориентировались в первую очередь на стоимость разработки — если платформа поможет уменьшить трудозатраты на проект и дальнейшее развитие даже на 2-3 человеко-месяца, это уже выгодно. По нашим оценкам, уже для средних проектов экономия в разы выше. Для небольших проектов есть бесплатная лицензия (до 5 конкурентных) или достаточно дешевая до 20 конкурентных пользователей — что вполне может означать 50 и более уникальных. Поэтому мне кажется, что ценовая политика вполне разумная.
Согласен. У нас немного другой подход, мы стараемся длинные ролики не делать.
Вместо этого делаем отдельные по разным темам, мне кажется это удобнее.
Часть уже есть здесь: www.cuba-platform.com/ru/tutorials
Сейчас здесь в основном обзорные ролики по некоторым компонентам платформы, постепенно будем добавлять ролики непосредственно по процессу разработки. Все желаемое сразу к сожалению сделать не получается, так как это достаточно трудоемкий процесс.
Мы помогаем заказчикам выявить первоочередные задачи, и сформировать наилучшее решение. В результате мы часто внедряем систему итеративно (agile), так, чтобы решить наиболее насущные задачи в максимально короткий срок. При этом далеко не всегда при внедрении ТЕЗИС классический модуль канцелярии (входящие-исходящие, ОРД и прочее) является наиболее востребованным. Для бизнеса формальный документооборот редко является действительно критичной задачей. Например для Российского Регистра Морского Судоходства мы в первую очередь реализовали процедуры прохождения заявок на освидетельствование судов, освидетельствования в промышленности и флоте и только потом стандартное согласование договоров и канцелярию.
И agile, и waterfall — это концепции, реализация которых может сильно отличаться на практике. Если говорить упрощенно, для небольших проектов — например простое внедрение ТЕЗИС — мы используем waterfall модель. Требования понятны, можно легко написать спецификацию и рассчитать конечную цену внедрения. Очевидно, что это максимально комфортный вариант для заказчика. Необходимость изменений в таком случае обычно невелика, и формальный процесс управления ими (change requests) не слишком трудоемок.
Для крупных проектов — в основном это сложное корпоративное ПО, или масштабные внедрения продуктов ТЕЗИС или Sherlock — такой подход уже плохо работает. В большинстве случаев (скажу больше — во всех) на начальном этапе заказчик может сформировать лишь высокоуровневые требования к решению. Понимание деталей приходит по мере развития проекта, когда становятся понятными возможности системы и то, как они используются на практике. В таких проектах мы используем agile методологию. Детальное планирование и анализ требований осуществляются лишь на короткий горизонт ближайшей итерации — спринта (в нашей практике 1-2 месяца). Параллельно с разработкой ведется планирование следующего и т.д. Это дает гибкость в управлении изменениями и позволяет минимизировать ненужную работу. Например, детальное планирование всего проекта, когда мы наверняка знаем, что большая часть требований изменится. Или формальную реализацию функциональности по спецификации (она ведь подписана!), когда уже очевидно несоответствие спецификации реальным потребностям. В итоге мы экономим время и деньги заказчика.
С другой стороны, мы не можем применять «экстремальные» варианты agile процессов, в которых долгосрочное планирование отсутствует в принципе (хотя я думаю они хорошо подходят например для разработки компактных, но массовых продуктов на рынке b2c). И заказчик, и мы должны понимать конечную цель проекта, его архитектуру, основные принципы работы и взаимодействия компонентов. Поэтому обычно мы создаем roadmap, а также функциональную спецификацию на весь проект, покрывающую основные требования без деталей реализации. Это дает нам возможность примерно оценить общие сроки и бюджет проекта (с некоторой вилкой), и таким образом управлять ожиданиями заказчика.
По поводу публикаций в блоге. Вы безусловно правы, мы преследуем определенные PR и маркетинговые цели. Как и 100% зарегистрированных здесь компаний. Спасибо за теплые слова про предыдущие статьи, но на мой взгляд данная публикация также вполне соответствует правилам и принципам Хабра.
Это не копипаст — статья публикуется впервые. Да, она написана не нашими сотрудниками, что честно указано в начале статьи. Мы хотели, чтобы статья получилась достаточно интересной широкому кругу читателей, и действительно полезной тем, кто стоит перед выбором системы — поэтому и обратились к Станиславу, обладающему и широчайшим опытом в данной области, и литературным талантом. Я считаю, что это было правильное решение и не вижу здесь ничего предосудительного.
Это не реклама (хотя обратите внимание — формально она разрешена в корпоративном блоге!) — статья достаточно объективна и никаким образом не выделяет какой-то продукт, надеюсь вы не будете это отрицать. Да, взгляд Станислава на стандарты или другие моменты может не совпадать с вашим (и кстати, с нашим) — но ведь это нормально, в споре рождается истина, не так ли?
В связи с этим мне непонятна ваша сентенция про «то что проходит на ура на многих известных площадках с заказным контентом и на сайтах собственных компаний тут мало кому интересно». Впрочем, для этого есть объективный показатель — отзывы пользователей Хабра.
www.cuba-platform.com/ru/technologies
Вместо этого делаем отдельные по разным темам, мне кажется это удобнее.
Часть уже есть здесь: www.cuba-platform.com/ru/tutorials
Сейчас здесь в основном обзорные ролики по некоторым компонентам платформы, постепенно будем добавлять ролики непосредственно по процессу разработки. Все желаемое сразу к сожалению сделать не получается, так как это достаточно трудоемкий процесс.
www.cuba-platform.com/ru/quickstart