Skip to main content
Мы публикуем частые обновления нашей документации, и перевод этой страницы может все еще выполняться. Актуальные сведения см. в документации на английском языке.

Планирование и отслеживание работы для команды или проекта

Основные сведения об использовании средств планирования и отслеживания GitHub для управления работой c командой или проектом.

Введение

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

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

Создание репозитория

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

Репозитории можно настраивать для разных целей в зависимости от ваших потребностей. Вот несколько основных способов применения:

  • Репозитории продуктов: крупные организации, которые отслеживают свою работу и цели по отдельным продуктам, могут иметь один или несколько репозиториев, содержащих код и другие файлы. Такие репозитории также можно использовать для документации, отчетов о работоспособности продукта или планов по его развитию.
  • Репозитории проектов: репозитории можно создавать как для личных проектов, так и для проектов, над которым вы работаете вместе с другими пользователями. Организации, которая отслеживает работу по краткосрочным инициативам или проектам, например консалтинговой компании, необходимо получать отчеты о работоспособности проекта и перераспределять людей между разными проектами с учетом навыков и потребностей. Код проекта часто содержится в одном репозитории.
  • Репозитории команд: в организации, где над проектами работают команды, такие как команда средств разработки, код может быть распределен между несколькими репозиториями, созданными для разных работ, которые им нужно отслеживать. В этом случае может быть удобнее создать для каждой команды отдельный репозиторий как единое место для отслеживания всех работ, в которых она участвует.
  • Личные репозитории: личный репозиторий позволяет отслеживать все работы в одном месте, планировать будущие задачи и даже добавлять заметки или информацию, которую вы хотите сохранить. Сюда можно добавлять участников совместной работы, чтобы предоставить доступ к информации другим пользователям.

Если вам необходимы разные разрешения на доступ к исходному коду или вы хотите отслеживать проблемы и обсуждения, можно создать несколько отдельных репозиториев. Дополнительные сведения см. в разделе Создание репозитория только для проблем.

В следующих примерах в этом руководстве мы будем использовать пример репозитория под названием Project Octocat.

Передача данных о репозитории

Для репозитория можно создать файл README.md, чтобы рассказать о своей команде или проекте или сообщить важные сведения о репозитории. Зачастую README — первое, что видит посетитель репозитория, поэтому здесь же можно указать, каким образом пользователи или участники могут приступить к работе над проектом и как связаться с командой. Дополнительные сведения см. в разделе Сведения о файлах сведений.

Кроме того, можно создать файл CONTRIBUTING.md и добавить в него инструкции по участию в работе и взаимодействию с командой или проектом, например, информацию о том, как подать запрос на устранение ошибки или на доработку. Дополнительные сведения см. в разделе Создание рекомендаций для участников репозитория.

Пример файла README

Создадим файл README.md с информацией о нашем новом проекте — Project Octocat.

Снимок экрана: файл README.md для репозитория octo-org/project-octocat с подробными сведениями о проекте и способом связи с командой.

Создание шаблонов проблем

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

  • Отслеживание выпусков: проблему можно использовать для отслеживания хода выполнения выпуска или этапов запуска.
  • Крупные инициативы: проблему можно использовать для отслеживания хода выполнения крупной инициативы или проекта, которые затем сопоставляются с проблемами поменьше.
  • Запросы компонентов: ваша команда или пользователи могут создавать проблемы для запроса доработки того или иного продукта или проекта.
  • Ошибки: ваша команда или пользователи могут создавать проблемы для сообщения об ошибке.

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

Пример шаблона проблем

Ниже мы создадим шаблон проблемы для сообщения об ошибке в Project Octocat.

Снимок экрана: форма для создания шаблона проблемы. Поля заполнены для создания шаблона с именем "Отчет об ошибках для Project Octocat".

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

Снимок экрана: страница "Новая проблема" для octo-org/project-octocat с возможностью использования шаблона "Отчет об ошибках для Project Octocat".

Открытие проблем и использование списков задач для отслеживания работы

Для организации и отслеживания работы можно создавать проблемы. Дополнительные сведения см. в разделе Создание проблемы.

Пример проблемы

Приведем пример проблемы, созданной для крупной иницбиативы (внешний интерфейс) в Project Octocat.

Снимок экрана: проблема с именем "Интерфейсная работа для Project Octocat". Текст проблемы содержит список задач, которые необходимо выполнить.

Пример списка задач

Списки задач можно использовать для деления больших проблем на небольшие задачи и отслеживания проблем в рамках более крупной цели. При добавлении в текст проблемы у списков задач появляются дополнительные функциональные возможности. В верхней части проблемы отображается количество завершенных задач, а если кто-то закроет проблему, связанную с списком задач, флажок будет автоматически помечен как завершенный. Дополнительные сведения см. в разделе Сведения о списках задач.

Ниже мы добавили список задач в проблему Project Octocat, разделив ее на проблемы поменьше.

Снимок экрана: проблема с именем "Интерфейсная работа для Project Octocat". Текст проблемы содержит список задач с флажком перед каждой ссылкой на проблему.

Принятие решений в команде

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

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

Пример проблемы с участниками проектами

Приведем пример того, как участники одного проекта сообщают об изменении состояния работы в проблеме Project Octocat.

Снимок экрана: проблема с именем "Интерфейсная работа для Project Octocat". Комментарии от обоих @codercat элементов и @octocat предоставляют обновления состояния работы.

Использование меток для выделения целей и состояния проекта

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

Дополнительные сведения см. в разделе Управление метками.

Метку, созданную в репозитории, можно впоследствии применять к любой проблеме, запросу на вытягивание или обсуждению в этом репозитории. Фильтрация проблем и запросов на вытягивание по меткам позволит найти все соответствующие работы. Например, чтобы найти в проекте все ошибки внешнего интерфейса, отфильтруйте проблемы с метками front-end и bug. Дополнительные сведения см. в разделе Фильтрация и поиск проблем и запросов на вытягивание.

Пример метки

Ниже приведен пример метки front-end, которую мы создали и добавили в проблему.

Снимок экрана: проблема с именем "Интерфейсная работа для Project Octocat". На правой боковой панели в разделе "Метки" применяется метка "внешний интерфейс".

Добавление проблем на доску проекта

Вы можете использовать projects на GitHub для планирования и отслеживания работы для вашей команды. Проект — это настраиваемая электронная таблица, которая интегрируется с вашими проблемами и запросами на вытягивание в GitHub и автоматически обновляет сведения в GitHub. Макет можно настраивать, фильтруя, сортируя и группируя проблемы и запросы на вытягивание. Чтобы приступить к работе с проектами, см. раздел Краткое руководство по Projects.

Пример проекта

Ниже показан табличный макет из примера проекта, заполненный созданными нами проблемами Project Octocat.

Снимок экрана: представление таблицы проекта Project Octocat со списком проблем со столбцами "Заголовок", "Назначенные", "Состояние", "Метки" и "Заметки".

Этот же проект можно открыть как доску.

Снимок экрана: представление доски проекта "Project Octocat" с проблемами, упорядоченными по столбцам "Нет состояния", "Todo", "Выполняется" и "Готово".

Вы можете также использовать существующие projects (classic) на GitHub для планирования и отслеживания своей работы и работы вашей команды. Доски проектов состоят из проблем, запросов на вытягивание и заметок, распределенных в виде карточек между столбцами по вашему выбору. Доски проектов можно создавать для работы компонентов, для дорожных карт высокого уровня и даже для контрольных списков выпусков. Дополнительные сведения см. в разделе Сведения о projects (classic).

Пример доски проекта

Ниже показана доска проекта для репозитория Project Octocat из нашего примера с созданной нами проблемой, и добавлены проблемы поменьше, на которые мы ее разделили.

Снимок экрана: доска проекта с именем "Project Octocat Board" с проблемами, упорядоченными по столбцам "To do", "Выполняется" и "Done".

Дальнейшие действия

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