Planen und Nachverfolgen von Arbeiten für dein Team oder Projekt

Die Grundlagen für die Verwendung der Planungs- und Nachverfolgungstools von GitHub zum Verwalten von Arbeiten in einem Team oder Projekt.

In diesem Artikel

Einführung

Du kannst GitHub-Repositorys, -Issues, -Projekte und andere Tools verwenden, um deine Arbeit zu planen und nachzuverfolgen, unabhängig davon, ob du an einem einzelnen Projekt oder in einem funktionsübergreifenden Team arbeitest.

In diesem Leitfaden erfährst du, wie du ein Repository für die Zusammenarbeit mit einer Gruppe von Personen erstellst und einrichtest, Issuevorlagen und -formulare erstellst, Issues öffnest, Aufgabenlisten verwendest, um Arbeit aufzugliedern, und ein Projekt (klassisch) zum Organisieren und Nachverfolgen von Issues einrichtest.

Repository erstellen

Beim Starten neuer Projekte, Initiativen oder Features besteht der erste Schritt darin, ein Repository zu erstellen. Repositorys enthalten alle Dateien deines Projekts und machen einen Ort verfügbar, an dem du mit anderen zusammenarbeiten und deine Arbeit verwalten kannst. Weitere Informationen findest du unter Ein neues Repository erstellen.

Du kannst Repositorys für verschiedene Zwecke basierend auf deinen Anforderungen einrichten. Im Folgenden sind ein paar gängige Anwendungsfälle aufgeführt:

  • Produktrepositorys: Größere Organisationen, die Arbeit und Ziele im Zusammenhang mit bestimmten Produkten nachverfolgen, verfügen gegebenenfalls über mindestens ein Repository, das den Code und andere Dateien enthält. Diese Repositorys können auch für Dokumentation, Berichterstellung hinsichtlich der Produktintegrität oder zukünftige Pläne für das Produkt verwendet werden.
  • Projektrepositorys: Du kannst ein Repository für ein einzelnes Projekt erstellen, an dem du arbeitest, oder für ein Projekt, an dem du mit anderen zusammenarbeitest. Eine Organisation, die die Arbeit für kurzlebige Initiativen oder Projekte nachverfolgt, z. B. ein Beratungsunternehmen, muss über den Sachstand eines Projekts berichten und Projektbeteiligte basierend auf Qualifikationen und Bedürfnissen auf verschiedene Projekten verteilen. Code für das Projekt ist häufig in einem einzigen Repository enthalten.
  • Teamrepositorys: Bei einer Organisation, die Personen in Teams gruppiert und diesen Projekte zuteilt, z. B. im Fall eines Teams für Entwicklertools, kann Code auf viele Repositorys für die verschiedenen nachzuverfolgenden Arbeiten verteilt sein. Hier kann es hilfreich sein, ein teamspezifisches Repository als zentralen Ort zu nutzen, an dem alle Arbeiten nachverfolgt werden, an denen das Team beteiligt ist.
  • Persönliche Repositorys: Du kannst ein persönliches Repository erstellen, um all deine Arbeit an einem zentralen Ort nachzuverfolgen, zukünftige Aufgaben zu planen oder sogar Notizen oder Informationen hinzuzufügen, die du speichern möchtest. Du kannst auch Projektmitarbeiter hinzufügen, wenn du diese Informationen für andere Personen freigeben möchtest.

Du kannst mehrere, separate Repositorys erstellen, wenn du unterschiedliche Zugriffsberechtigungen für den Quellcode und zum Nachverfolgen von Issues und Diskussionen benötigst. Weitere Informationen findest du unter Ein Repository nur für Issues erstellen.

In den folgenden Beispielen in diesem Leitfaden wird ein Beispielrepository mit der Bezeichnung „Project Octocat“ verwendet.

Vermitteln von Repositoryinformationen

Du kannst eine README.md-Datei für dein Repository erstellen, um dein Team oder Projekt einzuführen und wichtige Informationen darüber zu vermitteln. Eine README-Datei ist häufig das erste Element, das ein Benutzer deines Repositorys sehen wird, sodass du auch Informationen darüber bereitstellen kannst, wie Benutzer oder Mitwirkende mit dem Projekt beginnen und wie du dich an das Team wenden kannst. Weitere Informationen findest du unter Informationen zu README-Dateien.

Du kannst auch eine CONTRIBUTING.md-Datei erstellen, die eigens dafür vorgesehen ist, Richtlinien vorzugeben, wie Benutzer oder Mitwirkende Arbeit zum Team oder Projekt beitragen und mit diesem interagieren können, z. B. wie sie ein Issue zur Fehlerkorrektur öffnen oder eine Verbesserung anfordern können. Weitere Informationen findest du unter Richtlinien für Repository-Mitarbeiter festlegen.

README-Beispiel

Zum Einführen des neuen Projekts – „Project Octocat“ – kann eine README.md-Datei erstellt werden.

Screenshot der Datei „README.md“ für das Repository „octo-org/project-octocat“ mit Details zum Projekt und zur Kontaktaufnahme mit dem Team.

Issuevorlagen erstellen

Du kannst Issues verwenden, um die verschiedenen Arten von Arbeit nachzuverfolgen, die dein funktionsübergreifendes Team oder Projekt abdeckt, sowie Informationen von Beteiligten außerhalb deines Projekts zu sammeln. Im Folgenden findest du ein paar gängige Anwendungsfälle für Issues.

  • Releasenachverfolgung: Du kannst ein Issue verwenden, um den Fortschritt für ein Release oder die Schritte zum Abschließen eines Starttags nachzuverfolgen.
  • Große Initiativen: Du kannst ein Issue verwenden, um den Fortschritt großer Initiativen oder Projekte nachzuverfolgen und dann eine Verknüpfung zu den kleineren Issues herzustellen.
  • Featureanforderungen: Teams oder Benutzer können Issues erstellen, um eine Verbesserung deines Produkts oder Projekts anzufordern.
  • Fehler: Teams oder Benutzer können Issues erstellen, um einen Fehler zu melden.

Je nach Typ des Repositorys und Projekts, an dem du arbeitest, kannst du bestimmte Arten von Issues gegenüber anderen Arten priorisieren. Nachdem du die häufigsten Issuetypen für dein Team identifiziert hast, kannst du Issuevorlagen und -formulare für dein Repository erstellen. Issuevorlagen und -formulare ermöglichen es dir, eine standardisierte Liste von Vorlagen zu erstellen, die Mitwirkende auswählen können, wenn sie ein Issue in deinem Repository öffnen. Weitere Informationen findest du unter Issuevorlagen für Dein Repository konfigurieren.

Beispiel für eine Issuevorlage

Nachfolgend wird eine Issuevorlage zum Melden eines Fehlers im Projekt „Octocat“ erstellt.

Screenshot des Formulars zum Erstellen einer neuen Issuevorlage. Die Felder werden ausgefüllt, um eine Vorlage mit dem Namen „Fehlerbericht für Project Octocat“ zu erstellen.

Nachdem du nun die Issuevorlage für den Fehlerbericht erstellt hast, kannst du diese beim Erstellen eines neuen Issues im Projekt „Octocat“ auswählen.

Screenshot der Seite „Neues Issue“ für „octo-org/project-octocat“ mit der Option zur Verwendung der Vorlage „Fehlerbericht für Project Octocat“

Öffnen von Issues und Verwenden von Aufgabenlisten zum Nachverfolgen der Arbeit

Du kannst deine Arbeit organisieren und nachverfolgen, indem du Issues erstellst. Weitere Informationen findest du unter Einen Issue erstellen.

Beispiel für ein Issue

Hier ist ein Beispiel für ein Issue, das für eine große Initiative, Front-End-Arbeit, im Projekt „Octocat“ erstellt wurde.

Screenshot eines Issues namens „Front-End-Arbeit für Project Octocat“. Der Issuetext enthält eine Liste der zu erledigenden Aufgaben.

Beispiel für eine Aufgabenliste

Du kannst Aufgabenlisten verwenden, um größere Issues in kleinere Aufgaben aufzuteilen und Issues als Teil eines größeren Ziels nachzuverfolgen. Aufgabenlisten verfügen über zusätzliche Funktionen, wenn sie dem Text eines Issues hinzugefügt werden. Du kannst sehen, wie viele von der am Anfang des Issues aufgeführten Gesamtzahl von Aufgaben abgeschlossen wurden. Wenn jemand ein in der Aufgabenliste verknüpftes Issue schließt, wird das Kontrollkästchen automatisch aktiviert, um das Issue als abgeschlossen zu markieren. Weitere Informationen findest du unter Informationen zu Aufgabenlisten.

Nachfolgend wurde dem Issue des Projekts „Octocat“ eine Aufgabenliste hinzugefügt, in der das Issue in kleinere Issues unterteilt wurde.

Screenshot eines Sachverhaltes namens „Front-End-Arbeit für Project Octocat“. Der Sachverhalttext enthält eine Aufgabenliste mit einem Kontrollkästchen vor jeder Sachverhaltverbindung.

Aufschlüsseln ihrer Arbeit mit Unterproblemen

Note

Problemtypen, Unterprobleme und erweiterte Problemsuche befinden sich derzeit in einer Opt-In-public preview für Organisationen. Weitere Informationen und Hinzufügen Ihrer Organisation zur Warteliste finden Sie im „GitHub-Blog“.

Sie können einem Problem Unterprobleme hinzufügen, um größere Arbeitspakete schnell in Aufgaben aufzuteilen. Unterprobleme unterstützen Hierarchien von Problemen auf GitHub, indem Beziehungen zwischen Ihren Problemen hergestellt werden. Sie können mehrere Ebenen von Unterproblemen erstellen, die Ihr Projekt genau darstellen, indem Sie die Aufgaben genau so detailliert aufschlüsseln, wie Sie und Ihr Team es benötigen. Siehe „Hinzufügen neuer Unterprobleme“ und „Browsen von Unterproblemen“.

Treffen von Entscheidungen als Team

Du kannst Issues und Diskussionen verwenden, um im Team zu kommunizieren und als Team Entscheidungen zu geplanten Verbesserungen oder Prioritäten für dein Projekt zu treffen. Issues sind nützlich, wenn du sie zur Diskussion bestimmter Details erstellst, z. B. für Fehler- oder Leistungsberichte, die Planung für das nächste Quartal oder das Design für eine neue Initiative. Diskussionen sind nützlich für offenes Brainstorming oder Feedback außerhalb der Codebasis und repositoryübergreifend. Weitere Informationen findest du unter Kommunikation in GitHub.

Als Team kannst du auch den aktuellen Stand täglicher Aufgaben innerhalb von Issues kommunizieren, damit jeder den Sachstand der Arbeit kennt. Du kannst z. B. ein Issue für ein großes Feature erstellen, an dem mehrere Personen arbeiten, und jedes Teammitglied kann Updates jeweils mit Status oder offenen Fragen in diesem Issue hinzufügen.

Issuebeispiel mit Projektmitarbeitern

Hier ist ein Beispiel für Projektmitarbeiter, die den aktuellen Sachstand ihrer Arbeit an dem Problem des Projekts „Octocat“ mitteilen.

Screenshot eines Issues namens „Front-End-Arbeit für Project Octocat“. Kommentare von @codercat und @octocat sind Statusupdates für die Arbeit.

Verwenden von Bezeichnungen zum Hervorheben von Projektzielen und -status

Du kannst Bezeichnungen für ein Repository erstellen, um Issues, Pull Requests und Diskussionen zu kategorisieren. GitHub bietet auch Standardbezeichnungen für jedes neue Repository, die du bearbeiten oder löschen kannst. Bezeichnungen sind nützlich zum Nachverfolgen von Projektzielen, Fehlern, Arbeitstypen und Issuestatus.

Weitere Informationen findest du unter Verwalten von Bezeichnungen.

Nachdem du eine Bezeichnung in einem Repository erstellt hast, kannst du diese auf beliebige Issues, Pull Requests oder Diskussionen im Repository anwenden. Anschließend kannst du Issues und Pull Requests nach Bezeichnung filtern, um alle zugeordneten Arbeiten zu ermitteln. Suche beispielsweise nach allen Front-End-Fehlern in deinem Projekt, indem du nach Issues mit den Bezeichnungen front-end und bug filterst. Weitere Informationen findest du unter Filtern und Suchen von Problemen und Pull-Anforderungen.

Beispiel für Beschriftungen

Nachfolgend findest du ein Beispiel für eine front-end-Bezeichnung, die erstellt und dem Issue hinzugefügt wurde.

Screenshot eines Issues namens „Front-End-Arbeit für Project Octocat“. Auf der rechten Randleiste wird im Abschnitt „Bezeichnungen“ die Bezeichnung „Front-End“ angewendet.

Hinzufügen von Issues zu einem Projekt (klassisch)

Du kannst projects auf GitHub verwenden, um die Arbeit für dein Team zu planen und nachzuverfolgen. Ein Projekt ist eine anpassbare Kalkulationstabelle, die mit den Issues und Pull Requests in GitHub integriert ist und automatisch auf dem neuesten Stand der Informationen in GitHub gehalten wird. Du kannst das Layout anpassen, indem du die Issues und Pull Requests filterst, sortierst und gruppierst. Informationen zu den ersten Schritten mit Projekten findest du unter Schnellstartanleitung für Projects.

Beispielprojekt

Hier ist das Tabellenlayout eines Beispielprojekts abgebildet, das mit den erstellten Issues des Projekts „Oktocat“ gefüllt ist.

Screenshot der Tabellenansicht des Projekts „Project Octocat“ mit einer Liste von Issues mit Spalten für „Titel“, „Zugewiesene Personen“, „Status“, „Bezeichnungen“ und „Anmerkungen“

Dasselbe Projekt kann auch als Board angezeigt werden.

Screenshot der Boardansicht des Projekts „Project Octocat“ mit Issues, die Spalten für „Kein Status“, „To-do“, „In Bearbeitung“ und „Fertig“ enthalten

Nächste Schritte

Du hast jetzt mehr über die Tools erfahren, die GitHub zum Planen und Nachverfolgen deiner Arbeit bietet. Außerdem hast du die ersten Schritte der Einrichtung deines funktionsübergreifenden Team- oder Projektrepositorys ausgeführt. Hier findest du einige hilfreiche Ressourcen, die du nutzen kannst, um das Repository weiter anzupassen und deine Arbeit zu organisieren.