Iterationsübersicht

Die App "Iterationsübersicht" ermöglicht es Ihnen, eine einfache Übersicht zum Fortschritt des Teams für eine Iteration anzuzeigen. Basierend auf dem Arbeitsstatus, den Defekten und den Testfällen werden farbige Indikatoren angezeigt, mit denen Sie die Probleme umgehend behandeln können.

Iterationsübersicht

Angezeigte Daten

Der obere Bereich zeigt grundlegende Iterationsdetails:

  • Name
  • Tage verbleibend
  • Gesamtanzahl der Tage
  • Iterationszustand ("Planung", "Übergeben", "Akzeptiert")

Abhängig vom Zustand Ihrer Iteration werden Warnmeldungen in bis zu drei Abschnitten angezeigt.

Akzeptierte Arbeit

Die gesamt akzeptierte Arbeit stellt alle Elemente dar, die direkt in der Iteration geplant wurden. Dieser Abschnitt wird immer angezeigt und enthält den Prozentsatz der Arbeit mit dem Zeitplanzustand "Akzeptiert". Zu den Arbeiten in diesem Prozentsatz gehören:

  • User Storys
  • Unabhängige Defekte (nicht an den Storys in der Iteration angehängt)
  • Defekt-Suites
  • Testsätze

Der Balken neben dem Prozentsatz der akzeptierten Arbeit ändert abhängig vom Iterationszustand seine Farben:

  • Grau: Einige, alle oder keine Arbeiten wurden in der ersten Hälfte der Iteration akzeptiert.
  • Grün: Alle Arbeiten wurden akzeptiert. Iteration ist beendet.
  • Gelb: Einige oder keine Arbeiten wurden in der zweiten Hälfte der Iteration akzeptiert.
  • Rot: Einige oder keine Arbeiten wurden akzeptiert. Iteration ist beendet.

Hinweis: Es müssen Punkte im Feld "Planschätzung" der geplanten Elemente in Ihrer Iteration eingegeben sein, damit der Prozentsatz der akzeptierten Arbeiten angezeigt wird.

Aktive Defekte

"Aktive Defekte" zeigt Defekte an, die mit User Storys verknüpft sind, die der Iteration zugewiesen jedoch nicht direkt in der Iteration geplant sind. In diesem Abschnitt wird nur angezeigt, ob offene Defekte an den User Storys in der Iteration angehängt sind.

Hinweis: In dieser App sollen Defekte angezeigt werden, die mit Storys verknüpft sind, die nicht in den Punkten für die Iteration gezählt werden. Dadurch wird sichergestellt, dass keine Arbeiten übersehen werden. Es ist nicht empfehlenswert, Storys mit verknüpften Defekten zu akzeptieren, wenn die Defekte nicht behoben wurden.

Die Gesamtanzahl der Defekte, die sich nicht im Zustand "Geschlossen" befinden, wird angezeigt. Der Balken neben diesem Abschnitt ändert abhängig vom Iterationszustand seine Farben:

  • Gelb: Alle offenen Defekte. Iteration ist noch aktiv.
  • Rot: Verbleibende offene Defekte. Iteration ist beendet.

Tests bestanden

Dieser Abschnitt zeigt an, ob Testfallergebnisse in der Iteration für Tests vorhanden sind, die an einer User Story oder an einem Testsatz angehängt sind. Wenn verknüpfte Testfälle aber keine Ergebnisse vorhanden sind, dann wird dieser Abschnitt nicht angezeigt. Der Abschnitt wird abhängig vom Zustand der Ergebnisse und der Iteration farbig angezeigt:

  • Grau: Einige Tests haben während der ersten Hälfte der Iteration bestanden.
  • Grün: Alle Tests haben bestanden, zu jedem Zeitpunkt.
  • Gelb: Während der ersten Hälfte der Iteration haben keine Tests bestanden, oder einige Tests haben während der zweiten Hälfte bestanden.
  • Rot: Einige oder keine Test haben bestanden. Iteration ist beendet.

Definieren der ersten Hälfte einer Iteration

Viele dieser Statusaktualisierungen beruhen auf das Alter der Iteration. Die Regeln für die Definition der ersten und zweiten Hälfte einer Iteration sind:

  • Wenn die Länge der Iteration 10 Tage oder kürzer ist, dann ändert sich die Farbe von grau auf gelb, nachdem 50 % der Tage vergangen sind.
  • Wenn die Länge der Iteration 10 Tage oder länger ist, dann ändert sich die Farbe nach dem fünften Tag der Iteration von grau auf gelb. Der Grund dafür ist, dass es sehr viel gefährlicher ist, wenn Sie sich in der dritten Woche einer vierwöchigen Iteration befinden und keine akzeptierten Arbeiten haben, im Vergleich zum dritten Tag in einer fünftägigen Iteration.

Zusätzliche Funktionen

Verwenden der Einstellung für die automatische Höhe, um den senkrechten Bereich der App automatisch an die Menge der sichtbaren Daten anzupassen

Coaching-Ecke: Warum sind diese Warnungen wichtig?

Unsere Coaching-Organisation ist auf Agile-Methoden spezialisiert und hilft Kunden dabei, die Verwendung von CA Agile Central auf ihre speziellen Workflows zuzuschneiden. Überprüfen Sie Folgendes mit Ihren Scrum-Teams, um sicherzustellen, dass Sie effektive "Definition of Done"- und Arbeitsvereinbarungen erstellen.

Weitere nützliche Informationen stehen Kunden von CA Agile Central zur Verfügung, die ihre Agile-Prozesse noch weiter vorantreiben möchten. Gegen eine geringe Gebühr können Sie eine telefonische Beratungssitzung für eine Stunde buchen. Hier erfahren Sie mehr.

Warum müssen Storys schon früh in der Iteration akzeptiert werden?

Nicht akzeptierte Storys stellen Risiken dar. Es könnte das Risiko bestehen, dass die Story am Ende der Iteration nicht abgeschlossen ist und dass die gesamte Iteration in Schwierigkeiten gerät, wenn nicht akzeptierte Arbeiten entdeckt werden. Um dieses Risiko zu mindern, überprüfen Sie regelmäßig die Storys, und akzeptieren Sie genehmigte User Storys, sobald sie abgeschlossen sind. Durch proaktives Management beim Akzeptieren von User Storys hat das Team ausreichend Zeit, um vollständig akzeptierbare Storys zu liefern, die auf der zuvor vereinbarten "Definition of Done" basieren.

Neben diesem Risiko ist das pünktliche Akzeptieren von Storys ein wichtiger Punkt, um exakte Burndown-Diagramme zu erhalten. Abgeschlossene Story-Punkte werden erst in diesen Diagrammen dargestellt, sobald sie akzeptiert wurden. Wenn Sie abgeschlossene Storys nicht akzeptieren, dann bleibt Ihr Diagramm bis zum letzten Tag der Iteration flach und ist damit für Ihr Team und Ihre Stakeholders nutzlos.

Aus Lean-Sicht sind nicht akzeptierte User Storys ein Teil von WIP (Work-in-Progress). In der Lean- und Agile-Softwareentwicklung versuchen Teams den WIP einzuschränken, indem die Anzahl der Storys, die sich gleichzeitig in Bearbeitung befinden, eingegrenzt wird. Diese Einschränkung gilt für Storys, die abgeschlossen sind, jedoch noch nicht akzeptiert wurden. Diese Storys werden als "In Bearbeitung" betrachtet, da sie jederzeit als inakzeptabel gelten und aus dem Zustand "Abgeschlossen" verschoben werden können. Das Verwalten von WIP-Einschränkungen erleichtert den Arbeitsablauf des Development-Teams, indem Unterbrechungen und Kontextwechsel eingeschränkt werden.

Warum sollten alle Defekte abgeschlossen werden, bevor eine Story akzeptiert wird?

Wenn Sie eine "Definition of Done" für User Storys erstellen, dann ist es empfehlenswert, dass für die Teams alle Defekte dieser Storys geschlossen sein müssen, bevor sie akzeptiert werden. Da eine akzeptierte Story eine abgeschlossene Funktion darstellt, stellen alle Defekte, die an die Story angehängt sind, eine technische Schuld dar und sollten während der Iteration gelöst werden.

Es ist empfehlenswert, User Storys zu testen, sobald sie fertig sind. Wenn mehr Zeit benötigt wird, um gefundene Defekte zu beheben, dann sollte das Team versuchen, diese Defekte zu beheben, bevor andere Storys in der Iteration gestartet werden. Wenn für die Behebung des Defekts viel Zeit benötigt wird, dann sollte das Team die verknüpfte User Story nicht veröffentlichen und die erforderlichen Arbeiten in die Schätzung der nächsten Iteration einbeziehen. Es ist allgemein besser, eine einzelne, abgeschlossene und vollständig getestete Story zu liefern, als mehrere unvollständige und nicht getestete Storys nach einer Iteration zu liefern.

Warum sollten alle Tests in einer Iteration bestehen?

Zusätzlich zu den Akzeptanzkriterien stellen Testfälle die allgemeine Qualität einer abgeschlossenen User Story oder Iteration dar, und sie geben an, ob sie akzeptabel sind. Sie können viele Testtypen erstellen: Akzeptanz, Leistung, Regression, Funktional, Benutzerfreundlichkeit und Benutzeroberfläche. Alle diese Testtypen sind für alle Agile-Development-Teams bei der Erstellung der "Definition of Done" sehr wertvoll. Wenn Ihr Team diese verschiedenen Tests in den Alltag integriert, wird es immer wichtiger, dass alle Tests vor dem Ende der Iteration bestehen. Außerdem sollten so viele Tests wie möglich bestehen, wenn jede einzelne Story als Teil des Akzeptanzprozesses abgeschlossen wird.

Wenn Sie sich dem Ende einer Iteration nähern und nur wenige Tests abgeschlossen wurden, dann besteht ein höheres Risiko, dass Ihre Verpflichtungen nicht erfüllt werden. Unvollständige Tests können versteckte Defekte beinhalten, die dann zur technischen Schulden führen und möglicherweise zukünftige Iterationen stören.

Feedback

Benötigen Sie weitere Informationen? Die CA Agile Central-Community ist Ihre zentrale Anlaufstelle für Self-Service und Support. Treten Sie der CA Agile Central-Community bei, um dem CA Agile Central-Support Feedback mitzuteilen oder Fälle zu melden, Antworten zu finden oder mit anderen Benutzern zusammenzuarbeiten.