When to write strategy, and how much?Отличная статья Will Larson. Она посвящена созданию стратегии в инженерной команде с акцентом на выборе подходящего момента для её написания, определении оптимального объёма и способе внедрения.

В самом начале автор рассуждает о моментах, когда работа над стратегией действительно оправдана, таких как конфликт между командами или важные кадровые изменения, и объясняет, что не всегда правильным решением является создание стратегии "здесь и сейчас". Автор предлагает рассматривать три стратегических состояния: глобально согласованное, частично согласованное внутри команд и несогласованное, указывая, что разработка стратегии наиболее актуальна для ситуаций, когда команда находится во втором или третьем состоянии. Кроме того, если ситуация в компании ухудшается, но состояние стратегий ещё приемлемо, это может стать стимулом к началу работы над ними.

Следующим рассматривается вопрос оптимального количества стратегий. Автор рекомендует ограничивать количество одновременно разрабатываемых стратегий одной или двумя, чтобы обеспечить их успешное внедрение и избежать перегрузки организации. При этом подчеркивается важность постепенного роста стратегий и гибкого видения конечного результата, которое поддерживает принятие мелких шагов. На примере Uber: в какой-то момент возникла проблема надёжности сервисов и скорости их разработки. Для её решения была создана стратегия, направленная на обеспечение безболезненного деплоя и функционирования сервисов. Реализация этой стратегии постепенно привела к решению более глобальной исходной проблемы.

Далее самое интересное. Для внедрения стратегии нужно учитывать масштаб внедрения (команда или вся организация) и стиль изложения стратерии: запретительный (proscriptive, пример: "блокировать MR, если код не прошёл линтеры") или разрешительный (permissive, пример: "давайте использовать линтеры, вот основные правила, в каждой команде можно кастомизировать под себя"). Чем больше масштаб внедрения, например, на уровне всей компании, тем больше разрешительных пунктов должно быть. Иначе вряд ли стратегию получится внедрить.

Немаловажный момент, на который обращает внимание автор – оценка эффективности стратегии, а также её влияние на принятие различных решений.

Статья любопытная, как и многие другие от этого автора :)

#edu #systemdesign

Вдохновившись выступлениями прошлых лет, побывал тут на ArchDays 2024.

Были доклады поверхностные – за всё хорошее, против всего плохого, были доклады, где люди просто плохо готовились к выступлению или рассказывали сырой материал.

Однако удалось послушать и два хороших выступления:

▫️Замечательный своей концептуальностью доклад Александра Поломодова про архитектуру Т-Банка, в процессе которого было множество полезных отсылок, которые он опубликовал у себя в канале, и куда можно уже врываться и изучать.

▫️И очень практический доклад Виталия Минко на тему архитектурных принципов. Как только доклад появится на ютубе, обязательно сделаю пост о нём. А пока от него же доклад с одной из прошлых конференций на тему Технического радара. В нём затрагиваются темы: что такое Технический радар, для чего он нужен, когда и как его внедрять в своей компании.

#systemdesign

БагскрамНедавно поднимали вопрос классификации багов и во что это может вылиться.

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

Для таких случаев существует такая замечательная процедура, как багскрам.

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

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

Проводить багскрам следует по следующему сценарию:

ПодготовкаЗаранее выбрать скоуп багов, которые хотите разобрать.

Встреча1. Тот кто проводит встречу, планомерно открывает каждый из багов.
2. Тестировщик, который завёл баг, тезисно описывает проблему.
3. Команда обсуждает баг, появляется и фиксируется какая-то дополнительная информация. Далее определяется приоритет бага, назначается ответственный. Очень важно, чтобы во время обсуждения руководитель проекта или любой другой фасилитатор следил за тем, чтобы встреча не уходила не в то русло и шла чётко по плану.
4. По результату обработки бага оставляется комментарий о том, что баг рассмотрен на багскраме. Это нужно, чтобы по нескольку раз не смотреть одно и тоже. Если на следующем багскраме окажется снова этот баг, то возникнут закономерные вопросики.

Периодический багскрам в целом не даёт багам накапливаться и превращаться в неуправляемую массу.

А на тех проектах, где такое мероприятие у нас проводится, конечно, зафиксирован процесс: участники, периодичность, правила, примеры фильтрации багов в системе контроля задач. Чтобы любой человек мог ознакомиться с процессом.
#devfm #teamwork

Есть такой замечательный ресурс от гугла – API Improvement Proposals. Ребята активно поддерживают ресурс, где делятся своими практиками по разработке API.

AIP содержит:

▪️ Рекомендации по проектированию API: AIPs охватывают все основные аспекты создания API, от именования ресурсов до управления версиями и методов работы с HTTP-запросами. Это включает в себя рекомендации по структуре URL, стандартам наименования полей и параметров, а также подходы к работе с HTTP-методами (GET, POST, PUT, DELETE).

▪️Шаблоны и примеры: для многих сценариев предлагаются конкретные примеры и шаблоны реализации, которые помогают разработчикам лучше понимать, как применять правила на практике. Например, можно найти примеры по созданию структурированных ответов, оформлению ошибок и управлению версиями API.

▪️ Конкретные правила и стандарты: AIPs охватывают такие темы, как использование протокола gRPC, RESTful API, стандарты кодирования, а также рекомендации по работе с HTTP-заголовками, кодами ошибок, аутентификацией и авторизацией.

▪️Методология и философия проектирования: помимо технических аспектов, AIPs содержат информацию о том, как Google подходит к проектированию API на концептуальном уровне. Это позволяет понять, почему определённые решения предпочтительны с точки зрения пользовательского опыта и долгосрочной поддержки API.

#skills

Анализ источника багов как начало улучшения процессов работы в командеУ нас есть один достаточно сложный и душный проект. На нём трудятся специалисты самых разных направлений, в том числе бизнес-аналитики, системные аналитики, разработчики, тестировщики. Сложный проект и такая команда требуют качественной координации и слаженной работы – что-то сломаться может где угодно.

Всё шло как обычно, тестировщики тестировали, баги заводились, баги фиксились.

Но тут мы решили посмотреть на природу багов. Из-за чего они возникают? Где что-то ломается?

В результате этого процесса получилось классифицировать баги:
– кейс не проработан бизнес-анализом
– кейс не проработан системным анализом
– в требованиях нечёткие формулировки: аналитик написал как-то расплывчато, разработчик не пошёл уточнять
– ошибка разработчика
– ёпрст, никто об этом не думал, бизнес сам не представлял, что такое бывает

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

Меня, конечно, в первую очередь интересует системный анализ и разработка, на этом и сосредоточились.

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

✅ По части системного анализа детально изучили существующие требования и места рассинхрона. Особое внимание обращали не на техническое решение, а на структуру документа, уровни детализации, проработали конкретные формулировки, договорились об исправлениях.

Вот такие жирные проблемы удалось выявить в результате анализа природы багов и решения, к которым удалось прийти.
#devfm #systemdesign

Недавно говорили за архитектурные схемы. Ещё одним полезным артефактом команды разработки проекта является табличка с зонами ответственности и компетенциями. И вроде банально, но смотрел в разные проекты и не везде подобное видел.

Структура подобной таблички:
– сервис - самая верхнеуровневая сущность для удобной навигации по табличке. Если у вас монолитная архитектура, то можно эту колонку опустить или взять любую другую верхнеуровневую единицу разделения. Тут главное, чтобы вам удобно было ориентироваться
– модуль – более конкретное уточнение функционала
– ответственный разработчик – кто именно отвечает за этот модуль, с ним советуются, если что-то хотят туда внедрить, его тегают в МРах, к нему идут, если что-то сильно сломалось
– разработчики – те, кто принимал участие в разработке модуля и представляют, что там происходит
– аналитик – если в вашей команде есть системные аналитики, то имеет смысл указать этих ребят в этой же табличке

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

Есть несколько причин, почему это полезно:
– если проект долгоиграющий, то в целом хорошо бы понимать, кто за что отвечает, кто в чём разбирается. На длинной дистанции найдется достаточно количество заинтересантов, которые будут приходить с разными вопросами
– позволяет отслеживать bus factor. Табличка даёт очень наглядное представление, где у нас проблема с зонами ответственности, за какой функционал отвечает всего один человек, и нет у него никакой подмены
– более вдумчиво планировать отпуска. Сразу понятно, кого нельзя отправлять в отпуск одновременно
– и ещё один пункт, который совсем недавно поймали. У нас была проблема, что баги тестироващиками классифицировались по направлениям бек/фронт, но далее они падали на тимлидов, которые должны были вникать и распределять по ответственным и, самое печальное, – тратить свое драгоценное время. Потом мы показали тестировщикам табличку с зонами ответственности, они теперь дотошно диагностируют проблему и закидывают баг сразу на исполнителя. Получилось очень хорошо, ошибок минимальное количество
#devfm #systemdesign

Когда cron уже не хватает

Иногда классического cron не хватает, и есть замечательная альтернатива – fcron.
Для моей задачи нужны были хитрые условия запуска с определенной частотой и определенным количеством раз, которые fcron позволяет конфигурировать.

Но у него в целом более разухабистый функционал, чем у классического cron: с зависимостью задач друг от друга, выполнением задач по условиям, с более гибкой настройкой расписания.

#tools

fcron.free.fr

Fcron : a periodical command scheduler for Unix and Linux systems

Fcron is a scheduler designed for Unix/Linux systems, especially usefull when your system is not up all the day long.