JIra + Greenhopper - Agile richtig machen

Ich bin neu in der Agilen fließen in JIRA + Greenhopper.
Ich versuche zu verstehen, was ist die richtige/bessere Weg zu arbeiten Agile JIRA + GH.
Ich habe gelesen, auf dem Netz für einige Informationen - so weit, dass ich verstehen, wir haben Geschichten und Epen (das sind GROßE Geschichten). Ich wollte wissen, was ist die Strömung die Erstellung der Aufgaben:

  1. Zunächst öffnen wir eine Geschichte/Epos und definieren Sie es in einem nicht-technischen text.
  2. Wir können Teilaufgaben an die Geschichte ( ich habe technisch-Teilaufgaben erst jetzt).
  3. nach dem öffnen der story - Entwicklung, neue tickets (bug/neue Funktion/Aufgabe etc) angelegt und verknüpft sind mit der FRAGE VERKNÜPFEN die Geschichte.

Ist dies die richtige Strömung? Meine Fragen sind:

  1. Ich verstehe nicht, warum in (2) wir sollten öffnen Teilaufgaben für technische Probleme, wenn ich open-development-tickets separat und miteinander verknüpfen - also, was ist der Zweck der sub-Aufgaben in Geschichte?
  2. Gibt es eine bessere/einfachere Möglichkeit zu schaffen, die dev-tickets direkt vom GH? oder muss ich öffnen Sie Sie einzeln auf und verknüpfen Sie Sie mit der Geschichte übergeordneten Thema?

Vielen Dank für die schnelle Antwort.

InformationsquelleAutor der Frage Himberjack | 2011-06-05

  1. 27

    Wie wir benutzen es ist wie folgt:

    1. Wir erstellen eine Geschichte zu definieren, eine feature-Anfrage (eine nicht-technische Aufgabe in Ihrem verbage)

    Wenn wir das planen einer iteration, werden wir priorisieren die Geschichten, die wir erreichen wollen. Für jede Geschichte, das team wird das erstellen von tasks (Teilaufgaben) auf, wie die Geschichte aufzubauen. Diese Aufgaben werden bestimmte Dinge erledigt werden: Erstellen einer Datenbank-Tabelle, ändern der controller-code, QA die Funktion aktualisieren der Öffentlichen Dokumentation, etc.; zusammen mit der person, die werden die Durchführung der Aufgabe und Ihre Einschätzung auf Zeit.

    Als die iteration fortschreitet, jedes team Mitglied meldet Ihre Arbeit auf jede Aufgabe und verfeinert Ihre Einschätzung auf die Aufgabe, wie Sie haben mehr Informationen. Wenn die Aufgabe abgeschlossen ist, wird es geschlossen. Wenn alle Aufgaben abgeschlossen sind, wird die Geschichte für die Bereitstellung bereit ist.

    Auch, beim erstellen von sub-Aufgaben, wenn Sie das hinzufügen von sub tasks in der Kartenansicht unter das ZAHNRAD, es wird eine Karte geben Sie die Elemente auf die Aufgabe (ähnlich wie die Karte der Schöpfung), wo Sie auch weiterhin zu schaffen Teilaufgabe Karten, bis getan. Unserer Meinung nach, eine sehr schnelle, einfache Methode zur Eingabe von Aufgaben.

    Hoffentlich hilft. Lassen Sie mich wissen, wenn Sie Fragen haben oder möchten Sie mehr details auf etwas anderes.

    InformationsquelleAutor der Antwort Steven Mastandrea

  2. 16

    Ich denke, es ist wichtig zu beachten, dass der flow unterscheidet sich von team zu team.

    Beispielsweise einige teams ein product owner, der beginnt mit der Epischen und dann bricht diese nach unten in Geschichten, hinzufügen von Akzeptanz-Kriterien /Bedingungen von Erfolg, wie Sie gehen. Oft wird in diesem Szenario wird das team gemeinsam in einer Vorbesprechung und zerlegen diese Geschichten in der Sub-Tasks.

    Einige teams geben, die ein story point-Schätzung (in der Regel fibonacci) zu den Geschichten, die anderen weisen Sie eine Stunde schätzen, um die Sub-Aufgaben. Bei der Zuteilung einer Stunde Schätzung teams Häufig aktualisieren Sie die Verbleibenden Schätzung, wie Sie Fortschritte. Dies gibt einen guten Hinweis auf die Stunde burndown-chart, was den sprint Fortschritt ist.

    Habe ich auch gesehen, die teams, in denen der product owner erstellt eine Menge Geschichten und Aggregate, die Sie manuell in Epen zu einem späteren Zeitpunkt. Wenn ich hatte eine bevorzugte Methode wäre es der erste Ansatz für eine einfache, aber es wird immer Geschichten, die man verpasst/vergessen und Hinzugefügt werden, während einer planungssitzung.

    Den Epen der Regel geplant in etwas anderes als einen release-backlog, wie Sie erstrecken sich oft über mehrere sprint-backlogs. Beide sprints und releases behandelt werden als Fix-Versionen in JIRA, Schachteln von Eltern/Kind-Rückstände hilft eine Visualisierung, wie das, was geplant ist.

    Dies ist für scrum. Wenn Sie daran interessiert sind kanban-dann kann ich teilen, was ich gesehen habe, teams zu tun in diesem Szenario, sagen Sie einfach die Wort.

    Cheers,
    Nicholas Muldoon

    InformationsquelleAutor der Antwort Nicholas Muldoon

Schreibe einen Kommentar