Подкаст DevFM: Ретроспектива силами команды разработки

Мы тут собрались с духом и решили записать подкастик. Обсудили интересную и насущную тему – ретроспективы.

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

#devfm #podcast #teamwork

Оценка сроков проекта для тимлида

Как узнать у разработчика сроки решения задачи? Ну, никак. Он вам будет врать.

Если вы всё ещё хотите узнать сроки, то придется попотеть:
1. Спрашиваете сроки. Вам говорят некую величину R.
2. Если R <= 16 рабочих часов, то реальное время выполнения проекта составит примерно R умножить на π, то есть ~3,14R. Почему умножаем на Пи? Во-первых, это красиво. Во-вторых, тройного запаса обычно хватает.
3. Если R > 16 часов, то задача слишком большая и разработчик дал рандомный срок. В этом случае срок можно рассчитать как R×π + 2 недели. Почему умножаем на Пи? Потому что это красиво. Почему добавляем 2 недели? Потому что за 2 недели можно сделать что угодно...

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

Ответ на пост Трудоемкость != сроки

#edu #teamwork

Подкаст DevFM: Кто такой тимлид тимлидов (yandex / youtube / podster)

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

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

Что изменилось на новой должности? Нюансы потери детализации над проектом. Нужны ли KPI?

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

Наш первый подкаст

#devfm #podcast #teamwork

Советы руководителю от руководителя

Эта статья прекрасна своей простотой и очевидностью, но она затрагивает очень важные аспекты.

Автор касается многих тем, особенно мне откликнулись эти:
– ты, как руководитель, не должен быть незаменим, думай о bus factor.

– старайся давать своим сотрудникам чуть больше, чем даёт кампания. Мне кажется, это очень важно. По этой части я, например, некоторым своим ребятам покупал copilot, пробивал билеты на highload++, или отстаивал необходимость повышения зп. Очень приятно создавать комфортные условия для классных ребят.

– поддерживай связь с людьми, с которыми по какой-то причине перестаешь работать. Приведу цитату автора: "С работы ты можешь унести только две вещи: опыт и связи. Цени эти вещи."

#edu #teamwork

Проводим ретро с помощью parabol

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

А теперь хотим поделиться просто замечательным инструментом для проведения ретро – parabol. Последние несколько ретро в разных командах проводили именно там.

Супер понятный инструмент, ведущий вас по процессу:
– накидывание поинтов (возможно, анонимное)
– таймер как помощник отслеживания времени
– группировка поинтов по темам
– голосование за актуальные темы
– накидывание задач по каждой теме с назначением исполнителя
– выгрузка результатов в различных форматах

Из плюсов: можно выбрать разные шаблоны, можно проводить и организовывать не только ретро, есть встроенные гайдлайны, как проводить ретро – очень удобно, если никогда этого не делали.

Разумеется, есть платная версия, но для проведения ретро командой хватит бесплатной.

#tools

Всё в той же статье про порядок столбцов в Postgres автор использует термин bike-shedding.

Представьте себе ситуацию: группа людей собралась обсудить важный проект, например, строительство атомной электростанции. Вместо того, чтобы сосредоточиться на ключевых вопросах безопасности и эффективности, они тратят часы на обсуждение цвета велосипедной стоянки. Звучит абсурдно? Это и есть "bike-shedding" — термин, описывающий склонность тратить много времени на обсуждение простых и незначительных деталей, оставляя без должного внимания действительно важные задачи. Подобные вопросы привлекательны ещё потому, что обычно не требуют глубоких знаний и каждому есть что сказать, а за неверное решение не будет никакой ответственности.

Честно, очень люблю этот термин, он на уровне с bus factor ёмко выражает проблематику.

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

#edu #teamwork

Когда всё горит

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

На тему преодоления кризисных ситуаций с точки зрения руководителя принёс вот такую статью.

Автор предлагает сосредоточиться на следующих аспектах.

Обеспечение поставок продукта (круто звучит по-английски – Ensuring Goal-Aligned Delivery).
– жесточайше приоритизируйте: нужно сосредоточиться только на самых критических моментах
– ускоряйте работу: сократить бюрократические проволочки, выдать команде полномочия на принятие решений
– цените время: нужно максимально ограничить отвлекающие факторы, убрать лишние встречи
– управляйте техдолгом: он неизбежно будет расти, а ваша задача аккуратно фиксировать и подсвечивать проблемные места для будущих фиксов
– будьте с командой: вы как руководитель должны быть вовлечены в проблемы проекта и команды, помогать их решать

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

Поддержка сильной команды
– поддерживайте мораль: заряжайте команду позитивом, отмечайте быстрые победы, избегайте противопоставления себя другим отделам
– управляйте производительностью: негативное поведение в команде должно решаться оперативно, и вред от токсичного сотрудника может перевесить выгоду от его уникальных скиллов
– трудности это рост: покажите команде, что текущие вызовы — это возможность для личного и профессионального роста. Помогайте им развивать навыки, которые останутся с ними

И ещё немаловажное замечание. Не забывайте о своем здоровье: вы не сможете помочь другим, если сами выгорите. Заботьтесь о себе, находите время на отдых и восстановление. В конце концов, не корову проигрываете.
#edu #teamwork

Багскрам

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

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

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

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

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

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

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

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

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

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

Работаем со связанными ветками в Git

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

Автор предлагает делить работу над задачей на несколько логически связанных частей. Каждая часть оформляется в виде отдельной ветки и сопровождается merge request-ом. При этом каждая ветка бранчуется от предыдущей. Например, feature-xyz/part-2 от feature-xyz/part-1, а feature-xyz/part-3 от part-2. Получается такой стек из веток.

Такой подход позволяет упростить ревью – каждый MR охватывает минимальный объем изменений, и создать историю коммитов, которая позволит читать изменения кода по шагам, понимая логику их внесения.

И всё выглядит хорошо до тех пор, пока не нужно внести изменения в part-1 по результатам ревью, а потом влить эти изменения в ветки part-2 и part-3. Или когда в основной dev-ветке появятся изменения, нужно также их затащить во все свои маленькие веточки. Тут приходит на помощь rebase со всеми сопутствующими приседаниями.

Чтобы избежать приседаний, автор предлагает решение: использовать опцию --update-refs команды rebase. В этом случае при ребейзе самой последней вашей ветки git сам обновит все родительские ветки.

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

#skills #teamwork

Справляемся с рисками

Две совсем несложные статьи (раз, два), посвящённые риску и управлению рисками.

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

Для анализа риска автор разделяет его на два компонента:
– Вероятность: насколько возможно, что негативное событие произойдёт?
– Последствия: какие убытки или проблемы оно принесёт?

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

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

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

По сути мы возвращаемся к составляющим риска:
– Снижение вероятности. Мы пытаемся сделать так, чтобы рискованное событие с меньшей вероятностью происходило.
– Снижение последствий. Мы уменьшаем ущерб, если событие всё же произойдёт.

Автор приводит не айтишный пример, но, в целом, неплохо демонстрирующий суть.
Нужно переправиться через реку:

Для снижения вероятности падения в воду мы можем:
– Использовать командные техники переправы
– Искать более мелкий участок реки для перехода

Для снижения последствий попадания в воду мы можем:
– Запаковать вещи в водонепроницаемые мешки, чтобы предотвратить их повреждение
– Разместить спасателей ниже по течению, чтобы минимизировать риск травм или утопления

#teamwork