Kanban zur Abwicklung von Reporting-Anforderungen

2.051 Aufrufe

Veröffentlicht am

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.

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Kanban zur Abwicklung von Reporting-Anforderungen

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

×