Не смог в этом году поехать на ЛАФ, но пристально слежу за докладами (и читаю обзоры Макса Цепкова, большое ему спасибо!). Всегда очень интересно — про что говорит сообщество, какие темы актуальны.

Встретил упоминание доклада "Практические подходы к измерению KPI аналитиков на Agile-проектах", и тут у меня прямо всё встрепенулось! KPI и Agile в одном предложении! Тут, как говорится, или крестик снимите, или трусы наденьте. Из разных миров слова. Или уж KPI и прочие корпоративные радости, или agile с самоорганизующимися командами и самоулучшающимся процессом, уважением к способу работы команды и фокусом на поставке бизнес-ценности.

А работа по спринтам — это ещё не agile, это просто способ организации работ короткими итерациями, при чем тут agile. Из него, наоборот, ту ещё соковыжималку можно сделать при желании.

Интересно, конечно, будет сам доклад посмотреть — что там автор про KPI думает и про Agile. А у вас, дорогие читатели, какой опыт?

ChatGPT нарисовал вполне приличную форму. Тут уже можно про что-то говорить, вполне неплохо. Надо будет попробовать объяснить ему какие-нибудь дополнительные принципы UX, и уже можно использовать!

К вопросу про инженерные практики. Несомненно, одним из признаков инженерной деятельности, кроме справочников, являются стандарты. И по требованиям, конструированию и архитектурному проектированию систем стандарты как раз есть, и даже много. Причем не только ГОСТ 34 родом из 70-х, который только состав документов регламентирует (и который, вообще говоря, очень хорош, как чек-лист, если вы проектируете в целом систему, а не только ПО). Есть и более современные и интересные стандарты.

Например, ГОСТ Р 59795-2021, заменяющий старый РД 50-34.698-90, в котором указано - что именно писать в разных документах, про которые рассказывает ГОСТ 34.201-2020 и, в частности, именно про документ Технического задания по ГОСТ 34.602-2020. Там, конечно, свой язык, и не всегда можно догадаться, что "Схема функциональной структуры" - это контекстная диаграмма + диаграмма контейнеров из модной C4model, "Ведомость покупных изделий" по сути является списком зависимостей, а "распределение действий между персоналом и техническими средствами при возникновении различных ситуаций при решении задачи (комплекса задач)" мы сейчас называем use case'ом.

Но есть и более крутые стандарты! Например, горячо любимый мной ISO/IEC/IEEE 29148:2018 Systems and software engineering — Life cycle processes — Requirements engineering. Меня часто спрашивают про книги, а я сам уже давно почти никаких книг не читаю, разве что по архитектуре (по ней пока мало стандартов). Я читаю стандарты и руководства, да ещё научные статьи. И по инженерии требований рекомендую в первую очередь ISO 29148 и Руководство по написанию требований от INCOSE. К сожалению, найти их в свободном доступе довольно сложно (если вы инженер, то вам компания этот стандарт купит за какие-то там жалкие 208 CHF). К счастью, пару недель назад Константин Валеев сделал прекрасный обзор этого стандарта на канале моего коллеги по Школе системного анализа и проектирования: https://www.youtube.com/live/H71XEhXBsHY

Эти два документа - стандарт и руководство - единственные из известных мне говорят о том, как же, всё-таки, писать требования, а не просто о чём их писать. Какие формулировки использовать. Как управлять требованиями, какие у них есть атрибуты, и что писать в сами требования, а что в атрибуты. Как отличить качественные требования, и что вообще означает "качество" применительно к требованиям. На русский язык этот стандарт не переведен (в отличие от Руководства, которое, впрочем не так-то просто купить, хотя оно на русском как раз есть, я даже немного участвовал в его переводе).

Зато на русском есть удивительный ГОСТ Р 59194―2020. Это стандарт представляет перевод некоторой части ISO 29148, касающуюся как раз формулировок и атрибутов требований (впервые на русском!). Например, там есть пункт "Каждое требование должно быть уникально идентифицировано для обеспечения прослеживаемости в ходе разработки. Уникальный идентификатор требования не изменяется в ходе ЖЦ объекта, в том числе при внесении изменений
в требование.", что, по сравнению с ГОСТом 34 невероятный прогресс! (Ссылки на ГОСТы 34 серии там присутствуют, так что можно использовать их совместно, и перестать жаловаться на "морально устаревший" ГОСТ 34).

Да что там, в этом стандарте даже есть разделение на исходные и проектные требования: "Для разрабатываемых объектов на основании утвержденной спецификации исходных требований разрабатывают спецификацию проектных требований, обусловленных принятыми при проектировании и в результате анализа исходных требований техническими решениями.", что совсем прекрасно! Та самая тема, о которой я давно говорю: как только вы принимаете какое-то техническое решение - например, "данные будут выводиться в виде таблицы" - тут же возникает целый куст новых требований, связанных с таблицей (перенос строк, отображение изображений и значков в ячейках таблицы, возможность сортировки и фильтрации, изменения ширины, скрытия и перестановки столбцов, и т.д. - требования, которые не возникли бы, если бы для вывода использовался другой способ).

Стандарт также (наконец-то!) вводит шаблон формулировки требования: [Условие]Субъект,Действие,Объект[Значение/Ограничение].

Кроме того, постулируется, что требования включаются в документацию конфигурации, и управление ими происходит по правилам ГОСТ Т Р 59193–2020 (Управление конфигурацией). Это тоже замечательно, потому что там есть, например, такое понятие, как "класс изменения конфигурации" и процедуры, которые нужно исполнить при изменении конфигурации. Приятно, что все эти стандарты на русском, и доступны на сайте ТК482 (см. в ветке обсуждения прямые ссылки)

По нашим опросам, одна из самых неинтересных аналитикам тем — это технические средства и протоколы передачи информации. Ну вот эти все процессоры, память, диски, каналы, все эти железяки. Грустный физический мир со своими физическими ограничениями, которые вносят несовершенство в идеальные логические модели (при построении физической модели БД происходит денормализация, какой ужас!)

Вторая скучная тема — НФТ, нефункциональные требования. Они связаны и понятным образом опираются на физические ограничения. Но это такая техника, не хочется с этим разбираться. Ещё традиционно нелюбимые темы — безопасность и мониторинг. Зато самая востребованная тема среди аналитиков — архитектура и микросервисы! Очень все хотят про это знать. Вот ведь парадокс.

А вот и картинка про типичные заблуждения о работе распределенных систем. Для архитекторов.

1) Сеть и её компоненты никогда не падают
2) Задержек при передачи по сети не существует
3) Ширина канала бесконечна
4) Сеть абсолютно безопасна
5) Топология сети никогда не меняется
6) Есть только один администратор
7) Расходов на передачу информации не существует
8) Сеть гомогенна (все устройства в сети одинаковы)

Даже среди архитекторов, похоже, эти заблуждения распространены. Как же вы собираетесь проектировать такие системы, не вникая в детали передачи и обработки данных?

Продолжая тему про распределенные системы: очень частый запрос — распил монолита на микросервисы. Все занимаются распилом! Коллеги по школе организуют вебинар с разбором распила монолита с точки зрения организации БД.

Еее! 2000 подписчиков на канале! Спасибо, друзья! 🎉🍾🏅


Пользуясь поводом, хотел спросить — про что вам больше всего интересно читать в канале? Я создавал его, как транслятор для своих идей и размышлений по поводу системного анализа и других аспектов создания программных систем, но потом случился chatGPT, и, кажется, многие пришли сюда именно за этой темой. Кроме того, я последние уж даже и не знаю, 15 лет?.. занимаюсь обучением и созданием систем для обучения, но про это я обычно в канал не пишу, а было бы вам интересно про методики в этой области? В общем, сейчас будет опрос про дальнейшее направление канала, чекните, пожалуйста, интересные вам темы.

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

А вот вам пока воркшоп сразу по трем темам, имеющим отношение к архитектуре: проектирование структур данных в реляционных и нереляционных БД, языки запросов у ним и микросервисы!

Давно искал такую шпаргалку. И для себя, и участникам тренингов показывать. Например, после выделения сервисов в Event Storming, чтобы принять предварительные архитектурные решения. Правда, говорят, правую часть можно смело заменить на Postgres, Postgres, Postgres,..., Mongo, Elastic, FileStorage, и на этом успокоиться :)

Завершил сегодня очередной поток курса "Основы проектирования интеграций ИТ-систем", понял, что одно из самых важных умений, которым мы учим — способность аналитика понимать фразы типа:

"Решение на основе семантики «at most once» с использованием мультипроцессингового пула в условиях неидемпотентности запросов и возможности организации обратной связи между консюмером и продюсером даёт следующие возможности: <...>“

— и не просто понимать, а уметь эти решения обсуждать и оценивать. То есть, фактически, переходить от systems analysis к systems design.

Очень интересно, насколько часто возникает вопрос про сравнение REST, SOAP, GraphQL, gRPC и лучший выбор одного или другого в конкретных условиях. При этом REST — это архитектурный стиль или набор принципов, SOAP — стандартизированный протокол, GraphQL — язык запросов, а gRPC — программный фреймворк :))

Вопрос получается типа: "что лучше выбрать для работы: Agile Manifesto, ГОСТ 34, Jira или UML?" 🤦🏼‍♂️

Да, я знаю, что это не совсем так, но мне очень забавно, что все эти разноуровневые понятия называют именно вот так по-разному, но потом берутся сравнивать. И знаю, почему их сравнивают — потому что все эти штуки, разной степени определенности, стандартизированности, поддержанности готовыми программными библиотеками — в любом случае реализуют паттерн взаимодействия "вызов удаленной процедуры", RPC. То есть, при сравнении речь идёт о разных способах реализации одного и того же паттерна! А значит, можно сравнивать, несмотря на то, что мы сравниваем спецификацию языка с набором идей.

Интересная картинка сравнения возможностей проприетарных и открытых моделей. По кодингу и умениям делать выводы GPT-4 пока впереди, а вот по написанию "просто текстов" и по гуманитарным вопросам Викуна уже практически сравнялась.

Ну и собственно самое главное.

По этому бенчмарку видно, насколько существенна разница в разных группах вопросов между моделями. Самый большой отрыв в Reasoning и Coding, там просто нет моделей, хотя бы приближающихся по уровню к GPT-4.

Зато в написании обычных текстов и в ролеплее модели +- могут использоваться. То есть построить дома чатбота, чтобы не скучать, уже можно, а делать умную машину, решающую проблемы автономно — нет.

Ну и минорное - авторы выпустили новые модели Vicuna v1.3 размерами от 7 до 33 миллиардов параметров. Веса забирать здесь.