Вне зависимости от методологии разработки ПО, каждая команда сталкивается с этапом планирования и оценки задач. Есть те, кто привык оперировать человекочасами и человекоднями, есть те, кто уверовал в мощь и эффективность оценок в абстрактных величинах, таких как Story Points (далее SP). У этой статьи нет цели доказать превосходство одного подхода к оценке над другим. В ней речь пойдет об истории одной команды, которая пожила четыре спринта с оценками в часах, перешла на SP, а спустя девять спринтов подумывает о том, не вернуться ли к первому подходу.

На каждом из этапов казалось, что сделанный выбор логичен и обоснован. На самом деле, это был один большой эксперимент по поиску способа, как команде попадать в оценки и цели спринта. Набитыми шишками и выводами делимся с вами.

«Разработка по Agile» не предполагает точных сроков реализации функциональности, но каждому владельцу продукта прилетает в неделю сотни «А когда будет готово...?». Даже когда продукт находится на этапе погружения команды в бизнес‑контекст и не завершены исследования, требуется определить сроки выхода MVP, ведь продукт или фича нужны «вчера» и важность стратегического планирования на квартал или год никто не отменял. Рассмотрим ситуацию, когда продукт не находится на ПРОДе и нет точного состава MVP.

Цель статьи — рассказать об оценке бэклога в полной неопределенности.

Прежде, чем выдвигать гипотезы по срокам, важно сделать ряд «приседаний» с командой после дискавери‑фазы: это декомпозировать продукт на фичи, определить MVP, составить USM и только потом с видением продукта приходить к архитекторам и команде, чтобы обсудить не просто оценки, а реализацию и зависимости. Здесь сталкиваемся с рядом проблем задач, например, если команда оценивает бэклог в SP, что невозможно и не правильно переводить в человеко‑дни, а положить SP на календарный график и диаграмму Ганта нереально (подробнее о SP туточки) или есть зависимости от фичей смежных команд и сроки их реализации еще неизвестны, или архитектура еще не готова и остается только выдвигать гипотезы, как будет реализовано. Вот здесь начинается интересный квест.

Владелец продукта вместе с командой разработки могут выбрать такой вариант: оценить риски, заложить время на дополнительные исследования и еще что‑нибудь — в таком случае мы окажемся с MVP через год‑два, что не подойдет никому. И ведь одной из важных задач продакта — это урезать функциональность на MVP по всем канонам и сделать быстро/дешево. В связи с этим рассмотрим шаги для проведения первичной оценки, когда есть понимание функциональности, но еще не проведен подробный бизнес‑анализ. Забегая вперед, это не «красная таблетка» и эти шаги не спасут от возможных изменений состава MVP, переприоритезации или влетающих новых важных задач. Ниже описанные шаги дают вектор движения и помогают сформировать ответ на вопрос «Когда?», не скатываясь в Waterfall.

Всем привет!

Меня зовут Марина, я инженер по нормативно-справочной информации (НСИ) компании Bimeister. Наш отдел занимается формированием баз данных оборудования (БДО) и баз данных нормативов (БДН) для создания цифровых моделей производственных активов в ПО Бимейстер.

Формирование НСИ при оцифровке производственных активов, это сложная технологическая задача, требующая участия серьезной команды инженеров, хорошо понимающих специфику деятельности конкретного производства и его технологических систем. В нашей команде более 50 инженеров НСИ, специалисты по надежности, большая группа специалистов по оцифровке документации.

Работа сложная, требующая внимания, терпения и времени. Много различных процессов и этапов.

Мы находимся в постоянном поиске вариантов оптимизации текущих процессов формирования НСИ.

Летом 2022 года в нашей компании прошла серия митапов на тему «Система менеджмента качества и моделирование бизнес процессов». Тема заинтересовала меня потому, что давно были идеи по улучшению рабочих процессов и я решила поучаствовать. После интенсива и обучения я овладела навыками моделирования бизнес-процессов (БП) в нотации BPMN 2.0. При моделировании рабочих процессов и их анализе была предложена оптимизация некоторых из-них.

В этой статье расскажу об опыте, знаниях, идеях и как мы в команде улучшали рабочие процессы.

Angular CDK имеет широкие возможности для скроллинга плоского списка. Если размер каждого элемента одинаков, то можно воспользоваться FixedSizeVirtualScrollStrategy: всего лишь нужно прокинуть размер элемента в пикселях, проитерироваться по данным и виртуальный скроллинг готов. Но что делать, если размер элементов разный? Данную проблему можно решить кастомной стратегией виртуального скроллинга. В данной статье мы рассмотрим как построить такую стратегию для pdf-документов.

Выгорать нельзя гореть

Чтение ФТ — занятие непростое. Восприятие новой информации и её анализ требуют продолжительной концентрации и расходуют главный ресурс IT‑шника — внимание.
Если текст сложный, читатель спотыкается в нём и увязает, перечитывает по несколько раз, тратя время и ресурс внимания.

В статье расскажу про простые приёмы для начинающих писателей требований, которые помогут сделать их легче для чтения и ориентирования.

Всем привет! Меня зовут Марат и я занимаюсь разработкой высокодетальных 3D-моделей оборудования в компании Bimeister.

Расскажу про то, как мы создаем огромную базу 3D-моделей для промышленных предприятий и какие инструменты при этом используем.

Итак, сейчас у нас стоит задача разработать без малого 5000 детальных 3D-моделей оборудования, функционирующего в составе действующего нефтехимического промышленного комплекса. В дальнейшем, эти цифровые модели будут использоваться в нашей системе Bimeister, в составе эксплуатационной информационной модели предприятия.

Мы выбрали не самый легкий путь.

Приветствую, дорогие читатели, меня зовут Алексей Федулаев. Я работаю на позиции DevSecOps в компании Bimeister и делаю наши продукты безопаснее.

Данная статья будем по мотивам моего выступления на конференции Highload++ 2022, где я рассказывал про “Построение архитектуры с использованием формальных моделей безопасности”. В статье мы узнаем:

Всем привет! Меня зовут Настя и я инженер-конструктор в компании Bimeister. В данной статье хочу поделиться нашим опытом внедрения технологий информационного моделирования (ТИМ) на стадии эксплуатации в живых проектах цифровизации.

Сейчас много хайпа вокруг этой темы – цифровые модели…это панацея от всех болезней! Куча мега-специалистов заявляет, что они знают, как правильно создавать «цифру». Куча людей создает цифровые школы, отдельные дома и целые жилые микрорайоны, и это круто и вызывает уважение! Но мало кто рассказывает о реальных проектах цифровизации промышленных объектов.

Привет, Хабравчане! Меня зовут Валентин, я backend‑разработчик в компании Bimeister.
Уже почти как год вместе с командой разрабатываем новый продукт с применением Domain‑driven design подхода. Как же так получилось?

Так вот, разработка начиналась совершенно с нуля и это была хорошая возможность применить данный подход и попробовать его на практике. В момент начала разработки, перед нашей командой сразу встал вопрос: «А как же хранить аггрегаты, сущности, value‑object'ы в базе данных с использованием EF Core? ». Если вы только начинаете применять DDD и перед вами и вашей командой встала такая же проблема, то эта статья поможет вам приблизиться к ее решению, да пребудет с вами сила Эванса!