Die Prakitken: Ein Überblick

• 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

Im vorigen Kapitel habe ich verschiedene Aspekte der agilen Softwareentwicklung beleuchtet. Ich habe dabei immer mitbetrachtet, welche Rolle wir, im Engineering, dabei spielen. Im aktuellen Kapitel "Die Praktiken: Ein Überblick" wird es etwas technischer: In sieben Teilen werde ich genauer auf die einzelnen Praktiken und Vorgehensweisen eingehen.

Bevor ich noch näher auf die Inhalte des Kapitels eingehe, mach bitte kurz Pause und notiere die Antworten auf folgende Fragen in deinen Notizen. Dazu lädst du am besten die aktuelle Notizbuchseite herunter und druckst sie doppelseitig aus.

• Welche agilen Engineering-Praktiken fallen dir spontan ein?
• Welche davon hast du bereits selbst ausprobiert?
• Welche fallen dir noch schwer?

Ziele

In einem früheren Teil dieser Serie habe ich gesagt: "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

Alle Praktiken des agilen Engineering verfolgen mindestens einen dieser fünf Punkte. Die Anwendung der Praktiken ermöglicht es uns also, die Ziele der agilen Entwicklung zu erreichen und diese Ziele sind:

1. Sicherstellen, dass für die 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.

Limited Upside und Unlimited Downside

Bevor es zu den einzelnen Praktiken geht, möchte ich noch ein weiteres Konzept einbringen: "Limited Upside und unlimited Downside". Ähnlich wie im früheren Teil der Serie "Jetzt tun vs. der richtige Zeitpunkt" leihen wir uns wieder Begriffe aus dem Finanzwesen aus. Damals waren es Optionen, aus denen in unserer Welt Real Options wurden. Dieses Mal sind es die Begriffe Upside und Downside. Und wie schon damals können wir die Bedeutung nicht 1:1 übertragen, aber die Begriffe können uns inspirieren, über gewisse Situationen und Probleme nachzudenken.

Upside bezeichnet im Finanzwesen die potentielle Wertsteigerung eines Investments, Portfolios oder Marktes. In der Softwareentwicklung können wir uns auch darüber Gedanken machen, welchen Gewinn wir uns für unsere investierte Zeit erwarten, wenn wir zum Beispiel ein neues Feature implementieren, Test-Driven Development ausprobieren oder ein kleines Refactoring starten. Dieser Gewinn können verschiedene positive Veränderungen sein—zum Beispiel gesparte Zeit, besseres Feedback oder höherer Wert der Software.

Downside bezeichnet auf der anderen Seite die negative Veränderung eines Investments, Portfolios oder Marktes. Manche Investments haben unlimited downside, zum Beispiel "Short Selling": Wenn der Preis des zugrundeliegenden Assets steigt, verliert der Short Seller Geld und der Preis kann theoretisch beliebig steigen. In der Softwareentwicklung gibt es auch Dinge, deren negative Auswirkungen potentiell nicht limitiert sind: Wenn ein Teil unseres Codes eine niedrige interne Qualität aufweist, kostet uns das jedes Mal Zeit und Geld, wenn wir an diesem Teil etwas ändern müssen. Und theoretisch gibt es keine Grenze dafür, wie oft wir an diesem Teil etwas ändern müssen.

Kapitelinhalt

In den 7 Teilen dieses Kapitels werde ich die Praktiken vorstellen, um die es dann im Rest der Serie geht. Später werde ich die Praktiken aus verschiedenen Blickwinkeln betrachten und in verschiedenen Kontexten erklären, während wir in diesem Kapitel noch auf einer etwas höhreren Flughöhe bleiben.

Im ersten Teil, "Schnelle Lieferung", spreche ich über Praktiken, die es uns ermöglichen, kleinere Pakete schneller direkt zu den Endbenutzern zu liefern. Diese Praktiken sind:

• Kundeneinbeziehung und Iterationen
• Continuous Integration und Continuous Delivery
• Feature Flags, Toggles, etc...
• Nachhaltiges Arbeiten
• Spike Solutions

Danach, im Teil "Codequalität", geht es um interne und externe Qualität und darüber, wie wir beides kontinuierlich verbessern können. Also, es geht um die Praktiken:

• Einfaches Design
• Agiles Testen
• Refactoring
• Coding Standards

Der dritten Teil, "Gemeinsam lernen und entwickeln", dreht sich um Zusammenarbeit. In der agilen Softwareentwicklung bedeutet das:

• Pair / Ensemble Programming, Kollektives Eigentum
• Einfaches Design
• Agile Architekturarbeit
• Kontinuierliche Verbesserung
• Spike

Und der nächste Teil, "Kommunikation", schließt die Liste der Praktiken ab:

• Specification by Example
• Domain-Driven Design
• DevOps
• Agile Dokumentation
• Gemeinsame Verbesserung

Danach kommen noch zwei Teile zu den Themen "Schätzungen und #NoEstimates" und "Technical Dept"; Mit beiden müssen wir uns im Engineering immer wieder befassen. Und im letzten Teil des Kapitels befasse ich mich damit, wie man Praktiken lernen und üben kann.

Die menschliche Seite

Die oben genannten Praktiken zu erlernen und in einem Team produktiv einzusetzen, erfordert Übung und Zeit. Aber nicht nur das—es kann auch zu neuen Konflikten und Frustrationen kommen.

Every problem is a people problem.

Manche von euch (oder sogar alle) werden es oft schwierig finden, die neuen Praktiken einzusetzen. Stellt sicher, dass sich diese Personen nicht alleine gelassen fühlen. Und dass sie sich sicher genug fühlen, Fragen zu stellen—auch immer wieder.

Die neuen Arten der Zusammenarbeit verändern auch die Teamdynamik und manche Teammitglieder fühlen sich damit vielleicht unwohl. Oder, schlimmer noch, sie nutzen die neue Teamdynamik, um einen persönlichen Vorteil auf Kosten der Anderen zu generieren.

Vielleicht sind manche im Team nicht einverstanden mit der neuen Arbeitsweise und machen nur noch Dienst nach Vorschrift. Oder, schlimmer noch, sie sabotieren aktiv die Bemühungen, agile Praktiken einzuführen.

Ich werde später auch noch detaillierter auf solche Probleme eingehen. Für jetzt ist erst mal wichtig: Die Einführung der agilen Engineering-Praktiken ist für viele Teams eine große Umstellung und kann dementsprechend viel Reibung verursachen. Seid vorsichtig und überprüft immer wieder, ob ihr noch gut zusammenarbeitet. Iteration und Feedback sind auch hier wichtig.

Fazit

In den folgenden Teilen dieses Kapitels werde ich also verschiedene Praktiken erstmalig vorstellen und sie in den Rahmen von Agile Engineering einordnen. Ich spreche darüber, wie man diese Vorgehensweisen lernen und üben kann. Und wir müssen auch über Technical Dept und schlechten Code sprechen—und vor allem über Schätzungen und deren Nutzen und Probleme.

Die erwähnten Praktiken findest du auch in der vorgedruckten Notizbuchseite, die du herunterladen kannst. Such dir zwei bis drei aus, die du hilfreich findest und zwei bis drei, von denen du denkst, dass sie keinen Nutzen haben. Notiere bitte die Gründe dafür.

Weitere Informationen

• Upside: Risk/Reward Definition and Examples
• Downside: Meaning, Examples, Protection Strategies
• Pia Nilsson, Knowing Me, Knowing You - Growing Teams to Continuously Deliver

Kapitelinhalt: