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

1656597372 kak ispolzovat sobstvennye funkczii github chtoby pomoch upravlyat raspredelennoj komandoj

Моя команда создала вики-страницу в нашем частном хранилище Github о том, как мы работаем с общей базой кода. Я хочу поделиться этим с вами.

Мы команда из 15 человек с 10 разработчиками, менеджером проекта (PM), технический руководитель (TL), менеджер по инженерии, UXer и DevOps, распространяющийся в трех европейских странах. Продукт представляет собой внутренний веб-ориентированный SaaS, используемый другими командами внутри компании.

Общение

В основном мы общаемся через Slack, но проводим ретро-конференции (VC) раз в две недели. У нас нет ежедневного стендапа, но вместо этого у нас есть еженедельное упоминание о задачах на неделю, где каждый может написать обновление в цепочке. Идея состоит в том, чтобы превратить вопросы стояния по вопросам людей в задачи. Идею мы получили от мастерской «Поток». Маркус Хаммарберг:

Почему?

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

GitHub имеет множество встроенных функций управления проектами. Кроме того, разработчикам легче иметь свой код и задачи в одном месте. Такие функции, как закрытие проблем с помощью комментариев, руководство по вкладам и шаблоны проблем, владельцы кода и его интеграция с другими службами делают его достаточно полезным инструментом.

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

Что?

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

Как?

Мы используем проблемы, метки и вехи GitHub. Пока мы не используем проекты GitHub (но вместо этого используем Zenhub как нашу доску Kanban).

Когда?

Мы используем еженедельные вехи. В начале каждой недели мы проводим совещание по планированию (также на VC), где вместе с PM/TL мы определяем еженедельный этап, который является центром внимания команды на эту неделю.

Мы используем вехи GitHub, которые имеют такие названия, как W22, с описанием того, что должно быть достигнуто к концу недели. В нем также верно упоминаются критерии принятия.

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

Атомные проблемы и запросы на подъемник

  • Каждый вопрос должен касаться одного. Если обсуждение проблемы выходит за пределы, создайте другую проблему.
  • Всегда начинайте с проблемы, а не с пиара. Всегда обсуждайте проблему (в вопросе), прежде чем подавать решение (в PR).
  • Сдавливайте PR во время слияния, чтобы сохранить историю master отделение чистое и разумное.
  • Добавлять справочную информацию в PR – хорошая практика, но если вы пишете слишком много, это, вероятно, означает, что вместо этого вам нужно прокомментировать проблему.
  • Держите обсуждение в вопросах и разрешите определить приоритеты, прежде чем начинать кодировать.

1:1 сопоставление между вопросами и PR

  • В редких случаях, когда вы делаете PR без соответствующей проблемы, создайте проблему и ссылайтесь на нее в описании PR.
  • Для каждого PR должна быть хотя бы одна проблема.
  • Рекомендуется, чтобы каждый PR закрывал одну проблему.
  • Напишите краткое описание решения в ОР и обратитесь к соответствующему вопросу.

Нет прямых обязательств к мастеру

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

ВОЗ?

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

Мы используем программирование мобов для больших задач, и в этом случае назначаются все люди, участвующие в этой задаче. Они также пингуются в описании PR, поэтому получат обновления для комментариев по PR.

1*MGMLp6oH0kjAnAjTg6ySCg

Этикетки

Создавая проблему, мы назначаем ей соответствующие метки для упрощения фильтрации. Например, мы можем отфильтровать все test связанные вопросы или prio-hi проблемы одним щелчком мыши или даже создание закладки для запроса.

Существует много этикеток, но в основном они делятся на следующие категории:

Расстановка приоритетов

Когда поступает новая проблема, она ждет, пока премьер-министр определяет ее приоритет, и получает одну из следующих меток:

  • prio-high: приоритетные задачи, которые следует выполнить как можно быстрее
  • prio-mid: задачи среднего приоритета, которые можно выполнять, когда нет задач высокого приоритета
  • prio-low: задачи с низким приоритетом, которые могут ожидать
  • on-hold: задачи, которые мы не будем выполнять до последующего сообщения

Если проблема не имеет ни одной из этих меток, ее не следует работать. Премьер-министр может изменить приоритет вопроса на основе изменений в потребностях заинтересованных сторон.

Когда проблема имеет веху, она готова к разработке. Все другие вопросы, не являющиеся вехой, находятся в «отставании». Проблемы можно отнести к еженедельному этапу следующей недели. Если вы не можете внести свой вклад в веху на этой неделе, возможно, вы сможете подготовиться к следующей неделе, выполнив часть этой работы.

Кто угодно может создать проблему. На самом деле, вопрос может быть проблемой, если вы считаете, что это лучший способ получить ответы. Проблема не превращается автоматически в задачу, пока ей не будет определен приоритет (получен a prio-* метка) и добавлен в этап.

Размер

  • EPIC: – это проблема, которая может привести к нескольким PR и должна быть разбита на atomic проблемы, прежде чем они будут реализованы.
  • atomic: это вопрос, который можно реализовать самостоятельно и приведет к PR

Группировка

Мы также используем метки, чтобы группировать подобные проблемы вместе или обозначать различные аспекты проблемы или PR. Проблема может иметь любое количество этих флажков:

  • tooling проблемы, касающиеся системы сборки, линтинга, тестового инструмента…
  • test вопросы тестирования и обеспечения качества
  • ux проблемы, требующие определенной работы с UX, улучшения UX или каким-то образом влияют на UX
  • config проблемы, связанные с изменениями конфигурации
  • doc проблемы с документацией (комментарии в коде или опубликованная документация, например вики)
  • perf: предложения по мониторингу и повышению эффективности
  • dx: вещи, улучшающие работу разработчика, таких как журналирование и т.д.
  • security: проблемы безопасности или улучшение безопасности.
  • discussion: мы не достигли консенсуса там, возможно, вы можете внести свой вклад?
  • help needed: проблема нуждается в помощи со стороны внешних команд (если вы ждете внутреннего волонтера, вы можете просто пойти и отправить им запрос). Эти проблемы, как правило, хороший кандидат для PM/TL для облегчения межкомандного общения.
  • feature: для ввода новых функций
  • bug: для отчетов об ошибках
  • можно добавить больше меток, если у нас достаточно проблем, которые соответствуют определенному уровню.

То, что GitHub не может сделать

К сожалению, текущего инструментария Github не хватает по крайней мере двух важных вещей:

  1. Нет простого способа сгруппировать проблемы вместе в (Эпики). Некоторое время мы использовали этикетки, но это было не оптимально.
  2. Кроме использования меток невозможно определить приоритеты проблем. Нам нужен инструмент, где порядок вопросов может показать их значимость.

Обе эти проблемы решает Zenhub, являющееся расширением Chrome/Firefox, обогащающего родной интерфейс GitHub. Он также имеет службу для тех, кто не использует Chrome/Firefox.

Единственная область, в которой Zenhub все еще не хватает – это определение лимита незавершенной работы (лимит WIP).

Добавить комментарий

Ваш адрес email не будет опубликован.