Agile Software- und Produktentwicklung

Kürzere Entwicklungszyklen, iteratives Vorgehen und Risikominimierung

Agil will heutzutage fast jede Firma sein, der Einstieg in diese Art der Software- beziehungsweise Produktentwicklung ist leider nicht immer ganz trivial. Wichtig ist neben einer gemeinsamen Basis mit dem „Manifesto for Agile Development“ was Agil in der Software- und Produktentwicklung eigentlich wirklich bedeutet. Eines der wichtigsten Themen hierbei ist die Kommunikation, Schwerpunkte sind Meetings, Rollen, Visualisierungen, Wissenstransfer, Dokumentation und gemeinsames Verständnis.

Dieses wird benötigt, um eine transparente und dem Kundenwunsch entsprechende Planung und Schätzung der Anforderungen zu erreichen, anhand derer dann die konkrete Architektur gestaltet werden kann. Wobei hier darauf zu achten ist, flexiblen und nachhaltigen Code zu schreiben, welcher sich den Gegebenheiten anpassen kann und kontinuierlichen Tests unterzogen ist. Die richtige Vorgehensweise bei größeren Änderungen ist genauso wichtig, um die Performance der Teams weiterhin gewährleisten zu können und um negativer Stimmung vorzubeugen, welche durchaus auch zu einem Scheitern einer Änderung führen können.

Neben einem notwendigen Changemanagement geht es auch um die Abwägung der Kosten und Nutzen der Agilen Software- und Produktentwicklung. Agile Methoden sparen Zeit und Nerven und schaffen Flexibilität, haben aber auch die Gefahr, alles mögliche zu „agilisieren“. Es ist unbequem, sich von alten Gewohnheiten zu trennen und neue Wege zu gehen. Nicht überall ist das jedoch wirklich notwendig. Mit den richtigen Rückkopplungsprozesse und zyklischen (iteratives) Vorgehen kann minimalinvasiv getestet werden, was aus dem Agilen Baukasten im Team bzw. Projekt wirklich etwas bringt.

Agilisierung

Die agile Produktvision
Schwergewichtige Prozesse bringen alles in Stocken, was hilft?: Bewährte Wertesysteme und Prinzipien für leichtgewichtige Prozesse und effizienzsteigernde Methoden („Agiles Manifest“)
Operationalisierung von Effizienz und Effektivität in der Softwareentwicklung mit den Mitteln wie „Lean Canvas“, „Running Lean“ - Fokussierung auf Kundenmehrwert und Schlüsselaktivitäten / Schlüsselressourcen
Was im Team passieren muss, damit es wirklich intrinsisch motiviert agil wird bzw. zu Veränderungen kommt (Change Management für das Team, Prozesse und die Team-/Unternehmenskultur, agiles Mindset und Willen)
- Die Entwicklung ist gefühlt zu ineffizient: Fühlen ist kein Messen. Methodiken zur Aufdeckung der eigentlichen Probleme, z. B. durch die Visualisierung des Arbeitsflusses, Over-Engineering von Builds mit Team Foundation Server / Jira & Co.
- Wann Scrum, Kanban & Konsorten sinnvoll sind und wann nicht – Agile Konzepte kurz zusammengefasst
- Die Werte von Agilität bei Scrum (Focus, Openness, Commitment, Respect), Kanban (Wirtschaftlich zu denken, Kontinuierliche Verbesserung statt „nur Arbeiten“, über den Tellerrand schauen) & Co.
- Allgemeingültige Praktiken, die minimalinvasiv zur individuellen Verbesserung im Team bzw. Unternehmen getestet werden könnten, etwa den Mitteln aus Kanban: Kanban-Board zur Visualisierung von Aufgaben, Umstellung auf Durchfluss statt Iterationen
Anti-Pattern und Übertreibungen – wie Agilität zu Problemen und Stillstand führt (richtig dokumentieren auf den Kontext bezogen statt alles dokumentieren)
Die Kosten, Nutzen und Folgen von Agilisierung
- Positive/negative Erfahrungen aus abgeschlossenen Aufgabenstellungen werden zu Verhalten als Folge von Haltung zu etwas (Agilität) – Situationen und Problemstellungen lassen sich besser (ein-)schätzen
- Das Fehlen von Wissen der agilen Software-/Produktentwicklung und zu viel Freiraum als Hauptgefahr von Agilität – Üben, üben, üben
- Weniger Fehl- und Blindleistung
- Risikomanagement von komplexen Situationen
- Regelmäßige iterative Fertigstellung kleiner Inkremente kann die Time to Market von Produkten
- Nutzensteigerung als Folge der Vermeidung negativen Geschäftswerts

Schätzen und Planen

Wert des Produktes (Value Proposition)
Verantwortungsvoller Umgang mit Anforderungsänderungen (Change Management für das Produkt)
Anforderungen erfassen und gestalten (Story Mapping & Co.)
Was gut von schlecht bei Spezifikationen und Aufgabenbeschreibungen unterscheidet – Definition of Done und Definition of Ready
Wie (Domänen-)Wissen am besten vom Kunden zum Entwickler bzw. Team und umgedreht transferiert wird
Reden alle vom gleichen? Validierung mit einfachen Tests – Methoden für Prototyping
Priorisierung und Bewertung der erfassten Anforderungen mit den Mitteln vom Gamestorming (100 Dollar Test & Co., Produktbox-Design)
Unterschied zwischen funktionalen und nicht-funktionalen Anforderungen und deren Impact auf die Produktentwicklung

Umsetzung und Praktiken

Was eine agile Architektur ist und wie sie entsteht bzw. sich im laufenden Projekt verändert
- Refactoring als Folge agiler Entwicklung
- Explorationsphasen vs. Produktvision
- Flache vs. Steile Aufwandskurven
- Klassisches Vorgehen (Schicht 1..n) vs. Inkrementelles Vorgehen (Version 1..n)
- Kleinteiligkeit und Austauschbarkeit von Softwarefragmenten im agilen Kontext um Kosten für Reimplementierungen, Problembehebungen und Einarbeitungen neuer Mitarbeiter besser im Griff zu haben („technische Schuld“)
Wieso der Kontext bei der Architektur trotz und gerade bei „Lean“ (schlank auf den Prozess) nicht aus den Augen verloren werden darf
Integration von Änderungen
ALM
Code-Reviews
Was eine agile Architektur ist und wie sie entsteht bzw. sich im laufenden Projekt verändert

Kommunikation

Was sinnvolle Rollen, Verantwortlichkeiten, Reportings, Visualisierungen und Mittel zur Synchronisation für agile Software- / Produktentwicklung sind
Projektleiter vs. Product Owner – wie sich diese Rollen unterscheiden, häufig überschneiden und ihre Wichtigkeit im agilen Umfeld je nach der Vorgehensweise (Scrum, Kanban etc.)
Agilität im verteilten Team
Kommunikation im Team, insbesondere zwischen verschiedenen Rollen wie Produkt Owner vs. Entwickler(-Team) oder Kunde und Produkt Owner, Tester und Entwickler usw. – mit Mitteln wie Spezifikation durch Beispiele
Welche Meetings überflüssig sind, welche Meetings brauch man, wie Meetings effizient gestaltet werden (etwa Meeting-Typen wie Retrospektive, Daily Standup, Kick-off, Quartalsmeetings und deren Sinn, Nutzen und Variationen)

Nach oben