sollen laut diesem Grundsatz maximal ein paar Monate dauern. Das Maximum bei Scrum ist ein Monat. Über diesen Punkt werden wir in diesem Buch noch häufig sprechen.
Der Vorschlag, funktionierende Software innerhalb weniger Wochen auszuliefern, also die Idee, innerhalb weniger Wochen über ein neues Produktinkrement zu verfügen, wurde seinerzeit mit Gelächter aufgenommen. Inzwischen gibt es aber sogar Projekte mit kürzeren Iterationen.
Prinzip 4: Fachexperten und Entwickler müssen während des Projekts täglich zusammenarbeiten.
Dies steht im Widerspruch zu der Idee, die Fachexperten (ob Kunden oder andere Experten) von den technischen Mitarbeitern zu trennen, die bei Projekten nach wie vor für Probleme sorgt. Techniker und Fachexperten betrachten die jeweils andere Partei manchmal als Gegner, was für das Projekt alles andere als optimal ist.
Darüber hinaus sind Produktanpassungen nur möglich, wenn die Fachexperten kontinuierlich verfügbar sind. Denken Sie nur einmal an die kontinuierliche Analyse von neuen Funktionen und das Prüfen von fertiggestellten Einheiten. Außerdem macht es mehr Spaß, den erfolgreichen Abschluss einer Iteration gemeinsam mit vielen Mitstreitern zu feiern.
Prinzip 5: Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.
Wir werden schon bald über weitere Aspekte adaptiver Systeme sprechen. Einer dieser Aspekt ist, dass die Projektmitarbeiter motiviert, eigenverantwortlich und selbstorganisiert arbeiten. Motiviertes, eigenverantwortliches und selbstorganisiertes Arbeiten ist nicht nur wichtig, weil es prinzipiell eine gute Sache ist, sondern vor allem, weil adaptive Lebenszyklen diese Art der Arbeit brauchen. Sie können sich ja, während wir die weiteren Prinzipien besprechen, schon einmal überlegen, warum das so ist.
Prinzip 6: Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist das Gespräch von Angesicht zu Angesicht.
Persönliche Gespräche sind effizienter und effektiver als E-Mails! Bitte beachten Sie, dass dies das prüfungsrelevanteste Prinzip aller Zeiten ist.
Auf dieses Prinzip werden wir nochmals zuruckkommen in Abschnitt 2.3.8, wenn wir über die so genannte osmotische Kommunikation sprechen.
Prinzip 7: Funktionierende Software ist das wichtigste Fortschrittsmaß.
Bei den meisten Projekten wird das Falsche gemessen. Dies ist ein grundlegendes Problem, denn das, was man misst, ist das, was man bekommt. Wenn Sie messen, wie viele Codezeilen erstellt werden, erhalten Sie mehr Codezeilen. Wenn Sie messen, wie beschäftigt die Entwickler sind, bekommen Sie stärker beschäftigte Entwickler. Wenn Sie die Velocity (Geschwindigkeit) messen, wird die Velocity gesteigert. Die ist aber nicht das Ziel.
Was soll also gemessen werden?
Das wichtigste Maß ist die Wertschöpfung. Diese ist jedoch schwer zu messen. Der nächstbeste Maßstab ist daher die funktionierende Software, die die Fähigkeit zur Wertschöpfung begründet.
Prinzip 8: Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
Keine übermäßigen Überstunden vor Releases. Ziel ist die langfristige Wertmaximierung nicht ein kurzfristiger Nutzen, der möglicherweise Produktivitäts- und Qualitätsverluste zur Folge hat.
Prinzip 9: Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.
Bei adaptiven Systemen besteht die Gefahr eines schlechten Designs, da dieses nach und nach, parallel zum Projektverlauf und nicht vorab umgesetzt wird. Um dieses Problem zu lösen, stehen bestimmte Praktiken zur Verfügung.
Prinzip 10: Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.
Dies klingt relativ kompliziert, bedeutet aber ganz einfach, dass mehr Funktionen nicht automatisch besser sind.
In der Einfachheit liegt die Kunst. Wir sollten versuchen, uns bei einer Lösung auf die wirklich nützlichen Funktionen zu beschränken. Dies spart Zeit und Geld (das für andere Projekte eingesetzt werden kann) und senkt die Wartungskosten.
Prinzip 11: Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
Selbstorganisation bedeutet in diesem Zusammenhang, dass das Team aus motiviert, eigenverantwortlich und selbstbestimmt arbeitenden Mitgliedern besteht, die sich aktiv an Entscheidungen beteiligen. Dies ist in der Regel eine gute Idee.
Prinzip 12: In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten entsprechend an.
Wir müssen akzeptieren, dass unsere Arbeitsweise nicht perfekt ist, haben aber die Möglichkeit, sie schrittweise zu verbessern. Und bitte, nehmen Sie sich hier kein Beispiel an der Verbesserung des Agilen Manifests oder der Prinzipien von Agile. Lassen Sie in diesem Fall ausnahmsweise die Worte, nicht die Taten sprechen.
■ 1.7 PRAKTISCHE ÜBERLEGUNGEN ZU ADAPTIVEN LEBENSZYKLEN
Erinnern Sie sich, wie der adaptive Lebenszyklus funktioniert? Hier noch mal das Bild, damit das Buch auch umfangreich genug wird:
Bei diesem Thema gibt es ein paar Punkte, über die wir sprechen müssen. Zunächst wählen wir für jede Iteration eine Reihe von Funktionen aus. Unser Ziel ist, bis zum Ende der Iteration ein funktionierendes Inkrement zu erstellen, das hoffentlich alle Funktionen enthält. Jetzt ist Ihre Meinung gefragt. Was halten Sie für besser, eine Iteration mit festem Umfang oder eine Iteration mit fester Dauer?
1.7.1 Iterationen mit festem Umfang versus Iterationen mit fester Dauer
Theoretisch ist beides möglich, aber in der Praxis haben sich Iterationen mit fester Dauer bewährt. Die Gründe hierfür sind, dass man bei Iterationen mit festem Umfang…
■ …mehr Zeit benötigt, um den Umfang abzuschließen. Dadurch erhält man weniger Rückmeldungen und somit weniger Möglichkeiten zur Anpassung des Produkts.
■ … zu viel Zeit für die einzelnen Funktionen aufwendet und zu viel Schnickschnack hinzufügt. Bei einer festen Dauer muss man sich stets auf die wichtigsten (wertschöpfenden) Punkte konzentrieren.
Aus diesem Grund nutzen fast alle Agile-Methoden Iterationen mit fester Dauer (so genannte Timeboxes) und bestehen meist darauf, diese einzuhalten. Eine Timebox ist eine Zeitspanne mit einer maximalen (oder festen) Zeitdauer, die unter keinen Umständen verlängert werden darf (verlängert man sie einmal,
