Skip to content

Episode 7: Requirements für die Vorstudie ::: Softwareprojekte

An einem verregneten Morgen kam Giuseppe mit einem Fremden zur Türe herein. Hans, Karl und Orlando waren sofort ziemlich nervös. Nie kam Giuseppe persönlich zu ihnen in die Häckerecke. „Ich möchte euch über unsere neuesten Familienaktivitäten unterrichten“, begann Giuseppe. „Wir haben mit einer Familie in einer anderen Stadt funssioniert. Unsere Geschäftsfelder passen optimal zusammen. Die neue Familie hat sich auf die Verteilung von bewusstseinserweiternden Mitteln spezialisiert. Wir sind gut im Geld waschen und zusammen können wir sehr viel Profit für die Familien erwirtschaften. Die andere Familie hat ebenfalls ein Verwaltungssystem und wir müssen unsere Systeme miteinander verschmelzen.“

Orlando war begeistert

„Das ist ja toll! Da können wir sicher voneinander profitieren und neue Integrationsmethoden lernen.“ Hans und Karl standen etwas abseits und ihre Gesichtsfarbe glich der Wand. Sie waren schneeweiß. Hans stotterte: „Das bedeutet nicht nur neue Funktionalität sondern eine Erweiterung der Basisfunktionalität. Wir haben kein System erstellt das mandantenfähig oder auf Austausch mit anderen Systemen ausgelegt ist.“ Giuseppe grinste: „Bevor wir weiter reden möchte ich euch Thomas vorstellen. Thomas ist ein Softwarearchitekt und Projektleiter der im Bereich der Fusionierung von Firmen schon mehrmals wahre Wunder vollbracht hat. Wir haben ihn eingestellt um die beiden Firmen sicher miteinander verbinden zu können. Weiterhin haben wir diverse Expansionspläne erarbeitet. Dem Familienrat ist klar, dass unsere heutigen Verwaltungssysteme uns nicht weiter optimal unterstützen können. Das bedeutet wir werden investieren und ihr braucht euch vorerst keine Sorgen um Betonschuhe und Tauchgänge machen.“ Giuseppe verabschiedete sich und Thomas ließ sich von den Dreien in die bestehende Umgebung einführen.

Eintrag in das Projekttagebuch von Thomas

Wie immer endete der erste Tag mit „das schaff ich nie“ Gedanken. Davon lass ich mich natürlich nicht abschrecken. Die drei Kollegen sind ziemlich eingeschüchtert und haben Angst. Ich bin neu in der Firma und werde das Problem hoffentlich bald erkennen. Was Giuseppe mit den Betonschuhen und Tauchgängen gemeint hat, verstehe ich noch nicht. Folgende Punkte habe ich bereits erkannt:
  • Giuseppe scheint ein ziemlich unstrukturierter Auftraggeber zu sein. Seine Ziele sind unklar und müssen genauer analysiert werden.
  • Die Firma befindet sich in einer Fusionierungsphase und das bedeutet einen enormen Change, sowohl bei der Infrastruktur wie auch bei den Mitarbeitern.
  • Die Fähigkeiten der drei Entwickler schätze ich als ausreichend ein. Sie sind Bastler und müssen zuerst an eine vernünftige Vorgehensweise gewöhnt werden.
  • Das Verwaltungssystem ist monolitisch aufgebaut.
  • Es besteht aus Eigenentwicklung ohne offenen Standards
  • Die Strategie und die Pläne der Firma sind nicht klar beschrieben. Hier muss eine umfassende Anforderungsanalyse durchgeführt werden.
  • Projektmanagement-Prozesse und -Vorlagen sind nicht vorhanden

Was hat Thomas an seinem ersten Tag gemacht?

Er hat begonnen sich ein allgemeines Bild der Lage zu machen. Er hat die vorhandenen Rahmenbedingungen abgesteckt. Am ersten Tag ist es unmöglich schon alles zu überblicken. Er muss sich an das Thema herantasten. Mit seiner Aufzählung hat er weiterhin begonnen eine Schwachstellenanalyse durchzuführen. Die Eckpunkte werden ihm helfen die Vorstudie erstellen zu können. Das bedeutet, dass man eine Vorstudie erst erstellen kann, wenn man hierfür schon diverse Anforderungen zusammengestellt hat. Diese Aussage klingt logisch, doch einige Kollegen erstellen Vorstudien ohne das tatsächliche Problem zu beschreiben. Vor allem bei Projekten die ähnlich aussehen wie bereits erstellte, verfällt der Projektleiter gerne in den Modus „Hey das kenne ich, das mach ich gleich nochmal!“ Ich kann davon nur abraten. Ein paar Stunden, oder gar Tage, Anforderungen zusammen tragen, spart im Projektverlauf das vielfache an Ärger und Kosten. Einen Nachteil hat diese Vorgehensweise: Niemand bekommt hinterher mit, dass sinnvolle Vorarbeit geleistet wurde. Das kann manchmal ziemlich frustrierend sein. Aber so ist das Projektleben. Wenn es gut läuft wird niemand etwas vom Projekt mitbekommen. Dann ist es einfach fertig gestellt worden.

Episode 6: Grenzen des Refactorings ::: Softwareprojekte

Zu Episode 1 wurde ein Kommentar geschrieben der mir zeigte das auch noch andere Mitstreiter das Problem des Refactorings aktiv angehen. Die Aussage „Andererseits weiß ich, dass wenn ich die Firma verlasse, dann werden die Projekte andere nach mir übernehmen und wieder alles reverseengeneeren müssen. ...wenn ich das Unternehmen verlasse, muss von vorne begonnen werden“ fand ich sehr passend. Mit Refactoring kann man nicht die Welt retten. Ein Softwaresystem ist für mich wie ein lebender Organismus. Unsere Haut wird beispielsweise alle sieben Jahre erneuert. Bei Software verhält sich das im Prinzip genauso.

Orlando war mal wieder auf einer Schulung

Ok, da war er schon in Episode 3 und das hat auch seinen Grund. Orlando ist Single und liebt es in Hotelzimmern herumzuhängen. Da das Familienunternehmen zur Zeit noch nicht in mehreren Ländern vertreten ist, ist es für ihn die einzige Möglichkeit das Jet-Set-Gefühl zu erleben. Bei der Schulung wurde der Model Driven Architecture-Ansatz besprochen. Wieder kam er freudestrahlend zurück und wollte das Erlernte sofort ausprobieren. Das ist auch eine typische Orlando Eigenschaft. Er nimmt gerne Neues an und versucht so viel wie möglich gleich zu implementieren. Da es sich bei dem, von Hans, Karl und Orlando, betreuten System um ein hochriskantes, produktives System handelt, ist diese Freude an Neuem für Hans und Karl nicht unbedingt nachvollziehbar. Zuweilen sind Orlandos Kollegen sonderbar altmodisch und wollen vor allem ein überlebensfähiges, stabiles System haben. Vielleicht liegt das an den Betonschuhen die am Ausgang von den schweren Jungs abgestellt wurden... Wie dem auch sei. Hin- und wieder werden Hans und Karl von Orlando überredet etwas Neues zu implementieren. Die Drei wollten erreichen, dass die Entwicklung auf Dauer gesehen immer stabiler und sicherer wird. Deshalb schauten sie sich ihr System genauer an und überlegten ob Model Driven Architecture eventuell eingeführt werden kann.

Keine Architektur?

Karl schaute sich die bisherigen Architekturkonzepte an. „Also im Moment sind wir mit einem Mischmasch zwischen prozeduraler Programmierung und objektorientierter Programmierung konfrontiert. Wenn wir das ändern wollen, müssen wir das ganze System am Besten wegwerfen und neu bauen.“ Die drei waren sich hier sehr einig. Ein Neubau würde jedoch einem langanhaltenden Tauchgang im Familienteich nahe kommen. „Vielleicht können wir uns wenigstens eine Architektur überlegen wie es aussehen sollte und das als unsere Strategie definieren. Dann könnten wir beim Review darauf achten in die Richtung der Strategie zu arbeiten“, bemerkte der geschulte Orlando. Hans nickte zustimmend. „Das klingt schon eher machbar. Wir werden also mit dem Refactoring keine endgültige Lösung finden. Wir werden die, zur Zeit erkannten Fehler und Missstände, aufdecken und korrigieren können. Das System wird also nie fertig werden.“ Orlando überlegte: „Ich glaube, dass ist eine normale Eigenschaft in komplexen Systemen. Jede neue Idee führt zu einer Änderung und diese Änderung erfordert neue Vorgehensweisen. Ich glaube das Geheimrezept liegt im Changemanagement und in der Umsetzung der Strategievorgaben. Lasst uns zuerst einmal eine Strategie für die nächsten drei- bis fünf Jahre definieren. Wir sollten dringend mit Giuseppe reden um zu erfahren was er alles vor hat. Dann können wir unsere IT-Bemühungen entsprechend auslegen.“ Vielleicht habt ihr euch schon hin- und wieder gefragt warum Firmen viel Geld für Enterprise Architektur ausgeben. Ich habe im Moment das Vergnügen mit den Architekten eng in einer Gruppe zusammen arbeiten zu können. Die Kollegen produzieren im Prinzip (außer Papier und endlosen Telefongesprächen ;) ) nichts. Doch der Gewinn für die Firma ist, dass sie sich über die weiteren Jahre Gedanken machen. Es ist wichtig die IT-Landschaft, wie jede andere Prozesslandschaft, über die Jahre hin proaktiv zu bewirtschaften. Unsere drei Freunde haben aus Angst vor Betonschuhen bisher nur reagiert. Mit dem Handwerkzeug Reverse Engineering, haben sie erreicht sich über Wasser zu halten und nicht zusammen mit ihrem alten System zu sterben. Doch um wirklich eine gute Zukunft zu haben, kommen sie um eine Strategie und eine sinnvolle Planung nicht herum. Es wird Zeit das wir eine Koordination in die Geschichte bringen! Um ehrlich zu sein, ich bin gespannt wo dieses Blog noch hinführt...
tweetbackcheck