31.08.2018
Software-Entwicklung
1. Teil: „So vereinfacht FlePA das Projektmanagement“
So vereinfacht FlePA das Projektmanagement
Autor: Ruy Kuhlmann
Wright Studio / Shutterstock.com
Klassisches Projektmanagement läuft häufig schief. Die neue FlePA-Methode verspricht Abhilfe. Der Fokus liegt dabei gleichermaßen auf dem Ergebnis, dem Team und den Prozessen.
Projektmanagement ist heute entweder klassisch Wasserfall oder modern agil. Das klassische Vorgehen gehorcht der Logik eines Brückenbaus. Es ist wenig spektakulär, doch viele Projekte scheitern, sprengen das Budget, den Zeitplan oder alles zusammen. Das Project Management Institute nennt nicht weniger als 47 Prozesse, die ein Projekt ausmachen.
Software-Entwicklungsmethode aus Werten, einem Manifest oder Prinzipien basteln lässt, ist mit der Zeit eine Liste an Praktiken (zum Beispiel Pair Programming), Rollen (etwa Scrum Master) und einigen neuen Bezeichnungen (Story Points, Poker-Schätzen) entstanden. Sie haben allein das Ziel, die agilen Methoden besser zu verkaufen.
Die klassische Methode verliert dabei oft das eigentliche Projektergebnis aus den Augen und wendet sich unwichtigen Nebenschauplätzen zu. Als Reaktion darauf entstanden agile Vorgehen. Die Grundlage sind erstens ihre Werte, zweitens das Manifest und drittens zwölf Prinzipien. Da sich keine Der agile Entwickler kann die Praktiken nach Wunsch zusammenstellen. So entstehen Dutzende agiler Methoden. Sie verlagern den Projektschwerpunkt hin zur Kommunikation und rücken die Menschen in den Mittelpunkt. Das Projektergebnis als Ziel der Arbeit wird in den agilen Methoden jedoch nicht berücksichtigt – stattdessen zum Beispiel Meetings.
In der Praxis zeigt sich aber, dass das Schreiben von Software anders ist als der Brückenbau. Ein Grund ist, dass Software abstrakter ist als eine Brücke. Der Kunde kann sich die Brücke viel plastischer vorstellen als das Programm zur Ampelsteuerung vor der Brücke. Um die Brücke zu bauen, ist eine klassische Methode gut. Doch ist eine agile Methode gut genug, um die Ampel-Software damit zu erstellen?
Einführung in FlePA
Viele Jahre Praxiserfahrung führten zum Hervorbringen eines neues Vorgehens zur Software-Entwicklung. Mit Blick auf die Mängel sowohl der klassischen als auch der agilen Methoden sowie die Schwierigkeiten, die aus der Abstraktion der Software-Entwicklung entstehen, ist die FlePA-Methode entstanden. FlePA steht für „Flexibles Planen und Arbeiten“. Der Schwerpunkt liegt nicht auf bestimmten Praktiken oder gar der Produktion von Dokumenten, sondern fokussiert das Projektergebnis. Nebenprodukte sollen Nebenprodukte bleiben, etwa die Dokumentation, und Nebenschauplätze nur Nebenschauplätze, etwa Meetings.
Die FlePA-Methode setzt sich mit den drei Gegenständen auseinander, die ein Projekt ausmachen:
- Projektergebnis: Was muss erstellt werden (das Ziel)?
- Team: Wissen, Können, Interaktionen der Mitglieder.
- Prozesse: Leitsätze definieren die Zusammenarbeit.
2. Teil: „Aufbau der FlePA-Methode im Detail“
Aufbau der FlePA-Methode im Detail
1. Projektergebnis
Es ist das Ergebnis einer (Engineering-)Leistung. Dieses soll so genau wie möglich beschrieben vorliegen, nicht nur aus Sicht der Architektur und des Designs, auch im Hinblick auf Funktionalität und Qualitätsansprüche.
Das zu erstellende Produkt wird sowohl als ein Ganzes als auch in Teilen betrachtet und analysiert, Funktionen und Tests werden definiert, Kosten, Ressourcen und Zeiten geschätzt. Doch soll die Planung modifizierbar sein (klassisches Wunschdenken) oder auch ignoriert werden (agile Leichtfertigkeit).
2. Team
Für das Team sollte ein Rahmen angewendet werden, der auf dem erweiterten „magischen Dreieck“ des Projektmanagements basiert. Dieses Dreieck, bestehend aus den Parametern Funktionalität, Kosten und Zeit, wird durch das Kriterium Qualität zu einem Viereck des Projektmanagements erweitert. Die Interaktionen zwischen den Teammitgliedern werden durch diesen Rahmen definiert. Auch muss der Rahmen an die wirkliche Teamgröße und das Können und Wissen der Mitglieder adaptiert werden.
Die Teammitglieder besetzen Rollen, etwa die des Projektleiters, und führen Funktionen aus. Dies kann beispielsweise die Schnittstelle zu anderen Teams sein. Es ist Unfug, wenn das ganze Team – am besten noch täglich – mit dem Kunden kommuniziert. Diese Aufgabe wird vom Kundenkommunikator übernommen. Der Funktion können eine oder mehrere Personen zugeordnet sein, wobei es gilt, die Gruppe so klein wie möglich und so groß wie nötig zu halten.
Je nach Größe des Teams werden einige Rollen und zudem mehrere Funktionen definiert. So kann zum Beispiel ein Team von drei Mitarbeitern vier Rollen und zwölf Funktionen innehaben. Anforderungsmanager- und Projektleiterrollen können in diesem Fall von einer Person ausgeübt werden.
3. Prozesse und Leitsätze
FlePA hat nur zwei Prozessblöcke: Planen und Arbeiten. Ein Projekt braucht Planung, handelt es sich doch um eine neue Entwicklung. Doch gerade weil das Ergebnis neu ist, muss diese Planung mögliche Änderungen mitberücksichtigen, die so gut wie sicher vorkommen werden – deswegen flexibles Planen. Was zu dieser Planung alles gehört, muss von Projekt zu Projekt einzeln festgestellt werden. Für ein Projekt kann das Design des GUI ausreichend sein, für ein anderes Projekt kann von der Architektur bis zur Wartung für zwanzig Jahre geplant werden müssen. Wenn sich etwas ändert, so sind diese Änderungen als Störgrößen in einem Regelkreis zu sehen.
Sie müssen durch eine Rückkopplung wieder einen Planungsprozess anstoßen. Genauso ist auch die Arbeit als Teil eines Regelkreises zu betrachten. Beispiele für Störgrößen sind in diesem Fall Mitarbeiter, die das Team verlassen und anschließend ersetzt werden müssen, oder etwa Arbeitsmittel, die ausfallen.
3. Teil: „FlePA in der Praxis“
FlePA in der Praxis
- Jeden zweiten bis dritten (zweiwöchigen) Sprint musste man die Architektur des Systems anpassen.
- Es war kaum möglich, die Software zu erweitern, ohne dass woanders etwas nicht mehr funktionierte.
- Die automatischen Tests waren ebenfalls so gut wie nicht zu warten, geschweige denn zu erweitern. Sie wurden weitgehend ignoriert.
- Ohne tagelanges Refactoring war kein Sprint zu realisieren. Weder zum ersten (sehr aggressiven) Termin wurde geliefert, noch zum zweiten. Zwischen beiden Terminen lagen mehrere Monate. Nach über einem Jahr mussten sich die Verantwortlichen eingestehen, dass auch diese Methode nicht funktionierte.
Jedoch war die Firma gezwungen, das zweite Projekt ordentlich zu Ende zu führen – ein drittes kam nicht infrage. Was konnte sie tun? Die sicherste Lösung hieß FlePA: Die Scrum Master wurden nach Hause geschickt. Der Product Owner wurde zum Kundenkommunikator. Alle Meetings und anderen Scrum-Rituale wurden abgeschafft. Nach einer zweiwöchigen Bestandsaufnahme wurden die brauchbaren Teile der geschriebenen Software in Module zerteilt und die Verantwortung über die einzelnen Module jeweils unter den Entwicklern aufgeteilt.
Neue Rollen und Funktionen
Die Probleme, die bei anderen Software-Teilen auftraten, wurden verallgemeinert und zu neuen Stories aufgearbeitet. Rollen und Funktionen wurden definiert und unter den Teammitgliedern verteilt.
Durch das Verantwortungsprinzip war jeder der Entwickler zuständig für sein Modul – und zwar in seiner Funktion als Modul-Meister und nicht durch sogenannte Story Points angetrieben.
Nach Ende der initialen zwei Wochen wurden noch etwa elf Wochen benötigt, um dem Kunden eine halbwegs saubere Software zu präsentieren. Etwa sechs Monate später konnte man dem Auftraggeber die erste Version eines funktionsfähigen Systems liefern.
Die Entwicklungszeit wurde so kurz, weil die Teams schon lange zusammengearbeitet hatten und große Teile der Software bereits geschrieben waren – wenngleich in einer Form, die die Mitarbeiter selbst als „Spaghetti-Code“ bezeichneten.
Fazit: Ziel statt Methode
Natürlich hatte man zuvor unter Scrum auch Sprints gehabt, die dazu dienten, Ordnung in das Chaos zu bringen. Sie hatten allerdings das Ziel, die Software zu verbessern (zu debuggen) und nicht, sie ganz neu zu schreiben. Somit blieb die Unsauberkeit des Systems grundsätzlich erhalten, was zum Scheitern führte.
FlePA – ohne die vielen Zwänge unflexibler Praktiken – konnte voll und ganz auf das zu erstellende System fokussieren.
Personen
Nfon CCO Gernot Hofstetter tritt zurück
Gernot Hofstetter war sechs Jahre beim Münchner Cloud-PBX-Anbieter Nfon, zuletzt als Chief Commercial Officer. Nun hat er das Unternehmen verlassen und ist zum Start-up Stealth Mode gewechselt.
>>
Künstliche Intelligenz
Memary - Langzeitgedächtnis für autonome Agenten
Das Hauptziel ist es, autonomen Agenten die Möglichkeit zu geben, ihr Wissen über einen längeren Zeitraum hinweg zu speichern und abzurufen.
>>
Cloud Infrastructure
Oracle mit neuen KI-Funktionen für Sales, Marketing und Kundenservice
Neue KI-Funktionen in Oracle Cloud CX sollen Marketingspezialisten, Verkäufern und Servicemitarbeitern helfen, die Kundenzufriedenheit zu verbessern, die Produktivität zu steigern und die Geschäftszyklen zu beschleunigen.
>>
Reactive mit Signals
Neuer Vorschlag für Signals in JavaScript
Das für die Standardisierung von JavaScript verantwortliche Komitee macht einen Vorschlag für die Einführung von Signalen in die Programmiersprache. Signals sollen reaktives Programmieren in JavaScript einfacher machen.
>>