Posts Tagged ‘project management’

Gelesen: Scrum “Produkte zuverlässig und schnell entwickeln”

Vor kurzem habe ich noch das Buch Scrum “Produkte zuverlässig und schnell entwickeln” gelesen. Das Buch wurde von Boris Gloger – einem Scrum Protagonist – verfasst. Es beinhaltet die Konzepte und Ideen hinter dem Framework Scrum. Auf eine Zusammenfassung verzichte ich an dieser Stelle, zumal in früherigen Blogs bereits einige Informationen genannt wurden. Die im Buch vorgestellten Konzepte werden anhand anschaulicher Beispiele vorgestellt, was für mich eher etwas langatmig wirkte und den Lesevorgang bremste. Besonders interessant war das Kapitel “Einführung von Scrum in grossen Projekten und Organisationen”, denn dieses Thema wird von vielen Autoren sonst nur am Rande erwähnt. Die Komplexität und Herausforderungen erhöhen sich in grossen Projekten. Als Einstiegs-Lesewerk empfehle ich weiterhin das Buch von Roman Picher und sehe dieses Buch als spannende Ergänzung. Ein Auszug aus dem Buch ist bei books.google.com zu finden.

Tags: , , , , ,

FDD Feature Driven Development (Teil 4)

Ein Feature wird von den Erfindern von FDD wie folgt definiert:

The features are small “useful in the eyes of the client” results.

FDD ist eine kundenorientierte Entwicklungsmethode mit kleinen Teilresultaten. Die Grösse eines Feature wird weiter eingeschränkt durch die Bedingung, dass ein Feature in maximal zwei Wochen entwickelt werden sollte, andernfalls muss es weiter aufgeteilt werden bis diese Vorgabe erfüllt werden kann. Der Vorteil einer solchen Vorgabe wird in der Motivation der Programmier und in der Messbarkeit der Resultate gesehen. Durch die häufige Erreichung eines brauchbaren und sichtbaren Resultats, d.h. alle zwei Wochen, kann die Motivation der Programmierer Aufrecht erhalten werden. Der Abschluss eines Feature kann zudem von den Projektverantwortlichen und den Manager zum Feststellen des Projektfortschritts verwendet werden. Da ein Feature als kundenorientiertes Resultat definiert ist, ist die Fertigstellung eines Feature auch ein für Nichtinformatiker verständlicher Meilenstein: ein Manager oder der Kunde kann sich unter dem Resultat etwas vorstellen. Der Aufwand für kleine Teilresultate kann besser geschätzt werden und deshalb erlaubt FDD eine bessere Projektkontrolle.

Die Prozesse für das Feature-Driven Development werden bewusst kurz und simpel gehalten, weil die Autoren die Meinung vertreten, dass eine Überspezifikation mehr schadet als nützt. Einen bis ins kleinste Detail definierten Prozess kann die schlussendlich benötigte Entwicklung eines Programms nicht ersetzen. Nichtsdestotrotz wird auf Prozesse im FDD aus folgenden Gründen nicht verzichtet:

  • Transformation auf andere Projekte und Wiederholbarkeit des Erfolgs
  • Schnellere Einarbeitungszeit für neue Mitarbeiter
  • Setzen von Prioritäten

Beim ersten Punkt geht es darum, ein bestimmtes Verhalten bei den involvierten Personen zu schulen, welches auch in späteren und neuen Projekten zum Erfolg führt. Ein simpler und klar definierter Prozess soll zu einer guten Gewohnheit werden. Zweitens kann mit einem simplen und klar definierten Prozess die Einarbeitungszeit für neue Mitarbeiter verkürzt werden. Drittens sollte sich die Entwicklung auf die wichtigen Punkte konzentrieren und Prioritäten setzen. Die Anforderungen sollen gewichtet sein nach “must-have”, “nice-to-have” etc.

Für weitere Informationen verweise ich auf Wikipedia:-)

Fazit

Der Hauptunterschied zwischen FDD Feature Driven Development und den anderen Agilen Methoden ist, dass bei diesem Vorgehensmodell als erster Projektschritt ein relativ detailiertes Modell des Gesamtprojektes erstellt wird. Von diesem Modell wird eine Liste von Features abgeleitet, aus denen das Gesamtmodell besteht. Im Gegensatz zu Extreme Programming, bei dem niemand auf ein Stück Code Besitz erheben kann, gibt es bei FDD zu jedem Feature einen Verantwortlichen, den sogenannten Feature Owner. Meiner Ansicht nach ist dieses Vorgehensmodell für grosse und komplexe Projekte ungeeignet.

Tags: , , , ,