Agile Scrum Handbuch. Frank Turley
Wertaussage 4: Reagieren auf Veränderungen ist wichtiger als das Befolgen eines Plans
Diese Wertaussage gilt, ähnlich wie die Wertaussage 2, spezifisch für adaptive Systeme. Bei Agile gibt es im Vorfeld keinen Plan, der den Weg weist und gleichzeitig festlegt. Agile Systeme leben von der Anpassung. Letzteres bezeichnet man bei Agile normalerweise als Change (Änderung), möglicherweise, weil den Kunden die Vorstellung gefällt, jederzeit alles ändern zu können. Streng genommen jedoch spricht man nur dann von Change, wenn etwas von der ursprünglichen Baseline-Planung abweicht. Bei adaptiven Systemen gibt es aber gar keine Baseline-Planung. Technisch gesehen handelt es sich um einen kontinuierlichen Fluss neuer Ideen. Bleiben wir jedoch ruhig bei der Bezeichnung Change (Änderung), wenn das für unsere Kunden wichtig ist.
■ 1.6 DIE AGILEN PRINZIPIEN
Das Agile Manifest ist angenehm kurz. Da die Autoren die neu benannten Ideen der Agile-Methode jedoch näher ausführen wollten, haben sie ergänzend folgende zwölf Prinzipien formuliert:
Prinzip 1: Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufriedenzustellen.
Wir sind wirtschaftlich tätig und brauchen zufriedene Kunden. Das ist offensichtlich. Heutzutage nimmt man gerne die Benutzerzufriedenheit als ultimativen Maßstab, da sie Gewinne für den Kunden generiert und der Kunde so früher oder später nachhaltig zufriedengestellt wird. Klingt das zu idealistisch?
Wie also können wir die Kunden zufriedenstellen? Dies tun wir über die von uns entwickelte Software, die das Potenzial hat, Wert (z. B. Geld) zu generieren. Liefern wir früh und kontinuierlich aus, können wir die Wertschöpfung beschleunigen. Darüber hinaus können wir Anpassungen vornehmen und so ein Produkt nach den Wünschen des Markts entwickeln, für das der Markt auch bereit ist zu bezahlen, und nicht ein Produkt, von dem wir nur annehmen, dass es auf dem Markt nachgefragt wird.
Prinzip 2: Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
Schlagen wir doch mehr Marketingkapital aus den Begriffen Änderung oder Change. Kunden lieben diese Begriffe.
Prinzip 3: Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.
Erinnern Sie sich an die Iterationen, über die wir gesprochen haben – diese Zeiträume, in denen wir Entwicklungsprozesse wiederholen, um Produktinkremente zu erzeugen? Diese Inkremente 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