• Software wird in mehreren Runden (Iterationen) entwickelt

• Lauffähige Software ist das oberste Ziel

• Das Team ist selbst verantwortlich, es gibt keinen Projektmanager

• *im Allgemeinen Software… aber nicht nur

Das „Herz“ von Scrum, in dem die eigentliche Entwicklungsarbeit geleistet wird

• Jeder Sprint kann man als Projekt ansehen bei dem alle Vorgaben erfüllt sein müssen.

• Jedes neue Inkrement baut auf das Alte auf.

• Ein Spint innerhalb einer Entwicklung hat immer eine gleichbleibende Dauer (Timebox max. 30 Tage)

• Das Sprint-Ziel ist die Entwicklung eines potentiell auslieferbaren Inkrements

• Das was entwickelt wurde…. z.B. eine App

  • Ein Product Increment ist potentiell Lauffähig….

    • d.h. es enthält alle Funktionalitäten die zur Ausführung einer Funktion nötig sind

  • Ein Product Increment ist getestet….

    • Alle fertigen Funktionalitäten sollen getestet sein, nicht nur auf Funktionalität, sondern auch auf Usability, Security usw.

  • Ein Product Increment ist demonstrierbar….

    • Es soll beim Sprint Review dazu genutzt werden, den aktuellen Stand und den Fortschritt zu demonstrieren

  • Ein Product Increment ist aber oft noch ein Prototyp….

    • Grade am Anfang der Entwicklung kann nur eine Teilfunktionalität am Ende des Sprint gezeigt werden, keine fertige Software die komplette Prozesse abdeckt

• Geordnete Liste von allem, von dem bekannt ist, dass es im Produkt enthalten sein soll (Funktionen, Features, User Stories)

• Das Backlog ist niemals vollständig und entwickelt sich mit dem Produkt weiter

• Der Product Owner ist die einzige Person, die für das Product Backlog und seine Einträge verantwortlich ist Das Sprint Backlog ist in der Verantwortung des Teams

• Teammitglieder sprechen während des Stand-Ups den Scrum Master an und nicht an das ganze Team

• Teammitglieder bringen neue Ideen ein und beginnen zu diskutieren

• Teammitglieder halten sich zu lange mit dem auf, was schon erledigt wurde, statt auf das zu focusieren was noch aussteht

• Teammitglieder sind nicht bei der Sache

• Scrum-Team identifiziert, welches Product Backlog Item spezifiziert werden muss.

• Product Owner erklärt, was es ist und warum es gebraucht wird.

• Entwicklungsteam versteht das Was und Warum.

• Entwicklungsteam weiß, wie es das Item umsetzen muss.

• Entwicklungsteam schätzt den Aufwand.

• Aktualisiertes Product Backlog Item ist weiterhin Aufwand und Nutzen wert.

Den eigentlichen Sprint kann man ebenfalls als Zeremonie sehen…..

Eine 2-4 Wochen andauernde Entwicklungs-Episode an deren Anfang das Sprint Planning steht, an deren Ende der Sprint Review und die Sprint Retrospektive stehen und die durch das Daily Scrum täglich eingeleitet (oder beendet) wird

Die eigentlich Entwicklungszeit nennt man auch Story Time

Rückblick auf den abgeschlossenen Sprint Feesdback Meeting, direkt nach dem Review.

• Alle Teilnehmer sollten stehen (logisch!).

• Der Zeitrahmen ist fest vorgegeben und sollte nicht zu lang sein. Standard sind 15 Minuten

• Das Meeting findet zu regelmäßigen Terminen immer zu gleichen Zeit statt.

• Jeder Teilnehmer kommt gut vorbereitet zum Meeting.

• Jeder Teilnehmer kommt zu Wort.

• Diskussionen werden vermieden und ggf. auf einen späteren Zeitpunkt vertagt.

• Das Daily findet am/beim -> Taskboard statt, dort können die Tasks direkt verschoben werden

• Scrum-Team identifiziert, welches Product Backlog Item spezifiziert werden muss

• Product Owner erklärt, was es ist und warum es gebraucht wird.

• Entwicklungsteam versteht das Was und Warum.

• Entwicklungsteam weiß, wie es das Item umsetzen muss.

• Entwicklungsteam schätzt den Aufwand.

• Aktualisiertes Product Backlog Item ist weiterhin Aufwand und Nutzen wert.

Backlog Grooming (manchmal auch als Backlog Refinement bezeichnet) beschreibt das Zuschneiden der User Stories bzw der Items im Backlog auf eine machbare Größe für den nächsten Sprint. Product Owner und Entwickler entscheiden zusammen, was noch zu groß ist. Dadurch wird der Product Backlog für das nächste Sprint Planning Meeting vorbereitet

• Ein Bugtracker ist ein Tool zur systematischen Fehlersuche und Protokollierung

• Manchmal ist ein Fehler (engl. Bug) aber auch wirklich ein Fehler – Und muss vom Tester oder vom Entwickler der ihn gefunden hat, an denjenigen weitergegeben werden, der ihn verursacht hat oder den, der ihn ausbessern soll - Dabei hilft ein Bugtracker, also ein Fehlerverwaltungssystem

• Beispiel Bugzilla

  • File a Bug: Wer einen Fehler findet, trägt ihn ein

  • Search: Entwickler können nach Fehlern suchen, die sie betreffen

• Ein Modultest (auch Unittest) wird in der Softwareentwicklung angewendet, um die funktionalen Einzelteile (Units) von Computerprogrammen zu testen d. h., sie auf korrekte Funktionalität zu prüfen.

• Modul/Unit = Eine Komponente, Klasse, Bauteil… Ist in sich abgeschlossen

  • Diese sollten separat getestet werden und erst wenn die Unit funktioniert, kann der nächste Task in Angriff genommen werden.

  • Daher ist der funktionierende Test auch Teil der -> Definition of Done (Management Praktik)

• Softwareentwicklung Nach der Implementierung oder währendessen

  • Am Taskboard wird markiert, ob ein Task oder eine Unit noch in der Entwicklung ist oder schon getestet wird, ob diese dokumentiert wurde und in welchem Status sie sich befindet.

  • Es geht aber auch anders. Manchmal schreibt der Entwickler oder die Entwicklerin zunächst die Tests und dann erst die Unit (-> Test Driven Development).

• Testen Testen heißt Fehler suchen und finden, also genau prüfen und nicht einfach durchwinken

  • Der Entwickler überlegt sich Testfälle und spielt diese mit der entwickelten Unit durch – am besten automatisiert und immer wieder bei jeder Änderung.

  • Der Test ist erfolgreich, wenn ein Fehler gefunden wurde… weil Fehler gibt es immer und diese sollen nicht in der Software bleiben

• Korrekte Funktionalität Dazu muss man erst mal wissen, was korrekt ist, also den erwarteten Wert

  • Beim Unit Test werden möglichst viele Testfälle automatisiert getestet.

  • Dazu muss man sich Testfälle überlegen – also mögliche Eingaben für Funktionen, Eingabefelder, Datenbankaufrufe etc. und die erwarteten Ausgaben dazu.

  • Beim Testen des Fehlermanagements ist es korrekt, wenn eine Fehlermeldung angezeigt wird, da dies die erwartete Ausgabe ist.

  • Der Test sollte auch den kompletten Quellcode abdecken, d.h. man sollte versuchen alle Fallunterscheidungen und Verzweigungen abzudecken.

• ist der Prozess, mit dem der Product Owner (häufig in Zusammenarbeit mit anderen) Backlog-Elemente im Backlog hinzufügt, anpasst, pflegt und priorisiert, um sicherzustellen, dass das wertvollste Produkt an Kunden versendet wird.

Vorteil

• Product Owner erhält zusätzlich Hilfe, um das Product Backlog zu verwalten

• Risiken werden gemindert, da das Backlog vor Sprint Plannings diskutiert wird

• Backlog enthält nur wirklich Relevante Items

• Fragen und Unklarheiten lassen sich schnell klären

Das Taskboard (oder Kanban Board oder Scrum Board) ist eine Möglichkeit zur Prozessvisualisierung.

Flexibel = Passe das Board an das agiles Vorgehensmodell an…. Z.B: durch weitere Spalten wie „Getestet“ oder „Dokumentiert“ … je nach Definition of Done

Übersichtlich = Man bewahrt den Überblick bei Team- und Projektaufgaben.

Transparent = Man hat einen Überblick über den aktuellen Status aller Aufgaben und teilt diesen mit allen Projektbeteiligten…. Auf einen Blick

Einfach = Man aktualisiert Teamaufgaben während der Besprechung im -> Daily Meeting

Vorteile:

• Die Visualisierung der Artefakte und die Darstellung der Fortschritte fördert die Zusammenarbeit in Teams.

• Oft ist ein Taskboard ein zentraler Anlaufpunkt, an dem sich Mitarbeiter treffen, um über Projekte, Prioritäten, Anforderungen etc. zu sprechen.

• Zusätzlich wirkt das Verschieben eines Artefakts in eine nachfolgende Spalte häufig motivierend.

• Planning Poker ist eine Technik für Teams, zur gemeinsamen, spielerischen Schätzung von Aufwänden von User Storys.

• Methodik, die es einem Team in bewährter Größe erlaubt, Anforderungen in kurzer Zeit angemessen genau zu schätzen. Das „Spiel“ liefert drei Ergebnisse:

Kurzer Ablauf:

1. Jeder im Team nimmt sich einen Kartensatz.

2. Der Product Owner stellt eine Anforderung kurz vor und das Team stellt Verständnisfragen.

3. Jeder legt die Karte mit seiner Schätzung verdeckt ab.

4. Anschließend decken alle gleichzeitig ihre gelegte Karte auf.

5. Wenn alle Schätzungen gleich hoch sind, gilt dies als Ergebnis.

6. Ansonsten diskutiert das Team kurz die Ausreißer und schätzt erneut.

• Schätzungen sollten nur von denjenigen abgegeben werden, die auch tatsächlich an der Aufgabe arbeiten.

• Bei Unsicherheiten zwischen zwei Zahlen sollte zur höheren Zahl geschätzt werden.

• Während des gesamten Planning Poker-Spiels ist ein Timer hilfreich, der ausschweifende Diskussionen und Fragerunden unterbindet.

Vorteil:

• Es macht Spaß!!!

• Auch introvertierte Teilnehmer können zu Wort kommen – alle Meinungen zählen gleich

• Die Qualität der Schätzung steigt, da jeder Teilnehmer seine Sicht der Dinge vortragen kann und somit auch jeder gehört wird.

• Strukturierter Ablauf. Als Folge diskutiert nicht jeder mit jedem, sondern zwei Teilnehmer, die zusammen einen gemeinsamen Nenner finden müssen. Das spart Zeit und oftmals auch Nerven.

• Kriterien, die abgeschlossen sein müssen, bevor ein Projekt oder eine User Story als abgeschlossen betrachtet werden kann.

• Transparenz Die Definition of Done sollte für alle sichtbar aufgehängt werden. Ein klassischer Fehler ist diese zu digitalisieren, da hierdurch diese nicht vergegenwärtigt wird. Die Definition of Done kann auch die Spalten des -> Taskboard beeinflussen

• Commitment Das gesamte Team muss die Definition festlegen. Eine einseitige Festlegung z. B. durch den SCRUM Master führt dazu, dass sie nicht beachtet wird bzw. das Team nicht hinter den Kriterien steht.

Vorteile:

• Es gibt ein gemeinsames Verständnis von Qualität des Teams.

• Jeder im Team weiß, was von jedem erwartet wird und was das Team als Einheit zu liefern hat.

• Der Anspruch im Team, qualitative Arbeit zu leisten, steigt.

• Die vereinbarten Kriterien lassen sich überprüfen, d.h. die DoD ist ein Arbeitsmittel.

• Es entsteht Klarheit darüber, ob ein Backlog Item, ein Feature oder eine User Story tatsächlich „done“ ist.

Starfish Kategorien:

• START: Mit was sollten wir beginnen?

• KEEP: Was müssen wir beibehalten, weil es so richtig funktioniert?

• MORE: Von was müssen wir mehr machen?

• LESS: Mit was müssen wir unbedingt aufhören?

• STOP: Mit was müssen wir unbedingt aufhören?

• Das Sprint Review ist ein Treffen am Ende eines Sprints zur Beurteilung und Abnahme der erledigten Arbeit in Bezug auf das gesteckte Sprintziel.

• Jeder der Interesse am „Produkt“ hat ist eingeladen

• Der Scrum Master lädt zum Sprint Review ein und moderiert das Meeting

• Das Team stellt nur fertige und vom Product Owner abzunehmende Stories vor.

• Es wird nur laufende Software und keine Folien gezeigt

• Jeder Teilnehmer kann Feedback geben.

• Beim Sprint Review wird sichtbar, was bereits erarbeitet wurde. Da nur realisierte User Storys und deren Umsetzung live im Produkt präsentiert werden dürfen, ist der Fortschritt der Entwicklung für alle Beteiligten direkt ersichtlich.

• Das Meeting bedarf keiner großen Vorbereitung, da keine Präsentation und keine Folien gezeigt werden, sondern lediglich das bisher erstellte Produkt präsentiert wird.