Upload
roskakori
View
1.312
Download
3
Embed Size (px)
DESCRIPTION
Aufträge zu Auswertungen im Bankwesen stelle durch ihre eine hohe Anzahl möglicher Auftraggeber, eine breite Streuung in der Komplexität und Umsetzungszeit sowie das weit gestreute Technologie-Set eine Herausforderung dar. Kanban ist eine schlanke und flexible Abwicklung, die unterstützt, solche Aufträge produktiv und prompt zu erledigen, so dass sowohl der Kunde als auch der Bearbeiter zufrieden sind. Eine Präsentation erfolgte auf der 9. Anwenderkonferenz für Software Qualität und Test (ASQT) 2011.
Citation preview
Kanban zur Abwicklung von Reporting-Anforderungen und
Datenänderungen
Thomas Aglassinger
Version 1.2
Folie 2 Stand September 2011Version 1.2
Agenda
• Ausgangssituation
• Überblick Kanban
• Umsetzung: theoretisch und praktisch
• Kennzahlen
• Fragen und Antworten
Folie 3 Stand September 2011Version 1.2
Ausgangssituation
• Reportinglandschaft der Raiffeisen Bankengruppe Steiermark
• Rolle der Abt. Solution Development (SDC)
• Auftraggeber
• Herausforderungen
Folie 4 Stand September 2011Version 1.2
Reporting für RBG Steiermark
Steiermark-spezifische
Auswertungen
Ad hocAuswertungenund generelle
Datenänderungen
Abt. Solution DevelopmentRRZ Süd
SektorweiteAuswertungen
AndereHersteller
Folie 5 Stand September 2011Version 1.2
Wer sind die Auftraggeber?
Ca. 20 Fachbereiche
Ca. 90 Banken
Steiermark-spezifische
Auswertungen
Ad hocAuswertungenund generelle
Datenänderungen
Abt. Solution DevelopmentRRZ Süd
Auftrag
Folie 6 Stand September 2011Version 1.2
Herausforderungen
• Mehr als 100 verschiedene Auftraggeber
• Breite Streuung bei Umsetzungszeit
• Breiter technologischer Werkzeugkasten
Folie 7 Stand September 2011Version 1.2
Sich daraus ergebende Fragen
• Wie wird ein Auftrag priorisiert?
• Wie gehen wir mit den unterschiedlichen Durchlaufzeiten um?
• Wie erkennen wir frühzeitig Handlungsbedarf und Verbesserungspotential?
• Wie berücksichtigen wir, dass die Mitarbeiter die einzelnen Werkzeuge in unterschiedlicher Tiefe beherrschen?
• Wie können wir unsere Leistung darstellen?
Folie 8 Stand September 2011Version 1.2
Kanban
• jap. 看板 , dt. „Karte“, „Tafel“, „Beleg“
• Ursprünglich bei Autoherstellung• Minimierung der Lagerbestands
• Gezieltes Herstellen von Zwischenprodukte
• In Folge auch in anderenProduktionsbetrieben
• Seit einigen Jahren auch fürSoftware-Entwicklung
Folie 9 Stand September 2011Version 1.2
Kernprinzipien von Kanban
• Konsequente Darstellung der aktuellen Aufträge
• Geringhalten der gleichzeitig bearbeiteten Aufträge (Limit für „work in progress“)
• Abgestimmte Priorisierung gemeinsam mit den Auftraggebern (Warteschlange)
• Pull-Prinzip: Mitarbeiter holt sichAuftrag selbst aus Warteschlange
• Buffet-Ansatz: jene Maßnahmenumsetzen, die Nutzen bringen
• Eigentliche Bearbeitung des Auftragsbleibt gleich
Folie 10 Stand September 2011Version 1.2
Darstellung der aktuellen Aufträge
• Über Tafel („White board“)
• Analog und/oder digital
• Basis für tägliche Kurzabstimmung
Folie 11 Stand September 2011Version 1.2
White board
• Enthält alle derzeit bearbeiteten Aufträge
• Auftrag durchläuft Stati bis zur Erledigung.
• Bei Bedarf: verschiedene Schwimmbahnen („swim lanes“).
ErledigteAufträge
Auftrags-bestand
Priorisierung Erledigung
Folie 12 Stand September 2011Version 1.2
White board - Gestaltung
• Auftragsstati und Schwimmbahnen frei wählbar
• Vom Team entwickeln lassen
• Darf sich im Laufe der Zeit wandeln
• Viele verschiedene Varianten im Einsatz
Folie 13 Stand September 2011Version 1.2
White board - analog
• Ein Post-It für jeden Auftrag
• Kurzbeschreibung, Startdatum, Enddatum
• Verschiedene Farben für Klassifizierung
Folie 14 Stand September 2011Version 1.2
White board - digital
1. Vollständige Kanban-Anwendungen
2. Auf Basis von Ticket-Trackern• Kanban über Plugins oder Customing• Kennzahlen über Plugins oder Scripting
Zahlreiche Systeme am Markt
Folie 15 Stand September 2011Version 1.2
White board – analog oder digital?
• Analog• Benötigt keine technische Infrastruktur
• Ständig sichtbar
• „Zum Angreifen“
• Digital• Unabhängig vom Aufenthaltsort
• Kennzahlen automatisiert ermittelbar
• Auftragsdetails ablegbar
• Empfehlung Literatur: beides gleichzeitig oder nur analog
Folie 16 Stand September 2011Version 1.2
White board - konkret
• Entscheidung: nur digital
• Infrastruktur weitgehend vorhanden
• Mitarbeiter in mehreren Räume
• Synchronisieren mit Analog-Kopie entfällt
• geringe Teamgrößen ein Bildschirm ok
Folie 17 Stand September 2011Version 1.2
White board - konkret
• Schwimmbahnen für Software (SW) und Organisatorisches (ORG)
• Über Trac und dynamische Wiki-Dokumente
Spalte entspricht Auftragsstatus
Eindeutige Auftragsnummer
Kurzbeschreibung
Folie 18 Stand September 2011Version 1.2
White board - Zusammenfassung
• Kompakte Darstellung aller aktuell bearbeiteten Aufträge
• Analog und/oder digital
• Auftragsstatus und ev. Schwimmbahnen
• Gestaltung nach eigenem Bedarf
Folie 19 Stand September 2011Version 1.2
Tägliche Kurzabstimmung
• Vor dem White board
• Jeder Mitarbeiter stellt kurz dar:
• Welche Aufträge habe ich gestern bearbeitet?
• Welche Aufträge werde ich heute bearbeiten?
• Gegebenenfalls: Wo gibt es Blockaden und wer unternimmt etwas dagegen?
• Kurz und kompakt (Richtwert: 5 Minuten)
• Gegebenenfalls Nachbesprechung
Folie 20 Stand September 2011Version 1.2
Tägliche Kurzabstimmung - konkret
• Vor Mittagspause
• Dauer i.d.R. 5 bis 10 Minuten
• Kurze inhaltliche Diskussionen erlaubt
• Kaum Nachbesprechungen
Folie 21 Stand September 2011Version 1.2
Konkreter Nutzen für uns
• Im Team immer alle aktuell informiert
• Vereinfachung für Vertretung bei Urlaub oder Krankenstand
• Einheitliche Ablage der Auftragsinformation
• Kaum Aufwände für Statusberichte
Folie 22 Stand September 2011Version 1.2
WIP-Limit
• WIP = „work in progress“
• Grenze für die Anzahl der Aufträge im White board
• Weniger Themensprünge
• Mitarbeiter bleiben eher im Flow
• Bessere Nutzung des Kurzzeitgedächtnisses
Folie 23 Stand September 2011Version 1.2
WIP-Limit - konkret
• WIP-Limit ist im White board eingetragen
• Auftragsbestand und erledigte Aufträge zählen nicht zu WIP
• Je Bedarf: Gesamt-Limit, Limit pro Status, Limit pro Schwimmbahn, Limit pro Mitarbeiter, …
Software-Aufträge in Bearbeitung: 8
WIP-Limit für Software-Aufträge: 10
Folie 24 Stand September 2011Version 1.2
Was ist ein sinnvolles WIP-Limit?
• Anfangswert finden:
1. Normal arbeiten und beobachten
2. Startwert wählen, ändern wenn notwendig
• So lange reduzieren, bis sich die Durchlaufzeit von Aufträgen nicht mehr ändert
• WIP-Limit darf sich ändern – mit gutem Grund (z.B. neuer Mitarbeiter)
Folie 25 Stand September 2011Version 1.2
Umgang mit WIP-Limit
• Oft: in der Anfangsphase „zu hoch“
• Im Zweifel: zwischenzeitlich erhöhen
• Immer etwas aktiv bearbeiten
• Wenn absehbar, dass Auftrag längerfristig blockiert ist: abbrechen und später wieder in die Warteschlange stellen
• Eventuell mit Auftraggeber umpriorisieren
Folie 26 Stand September 2011Version 1.2
Priorisierung der Aufträge
• Welcher Aufträge kommen in Warteschlange?
• Gemeinsam mit dem Auftraggeber
• Literatur:• Periodisches Treffen aller Auftraggeber (z.B.
monatlich)
• Auftraggeber verteilen WIP-Anteile untereinander
• Moderation durch Auftragnehmer
Folie 27 Stand September 2011Version 1.2
Priorisierung - konkret
• Herausforderung:• mehr als 100 Auftraggeber
• Kanban-Maßnahme mit Außenwirksamkeit
• Aktuelle Lösung:• Auftraggeber mit vielen Aufträgen erhalten Anfrage: „Welche
fünf eurer Aufträge sollen wir als nächstes in Arbeit nehmen?“
• Auftraggeber mit sporadischen Aufträgen: priorisieren wir selbst
• Bei Engpässen: spontane Priorisierung mit betroffenen Auftraggebern oder extern Beteiligten (Projekt-Abteilung, Geschäftsleitung, …)
Folie 28 Stand September 2011Version 1.2
Konkreter Nutzen für uns
• Erkennen von Engpässen
• Sachliches Darstellen von Engpässen
• Kaum konkrete Zieltermine für Aufträge
• Kaum Terminverschiebungen
Folie 29 Stand September 2011Version 1.2
Pull-Prinzip
• Mitarbeiter holt selbstständig nächsten Auftrag aus der Warteschlange
• Höhere Selbstständigkeit
• Keine konkrete Anweisung vom Vorgesetzten
Folie 30 Stand September 2011Version 1.2
Pull-Prinzip - konkret
• Nicht in Verwendung
• Kein erkennbarer Vorteil
• Nicht jeder Auftrag für jeden bearbeitbar
• Stattdessen: Team ermittelt Bearbeiter
Folie 31 Stand September 2011Version 1.2
Kennzahlen
• Zum Erkennen von Verbesserungspotential
• Zur Darstellung des Erfolges von gesetzten Maßnahmen für Verbesserungen
• Zur Darstellung der eigenen Leistung
• Einfache Messung über White board
Folie 32 Stand September 2011Version 1.2
Verteilung der Durchlaufzeit
• Durchlaufzeit = von Auftragserteilung bis Einsatz
• Ergibt zusicherbare Durchlaufzeit
• Zum Erkennen von „Ausreißern“ Spektralanalyse
Folie 33 Stand September 2011Version 1.2
Verlauf des Work in progress (WIP)
• Ziel: Höhen sind stabil
Verbesserung bei Einsatzplanung
Ferialpraktikant mehr Kapazität
Urlaube bei Auftraggeber weniger
Testabnahmen
Folie 34 Stand September 2011Version 1.2
Zusammenfassung
• Kanban: für Abwicklung von Aufträgen
• Effizienz durch verschiedene Maßnahmen:• Aktueller Stand (White board, Kurzabstimmung)
• Priorisierung mit Auftraggeber
• Limit für gleichzeitig bearbeitete Aufträge (WIP)
• Einführung nach Buffet-Ansatz
• Kennzahlen für Verbesserung
• Erfolgreich verwendet bei SDC/RRZ Süd
Folie 35 Stand September 2011Version 1.2
Referenzen
• Anderson, D.: Kanban – Successful evolutionary change for your technology business (2010, Blue Hole Press)
• Leopold, K.: Software Kanban im Einsatzhttp://heise.de/-1235465
• Hiranabe, K.: Visualizing agile projects using Kanban boardshttp://www.infoq.com/articles/agile-kanban-boards
• Patton, J.: Kanban oversimplifiedhttp://www.agileproductdesign.com/blog/2009/kanban_over_simplified.html
• Ladas, C.: Scrum-banhttp://leansoftwareengineering.com/ksse/scrum-ban/
• Trachttp://trac.edgewall.org/
Folie 36 Stand September 2011Version 1.2
Fragen und Antworten