framework

WAS IST SCRUM?

Scrum ist eine agile, inkrementelle Entwicklungsmethode. Mit jedem Inkrement liefert das Team ein potentiell nutzbares Produkt. Dabei können Anforderungsänderungen kontrolliert in das Projekt einfließen.

Im Mittelpunkt steht die Selbstorganisation des Teams. Der Scrum Master unterstützt dabei, um störungsfreies Arbeiten zu ermöglichen.

Das Entwicklungsteam benötigt keinen Projektleiter. Der Product Owner übernimmt als Produktverantwortlicher die fachlichen Anforderungen und definiert, priorsiert und passt diese ggf. an. Die Regeln von Scrum tragen zu Transparenz und störungsfreien Entwicklungszyklen (Sprints) bei.

WAS IST KANBAN?

STOP START - START FINISHING

Kanban ist ein Vorgehen, das beim Durchlauf einer Wertschöpfungskette die Anzahl paralleler Arbeiten, den Work in Progress (WIP), reduziert und somit schnellere Durchlaufzeiten erreicht.

Dabei werden Probleme, insbesondere Engpässe, schnell sichtbar gemacht.

Kanban kommt aus der Lean-Production und wurde durch den Einsatz bei Toyota bekannt. Das Vorgehen wurde inzwischen auf die Softwareentwicklung und auf organisatorische Abläufe angepasst.

Kanban ist ein wunderbares Tool, um auch persönliche Aufgaben zu visualisieren und eigene Aufgaben strukturiert und fokusiert abzuarbeiten.

GEGENÜBERSTELLUNG VON SCRUM & KANBAN

SCRUM

  • Iterationen mit gleicher Länge sind vorgeschrieben.
  • Team vereinbart eine bestimmte Menge an Arbeit, die im nächsten Sprint erledigt werden soll.
  • Velocity (Team-Geschwindigkeit) = Basis Metrik.
  • Teams sollen cross-funktional zusammengesetzt werden.
  • Anforderungen müssen innerhalb eines Sprints geschafft werden.
  • Burndown-Charts werden als Metrik benutzt.
  • Indirekte WIP-Limitierung durch die begrenzte Menge im Sprint. Optionale WIP-Limitierung innerhalb eines Sprints.
  • Schätzungen sind vorgeschrieben.
  • Keine neuen Anforderungen im laufenden Sprint.
  • Drei vorgeschriebene Rollen (Product Owner, Scrum Master, Entwicklungsteam)
  • Scrum-Board gehört dem Team und wird nach jedem Sprint geleert.

KANBAN

  • Iterationen sind optional. Unterschiedliche Kadenz für Planung, Relese und Prozessverbesserung.
  • Commitments sind optional.
  • Cycle-Time (Durchlaufzeit) = Basis Metrik für Planung und Prozessverbesserung.
  • Experten-Teams sind erlaubt.
  • Das Erledigen der Anforderungen dauert so lange es dauert. Es gibt keine Vorschrift an die Größe einer Anforderung.
  • Es wird kein bestimmter Diagrammtyp vorgeschrieben. Bewährte Diagramme sind CFD (Cumulativ-Flow-Diagramm) und Chart-Control.
  • Work-In-Progress (WIP) wird direkt limitiert.
  • Schätzungen sind optional.
  • Jederzeit neue Anforderungen im Rahmen der WIP-Limitierung möglich.
  • keine vorgeschriebenen Rollen
  • Board kann von 1-n Personen geteilt werden und wird kontinuierlich gepflegt.

EINSATZ VON SCRUM & KANBAN

 

EXTERME PROGRAMMING

XP bringt viele Werte und Prinzipien mit, die sich in anderen agilen Frameworks wie Scrum, Kanban etc. wiederfinden. Die Praktiken helfen Teams effiziente und wertvolle Software zu liefern.

XP enthält fünf Werte, die sich vorallem im Software-Bereich bewährt haben: Einfachheit, Kommunikation, Feedback, Respekt und Mut. Es fokusiert auf Test-Driven-Development (TDD), kleinen Releasen und eine Team-Struktur, die den Kunden beinhaltet.

Viele Reglen dieser agilen Methode sind speziell auf Coding, Design und Testen ausgerichtet. Das Planning wird z.B. direkt vor dem Tun durchgeführt. XP gibt vor, den Release auf einem hohen Level zu planen, jeder Iteration jedoch immer zu Beginn.

 

12 PRINZIPIEN VON XP

DAS PLANEN

Die vom Kunden gewünschten Software-Features, sind verbunden mit Kostenabschätzung durch die Entwickler, um die wichtigsten Faktoren für die Software zu bestimmen.

SMALL RELEASES

Die Software wird in kleinen Schritten entwickelt und häufig geliefert.

METAPHOR

Alle Team-Mitglieder eines XP-Teams haben eine gemeinsame Sprache und Beschreibungen als Leitfaden für die Entwicklung und die gemeinsame Kommunikation

SIMPLE DESIGN

Die Software sollte in jeder Stufe nur den absolut notwendigen Code für die vom Kunden gewünschten Ergebnisse bereitstellen. Die Absicht liegt nicht darin, für zukünftige Versionen des Produkts zu arbeiten.

TESTING

Tests finden von Anfang an durchgängig durch den gesamten Entwicklungsprozess statt. Entwickler erstellen die Tests vorab und schreiben dann die Software, um die Testanforderungen zu erfüllen. Die Kunden stellen Akzeptanztest zu jedem Stadium zur Verfügung, um das gewünschte Ergebnis sicherzustellen.

REFACTORING

XP-Entwickler verbessern die Software und ihre Architektur fortlaufend während des gesamten Entwicklungszeitraums anstatt bis zum Ende zu warten, um Fehler zu beheben und Veränderungswünsche zu berücksichtigen.

PAIR PROGRAMMING

Jede Zeile wird in Zusammenarbeit mit einem weiteren Entwickler am selben Rechner geschrieben.

COLLECTIVE OWNERSHIP

Aller Code gehört allen Entwicklern, die am Projekt mitarbeiten. Keine persönlich zugeordnete Verantwortlichkeit soll das Projekt verlangsamen. Wenn nötig, wird Code angepasst - und dann ohne Verzögerung

CONTINUOUS INTEGRATION

Ein XP-Team integriert und baut das Software-System mehrfach am Tag und hält für alle Entwicklung diesselbe aktuelle Software-Basis bereit.

40-STUNDEN WOCHE

Ein XP-Team macht keine übersteigernden Überstunden, um sicherzustellen, dass alle ausgeruht, aufmerksam und effektiv bleiben.

ON-SITE CUSTOMER

Ein XP-Projekt wird vom Kunden geleitet, welcher über die gesamte Zeit erreichbar ist, um Fragen zu beantworten, zu priorisieren und die Anforderungen an das Projekt festzulegen.

CODING STANDARD

Die Entwickler schreiben Code auf diesselbe Art und Weise. Dies ist die Grundvoraussetzungen, um als Pair zu arbeiten und die Verantwortung für den gesamten Code mitzutragen.

FEATURE DRIVEN DEVELOPMENT (FDD)

Feature Driven Development ist vor allem für die Product Owner ein hilfreiches Modell, um mit Hilfe des Kano-Modells, die Ausprägung der Features bestimmen können. 

Wichtig ist es jedoch, inkrementell zu arbeiten, d.h. von allen Features das Minimum zu erstellen und dann Schritt für Schritt aufzubauen. Dies stellt sicher, dass zum Liefertermin alle notwendigen Features erstellt sind anstatt nur ein Teil davon in der besten Variante.