И на сон грядущий, прямо шикарная статья про то, как писать документацию. Во-первых, написано профессионалом и ее приятно читать и стилистически и с точки зрения содержания. Во-вторых в сжатом виде дан огромный объем информации, да еще и со ссылками на огромное количество источников и доп. материалов. Терпеть не могу писать документацию, но если писать - то такую! https://habr.com/ru/post/698046/

С утречка бодречком - читать про создание надежных систем. Статья, которую я пожалуй перечитаю еще раз, ибо она содержит очень много с одной стороны очевидных, а с другой стороны очень полезных мыслей, что за раз они в голове не уложатся. Но в целом, статья гораздо больше про менеджмент и процессы, чем про технологии, что очень приятно, т.к. многие подобные статьи являются сугубо техническими. https://habr.com/ru/company/ruvds/blog/698014/

Прекрасная статья годичной давности с перечнем хороших и полезных книг, посвященных организации работы команд, как с инженерной, так и мотивационной точек зрения. Если хотите расти в сторону лидерства и управления командами, то почитать хотя бы часть из книжек стоит (у меня уже парочка есть) https://medium.com/the-serverless-edge/engineering-leadership-here-are-my-go-to-books-64f5b1ed971d

И вообще в другую степь - в визуализацию данных. Если честно, никогда не представлял себе, что отображение в виде дерева можно обогатить еще и набором слоев, которые будут дополнительно подчеркивать те или иные характеристики данных. Забрал идею в нашу команду DWH и BI, вдруг пригодится. https://habr.com/ru/post/672184/

Интересная шпаргалка про REST

А ваш покорный слуга снова на обложке)

Хотим поделиться что мы свели рассказы спикеров с предыдущей встречи в октябре в подробную статью 🌟📄
В лонгриде можно найти дополнительные инсайты, освежить память, а также почитать о чем мы говорили если вы вдруг не смогли прийти.
Читать здесь: Medium

А я снова про аналитика в скраме: https://premieragile.com/where-does-a-business-analyst-fit-in-a-scrum-team/#:~:text=A%20Scrum%20Business%20Analyst%20is,members%20of%20the%20Scrum%20Team. На этот раз почитал статью коллег с запада и они таки считают, что он нужен. Здравое зерно в их словах есть, как я давно утверждаю, изначально команде обязательно нужен аналитик, но по мере погружения в предметную область - необходимость в нем постепенно снижается, как и необходимость в подробных постановках etc. Но то, что его обзывают бизнес аналитиком уже вселяет радость!

И теперь немного в другую сторону. Про Enterprise и API. Т.к. раньше работал в телеком операторе, с интересом почитал статью коллег из Deutsche Telekom про построение корпоративного API шлюза в логике описанной умными дядьками из TM Forum. Сложно, тяжело, занудно, но в таком контексте необходимо, в нашем операторе было так же. С болью мы делали такой слой, но потому он даже начал приносить определенную пользу, хотя копий по пути к этому сломали немало. https://habr.com/ru/company/deutschetelekomitsolutions/blog/600189/

Только ленивый не прокомментировал ТЗ, написанное ChatGPT под руководством Юрия Куприянова https://www.youtube.com/watch?v=HkRAtRCXGbU. Ну что я вам говорил - писать ТЗ в современном мире уже не нужно, за вас это сделает нейросеть. А вот описать ей бизнес задачу - нужно! И тут то и нужен аналитик. Поэтому все идем думать, а не писать лишние бумажки, рутину - нейросетям!

Неплохой пост от Алексея Васильева про Agile, практически со всем согласен.

= Опять про Agile =

1. Метода Waterfall - не существует и никогда не было.

2. Винстон Ройс в 1970 году показал решение которое позволяло БЫСТРЕЕ выходить программному обеспечению в эксплуатацию. Пиши БОЛЬШЕ документов чтобы быстрее выпускать проекты. Потому, что на тот момент от идеи до внедрения было минимум 5 рабочих дней.

3. "За время пути собака смогла подрасти" , ЭВМ стали быстрее и цикл обратной связи ускорился, уже не нужно было создавать больше документов для быстрого выпуска.

4. Клиент никогда не НЕ ЗНАЕТ РЕШЕНИЯ но приходит с ним. это ГИПОТЕЗА! Однако все так увлечены созданием ПО что не обращают на это внимания.

5. Особенности культуры США (юристы и индивидуалим) совместно с п.4 к 1995 году показали что это контрпродуктивно.


Поэтому инженеры на местах придумали Agile-подходы, которые помогают решать СИМПТОМЫ и следствия от п5 + п2., за счёт п3, но не помогают решить п.4. Потому что это на уровне принятия решений, а не у инженеров.

Интересная статья про то как в условиях микросервисной архитектуры (а я напомню, что ее надо использовать с большим умом и осмотрительностью, чем монолит) работать с eventual consistency. Чтобы она была меньше eventual и больше consistency. https://softwaremill.com/microservices-101/