Aufrufe
vor 3 Jahren

01 | 2015 public

  • Text
  • Framework
  • Verwaltung
  • Frameworks
  • Einsatz
  • Unternehmen
  • Zivit
  • Anforderungen
  • Kanban
  • Entwicklung
  • Informationssicherheit
  • Erfolgsfaktoren
Erfolgsfaktoren für IT-Sicherheit

Spezifikation

Spezifikation Entwicklung Oberfläche Umsetzung Abbildung 2: Visualisierung des komplexen Oberflächen-Entwicklungsprozesses für das Projekt STEP Umsetzung der Kernpraktik im Projekt STEP Mit dem in Abbildung 2 gezeigten Kanban-Board arbeiten zwei eigenständige Teams innerhalb des Teilprojekts Oberfläche: ein Team zur Spezifikation der Oberfläche und ein anderes zur Umsetzung. Für beide Teams visualisiert das Kanban-Board die Arbeitsschritte: der linke Teil die Spezifikation, der rechte Teil die Umsetzung. Für beide Teams gibt es jeweils eine Eingangsspalte, die Platz für die fünf wichtigsten Arbeitspakete bietet, die als Nächstes bearbeitet werden müssen. In einem wöchentlichen Priorisierungsmeeting werden die Eingangsspalten je nach aktueller Priorität der Arbeitspakete gefüllt. Die roten Spalten markieren die Grenzen des Kanban-Boards – die Tickets innerhalb dieser Arbeitsschritte werden von anderen Teams beziehungsweise externen Stakeholdern bearbeitet. Das Teilprojekt Oberfläche hat darauf keinen direkten Einfluss. Eine Ansammlung vieler Arbeitspakete in einem solchen Arbeitsschritt ist sofort ersichtlich und kann auf diese Weise frühzeitig an das Management eskaliert werden. Umsetzung der Kernpraktik „Mache Richtlinien explizit sichtbar“ Arbeitsschritt zusammengefasst und über der entsprechenden Spalte des Kanban-Boards festgehalten. Dies wird als „Definition of Done“ (DoD) bezeichnet. Es ist üblich, dass die DoD für jeden Arbeitsschritt jeweils auf eine eigene Karte oder Haftnotiz geschrieben werden, um sie im Zuge der Weiterentwicklung des Kanban-Systems problemlos anpassen zu können. Umsetzung der Kernpraktik im Projekt STEP Abbildung 3 zeigt ein konkretes Beispiel für eine auf dem Kanban-Board über dem Arbeitsschritt „ADF-GUI erstellen“ angebrachte Definition of Done des Teilprojekts Oberfläche in STEP. Interessant ist besonders das frühzeitige Einbeziehen des anderen Teilteams „Test“, um späteren Komplikationen bei Abnahmetests vorzubeugen. Umsetzung Nach der reinen Visualisierung des Arbeitsprozesses werden alle Mechaniken und Regeln ermittelt und visualisiert, die momentan auf die Arbeitsweise im Team einwirken. Diese so geschaffene Transparenz ermöglicht dann die Selbstorganisation der Mitarbeiter und das Pull-Prinzip: Teammitglieder wählen sich ihr nächstes Arbeitspaket unter Berücksichtigung der Priorisierung und der Richtlinien auf dem Kanban-Board selbstständig und ziehen somit die Arbeit durch das Kanban-System. Wie im ersten Teil der Artikelserie beschrieben, wird hierfür gemeinsam festgelegt, wann jeder der Arbeitsschritte wirklich abgeschlossen ist. Diese Richtlinien werden nun für jeden Definition of Done „ADF-GUI erstellen“ • Dialogoberfläche mit ADF-Faces umgesetzt • Anbindung der Daten und der Aktionen an den Dialogkern / die Service-Schnittstelle • Validierungen, Warnungs- und Fehlermeldungen implementiert • Fachliche Bezeichner sind den UI-Elementen zugeordnet • Mockup-Version ist an Test übergeben worden (Deployment, Nachricht an Testumgebungsverantwortlichen) Abbildung 3: Beispiel für eine „Definition of Done“ 20 | .public 01-15 | Management

„Kanban ist für uns die optimale Ergänzung zum V-Modell XT. Es macht unser Vorgehen konkret und für jeden nachvollziehbar. Der aktuelle Projektstand ist jederzeit ablesbar, die Fortschritte sind exakt dokumentiert und der Fokus ist klar. Das steigert die Qualität der Arbeit.“ Fabian Wührl (Bundesagentur für Arbeit), Leiter des Teilprojekts Oberfläche in STEP Neben den DoD muss auch der Umgang mit verschiedenen Aufgabentypen von Arbeitspaketen geklärt werden, die durch das Kanban-System „fließen“. In einem IT-Projekt können beispielsweise Aufgabentypen wie „fachliche Entwicklung“ oder „Wartung“ vorkommen. Wenn der Aufgabentyp Auswirkungen auf den Arbeitsablauf hat, ist es üblich, die Aufgabentypen auch visuell zu unterscheiden. Dafür gibt es drei bewährte Ansätze: Wartung • Farbliche Unterscheidung: Die Haftnotizen, die Arbeitspakete repräsentieren, besitzen je Aufgabentyp eine festgelegte Farbe. • Swimlane pro Aufgabentyp: Die Arbeitspakete werden nach ihrem Aufgabentyp in separaten Swimlanes auf dem Kanban-Board dargestellt. • Eigenes Kanban-Board pro Aufgabentyp: Pro Aufgabentyp gibt es ein eigenes Kanban-Board. Dieser Ansatz ist dann sinnvoll, wenn sich herausstellt, dass sich auch die Arbeitsschritte der jeweiligen Aufgabentypen wesentlich unterscheiden. Abbildung 4: erweitertes Kanban-Board mit „ Wartung“ (Ausschnitt) Umsetzung der Kernpraktik „Limitiere die Anzahl der gleichzeitig bearbeiteten Arbeitspakete“ Aufgabentypen sind auch die Basis für die fortgeschrittene Kanban-Technik „Service-Klassen“, die wir im Detail in der kommenden Ausgabe von .public behandeln werden. Umsetzung der Kernpraktik im Projekt STEP Eine Visualisierung ohne Work-in-Progress(WiP)-Limits ist kein Kanban-System. Ohne Paradigmenwechsel – von der Mitarbeiterauslastung als Maxime hin zu Arbeitsreduzierung und Fokus auf die Systemverbesserung – kann Kanban nicht mit all seinen Stärken genutzt werden. Im Teilprojekt Oberfläche wurde beispielsweise neben dem ersten Aufgabentyp „fachliche Entwicklung“ bald der neue Aufgabentyp „Wartung“ eingeführt. Beide Aufgabentypen besitzen stark unterschiedliche Arbeitsabläufe. Abbildung 4 zeigt, dass neben dem existierenden Arbeitsprozess ein neuer Arbeitsprozess für die Wartung eingeführt wurde. In Kanban werden die WiP-Limits praktisch am Kanban-Board umgesetzt: Es wird über jeden visualisierten Arbeitsschritt eine konkrete Zahl geschrieben, die das WiP-Limit – die maximale Anzahl der dort gleichzeitig existierenden Arbeitspakete – festlegt. Ist das WiP-Limit erreicht, ist der Arbeitsschritt blockiert, neue Arbeitspakete können nicht mehr angenommen werden. Management | .public 01-15 | 21

msg

01 | 2018 public
02 | 2017 public
01 | 2017 public
02 | 2016 public
01 | 2016 public
02 | 2015 public
01 | 2015 public
01 | 2014 public
01 | 2014 msg systems study
01 | 2015 msg systems Studienband
Future Utility 2030
Lünendonk® Trendstudie
Digitale Transformation | DE
Digital Transformation | EN
DE | inscom 2014 Report
EN | inscom 2014 Report

msgGillardon

02 | 2018 NEWS
03 | 2016 NEWS
02 | 2016 NEWS
01 | 2016 NEWS
03 | 2015 NEWS
02 | 2015 NEWS
01 | 2015 NEWS
02 | 2014 NEWS
01 | 2014 NEWS
02 | 2013 NEWS
01 | 2012 NEWS
02 | 2011 NEWS
01 | 2010 NEWS
MaRisk
01 | 2017 banking insight
01 | 2015 banking insight
01 | 2014 banking insight
01 | 2013 banking insight
01 | 2012 banking insight
02 | 2011 banking insight
01 | 2011 banking insight
01 | 2010 banking insight
2018 | Seminarkatalog | Finanzen

Über msg



msg ist eine unabhängige, international agierende Unternehmensgruppe mit weltweit mehr als 6.000 Mitarbeitern. Sie bietet ein ganzheitliches Leistungsspektrum aus einfallsreicher strategischer Beratung und intelligenten, nachhaltig wertschöpfenden IT-Lösungen für die Branchen Automotive, Banking, Food, Insurance, Life Science & Healthcare, Public Sector, Telecommunications, Travel & Logistics sowie Utilities und hat in über 35 Jahren einen ausgezeichneten Ruf als Branchenspezialist erworben.

Die Bandbreite unterschiedlicher Branchen- und Themenschwerpunkte decken im Unternehmensverbund eigenständige Gesellschaften ab: Dabei bildet die msg systems ag den zentralen Kern der Unternehmensgruppe und arbeitet mit den Gesellschaften fachlich und organisatorisch eng zusammen. So werden die Kompetenzen, Erfahrungen und das Know-how aller Mitglieder zu einem ganzheitlichen Lösungsportfolio mit messbarem Mehrwert für die Kunden gebündelt. msg nimmt im Ranking der IT-Beratungs- und Systemintegrationsunternehmen in Deutschland Platz 7 ein.


© 2018 by msg systems ag - powered by yumpu Datenschutz | Impressum