Comments 10
Спасибо за статью!
С джирой никогда не работал и здесь у меня вопросы:
Есть ли у вас интеграции с фигмой/гитом? Как ведете документацию? Как все это выглядит в работе? И кто все это настраивает?
Есть интеграция с гитом, все МРы и коммиты линкуются к подзадачам. На сколько мне известно, то в JIRA имеется интеграция с фигмой, но ей мы пока не пользуемся.
Вся документация ведётся в confluence (wiki), со ссылками на задачи JIRA и в задачах тоже указываются ссылки на страницы wiki. Если очень верхнеуровнево, то имеются следующие крупные разделы: бизнес анализ, системный, разработка, тестирование, релизы, организационная часть и т.д.
В разработке описаны все микросервисы: модель данных и методы.
Аналитика декомпозирована на функциональные блоки, которые в свою очередь делятся на более мелкие, где системный аналитик и описывает требования.
Фактическую настройку workflow, автоматизации и правил выполняют администраторы JIRA, а сами идеи - что и как должно работать, как удобно выстроить процесс - занимаются все члены команды) в основном конечно лиды и продакты.
Разработчик, просто помни это: https://macode.ru/
Это, кстати, единственно верная методология.
А про статью чтоб два раза не вставать - у таски для разработчика есть всего два состояния - "никто не смотрит" и "сделано". Если появляется "в работе" значит или декомпозиция сделана неправильно (задача слишком большая) или бюрократы захватили планету (по-моему это как раз вариант из статьи). Когда у таски есть готова к тестированию, готова к мерджу, смерджена... мне это напоминает сцену из фильма "Космические М...звоны" (он-же Космические Яйца):
- "Приготовиться к перометке вперед!"
- "Есть приготовиться к перемотке вперед!"
- "Перемотка вперед!"
- "Есть перемотка вперед!"
Это они так видео перематывали :) Посмотрите на диаграмму "работа с историей" и поплачьте. Как-то проще надо быть.
Понимаю долю иронии и сарказма)
Со стороны это выглядит так, но когда нужно управлять 120 сотрудниками, то такая схема работает.
Если говорить конкретнее - статусы: разработка, code review, ready for merge и merge устраивают самих разработчиков.
В статус code review переводятся задачи, отправленные на ревью команде, пока проходит этот процесс разработчику не нужно думать какие это были задачи, он спокойно берёт следующие в работу.
Статус ready for merge нужен для лидов, чтобы понимать когда задача выполнена и её можно будет мержить в девелоп.
Статус Merge - это просто финальный статус, означающий, что работа с задачей завершена.
Что касается Истории, то там реализована автоматизация, которая описана в статье, поэтому разработчику не нужно делать лишних действий, кроме своей подзадачи, далее JIRA всё сделает за него.
Мы постоянно оптимизируем процессы и вся команда активно в этом участвует, поэтому разработчики тоже довольны.
Гипотетическая ситуация: Вы пришли на работу, Вам сказали: садись, пиши код, не буду мешать.
Ваши действия?
(???)
Многие разработчики страдают мнением, что все эти смешные скрамы, канбаны, смузи придуманы только для того, чтобы им мешали писать код, а глупые менеджеры и аналитики сосали деньги из бухгалтерии и жрали печеньки.
В реальности же, все это нацелено как раз на то, чтобы разработчик писал код и не занимался всякой посторонней деятельностью.
Справедливости ради, манифест из ссылки работает в команде размером 3 человека. Когда руководитель команды/проекта может держать все в голове или у себя в блокнотике.
Расскажите про свой опыт, будет интересно почитать.
Если не секрет, сколько часов уходит на задачу "Простой из-за отсутствия доступов"?
Есть в планах про использование rundeck в банке написать?
Управление IT-командой в Jira: опыт Банка ДОМ.РФ