Сегодня в канале СППР+ ожидается развёрнутая публикация.

Кто искал теорию по оценке трудозатрат на проекте
Вот лёгкий материальчик для чтения.
Там есть про "Оценщик трудозатрат разработки (RICEF Estimator)"
И простенькая таблица базовых действий при разработке с оценкой в трудоднях.
Вперёд, колхозники!

Интересные мысли об аналитиках.
Изложено вполне системно.
Самое важный вывод - лучше тот аналитик, который работает быстрее, пусть выдаёт и не самое лучшее решение, лишь бы оно устраивало заказчика.
Сделать лучше, но качественней - это плохо, если это превышает ожидания заказчика, это ест лишнее время от проекта и от затрат у заказчика.
Ещё из искрящих моментов - наняли 50 аналитиков, уволили из них 35 (за год и менее судя по тексту).
UPD тезисы выше из статьи, а не мнение автора поста.

Потрясающая статья.
Мы тут печёмся как СППР внедрять и как с ней работать.
А ведь это вспомогательная система ИТ-ландшафта, а не основная.
В статье же изложено с нужного ракурса, именно с нужной точки зрения причины проблем автоматизации.
Косвенное подтверждение давнего вывода, что до 75-90% процентов проектов автоматизации за 20-30 лет мало/ или бес/ полезные проекты.

Здесь хороший теоретический свод про работу с требованиями.
Упоминается СППР как дополнение к Confluence и Jira, решающее основную проблему - сложность работы с требованиями как с элементами списка в Confluence

В "DNS технологии" используют СППР, по крайней мере, для ведения "Технических проектов" (понимаемых как задания на разработку).
Вообще в статье рассматривается технология разветвлённой разработки.
Где главная проблема - как не перегрузить хранилища конфигураций слиянием изменений и многоветочной разработкой.
По смыслу статьи, под каждый Техпроект открывается хранилище.
Т.е.
- для Техпроекта развёртывается хранилище конфигурации.
- Техпроект является разделителем направлений разработки и балансером нагрузки от разработчиков.

По смыслу Техпроекта в СППР он не является напрямую заданием на разработку (Разработчику).
Это агрегатор описаний планируемых модификаций.
Задания разработчику нарезаются из Техпроекта СППР отдельным видом документов СППР.
Была мысль использовать ещё один уровень Техпроектов для агрегации Техпроектов под отдельные виды разработки.

По запросу "СППР" ХХ выдаёт 101 вакансию за "всё время".
Это же число выходит при запросе "за месяц".
Чтобы это значило....

ЗАО "СППР"

Для борьбы со спамерами в чат введено условие, что новичок не может писать ранее какого-то времени после входа (какое время разумеется секрет, предположим 24 часа).
Если вы не новичок и есть проблемы написать в чат - сообщите админу.
Чай новая техника не всегда правильно умеет работать.

В канале СППР+ большая публикация по готовому функционалу.
Суть - про идеологию реализации конфигуратора в платформе (СППР) и работу с метаданными как с данными.
UPD
Через малое время обещана выкладка видео о работе в системе.

Неплохая простенькая памятка по BPMN
Особенно понравились схемы с движением потока (судя по комментам сделано в Comunda)
В статье и комментах есть упоминания используемых продуктов для рисования.
Comunda c дорожками - неплохо бы такую схему прикрутить в СППР для отрисовки Процессов и Шагов.

Для тех кто хочет использовать СППР и управлять кодом/разработкой,
вот статья по написание построителя AST-дерева (за два дня как же!).
Хотя СППР задумана для описания функционального дерева на уровне пользователя/архитектора,
а AST-дерево это структура кода на уровне программиста,
в сущности управление кодом означает, что требуется сравнить соответствие функционального СППР-дерева c АСТ-деревом.
Алгоритм на проекте такой:
- аналитик, архитектор выявляют процессы и строят функциональную структуру
- программист пишет код, как обычно, без оглядки на что там архитектор выстроил
- постфактум хотелось бы понимать, насколько написанный код соответствует задуманной архитектуре
- также хотелось бы оперативно делать такую сверку по ходу изменения обоих деревьев
Мэппинг двух деревьев был бы неплохим решением для управления или хотя бы понимания как код и архитектура соответствуют друг другу.

В канале включена возможность реакции в виде телеграмовских "звезд".
Посмотрим, что же это такое.
Звезду можно поставить также и там же как и простую реакцию - тапом по посту (правый клик мышкой)
и выбрать звезду как реакцию и количество звёзд.
Жаль что это нельзя сделать в чате, чтобы пользователи могли друг другу ставить звёзды за сообщения.
Но может пока...

Напоминание:
- для новых пользователей в чате работает запрет на сообщения в течение 24 часов
- работает фильтрация по отдельным словам на спамеров
- работает народный @banofbot - ответом на сообщение

Хорошо структурированная статья по принципам проектирования кода ПО (не самого ПО, а именно кода).
С примерами на 1С.
А кто продумывал как SOLID применить к проектированию на уровне функциональности пользователя - т.е. на уровне СППР?

В с вязи с известной историей, происходящей вокруг Телеграм,
не дай бог и закроют или ограничат,
на всякий случай, сообщаем резервные размещения канала/чата
1) Дзен
2) Вконтакте
На сейчас на Дзене только автоматически публикуются посты из канала.
Во Вконтакте сейчас нет вообще ничего, просто держится для резерва.
Для осторожных, проницательных, разумных, считающих тему полезной
и помнящих в какой стране и в какое время живём,
рекомендуется присоединиться к указанным каналам.

"Как с помощью СППР победить техдолг"
Очень интересное изложение методики использования СППР от Гринатом/Росатом.
СППР используется как баг-трекер (бек-трекер у автора).
В СППР направляются потоки:
1) изменения конфигурации разработчиком
2) сообщения в техподдержку
3) ошибки из журналов регистрации из сотен инфобаз (28 видов баз, 600 серверов, 750+ сотрудников)
4) сообщения о медленных запросах из логов на серверах о запросах выполняемых дольше 3 секунд
5) сообщения из SonarQube об ошибках в статистическом анализе кода
Всё это поступления в баг-трекер СППР техдолга.
Далее данные группируются (по видам баз, по конфигурациям, по разработчикам и т.д.)
Собирается и выдаётся также информация о динамике видов ошибок и их исправления.
Стажёры и новички обучаются на разборе ошибок из СППР, что позволяет им входить в курс дела.
Заявляется что реализованы и архитектурные проверки в СППР (объекты без ролей, ошибки в типах метаданных и еженедельно анализируется

поиск объектов, на которые в конфигурации нет ссылок;
метаданные с программно-включённой историей изменений;
регистры с большим количеством измерений;
незакрываемые регистры накопления остатков;
документы без проведения или движений;
метаданные с некорректной длиной кодов / номеров;
регистры с пустыми ресурсами;
объекты, для которых не созданы роли доступа.

Весьма неплохо.
Из первого на что обратил внимание - вроде не заявлено что собираются автоматически все регистрации ошибок
во всплывающих окнах 1С - о которых часто не сообщают пользователи).
1С объявляло функционал регистрации таких ошибок, но если они в логах и техжурналах ловятся, то может Гринатом их и находит.

Ниже про разработку, основанную больше на архитектуре "от управления проектом" - вышло новое видеоописание

Коллеги, добрый день. Сейчас управляю проектами перехода с SAP на ERP  в общей сложности на 8 промышленных заводах. По ссылке (https://rutube.ru/video/private/52934c0c5d21d573e78d191cd88dd597/?p=0kdqEv-vAgS1eBqlsbgl2w) обзорное видео как организована работа РП, архитекторов и аналитиков. Описываю 3 подсистемы – непосредственное управление дорожной картой, бизнес-процессное моделирование и управление заявками и SD в целом. Как создавать и обновлять wiki   на своих проектах мы не используем WORD-Excel, не используем платных трекеров.  В общем, надеюсь опыт будет интересен. Буду рад любой обратной связи.

Весьма примечательное готовое решение для работы аналитика и архитектора с требованиями и проектами.
Архитектура самого решения полностью переработана и не совпадает с СППР.

Какие в ней плюсы:
1. Архитектура проектного решения ИС и бизнеса отделена от Управления проектами,
но вместе они соединяются через требования
2. Есть возможность интеграции с графикой drawio и archimate - схемы процессор рисуются и привязываются к объектам
3. Сквозная взаимосвязь требований и объектов/функций системы
4. Требования декомпозируются
5. Есть модели для описания бизнеса и модели ИТ-системы
6. Модели, требования и задачи из этапа в этап проекта могут копироваться.
Например: модель составленная на этапе "предпроектное обследование" может быть полностью перенесена в этап "разработка"
- очень удобно учитывать изменения в архитектуре, сделанные по ходу проекта. Есть сравнения изменений.
7. Есть возможность описания интеграций между базами (системами), в т.ч. и не1С. Например с excel-системой.
8. Очень удобные сквозные переходы и отслеживания взаимосвязей моделей, объектов, требований, задач проекта.
9. Система может прямо сейчас помочь архитектору быстро и несложно привести в порядок работу команды
с выдачей задач на разработку и тестирование и отслеживанием изменений в версиях проекта, моделей, требований.

Какие замечены минусы:
1. Не очень понятна связь с объектами метаданных и функциями
2. Тестирование (Ванесса) отсутствует напрочь как функция а значит тестирование не соединить с описанием бизнес-процессов
3. Интерфейс организован весьма неплохо и удобно, но есть подозрения, что для больших проектов всё равно будет сложновато.
4. Возможно личная профтрагедия у Пионтика и закрытие проекта "Архитектура как код" :)
(шуткен, но не почти, но чертовски неплохо отрисовка графики бизнес-процессов и документирование наложены на слои (домены) архитектуры бизнеса и архитектуры ИС и ПО,
у Пионтика, кстати, методика избегает работы с описанием архитектуры ПО - она больше под архитектуру бизнеса и ИС)
5. Есть другие подозреваемые подводные камни, но пока умолчу, это лучше обсуждать в чате. Выдвигайте свои соображения.

Рекомендуем посмотреть видео по системе и оценить насколько она поможет аналитикам и архитектору быстро организовать работу на проекте и сопровождении.
Автор разработки есть в чате @VitaliyZaporozhskiy
Виталий, моё почтение! Продукт сделан весьма перспективный и полезный уже сейчас.

О чём подумалось.
Эту бы разработку соединить бы с:
* СППР+ Сазонова (сейчас там фантастически реализован конфигуратор в платформе и работа с метаданными)
* СППРподERP Дениса Ермолаева (там глубже чем у Виталия сделано управление проектами - под договорное управление)
* Системой управления развёрткой баз/конфигураций под ветки разработки от @JaneGlass73 (на условиях, что система будет перепилена на работу с конфигуратором из работающего сейчас исходника под EDT)

Ваше мнение советы и идеи на эту тему могут быть полезными, ждём их в чате!