Mitglieder des FDD Teams
Das FDD Modellierungsteam vereint die folgenden Schlüsselpositionen:
- Der Projektleiter überwacht das gesamte Projekt.
- Der Chefarchitekt ist für den generellen Entwurf und die Modellierung des Systems zuständig. Der Chefarchitekt arbeitet mit anderen qualifizierten Entwicklern in der Planungsphase des Entwicklungszyklus zusammen.
- Der Entwicklungsleiter führt und betreut das Entwicklungsteam und überwacht die alltäglichen Programmieraktivitäten.
- Der Chefprogrammierer hilft bei der Analyse und dem Entwurf und kann auch kleinen Entwicklungsteams als Manager zugewiesen werden.
- Die für die Klassen verantwortliche Person ist ein Mitglied der kleineren Entwicklungsteams, die vom Chefprogrammierer geleitet werden. Zu den Zuständigkeiten gehören das Entwerfen, Codieren, Testen und Dokumentieren von Funktionen.
- Der Domainexperte ist Mitglied eines Teams, der das Problem kennt, das für den Kunden gelöst werden soll. Die Entwickler verlassen sich bei ihrer Arbeit auf das Wissen des Domainexperten, um den Kundenerwartungen stets gerecht zu werden.
Gründe für funktionsorientierte Entwicklung
Sie sollten die FDD Methodik in Erwägung ziehen, sobald Ihr Projekt zu groß und komplex für kleinere Scrum Teams wird, der Arbeitsaufwand also nicht mehr effektiv bewältigbar ist. Diese agile, funktionsorientierte Methodik eignet sich gut für langfristige Projekte, bei denen in regelmäßigen, vorhersehbaren Abständen Funktionen kontinuierlich geändert und erweitert werden.
Die FDD Methodik ist von Kleingruppen bis hin zu großen funktionsübergreifenden Teams sehr gut skalierbar, da hier der Fokus konzeptionsgemäß auf den Bedürfnissen und Wünschen des Kunden liegt.
Vorteile funktionsorientierter Entwicklung
- Vermittelt dem Team ein sehr gutes Verständnis des Projektumfangs und -kontextes.
- Erfordert weniger Meetings. Eine der Klagen, die in der agilen Methodik häufig geäußert wird, ist die zu hohe Anzahl von Meetings. Bei Scrum werden täglich Meetings abgehalten, um Kommunikation zwischen Teams zu ermöglichen. Bei FDD erfolgt die Kommunikation anhand der Dokumentation.
- Basiert auf einem nutzerorientierten Ansatz. Bei Scrum gilt der Produktmanager in der Regel als Endbenutzer. Bei FDD ist der Kunde der Endnutzer.
- Funktioniert gut bei großen, langfristigen oder fortlaufenden Projekten. Diese Methodik ist besonders skalierbar und kann mit dem Wachstum Ihres Unternehmens und des Projekts Schritt halten. Die fünf klar definierten Schritte erleichtern es neuen Teammitgliedern oder Mitarbeitenden, sich sehr schnell in das Projekt einzuarbeiten.
- Unterteilt Funktionsgruppen in kleinere Einheiten und regelmäßige iterative Releases. Codierungsfehler können so einfacher ermittelt und behoben werden. Das Risikopotenzial sinkt und Kundenanforderungen können erfüllt werden, da eine schnelle Umsetzung gewährleistet ist.
Nachteile funktionsorientierter Entwicklung
- Für kleinere Projekte ist die FDD Methodik nicht ideal; zudem eignet sie sich nicht für Projekte mit nur einem Entwickler. Für eine einzelne oder nur wenige Personen ist es schwierig, die verschiedenen Rollen ohne Unterstützung zu übernehmen.
- Hierbei besteht eine große Abhängigkeit von einem Chefprogrammierer, der in der Lage sein muss, als Koordinator, führender Designer und Mentor für neue Teammitglieder zu fungieren.
- Es gibt keine schriftliche Dokumentation für den Kunden, obwohl die Kommunikation zwischen den Teammitgliedern während der Projektentwicklungszyklen in hohem Maße dokumentiert wird. Daher erhält der Kunde keinen Nachweis für seine eigene Software.
- Der Schwerpunkt liegt auf individueller Codeverantwortung anstelle von gemeinsamer Verantwortlichkeit des Teams.
- Funktioniert möglicherweise nicht so gut bei älteren Systemen, da bereits ein System vorhanden ist und es kein Gesamtmodell zur Definition gibt. Möglicherweise müssen Sie von vorne anfangen und von Grund auf neu arbeiten.
5 Schritte des FDD Projektlebenszyklus
Nachdem Sie nun die Vorteile der funktionsorientierten Entwicklung kennengelernt haben, lassen Sie uns die einzelnen Schritte des Entwicklungsprozesses unter die Lupe nehmen, damit Sie diese in Ihrem Team umsetzen können.
Schritt 1: Entwicklung eines Gesamtmodells
In diesem Schritt verfassen Sie eine Übersicht, um Ihr Domainmodell zu definieren – das Unternehmensproblem, das im Rahmen Ihres Softwareentwicklungsprojekts gelöst werden soll. Das Team arbeitet eng mit dem Chefarchitekten zusammen, um den Umfang und den Kontext des Systems zu definieren. Mehrere Domainmodelle sollten zu einem Gesamtmodell zusammengeführt werden, das einen Überblick über Ihr System gibt.
Schritt 2: Erstellung einer Funktionsliste
Die Funktionsliste ähnelt dem Scrum Product Backlog. Arbeiten Sie die Funktionen heraus, die für den Kunden wichtig sind. Funktionen werden als Handlung, Ergebnis und Objekt ausgedrückt (z. B. „die Kontonummer des Nutzers überprüfen“).
Die Entwicklung einer bestimmten Funktion sollte nicht länger als zwei Wochen dauern. Dauert die Erstellung einer Funktion länger als zwei Wochen, sollte sie in kleinere Funktionen aufgeteilt werden.
Schritt 3: Planung nach Funktionen
Legen Sie die Reihenfolge fest, in der die Funktionen aus der Funktionsliste entwickelt und implementiert werden. Ziehen Sie potenzielle Risiken, Abhängigkeiten, den Arbeitsaufwand des Teams und einzelner Personen sowie alle anderen Hindernisse, die die Entwicklung von Funktionen behindern könnten, in Betracht.
Weisen Sie dann die Funktionsgruppen den kompetentesten Programmierern zu, die über die nötige Bandbreite verfügen, um sie innerhalb des vorgegebenen Zeitrahmens zu entwickeln.
Schritt 4: Design nach Funktionen
Der Chefprogrammierer legt fest, welche Funktionen in zweiwöchigen Abständen entworfen und entwickelt werden sollen. Diese Person legt auch die Prioritäten der Funktionen fest und bestimmt, wer Teil des Funktionsteam wird. Vor dem nächsten Schritt muss eine Entwurfsprüfung vom gesamten Team durchgeführt werden.
Schritt 5: Entwicklung nach Funktionen
In diesem Schritt werden alle Elemente implementiert, die zur Unterstützung des Funktionsdesigns erforderlich sind. Die Benutzeroberfläche wird entworfen und ein Funktionsprototyp wird erstellt und getestet. Wenn die Funktion den Test besteht und genehmigt wird, kann die fertige Version dem primären Build hinzugefügt und den Kunden zur Verfügung gestellt werden.