Ruy Kuhlmann Systemanalyse

Was ist, eigentlich, "Agil"?


"Agil" ist nichts anderes als eine Anzahl an (vielen) verschiedenen Praktiken die eine iterative Entwicklungsvorgehensweise ermöglichen (sollen).

Beispielsweise:

XP: Mehrere sogenannten definierten "Best Practices", ein Prozess soll sich aus diesen entwickeln, die Natur dieses Prozesses ist iterativ und somit 'agil'.

KanBan: beschreibt eine Vorgehensweise, daraus kann (und in Allgemeinen wird) ein Prozess entstehen; verschiedene agilen Praktiken können angewendet werden.

Scrum: Scrum definiert ein Prozess nach mehr oder minder strikten Regeln, diese und mehrere agilen Praktiken können (nicht sollen) übernommen werden; somit entstehen eine große Anzahl an sogenannten "Scrum-But" Teams, die das übernehmen, was bei ihnen zu funktionieren scheint.

Zu den "Best-Practices" gehören mehrere Konzepte die ein (agiles) Bild für die SW-Entwicklung abrunden.
Darunter:
Sprint: eine sogenannte Time-Box (fester Länge), in der designt, entwickelt und getestet werden soll (Iteration).
Pair Programming: Zwei Entwickler sitzen zusammen an einem Rechner; einer entwickelt, der andere überprüft und hilft (denkt mit).
Team Ownership: Jeder im Team darf etwas ändern wenn er meint, dies sei gut.
User Story: Eine Funktionalität aus der Sicht des (End-)Benutzers.

Hieraus ist ersichtlich, dass sich ein agiles Modell durch ein "Prozess der SW-Entwicklung" manifestiert.

Folglich: wenn ich ein agiles Modell (das eigentlich sehr oft nur eine Zusammensetzung von mehreren verschiedenen Best-Practices ist), verbessern will, dann soll ich an diesem (SW-Entwicklungs-) Prozess ansetzen.

Diese Verbesserung bewerkstellige ich mit einer von mir entwickelten analytischen Vorgehensweise, die ich SAvAP ("Strukturierte Analyse von Agilen Prozessen") nenne.


Die "Strukturierte Analyse von Agilen Prozessen"


Das Ziel der strukturierten Analyse ist das agile Prozess zu verbessern, effektiver zu gestalten und voraussagbarer zu machen.

Es ist nun mal so, dass viele "agilen" Projekte mit sehr viel Elan starten, doch nach einiger Zeit ist dieser Anfangsschwung verflogen, die Fortschritte werden geringer und das ist messbar (bisweilen stockt das Projekt sogar!).

Für gewöhnlich "verbessern" sich unsere selbstorganisierten Teams nach dem "Trial-and-Error" Prinzip. Dies ist einerseits ausgesprochen fehlerbehaftet (die "Errors" vom 'Trial-and-Error'!), andererseits führt das selten in einer überschaubaren Zeit zu einem wirklich guten Ergebnis.

Die agilen Methoden gehören zu den (sogenannten) leichten Entwicklungsmethoden, aus diesem Grunde ist das genaue Dosieren der Änderungen überaus wichtig: eine kleine Änderung kann sehr große Auswirkungen haben!

Genau hier setzt SAvAP an: beim Analysieren von den Zusammenhängen bei der Arbeit eines Teams und diese dann so zu optimieren, dass die Arbeit wieder "fließt".
Das ist nicht einfach, bedarf viel Wissen und Arbeit, auch einiges an Fingerspitzengefühl... ist aber möglich.

Es gibt drei Elemente, die ein agiles Prozess wirklich effektiv steuern und somit auch verbessern können:
  1. Die Länge des Sprints
  2. Die Größe des Teams
  3. Anpassung von Frequenz und Inhalt der bekannten Meetings (Daily, Retros, Sprint Planning)

Darüber hinaus gibt es eine ganze Reihe an Parameter und Werte, die man optimieren kann; viele davon sind vom eingesetzten agilen Modell abhängig.
Darunter:

  • Zusammensetzung des Teams
  • Kommunikation zwischen dem Team, denTester und dem Poduct-Owner
  • Uhrzeit von Daylies, Retros und andere Meetings
  • Frequenz von Daylies, Retros und andere Meetings
  • Umfang von Stories und Epics
  • Umfang des Back-Logs
  • Review-Umfang und Testumfang
  • Frequenz von Builds
  • Automatisierungsgrad, darunter auch CI/CD
  • Fehler-Abarbeitung
  • Zeitbedarf der Planungs-Arbeiten
  • Zeitbedarf der Architektur-Aufgaben
  • Zeitbedarf der Design-Arbeiten
  • Zeitbedarf zum Dokumentieren
  • Zeitbedarf zum Programmieren
  • Zeitbedarf zum Testen
  • Zeitbedarf zum "Refactoren"

Hilfe bei der Analyse des agilen Prozesses bekomme ich beim Messen und Auswerten von Werten, unter anderen:

  • Anzahl LOC
  • Anzahl Bugs
  • Messung der Story-Points
  • Anzahl Test-Cases (Anzahl von OK, Fehl geschlagen, nicht durchgeführt, etc)
  • Anzahl Code Reviews
  • Test-Metriken, wie viel des Codes wird durch getestet?
  • Kunden-Zufriedenheit (Bugs vom Kunden, Tickets, Support-Anfragen, etc)
  • Inkrement-Größe
  • Anzahl neue Features
  • Anpassungen von Design
  • Anpassungen von Architektur
  • Anpassungen von Programmierer
  • Anpassungen von Anforderungen
  • Anpassungen von Test-Cases
  • Risiko-Auswertung
  • Anzahl Tests (auch Ratio Manuelle/automatische Tests)

Die "Strukturierte Analyse von Agilen Prozessen" (SAvAP) ist keine esoterische Kunst sondern eine rein analytische Arbeit.

Die Anwendung von SAvAP schreibt folgende Tätigkeiten vor:
  • Einsammeln von Daten
  • Analyse der Daten
  • Erarbeitung von Verbesserungen für die verschiedenen agilen Praktiken
  • Implementierung der Änderungen
  • Nachträgliche Überprüfung (Verifizieren und Validieren)


Wechselwirkung zwischen agilen Methoden und SAvAP


SAvAP ist in keiner Weise ein Ersatz für die agilen Methoden (wie FlePA) oder steht in Wettbewerb mit irgend ein agiles Modell, vielmehr ergänzt SAvAP die agilen Methoden durch analytische Arbeit.

Scrum Masters bringen und halten ein Scrum-Prozess am Laufen; das Ziel der SAvAP ist nicht ein Prozess zu implementieren, sondern diesen durch analytische Kompetenz zu verbessern.

Dadurch ergänzt tatsächlich SAvAP die Arbeit des Scrum Masters (dieser hat eine eher organisatorische und Hinderniss-Behebende Funktion, während SAvAP durch Erhebung von Daten und ihre Analyse zu einer verbesserten, im Idealfall optimalen, Gestaltung der Prozesse beiträgt) und unterstützt ihm dabei dergestalt, dass "Scrum" schlicht und ergreifend besser funktioniert.


Entstehung


Die SAvAP ist aus mehreren Jahren Erfahrung bei der Projektarbeit im agilen Umfeld entstanden (seit dem Jahr 2010 bis Heute bei mehreren Firmen) und mein Grundlagenwissen als Systemanalytiker.


Mein Schwerpunkt liegt bei der Analyse von laufenden KanBan, XP und Scrum -Prozessen.

Struktur - Daten - Analyse - Ergebnis

Strukturiertr Analyse Strukturiertr Analyse Strukturiertr Analyse Strukturiertr Analyse Strukturiertr Analyse Strukturiertr Analyse Strukturiertr Analyse Strukturiertr Analyse Strukturiertr Analyse