Vortrag 2:
Funktionieren agile und dynamische Entwicklungsprozesse nur in dynamischen und agilen Unternehmen?
Entwicklungsprozess funktionieren, wenn die Ziele erreicht werden, das berühmte Dreieck Qualität, Kosten und Termin wird präsentiert.
Der Prozess bei Gebit ist iterativ, inkrementell, mehrfach paralleler Entwicklungsprozess, also Modell-Driven
Interpreter Framework, kein Generatorenframework, also interpretieren des Modells zur Laufzeit.
Gebit setzt agile Methoden wie
Parrprogrammierung, Testgetriebene Entwicklung und Refactoring
Auch hier fällt das Stichwort Continous Integration wieder.
Erstes Fallbeispiel: Projekt Entwicklung Kassensystem, Ablösung von Standardsoftware mit zahlreichen Schnittstellen zu Backend Systemen.
Bei GEBIT lag auch die Testverantwortung.
Die Beauftragung erfolgte immer in Monatssteps->Gefiel das Ergebnis bis dann->Nächster Step.
Die Entwicklung erfolgte alleine durch GEBIT.
Insgesamt 15 Monate bis zu ersten produktiven Implementierung.
Schlüssel zum Erfolg:
-Paarweise Spezifikation
-Volle Konzentration von Auftraggeber und Nehmer auf das Projekt
-Eskalierte Themen wurden ernst genommen
-Betroffene zu Beteiligten machen.
Zweites Fallbeispiel: Sachbearbeiteranwendung in einer Behörde.
Ablösung von 2 Altverfahren, 12,3kg Specs von mehr als 50 Autoren (Projekt lief bereits lange)
Testautomatisierung in hohem Mß durch MA des Kunden
Problem bei diesem Projekt, keine wirklichen ITler in der IT Abteilung der Behörde
Keine Projektleitung beim Kunden, da Mitarbeiter maximal 20-30% der Zeit für Projektleitung
Projekt für Einführung und Betrieb fehlte aber völlig.
Keiner der beteiligten Mitarbeiter war Vollzeit im Projekt, maximale Zuordnung war 50% im Projekt.
D.h. Oft laufen IT Projekte in IT fernen Unternehmen, ohne das Bewußtsein für die Bedürfnisse eines IT-Projektes.
Herausforderungen: Agile Methoden waren gesetzt
Es wurde sich am V-Modell orientiert
Umfangreiche Mitwirkungsleistungen des Auftraggebers wegen Budget
Hoher Headcount auf Kundenseite
aber Teilzeitkräfte, Tagesgeschäft, Altverfahren
Projektteams ohne Projekterfahrung. Das ist oft ein grosse Problem. Order by Mufti funktioniert hier nicht.
Die IT Affinität fehlte bei 90% des Projektteams, auch keine Seltenheit, leider oft sogar eine gewisse versteckte Aversion.
Es gab oft Spannungen zwischen den Linientätigkeiten und dem Projekt, oder wie ich immer sage, ENTWEDER Projekt ODER Linie, beides GEHT NICHT!
(Sorry, hier muss ich schreien)
Es wurde nur verwaltet, nicht proaktiv gesteuert. Auch dies kein seltenes Phänomen, meist wird mehr Wert auf Excel Schlachten und Statusberichte gelegt, als auf die aktive in Angriff Nahme der Entwicklungsherausforderungen. Der Entwickler ist meist das kleinste Rädchen, das das ganze einfache Programmierzeugs macht. Hierarchische Strukturen fressen gerade in grossen IT Projekten oft wichtige PT und Ressourcen.
Hier wurde die Agilität „ausgelagert“ zu den GEBIT Entwicklern.
Das Kernteam war mit dem Projektverlauf sehr zufrieden, aber die Mitwirkungsleistungen waren nicht in time. Es gibt immer noch Aufgaben, obwohl das Projekt zu Ende ist.
Kein Vorgehensmodell kann einen Erfolg erzwingen. Auch das Umfeld muss stimmen. Und da krankt es meist. IT Projekte ohne Mitarbeiter mit „Lust an der IT“ werden grausam!
Lessons learned:
Veränderung der Kommunikationskultur schwierig
Prozesse in Behörde dauern länger als lange.
Steuerung des Projektes notwendig
Spezifikationsänderungen nachvollziehbar dokumentieren
Stimmige Chemie kompensiert vieles
Betroffene zu Beteiligten machen
Spannungsfeld Fakten und Zahlen < -> Zweckoptimismus