Untergeordnete Seiten
  • Live-Session - Scrum und Kanban bei SEIBERTMEDIA
Zum Ende der Metadaten springen
Zum Anfang der Metadaten

Die Live-Session fand am 27. Januar 2011 wie immer um 11:15 Uhr auf unserer Live-Session-Portalseite statt.

Aufzeichnung der Live-Session

Dieses Video downloaden (164,48 MB, MP4)

Inhalte der Live-Session:

Scrum und Kanban bei //SEIBERT/MEDIA - Der Status Quo

Martin Seibert leitet in das Thema ein:

  • Über 20.000 Stunden Projekterfahrung in internen und externen Projekten mit agilen Entwicklungsmethoden
  • Eine der erfahrensten und größten Anbieter (für Scrum in Verbindung) mit Jira und Confluence (Atlassian-Tools) in Deutschland
  • 4 von der Scrum-Alliance zertifizierte Scrum-Master und Scrum-Product-Owner (Wir evaluieren eine Zertifizierung aller Projektteilnehmer im Unternehmen).
  • Großes Interesse am Thema und der Implementierung bei //SEIBERT/MEDIA
  • Wunsch der Etablierung von noch mehr Workshops und Beratungsleistungen für unsere Kunden
  • Best Practices: Methoden- und Werkzeugkiste mit Anwendungstipps soll noch größer werden. Hier sind wir am Austausch (auch mit Kunden) interessiert.

Scrum

Scrum hat drei Rollen (Scrum-Master, Product Owner, Team), drei Artefakte (Product Backlog, Sprint Backlog, Burn Down Diagramm) und fünf Meetings (Sprint Planning I, Sprint Planning II, Daily Scrum, Review, Retrospective).

  • Festes Entwicklungsintervall: Sprints dauern bei uns meist 2-4 Wochen.
  • Festgelegter Funktionsumfang: Product Owner priorisiert und stellt umzusetzende Features im Sprint Planning vor. Team verpflichtet sich zu Menge.
  • Tägliches Treffen (daily scrum) wie eine Einsatzbesprechung.
  • Am Ende gibt es eine Präsentation (Review) des aktuellen Stands für alle interessierten Stakeholder.
  • In einer Retrospektive am Ende jedes Entwicklungsintervalls (im Prozess) sammelt das Scrum-Team Ideen für Verbesserungen.

Grundsätze von Scrum

  • Nach jedem Entwicklungsintervall gibt es ein auslieferbares Produktinkrement.
  • Qualität ist nicht verhandelbar.
  • Selbstbestimmung des Teams (Operationalisierung der Umsetzung und Aufgabenverteilung)
  • Das agile Manifest
    • Individuen und Interaktionen vor Prozessen und Tools
    • Funktionierende Prozesse vor Dokumentation
    • Stetige Zusammenarbeit vor Verträgen
    • Offenheit für Änderungen vor Befolgen von Plänen

Vorstellung des Scrum-Taskboards

Multimedia-Elemente: Video des Boards, Fotos, Greenhopper in Jira (Screenshot und Live), Burndown-Chart aus Jira (gemalt und live)

  • Die Bahnen (swim lanes) sind User Stories. Die wichtigste steht ganz oben.
  • Die Bearbeiter platzieren Ihre Avatare auf den Aufgaben, die gerade bearbeitet werden.
  • Alles soll von links nach rechts und oben nach unten bearbeitet werden.
  • Es gibt eine "fast forward lane" im Team TwentyFeet.
  • Beim Task-Break-Down werden Karten mit der Hand erstellt.
  • Dann werden alle Karten in Jira erstellt. Die Karten werden alle ausgedruckt und ersetzen die handgeschriebenen Zettel (Demo-Video zu Scrum Cards aus Jira).
  • Die Arbeitsschritte entsprechen genau dem Jira-Workflow des Projekts.
  • Auch die Vorgangstypen entsprechen den Scrum-Üblichen Terminologien: Epics, User Stories, Tasks, Bugs
  • Alle geleisteten Arbeitszeiten werden in unseren TimeTracker eingegeben und in Jira hinterlegt. Damit generieren wir die Burn-Down-Diagramme.

Kanban

Kanban in der IT ist ein Vorgehen, das bei der Softwareentwicklung die Anzahl paralleler Arbeiten, den Work in process (WiP), reduziert und somit schnellere Durchlaufzeiten erreicht und Probleme – insbesondere Engpässe – schnell sichtbar macht.
Quelle: http://de.wikipedia.org/wiki/Kanban_in_der_IT

  • Grundprinzip
    • Eigenverantwortung: Pull (aus dem Team heraus) statt Push (durch den Projektmanager)
    • Stop starting. Start finishing.
    • Work in progress - Limits
  • Taskboard zur Übersicht
    • Darstellung des Status Quo der Produktion (Board ist optimalerweise nie leer)
    • Engpasserkennung - Sichtbarkeit und Prognose von Produktionsproblemen
    • Aufgabenverteilung im Team sichtbar machen (Avatare)
    • Priorisierung operationalisieren (Reihenfolgen und spezielle Kennzeichnungen)
    • Team entwickelt das Board selbst, damit es optimal zum Entwicklungsprozess passt. (Identifikation, Verbindlichkeit)

Vorstellung des Taskboards des Team Web

Multimedia-Elemente: Video mit Überblick über das Board, Fotos vom Board

 

Unterscheidung zwischen Scrum und Kanban

  • Letztendlich besteht Kanban aus dem Board und den Prinzipien.
  • Wir nutzen Scrum für große Entwicklungsprojekte und Kanban für Support- und Beratungsarbeiten und kleinere Aufgaben deren Umfang schlecht planbar ist.
  • Neue Anforderungen können bei Kanban jederzeit aufgenommen werden. Scrum ändert sich im Sprint nicht.
  • Kanban kennt keine Rollen.
  • Kanban definiert keine Meetings. Häufig werden Elemente aus Scrum eingesetzt: Daily Standup-Meeting, Retrospective.

Weiteres Kanban Anwendungsbeispiel: Das Projekt-Portfolio-Board

Multimedia-Elemente: Video mit Überblick über das Board, Fotos vom Board

Video mit Überblick und Funktionsweise des Boards:

Video zu IdeaMEMO ColorPADS:

Fotos für die Live-Session

Weitere Inhalte als Grundlagen

Für interessierte Leser gibt es hier noch ein paar weitere Inhalte, die in der Live-Session nicht behandelt werden können.

Scrum

  • Methode der agilen Software-Entwicklung und des agilen Projektmanagements
  • Kompromiss bei Funktionalität, nicht bei Qualität
  • Agilität durch Selbstorganisation des Teams und Kommunikation
  • Rollen im Scrum-Projekt: „Product Owner“, „Scrum Master“ und „Team“
  • Erfolgsfaktoren Sprints (=strikte Priorisierungen) und präzise Aufwandsschätzungen: Entwicklungsprozess, der auf kurzen, festen Zeitintervallen basiert, aktive Einbindung des Kunden in die Entwicklung, keine unfertigen Funktionen, kurze Reaktionszeiten bei Anforderungsänderungen, frühzeitige Problemerkennung und permanente Qualitätskontrolle
  • Weiterführende Fachartikel zum Thema

Kanban

  • Lean-Management-Methode
  • Kernprinzip: Menge an paralleler Arbeit (Work in Progress) beschränken (Work-in-Progress-Limits) und so die Durchlaufzeiten von einzelnen, wertschöpfenden Anforderungen zu verkürzen
  • "Taskboard" nach Kanban: Projekte und deren Status visualisieren
  • Ziele:
    • Übersicht über die aktuelle Projektlandschaft bekommen
    • Engpässe erkennen
    • Prioritäten steuern
    • Projekt- Durchlaufzeiten verkürzen
    • Nicht alles "auf einmal" machen: "Stop starting, start finishing"
    • Mittel- bis langfristigen Kapazitätsplanung ermöglichen

Agile Werte und Prinzipien

Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.

  • Zwar sind wohldefinierte Entwicklungsprozesse und Entwicklungswerkzeuge wichtig, wesentlicher sind jedoch die Qualifikation der Mitarbeitenden und eine effiziente Kommunikation zwischen ihnen.
  • Zusammenarbeit steht im Vordergrund - Prozesse und Werkzeuge dürfen angepasst werden, wenn sich die Zusammenarbeit dadurch verbessert.
  • Nicht das "Wie" steht im Vordergrund, sondern das "Was machen / erreichen wir?".

Funktionierende Programme sind wichtiger als ausführliche Dokumentation.

  • Gut geschriebene und ausführliche Dokumentationen können zwar hilfreich sein, das eigentliche Ziel der Entwicklung ist jedoch die fertige Software.
  • D.h. NICHT: "Es gibt keine Dokumentation" (oft gehörtes Missverständnis!)

Die stetige Abstimmung mit dem Kunden ist wichtiger als die ursprüngliche Leistungsbeschreibung in Verträgen.

  • Statt sich an ursprünglich formulierten und mittlerweile veralteten Leistungsbeschreibungen in Verträgen festzuhalten, steht vielmehr die fortwährende konstruktive und vertrauensvolle Abstimmung mit dem Kunden im Mittelpunkt.
  • Wir wissen: Es ändert sich stets einiges im Ablauf eines Projekts. Wenn man eng mit dem Kunden zusammenarbeitet, lassen sich für beide Seiten akzeptable Lösungen finden.

Der Mut und die Offenheit für Änderungen stehen über dem Befolgen eines festgelegten Plans.

  • Im Verlauf eines Entwicklungsprojektes ändern sich viele Anforderungen und Randbedingungen ebenso wie das Verständnis des Problemfeldes. Das Team muss darauf schnell reagieren können.
  • "Wer A sagt muss gar nichts".
  • Vermeintliche Planungssicherheit bewusst aufgeben, um offen auf Änderungen, die sicher kommen werden, reagieren zu können.

Prinzipien und Methoden

  • Vorhandene Ressourcen mehrfach verwenden ("Jeder macht 'alles'")
  • Teams und Mitarbeiter organisieren sich selbst und werden dazu auch in die Lage versetzt
  • Pull statt Push
  • Alle Teammitglieder übernehmen Verantwortung für das Endergebnis der Arbeit
  • Umsetzung:
    • einfach (KISS-Prinzip)
    • zweckmäßig, kundennah
    • Programmierung: Gemeinsamer Code-Besitz (Collective Code Ownership), Testdriven Development, Pair programming, Refactoring

Vorteile agiler Vorgehensweisen in Projekten

  • Striktes Vorgehen nach Ihren Prioritäten
  • Regelmäßig ein funktionsfähigen Zwischenstand
  • QS: Qualität ist nicht verhandelbar
  • Mehr Flexibilität
  • Nachhaltigkeit: Vermeidung hoher Weiterentwicklungs- und Wartungskosten
  • siehe auch unseren Blog-Artikel Welche Vorteile bringt mir als Kunde ein Scrum-Projekt?