Renga collaboration server для чего
Коллективная работа над проектом в Renga и Pilot-ICE
Продолжаем цикл статей, посвященных системам информационного моделирования, разрабатываемых компанией Renga Software. Мы уже рассказали вам о BIM в целом, а также о программах для архитектурно-строительного проектирования: Renga Architecture и Renga Structure. Сегодня мы поднимем тему коллективной работы нескольких специалистов над одним проектом и расскажем, как система Pilot-ICE может нам в этом помочь.
Рассмотрим первый вариант взаимодействия, когда в проектной организации используются только BIM-системы Renga. Тогда сценарий работы может выглядеть следующим образом:
После чего архитектору передается обновленная, проработанная с конструктивной и информативной точки зрения модель. То есть происходит поочередная работа с одним и тем же файлом, вся информация сохраняется и не искажается.
При такой схеме взаимодействия система управления проектной документацией Pilot-ICE может быть очень полезна с организационной точки зрения, ведь BIM – это не только информационная модель, но и процедура согласования выбранных проектных решений.
Разработанные чертежи публикуются в нередактируемых форматах, таких как .xps или .pdf, для дальнейшего обсуждения и проверки всеми участниками проекта, включая внешние организации. Если в процессе согласования возникнут замечания, то в системе есть все необходимые инструменты для проставления как текстовых, так и графических аннотаций. Можно вести переписку по замечаниям, видеть весь перечень замечаний к каждой версии электронного документа и т.д.
Второй вариант работы по технологии информационного моделирования – это использование более одной BIM-системы и, как правило, от разных разработчиков. Этот вариант более жизнеспособен, т.к. одно программное решение или интегрированная система не могут закрыть все проектные задачи, стоящие перед организацией при разработке проекта. Вероятнее использование смешанной среды из систем для решения конкретных задач, между которыми организована эффективная связь на основе информационных моделей, согласованных процессов и методов, а также общей терминологии.
И в этой связи хотелось бы напомнить про формат IFC, разработанный buildingSMART (International Alliance for Interoperability, IAI) для упрощения взаимодействия в строительной индустрии.
В этом случае, коммуникации специалистов между собой также может помочь Pilot-ICE. За счет возможности отслеживать версионность файлов с чертежами и другими проектными данными, разграничения прав доступа к тем или иным файлам, удобной процедуры согласования. Однако, у специалистов не получится работать с единой 3D-моделью.
Для реализации подобного взаимодействия, компанией АСКОН ведется активная работа над созданием Pilot-BIM Server, который в скором времени будет представлен широкой общественности.
В этом случае, каждый отдельно взятый специалист разрабатывает BIM-модель в рамках своей предметной области и в своем специализированном инструменте, а благодаря Pilot-BIM Server происходит междисциплинарная координация и автоматическое формирование единой глобальной модели. Такое организованное взаимодействие может обеспечить до 50% сокращения непроизводительных расходов проекта. А при согласовании моделей точно так же будут доступны инструменты создания замечаний и ведение переписки по ним.
В следующих статьях мы продолжим знакомить вас с системами Renga, расскажем о возможности получения смет из BIM-модели, примеры и кейсы практического использования Renga Architecture и Renga Structure, рассмотрим проблемы внедрения технологий информационного моделирования на предприятиях и многое другое.
О Renga от R&D
Поиск по этому блогу
Важное о совместной работе в Renga
У всех специалистов, работающих над проектом в Renga, одинаковые права. В любой момент специалист может внести необходимое изменение в модель, чертеж, спецификацию или таблицу.
Преимущество такой методологии заключается в том, что при согласованной работе команды вы не тратите ценное время на бюрократические проволочки.
Конфликты появляются, если в команде нет согласия, или если люди торопятся.
Налаживание процесса работы в команде понадобится при работе в любом программном обеспечении. Общие рекомендации по организации совместной работы приведены в одной из наших статей. Основная мысль заключается в том, что для работы в команде необходимо договариваться и действовать сообща.
По запросам в Службу технической поддержки, мы видим, что больше всего конфликтов происходит именно на первом этапе внедрения Renga для совместной работы над проектами. По этим запросам мы улучшаем совместную работу Renga, корректируем требования и рекомендации.
Renga Collaboration Server необходимо устанавливать на выделенный сервер. Это требование связано с тем, что при установке серверного приложения на клиентские компьютеры, увеличивается вероятность непредвиденного сбоя системы и, как следствие, увеличивается вероятность потери данных. Компьютер, на который установлен Renga Collaboration Server, нельзя выключать и перезагружать без предупреждения, нельзя запускать ресурсоёмкие приложения, у него обязательно должен быть резервный источник питания. Если сервер будет перезагружаться или его память будет полностью занята другими процессами, то рано или поздно это может привести к проблемам с совместной работой над проектом.
Настройте резервное копирование проектов, как на сервере, так и на машинах пользователей. Где хранить локальные копии каждый определяет самостоятельно, а на сервере настройте резервное копирование папки Projects, расположенной в папке установки Renga Collaboration Server, по умолчанию C:\Program Files\Renga Collaboration Server\Projects.
При совместной работе через интернет, используйте стабильное соединение.
Не работайте в одном файле на общем диске. У каждого участника совместной работы должна быть своя копия проекта на локальном диске.
Информируйте коллег о том, над чем вы работаете.
Синхронизируйте проект, как можно чаще, чтобы не допустить конфликтов или во всяком случае отследить возможные конфликты как можно раньше.
При работе над проектом в совместной работе не меняйте имя пользователя. Синхронизация должна выполняться тем пользователем, который внес изменения, в противном случае изменения будут отброшены сервером.
Заглядывайте в Журнал проекта. Для удобства отслеживания изменений, пришедших от других пользователей, мы добавили команду Открыть журнал проекта в меню Синхронизировать, расположенном в Основном меню Renga.
В спорных ситуациях, обращайтесь к Журналу проекта на сервере, так как в него записываются все изменения проекта с именем пользователя. Имена журналов проекта на сервере и на компьютерах пользователей и имя файла проекта на сервере совпадают. Для просмотра журналов мы рекомендуем использовать табличный редактор или систему бизнес-анализа, то есть специализированный инструмент, в котором можно сортировать и фильтровать данные.
Надеемся, что в ваших проектах не возникнет конфликтов, спасибо всем за отзывы, мы продолжаем совершенствовать совместную работу. Следите за новостями!
Совместная работа
С помощью Renga вы можете вести параллельную совместную работу разных пользователей над проектом.
Чтобы начать совместную работу:
Для настройки сервера запустите установку Renga Collaboration Server и следуйте указаниям установщика.
Нажмите Параметры, чтобы указать папку установки, порт подключения к серверу и интервал опроса.
Убедитесь, что указанный порт подключения открыт в брандмауэре Windows.
Настройте Интервал опроса, чтобы сервер мог вовремя определить и отключить недействительное подключение, и в случае неполадок в сети пользователь мог подключиться к Совместной работе снова.
Все изменения, произведенные в модели до синхронизации, сохраняются в локальной копии на устройстве пользователя и не видимы для других участников проекта.
Синхронизация должна выполняться тем пользователем, который внес изменения, в противном случае изменения будут отброшены сервером.
Журнал проекта
После публикации проекта на сервере в папке установки Renga Collaboration Server\Projects ведется журнал проекта. В нем описываются все изменения проекта после публикации.
На компьютере пользователя в папке %LocalAppData%\Renga Software\Renga также ведется журнал проекта, в котором отображаются действия пользователя и изменения, пришедшие при синхронизации.
Имена журналов проекта на сервере и на компьютерах пользователей и имя файла проекта на сервере совпадают.
Чтобы сохранить текущее состояние журнала в удобном расположении на диске:
Для просмотра и анализа журналов проекта рекомендуем использовать табличный редактор или систему бизнес-анализа.
О Renga от R&D
Поиск по этому блогу
Организация совместной работы
Сегодня хотим обобщить сведения о совместной работе Renga на текущий момент.
В статье Совместная работа в Renga: от теории к практике мы разбирали виды взаимодействия между людьми и определили, что проектирование относится к сотрудничеству. То есть при проектировании здания люди работают вместе для достижения общих целей, при этом происходит обмен знаниями, обучение и достижение согласия.
Не будем повторять содержание той статьи, давайте подумаем о том, как организовать процесс проектирования так, чтобы все были довольны.
Renga может позволить вашей организации перейти на гибкие методологии проектирования. Информации на тему гибких методологий и их внедрения вы можете найти множество, но мы бы хотели особенно выделить один из принципов, который положен в их основу:
«Люди и их взаимодействие важнее процессов и инструментов».
То есть нужно наладить диалог как внутри команды, так и с заказчиками, чтобы результат совместной работы в итоге удовлетворил всех.
Исходя из этого, мы предполагаем, что работа над проектом с помощью Renga будет происходить примерно так:
На каждом рабочем месте есть журнал, в котором в случае появления спорных моментов можно посмотреть, кто внес изменения принятые при синхронизации, а затем что-то уточнить у коллеги.
Руководитель также может следить за выполнением работы, синхронизируясь с сервером, и вносить свои правки или уточнять исходные данные.
Мы рекомендуем как можно чаще синхронизироваться, чтобы у всех членов команды всегда была актуальная модель. Любые спорные моменты необходимо решать в разговоре перед тем, как внести необратимые изменения.
Понятно, что так или иначе архитектор и конструктор будут работать, например, над всеми колоннами. Допустим, конструктору нужно указать, как армировать стену, а архитектору определить отделочные материалы, например, марку и цвет краски. В данный момент в Renga неделимые данные, которые передаются при синхронизации целиком, это объект. Так что если все-таки два смежных специалиста будут одновременно изменять параметры одного объекта, то возникнет конфликт, и будут приняты изменения только того участника проектирования, который синхронизируется первым. Это, конечно, отразится в журнале совместной работы.
Чтобы исключить такую ситуацию, предупреждайте коллег о том, с каким участком вы будете сейчас работать. Это не будет лишним и предотвратит возникновение конфликтов как программных, так и личных.
Проводите ежедневные встречи, показывайте, что вы сделали накануне, рассказывайте, с какими объектами вы будете работать сегодня, это не займет у вас много времени, но позволит избежать многих недоразумений и наладить контакт с коллегами и успешно выполнить проект.
Возможно, в вашей организации процесс поставлен именно так, как мы думаем. А может быть вы считаете подобную гибкость совершенно лишней. Главное, чтобы процесс, установленный в вашей организации, всех устраивал и приводил к хорошим результатам. Для управления процессом проектирования вы можете внедрить подходящие вам практики, использовать специализированные системы, но главное — оставайтесь на связи.
Если вы уже используете Renga в совместной работе, мы будем рады, если вы поделитесь тем, как построен процесс проектирования у вас.
Команда разработчиков Renga: как мы достигли идиллии, работая без менеджеров
7 команд и ни одного менеджера – думаете, такое возможно? Мы построили процесс, в котором показываем на каждом демо по 1-2 фичи от команды, проводим ретро команд, ретро релизов и при этом получаем реальное удовольствие от работы. Хотите организовать свою работу так же? Тогда добро пожаловать под кат.
Renga Architecture – система для архитектурно-строительного проектирования. Программа создана для максимальной помощи проектировщику в решении его задач: создание архитектурного облика здания и информационной модели, и быстрая компоновка чертежей согласно стандартам СПДС и многое другое.
Renga Structure — cистема для проектирования конструктивной части зданий/сооружений. Программа для инженеров-конструкторов и проектировщиков по созданию информационной модели здания или сооружения и получению чертежей марок КР/КЖ/КЖИ/КМ/АС.
Семейство продуктов Renga предназначено для проектирования по технологии BIM. Высокая производительность систем позволяет работать с большими проектами без видимого снижения качества работы с 3D-моделью:
Объектное проектирование
Создание в Renga 3D-модели здания/сооружения инструментами объектного проектирования (стена, колонна, окно и т.д.)
Коллективная работа
Обмен хранение и управление данными осуществляется с помощью BIM-Server Pilot
Взаимодействие со сметными системами
Интеграция Renga посредством API со сметными системами 1С-смета и ABC-смета для взаимодействия проектного и сметного отделов.
Автоматизация получения спецификаций и ведомостей
В Renga реализована функция получения отчетов для формирования спецификаций, ведомостей и экспликаций.
Автоматизация получения чертежей
По данным 3D-модели автоматически получаются виды (фасады, разрезы и планы) и размещаются на чертежах в заданных масштабах.
«Пусть лучше падает приложение, чем спроектированное здание»
— Шутка архитектора
Итак, наш департамент разработки состоит из 28 разработчиков, 3 продуктовых аналитиков и 6 тестировщиков. Каждая команда включает продуктового аналитика, тестировщика и четырех разработчиков. Мы следуем всем обязательным активностям скрама – спринты, планирование, ретро, демо, ежедневные стендапы. Более того, мы используем некоторые фишки из SAFe (Scaled Agile Framework) для синхронизации работы нескольких команд – еженедельные синхронизации команд, ретро релиза раз в 3-4 месяца. Есть у нас и не совсем обычная активность – мы ее называем груминг (grooming), на которой разбираем бизнесовую фичу вместе со всей командой и аналитиком и получаем список всем понятных требований к фиче и критериев готовности (DoDs).
Грумить или не грумить, вот в чем вопрос
В классическом скраме, как вы знаете, существует активность “Планирование”, на которой обязательно присутствует продуктовик (product owner), команда разработки, тестировщики и другие заинтересованные (stakeholders). В процессе планирования вырабатывается цель спринта, состав фич или стори (user story) для разработки. Присутствие product owner’а – обязательное условие успешного планирования, ведь только он может ответить на нестандартные вопросы о фиче, которые приходят в голову опытным (и не только) разработчикам при осознании цели фичи и в процессе декомпозиции ее на задачи.
Здесь кроется первый подводный камень классического скрама – как сделать возможным присутствие продуктовика на планировании 7-ми команд в один день? Может, есть возможность рассинхронизации команд и проведения планирования в разные дни? Получается, что product owner проведет 7 дней из 14, выделенных на спринт, на планированиях. Кроме того, в такой рассинхронизации становится непонятным, как проводить демо, на котором хочется показать интегральный результат работы всех команд?
Мы решили эту проблему. Планирование проводится только командой. На планировании команда занимается декомпозицей заранее подготовленных и разгрумленных фич, для которых уже сформированы критерии готовности. Таким образом, на планировании каждый в команде (если он/она внимательно слушали и активно участвовали в груминге) знает, что именно нужно сделать в той или иной фиче. Это экономит время product owner’а и позволяет синхронизировать планирование команд и проводить их в один день.
Особенность нашего скрама заключается как раз в проведении специальных активностей – грумингов фич. На них присутствует product owner, вся команда, которая будет разрабатывать фичу, тестировщики, технические писатели и все заинтересованные. Продуктовик рассказывает, о чем будет фича, как это должно выглядеть и основные сценарии использования. В процессе груминга любой присутствующий может задавать любые вопросы касательно функционала, сценариев использования, краевых условий. Как правило, несмотря на подготовленность фич от product owner’а, постоянно возникает 2-3 ключевых вопроса от присутствующих, которые могут отразиться на аналитике фичи и повлиять на ее конечный вариант. Кроме того, по вопросам, не принципиальным для аналитики, разработчики могут сами принять решение, как именно реализовать тот или иной функционал. Длительность активности зависит от сложности фичи и длится от 30 минут до 5 часов.
База знаний формируется, в том числе, из таких настенных записей
Таким образом, получается достаточно дорогая активность по трудозатратам. Но это единственный минус грумингов, плюсы которого очевидны и в значительной степени перевешивают время, затраченное на обсуждение. Некоторые плюсы я уже упоминал, пройдемся по ним еще раз:
Сами себе менеджеры
Спринты разработки у нас длятся десять рабочих дней. Между спринтами есть день для демо и ретро и день для планирования следующего спринта. В результате спринты не привязаны к дням недели, а только к абсолютному количеству рабочих дней.
У каждой команды есть командный чат в телеграм, который позволяет оперативно обсуждать все вопросы разработки, организации активностей, а также вопросы политики и религии. Проведение ретро, ежедневных стендапов, планирования, как правило, инициируется разными разработчиками, у кого есть время написать в чат. Ответственным за проведение активности может быть любой разработчик, кто пожелает. Назначаем время активности, собираемся командой и обсуждаем. Как правило, в каждой команде есть опытный тимлид, который также обладает хорошими soft skills, что позволяет не уводить обсуждения в сторону. Хотя, в каждой команде soft skills хорошо развиты у большинства разработчиков, что позволяет конструктивно обсуждать вопросы и сводить к минимуму время, затрачиваемое на не конструктивные обсуждения. Результатами большинства обсуждений становятся записи на маркерной доске, фото которой бережно хранятся в архивах чата и в облачном хранилище для истории.
Планирование
Задачи на планировании оцениваются в абстрактных рабочих часах, которых в рабочем дне мы оптимистично полагаем целых пять. То есть, если на задачу по оценке уйдет день, то мы оцениваем ее в пять часов. Используем для оценок покер планирования. Если оценки расходятся, как правило, это говорит о том, что кто-то из участников знает больше, чем другие. Таким образом, выравнивается понимание контекста задачи и, как следствие, переоценка задачи.
Почему мы не используем для оценки попугаев или story points? Со временем мы пришли к выводу, что команде важно правильно оценивать скорость разработки, чтобы давать правдоподобные обещания по разработке фич в очередном релизе. Основной критикой оценки в часах является зависимость от опытности разработчика и степени его знакомства с участком кода. В это же время story points позволяют оценивать объем работы без привязки к конкретному разработчику. Но что произойдет, если в очередном спринте задачу в, например, 3 story points возьмет новичок? Он потратит на нее 3 дня, в то время, как опытный управится за 1 день. Таким образом, скоуп спринта перестанет быть привязанным к временным рамкам спринта. Мы же в процессе планирования выравниваем именно время на задачу. Бывает, что опытный разработчик оценивает задачу в два часа, а неопытный – в пять часов. После обсуждения окончательной оценкой скорее всего станет пять часов. Таким образом, мы потенциально завышаем оценку задачи, но зато защищены от невыполнения обязательств по разработке скоупа спринта.
Помимо декомпозированных задач, для фичи обозначается багпул (bugpool), который также оценивается, в том числе тестировщиком. Смысл его состоит в обозначении степени неопределенности для потенциальных багов в фиче. Кажется, что можно принимать неопределенность всегда за 30-50%. Тем не менее опыт показывает, что неопределенность зависит от контекста самой задачи. Например, баги в задаче, связанной с нетипичным использованием GUI или неизвестной части Qt, наверняка станут головной болью. В это же время фича на расширение известного функционала понятна и предсказуема. Это позволяет нам иметь запас часов в спринте на починку багов, помимо основной оценки времени на разработку.
Ретро
Закончить рассказ хочется на самой позитивной активности спринта. Ведущий ретро, как правило, выбирается по правилу: кто дольше всех не вел ретро. На ретро мы составляем список позитивных и не очень моментов. Как правило, в части плюсов бывают записи вроде “Показали на демо 3 фичи”, “Починили сложный баг”, “Отметили день рождения команды”. В части минусов встречаются наоборот “Не успели доделать фичу”, “Нашли невоспроизводимый баг”, “Нашли архитектурную проблему”. По каждому минусу, как правило, проходит бурное обсуждение, которое выливается в конструктивные предложения и соответствующие улучшения. Особенно приятно перечитывать предыдущие ретро и видеть, как с каждым спринтом мы не возвращаемся к прежним минусам.
На каждом ретро настроение отличное, но некоторые минусы бывают очень серьезными: “Даня недостаточно настойчив”
На посошок
На повестке остались не освещенными вопросы проведения синхронизации команд, демо, планирования релиза, ретро релиза. В следующих статьях обязательно расскажу об этом и о многом другом.
Присоединяйся к нашей команде разработчиков без менеджеров. Попробуй нашу BIM-систему – спроектируй дом своей мечты.
Анатолий Осокин, ведущий инженер-программист, Renga Software.