Warum Agile Engineering?

• 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 die Vorteile von agilen Vorgehensweisen wirklich realisieren zu können, brauchen wir eine Engineering-Kultur, welche nichts mehr damit zu tun hat, wie man früher Software gebaut hat. Und die nur in wenigen Organisationen durchgängig vorherrscht.

In diesem und den folgenden Teilen des Kapitels "Warum Agile Engineering?" erkläre ich, warum es eine eigene Kultur und spezielle Vorgehensweisen und Praktiken in der Entwicklung braucht, um Agilität erreichen zu können.

Bevor es weitergeht, nimm dir kurz Zeit und beantworte die folgenden Fragen, am besten auf Papier. Dafür kannst du dir auch die aktuelle Notizblock-Seite herunterladen und doppelseitig ausdrucken.

• Was fällt dir spontan zum agilen Manifest ein?
• Inwieweit bist du einverstanden mit dem agilen Manifest?

Was ist Technical Excellence in der agilen Softwareentwicklung?

Keine Angst, ich werde nicht das gesamte agile Manifest hier wiederholen - noch nicht. Nur so viel: Aus den 12 Prinzipien lässt sich ableiten, dass Engineering einen besonderen Stellenwert haben muss. Speziell aus dem Prinzip:

Continuous attention to technical excellence and good design enhances agility.

Aber was genau ist diese "Technical Excellence"? Was bedeutet das für uns in der täglichen Arbeit? Und was müssen wir tun, um sie zu erreichen? Diese Fragen und mehr werde ich in "Quick Glance At: Agile Engineering" beantworten.

Aber nur mit dieser Serie wird es dir nicht möglich sein jede einzelne Praktik und Vorgehensweise produktiv in deinem Team an eurem Produktionscode auszuführen. Ich bin überzeugt, das ist mit diesem Format auch gar nicht möglich und das ist auch nicht das Ziel. Dazu braucht es Übung, weitere Erklärungen und eventuell sogar Coaching und Training. Aber ich werde darüber sprechen, wie du die notwendigen Fertigkeiten erlernen kannst, um die Praktiken produktiv zu verwenden.

Da das Thema groß und vielfältig ist, werden wir uns schrittweise herantasten. Ich werde nicht eine Praktik, wie zum Beispiel Test-Driven Development, einfach ohne Kontext vorstellen. Stattdessen werde ich anhand von verschiedenen Themenbereichen, wie "Interne und externe Qualität", "Mit Legacy-Code leben" oder "Design: Wann und wie?", die dafür notwendigen Praktiken und Vorgehensweisen erklären.

Inhalte "Warum Agile Engineering?"

In diesem ersten Kapitel, "Warum Agile Engineering", werden wir uns mit Zielen der agilen Entwicklung befassen. Diese Ziele haben einen großen Einfluss darauf, was wir tun müssen, um sie zu erreichen.

Ich werde zeigen, warum eine kleinere Lieferung, die früher geliefert wird, besser ist, als eine größere und diese Aussage auch einordnen: Wieviele Lieferungen können wir den Kunden überhaupt zumuten? Was müssen wir zusätzlich tun, damit das funktioniert?

In "Mean Time to Feedback" werde ich erklären, warum schnelles Feedback eines unserer Hauptziele sein sollte und wie wir, als Entwicklungsteam, dabei unterstützen können.

Aber wie kommen wir dort hin? In "Doing things right vs. doing the right thing" geht es um Business Agility und wie die Softwareentwicklung helfen kann, diese zu erreichen. In diesem Zusammenhang müssen wir auch über Effizienz und Effektivität sprechen. Es bringt nichts, wenn wir, in der Softwareentwicklung, schnell und effizient arbeiten, wenn wir an den falschen Themen arbeiten.

Aber agile Softwareentwicklung steht auch immer wieder in der Kritik: Sie führe zu Micromanagement und Planlosigkeit. Und wenn so viele Organisationen Probleme haben, "wirklich" agil zu werden—was auch immer "wirklich" bedeutet—dann wird das wahrscheinlich an der Agilität liegen und nicht an den vielen, unterschiedlichen Firmen... Oder? Im Teil "Agil - Das funktioniert doch gar nicht!" werde ich auf diese Kritik eingehen.

In "Jetzt tun vs. der richtige Zeitpunkt" erkläre ich, dass es oft besser ist, gleich etwas zu tun (und dann eventuelle Fehler zu korrigieren) als zu warten... Aber auch nicht immer. Wir müssen Abwägen zwischen dem Nutzen, den wir daraus ziehen, etwas jetzt zu machen und dem Wert, den unsere Optionen für die Zukunft noch haben.

Der letzte Teil dieses Kapitels heißt "Der Code ist nicht der Flaschenhals". Im agilen Engineering investieren wir sehr viel Energie darin, schneller besseren Code zu schreiben. Aber langfristig kann das nicht unser einziges Ziel sein.

Fazit

In diesem ersten Kapitel geht es also darum, was agile Softwareentwicklung bedeutet, was wir damit erreichen wollen und wie sich Agile Engineering hier einordnet. Nach diesem Kapitel werde ich einen kurzen Überblick über verschiedene Engineering-Praktiken geben und danach geht es in die vorher erwähnten Themenbereiche.

Ach, und das mit dem Notizblock? Ich fände es gut, wenn du dir während der Teile dieser Serie Notizen machen würdest, um später darauf zurückkommen zu können. Dazu stelle ich immer wieder kurze Fragen und ich stelle spezielle Download-Links mit vorgedruckten Notizblockseiten zur Verfügung. Auf diesen Notizblockseiten gibt es auch immer wieder Informationen zum aktuellen Teil und genügend Platz für allgemeine Notizen. Also, am besten gleich herunterladen, doppelseitig ausdrucken und ausfüllen...

Heute habe ich dir einen Überblick über die nächsten Themen in diesem Kapitel gegeben. Im nächsten Teil, "Ziele der agilen Entwicklung", geht es dann darum, was wir eigentlich durch Agilität erreichen wollen, und wie agiles Engineering dabei helfen kann.

Zum Schluss schreibe bitte noch die Antworten auf die folgenden Fragen in deine Notizen:

• Wie gut funktioniert agile Softwareentwicklung in deinem Team?
• Was möchtest du dir aus diesem Teil merken?
• Welche neuen Fragen sind durch diesen Teil aufgekommen?

Weitere Informationen

• DevTeams.at - Consulting, Coaching und Training - David Tanzer
• Das Agile Manifest

Kapitelinhalt: