Zur Andacht

"Scrum ersetzt die Inkompetenz des Projektmanagers durch die Unfähigkeit des Teams!"

Neulich gehört - hat was, oder?

Hilfe – meine Programmierer bauen Frameworks!

Bei der Planung Ihres Projektes haben Entwickler und Architekten mitgearbeitet. Der Termin ist zwar eng, aber erreichbar. Sie dürfen nur keine Zeit verlieren! Nach dem Setup der Arbeitsumgebungen und des Build-Prozesses läuft die Entwicklung langsam an, Ihr Blutdruck sinkt und Sie atmen mal durch.

Das wichtigste erste Feature ist, die Daten persistent zu speichern, klar: in der Datenbank. Das Datenmodell haben Ihre Leute schon erstellt, hat viel Zeit gekostet, bis die zufrieden waren. Jetzt geht’s los! Die Entwickler hauen in die Tasten und malen Kästchen-Diagramme an die Whiteboards. So weit, so beeindruckend.

Irgendwie sehen Sie zwar viel Arbeit, aber wenig konkrete Ergebnisse? Und immer, wenn Sie nachfragen, heißt es: „Läuft! Muss halt sein: der Code ist die Basis, damit wir später schnell implementieren können.“

Keine Sorge – Sie sind nicht allein! Was Ihnen gerade passiert, haben viele Projektleiter schon durchgemacht: Ihre Entwickler bauen nämlich gerade ein Framework! Sicherlich gibt es ganz in Ihrer Nähe eine Selbsthilfegruppe von Software-Projektleitern, die Sie freundlich aufnimmt... Im Ernst: Warum tun die das? Und bringt das Ihr Projekt voran oder in Bedrängnis?

Ihre Entwickler haben natürlich in der ein oder anderen Form einen Informatik-Hintergrund, häufig durch Ausbildung, viele sogar durch ein Studium. Irgendwann einmal hat sich die Informatik von ihren Stiefeltern, der Mathematik und der Elektrotechnik, losgesagt und verfolgt seit dem eigene Ansichten, Traditionen und Mythen.

Eine grundlegende Tradition ist die Abstraktion eines Algorithmus oder eines Fachobjektes durch eine generische Sicht: wenn der Sortieralgorithmus mit Adressdaten funktioniert, warum nicht auch mit Kontodaten? Ist nicht jeder Beteiligte in einem Geschäftsprozess ein Partner, der zumindest eine postalische Adresse hat?

Gerade die Abstraktion bietet aus kaufmännischer Sicht durchaus Vorteile: Sie wollen ja nicht jedes Mal wieder für die Erfindung des Rades bezahlen – schließlich ermöglicht insbesondere die Objektorientierung eine generische Herangehensweise und eine schnelle Wiederverwendung bei niedrigen Kosten.

Gerade die stets angeführten Kostenvorteile bei Wiederverwendung halte ich übrigens für einen hartnäckigen Mythos: Wie viele EU-Forschungsprojekte, experimentelle Programmiersprachen und wissenschaftliche Arbeiten hat es hierzu schon gegeben? Und wie viel Code wird in der Praxis wirklich wiederverwendet? Oft stellt man fest, dass ein cleverer Algorithmus doch noch ziemlich ausgebaut werden muss, damit er auch tatsächlich wiederverwendbar ist – etwa als Framework. Denn die Situationen, in denen Code erneut eingesetzt werden soll, können extrem unterschiedlich sein: vielleicht ist die generische Sortierung gar nicht so vorteilhaft, wenn zu viele Sätze in eine Maske geladen werden müssen? Will sagen: Trau, schau, wem!

Falls Sie Entwickler-Magazine wie die c’t, Java-Magazin, Entwickler-Magazin, Objekt-Spektrum u.a. lesen: wundern Sie sich auch immer, wie viele Frameworks aus dem Open Source Bereich dort vorgestellt werden? Natürlich gibt es auch viele, viele kommerzielle Frameworks, die in diesen Zeitschriften beworben werden. Es wäre mal interessant nachzuhalten, welche der vorgestellten Frameworks wieder in der Versenkung verschwinden! Die wesentliche Erkenntnis ist aber meist: 

"There is a framework for that!“

Wenn Sie ein Framework bauen wollen oder müssen – weil es wirklich kein passendes und verfügbares gibt – wie tun Sie das dann?

Treiben Sie die Entwicklung von Framework und Anwendung, Modul oder was immer auf dem Framework basiert, parallel voran:

• Die Entwickler bauen ein Feature des Frameworks, z.B. „lese Daten aus Tabelle und packe sie in ein Objekt“.
• Dann bauen sie z.B. die Geschäftslogik, den Service zum Aufbereiten der Daten sowie eine Maske, in der die Daten angezeigt werden.
• Dabei lernen Ihre Entwickler ziemlich viel über die tatsächlichen Anforderungen der nutzenden Module an das Framework – und können schnell das Framework noch anpassen. Das Ganze können Sie natürlich auch halb parallel machen: die einen bauen das Framework, die anderen die Maske.
• Danach kommt das nächste Feature dran, z.B. Speichern von Objekten in der Datenbank.
• (und so weiter)

Selbst wenn sich zwischendurch die Richtung des Projektes ändert, und auch wenn Sie am Ende wirklich ein komplettes Framework haben:

• Sie bauen nur das, was wirklich benötigt wird – Code für „später“ oder meist „viel später“ oder sogar „viel, viel später“ wird nicht für teures Geld erstellt.
• Die Vorausplanungen für das Framework werden schnell validiert – nichts ist so erkenntnisbringend wie nutzende Module! Wir alle neigen nämlich bei Planungen zu  Irrtümern – sonst wären wir ja schon alle Millionäre oder Nobelpreisträger...
• Wenn Sie dies mit relativ kurzen Zyklen umsetzen, verstärken Sie diese Effekte noch.

So gut das alles klingt: Sie werden Ihre Entwickler schon überzeugen müssen. Als Projektleiter haben Sie noch andere Mittel, in Scrum-Projekten müssen Sie den Product Owner dafür gewinnen. Machen Sie den Entwicklern klar, dass es um harte Dollars geht!

Übrigens ist das Beispiel mit der Persistierung natürlich nur ein Beispiel... Sie haben dafür natürlich eine große Auswahl an Frameworks (im Java-Bereich) unter Hibernate, Eclipselink, iBatis und anderen. Natürlich haben die alle ihre Schwächen – dafür könnte man ein perfektes, neuartiges Framework bauen...

Beobachtung des Tages: PMBoK und oder Wasserfall?

Gestern Abend traf sich wieder das PMI Cologne Chapter zu Vortrag und News aus dem Chapter. In der Diskussion in der traditionellen Brötchenpause fiel uns im Gespräch folgendes auf:
Man hört häufig, dass das PMBoK ja einen traditionellen Ansatz vertritt und sehr Wasserfall-artig sei. Das verwundert immer die zertifizierten PMPs und alle, die es sich angetan haben und das PMBoK wirklich gelesen haben - es steht da nämlich so nicht drin. Im Gegenteil: iteratives und inkrementelles Vorgehen ist durchaus vertreten!

Woher kommt diese Vorstellung?

Ich meine, dass wir vor allem in der IT häufig eher kleine Projekte haben. Naheliegenderweise sind große Projekte mit mehreren tausend Projekttagen auch seltener. Gerade beim Einsatz von Scrum verdrängt man gerne mal, dass in größeren Landschaften auch jemand das Ganze irgendwie zusammenführen muss - und das steht nicht im Scrum-Guide!

Nun muss man nur die Product Owner (in Scrum) dazu bekommen, sich die PMBoK-Inhalte anzusehen: sie machen ja in Scrum einen wesentlichen Teil der "traditionellen" PM-Aufgaben...