Rose debug info
---------------

Заметки (не) разработчика

Телеграм · LinkedIn · Github · Теги

Позднее Ctrl + ↑

Jira Workflow

Я стараюсь придерживаться принципа KISS (keep it stupid, keep it simple) не только при написании кода, но при выстраивании процессов внутри команд. Так, например, приведенный Jira Workflow имеет максимально прозрачный пайплайн выполнения задач.

Типы запросов

  • Задача — задача, которую необходимо выполнить.
  • Подзадача — задача меньшего объема в рамках задачи.
  • Баг — проблема, которая влияет на функциональность сервиса.
  • Общая задача — активности, связанные с выяснением функциональных требований будущей спецификации. Может выступать в роли спайка / исследовательской деятельности.
  • User Story — новая функциональность продукта с точки зрения пользователя. В нашей команде выполняет функцию эпика из-за специфики настройки корпоративной Jira.
  • Инцидент — системный сбой или инцидент. Для Remedy.

Приоритеты

  • Блокер
  • Высокий
  • Нормальный
  • Низкий

Статусы задач

  • 📥 Бэклог
  • 😲 To Do — бэклог спринта
  • 💪🏻 В работе
  • 📝 Ревью
  • 🔅 К тестированию ← только после выполнения автоматических тестов на CI и тестирования исполнителем
  • 🐹 Тестирование ← QA берет в работу
  • 🚢 Готово к релизу ← для планирования релиза и его деплоя на продакшен-окружение
  • ✅ Выполнено

Workflow

Задача и баг

Workflow задачи и бага

Общая задача

Workflow общей задачи

На основе перечисленных статусов задач команда может создавать Kanban и Scrum-доски для удобной визуализации пайплайна.

 589   7 мес   Jira   Менеджмент

Внутренняя Wiki команды

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

Внутренняя Wiki команды

Когда всех начали переводить на удаленку, мои команды уже были готовы к такому формату в том числе из-за отсутствия белых пятен в знаниях. И не раз на ретроспективах было сказано друг другу «Спасибо» за туториалы, продуктовые спецификации или описание почему когда-то было принято то или иное решение.

Не экономьте на документации. Да, в Agile-манифесте написано «Работающий продукт важнее исчерпывающей документации», но это не значит, что на нее не нужно выделять время команды.

Срыв дедлайна — в 99% случаев вина менеджмента, а не команды разработки

В своем маленьком Телеграм-канале я делал опрос на тему «Срыв дедлайна — в 99% случаев вина менеджмента, а не членов команды разработки?». Проголосовали 15 человек — почти половина канала:

  • За ответ «Нет» 7% — один человек
  • За ответ «Да» 20% — три человека включая меня
  • За ответ «Все не так однозначно» 73% — одиннадцать человек

Итак, почему я считаю, что почти всегда срыв дедлайна — вина и ошибки менеджмента.

Давайте представим среднестатистическую кросс-функциональную команду разработки: продакт или деливери менеджер, бэкенд, фронтенд, DevOps, QA. И новый проект, фичу или какие-то серьезные изменения в продукте.

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

Первая ошибка менеджмента возникает уже на этапе договоренностей с бизнесом. Как правило, менеджер продукта обсуждая с бизнесом результат, ставит перед собой и командой дедлайн. Бизнес, конечно же, ничего не знает про команду, ее состав, опыт, сработанность и др. факторы и просто ожидает некую временную отсечку, после которой можно смотреть на достижение поставленных целей и дальнейшее изменение стратегии. Если менеджеры договорились между собой о дедлайне, не вовлекая в процесс оценки команду и не заложив дополнительное время на непредвиденные обстоятельства, то практически всегда мы в итоге получаем срыв этого самого дедлайна: скоуп задач оказался слишком большим, затянулись этапы подготовки (анализ, описание требований и спецификаций, инфраструктуры и др. операционные вопросы), команда посмотрев требования высказала свою точку зрения, оценки менеджера и команды разошлись и т. п.

Ок, даже если так случилось, и менеджер вдруг понял, что команда не вложится в оговоренные сроки, то вырулить все еще можно порезав скоуп задач и цели, а затем пойти передоговариваться с бизнесом (в счет не берем ситуации сделай или умри, когда бизнес запускается под какой-то ивент). И на этом этапе решает умение управлять ожиданиями заказчика и стекхолдеров. Если менеджер этого не делает, то с большей вероятностью, исходная ситуация будет усугубляться при приближении даты дедлайна: менеджер и команда будут пытаться вкидывать больше ресурсов, принимать рискованные решения. За счет этого увеличиться уровень стресса и напряжения внутри команды. Здесь мы видим вторую ошибку менеджмента, которая может оказаться фатальной для всех — бизнеса, который пребывал в неведении и ждал результатов от команды; команды, которая в поте лица пыталась все же выполнить срок и выгорела; менеджера, который показал, что не в силах спланировать разработку, управлять ожиданиями и рисками.

Вот и получается, что на 1% срывов всех дедлайнов остаются внешние факторы, которые случились либо перед самым запуском: например, ваш провайдер инфраструктуры внезапно упал из-за урагана, либо кто-то из команды заболел (но и в этой ситуации вы, как менеджер, тоже просчитались — допустили bus factor на проекте), либо вы совместно с бизнесом поняли, что не стоит выпускать на рынок сырой продукт, и репутация компании стоит дороже тех изменений, которые вы планировали показать конечным пользователям.

 51   7 мес   Менеджмент

Запуск программы в фоновом режиме

В MacOS и операционных системах семейства Unix для запуска программы в фоновом режиме достаточно
добавить к команде знак амперсанда &. Пример:

sync --folder /home/akrisanov/downloads &

После ввода команды оболочка отвечает идентификатором процесса (PID) который может быть использован в дальнейшем для прекращения работы процесса.

Данный трюк часто бывает полезен при запуске серверов или других демонов.

 64   2020   PID   Shell   Unix

Fatal Lock File Postmaster Pid Already Exists

Иногда при обновлении PostgreSQL через Homebrew возникает следующая проблема. «Починить» ее можно удалив файл, содержащий идентификатор запущенного процесса и заново запустив сервис БД:

$ brew services stop postgresql
$ rm /usr/local/var/postgres/postmaster.pid
$ brew services start postgresql
 30   2020   Homebrew   macOS
Ранее Ctrl + ↓