Ziele der agilen Entwicklung

• Video
• Audio (Podcast)

Peer-to-peer player für bessere Performance

Oder, hole dir diese Serie als Audio-Only Podcast!

Zur aktuellen Episode geht's hier

Um zu verstehen, wie wir im Engineering die Agilität der Softwareentwicklung unterstützen können, müssen wir uns zuerst darüber unterhalten, welche Ziele die agile Softwareentwicklung eigentlich erreichen will.

Im vorigen Teil der Serie habe ich einen Überblick über alle Themen des aktuellen Kapitels gegeben. Heute soll es um Werte und Prinzipien der agilen Softwareentwicklung und um Agile Doctrine gehen; und darum, wie diese Dinge die Engineering-Kultur in einem Unternehmen beeinflussen—oder beeinflussen sollten.

• Was denkst du, welche Ziele verfolgen dein Team, deine Abteilung und dein Unternehemen mit ihrer agilen Vorgehensweise?
• Oder, falls ihr noch gar nicht "agil" arbeitet, welche Ziele sollten sie verfolgen?
• Was bedeutet das für deine tägliche Arbeit?
• Was funktioniert gut, was funktioniert weniger gut?

Mach kurz Pause und notiere die Antworten auf Papier. Dafür kannst du dir auch die aktuelle Notizblock-Seite herunterladen und doppelseitig ausdrucken.

Das Agile Manifest

Das agile Manifest, mit dem das Wort "agil" für leichtgewichtige Entwicklungsmethoden eingeführt wurde, listet 8 Werte auf, jeweils in 4 Paaren. Einer der beiden Werte eines Paares ist immer wichtiger als der andere, aber beide sind wichtig, z.B.:

Individuals and interactions over processes and tools

bedeutet, dass wir "individuals and interactions" höher schätzen als "processes and tools".

In einer untergeordneten Seite werden noch 12 Prinzipien der agilen Softwareentwicklung aufgelistet, z.B.:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Falls du das agile Manifest noch nie oder schon länger nicht gelesen hast, kannst du gerne kurz pausieren und jetzt nachlesen.

Alles klar! Oder? Wie kommen wir von diesen Werten und Prinzipien jetzt auf Ziele, die wir verfolgen sollten? Oder konkrete Leitlinien für unser Handeln?

Welche Ziele verfolgt die Agile Softwareentwicklung?

Eine der größten Herausforderungen der Softwareentwicklung ist es, überhaupt das "richtige" System zu bauen:

• Wir müssen sicherstellen, dass wir die Anforderungen und Bedürfnisse aller Stakeholder richtig verstanden haben.
• Die Software, die wir liefern, muss diese Anforderungen auch tatsächlich erfüllen und die Bedürfnisse befriedigen.
• Die Anforderungen und Bedürfnisse ändern sich ständig: Software, die gestern noch passend gewesen wäre, kann heute schon nutzlos sein.

Je länger wir ohne gutem Feedback arbeiten, umso schwieriger wird es, dieses richtige System zu bauen. Der Einsatz (investiertes Geld, investierte Zeit) und das Risiko steigen. Der Nutzen, den wir am Ende der Entwicklung bekommen, steigt zwar auch. Aber durch das steigende Risiko wird es immer unwahrscheinlicher, dass wir ihn tatsächlich erreichen. Und wenn etwas schief geht, verlieren wir mehr investiertes Geld und Zeit. Genau das müssen wir vermeiden.

Die agile Softwareentwicklung verfolgt deshalb folgende Ziele:

1. Sicherstellen, dass für den Anwender nützliche Funktionalität gebaut wird und das bei sich ständig ändernden Anforderungen. Also ändert sich auch die Definition dessen, was "nützlich" ist, mit der Zeit.
2. Sicherstellen, dass Investitionen—Zeit, Geld und Resourcen—optimal eingesetzt werden. "We are in this for the money", wie schon GeePaw Hill in "Five Underplayed Premises of TDD" gesagt hat.
3. Sicherstellen, dass die Geschwindigkeit, mit der wir liefern, über Jahre gehalten werden kann. Softwaresysteme werden komplexer, je mehr Features wir hinzufügen und trotzdem wollen wir nicht langsamer werden.

Agile Doctrine

Um diese Ziele zu erreichen, hat Jason Yip folgende "Agile Doctrine" formuliert—also Leitlinien, die uns unterstützen und führen sollen. Eine Doktrin soll es uns ermöglichen, ohne Risiko die Entscheidungsfindung zu dezentralisieren. "Agile Doctrine" von Jason Yip umfasst vier Punkte:

1. Reduce the distance between problems and problem-solvers: Sowohl die physische als auch die konzeptuelle Entfernung.
2. Validate every step: Bringt uns der Schritt vorwärts? Was ist das gewünschte Ergebnis und haben wir es erreicht?
3. Take smaller steps: Und dabei auch die Transaktionskosten, die zwischen den Schritten entstehen, reduzieren.
4. Clean up as you go: Verhindern, dass das System degradiert.

Als Entwickler sind wir normalerweise die problem-solvers und unsere Budgets begründen sich hauptsächlich dadurch, dass wir die Probleme der Endbenutzer unserer Software lösen und dadurch einen Wert für unser Unternehmen erschaffen. Aber um erfolgreich zu sein, müssen wir auch Probleme anderer Stakeholder lösen: Probleme des Kunden, der Rechtsabteilung, des Betriebs und unsere eigenen.

Wir müssen jeden unserer Schritte prüfen, um sicherzustellen, dass wir auf dem richtigen Weg sind—auch wenn sich der richtige Weg ändert. Wir gehen kleinere Schritte, um schneller auf Feedback reagieren und ggf. gegensteuern zu können. Und wir räumen währenddessen immer auf, um das Chaos nie zu groß werden zu lassen.

Was ist Agile Engineering?

Die Praktiken und Vorgehensweisen, die wir im Engineering anwenden, unterstützen die Agilität, indem wir:

1. Wertvolles Feedback maximieren
2. Das richtige Design zum richtigen Zeitpunkt implementieren
3. Kurze Zyklen von der ersten Idee bis zur produktiven Software ermöglichen
4. Unnötiges Re-Work vermeiden
5. Risiko minimieren

In späteren Teilen dieser Serie werde ich über Praktiken sprechen, deren Nutzen oft kontrovers diskutiert wird. Diese werden wir unter den Gesichtspunkten, die ich gerade erwähnt habe, betrachten und dabei immer beachten: "We are in this for the money"—also, wir wollen Dinge nur dann tun, wenn wir dadurch Zeit, Geld oder Ressourcen sparen können.

Heute habe ich erklärt, was die Werte und Prinzipien der agilen Softwareentwicklung sind, wie sie mit einer "agile Doctrine" zusammenhängen und wie diese Dinge die Engineering-Kultur in einem Unternehmen beeinflussen—oder beeinflussen sollten. Im nächsten Teil werde ich zeigen, dass kleinere Lieferungen, früher geliefert, besser sind—selbst, wenn man insgesamt denselben Umfang in der gleichen Zeit liefert.

Am Ende wird es wieder Zeit für den Notizblock: Wie können die folgenden beiden agilen Engineering-Praktiken zu den vorher genannten Zielen und Vorgehensweisen beitragen? Wie helfen sie uns, Zeit, Geld oder Ressourcen zu sparen?

• Pair Programming
• Test-Driven Development

Weitere Informationen

• DevTeams.at - Consulting, Coaching und Training - David Tanzer
• Das Agile Manifest
• 12 Prinzipien der agilen Entwicklung - Agiles Manifest
• Jason Yip: What is Agile doctrine?
• Five Underplayed Premises of TDD