Lessons Learned

Lessons Learned - auf Deutsch "gewonnene Erkenntnisse", Erfahrungen aus der Software-Entwicklung.

Organisation

Scrum

• bei der Einführung von Scrum in einer Organisation können viele Fehler gemacht werden
• nach meiner Erfahrung gibt es aber ein Hauptproblem:
• wenn Manager Scrum nicht verstehen, dann kann man die Einführung von Scrum in einer Organisation vergessen
  • manche Menschen sind der Meinung, dass sich Teams "selbst" zu Scrum-Teams zusammenfinden könnten
  • wenn Mitarbeiter aber Scrum noch nicht kennen oder verstehen, dann kann es passieren, dass keine Scrum-Teams "von selbst" dabei herauskommen
  • wenn es schlecht läuft, hat man Wasserfall-Teams, in denen nur Entwickler oder nur Tester sind und keine cross-funktionalen Teams
  • hier muss ein Manager eingreifen
  • theoretisch könnte ein "Scrum Master" oder "Agile Coach" eingreifen
  • wenn sich jemand aber lediglich als "Scrum Master" bezeichnet und wenig Ahnung hat, dann bleibt nur der Manager
  • Manager sind schließlich auch dafür verantwortlich, ob und wie die Rollen "Scrum Master" und "Product Owner" besetzt werden
• bei misslungener Einführung von Scrum, kann es passieren, dass ein Scherbenhaufen hinterlassen wird
• Mitarbeiter geben dann Scrum die Schuld, anstatt der misslungenen Umsetzung

Feedback

• Manager sollten regelmäßiges Feedback durch Mitarbeiter ermöglichen

Flache Hierarchien

• flache Hierarchien können dazu führen, dass Manager weder zeitlich noch inhaltlich auf Feedback von Mitarbeitern reagieren können
• dadurch berichten Mitarbeiter unter Umständen nicht mehr Probleme, die nur ein Manager lösen kann
• Probleme können über Jahre liegen bleiben und sich aufstauen
• bei flachen Hierarchien kann es zu Verantwortungsdiffusion kommen
• das kann natürlich auch bei klassischen Hierarchien mit unfähigen Vorgesetzten passieren

Standortübergreifende Arbeit

• standortübergreifende Arbeit ist generell problematisch, da die Kommunikation eingeschränkter ist als vor Ort
• Missverständnisse können zu Spannungen im Team führen
• wenn noch eine Sprachbarriere durch länderübergreifende Arbeit dazukommt, wird es noch schwieriger
• wenn eine Einzelperson an einem Standort mit einem Team von einem anderen Standort zusammenarbeitet, kann es langfristig zu Motivationsproblemen führen
• Arbeit hat auch immer eine soziale Komponente
• wenn Arbeit an mehreren Standorten, dann lieber komplett getrennte Teams mit klar definierten Schnittstellen
• wenn trotzdem standortübergreifende Arbeit nötig sein sollte, dann sollten zumindest gelegentliche Teambuilding-Maßnahmen durchgeführt werden

Know-How

• gerade in Software-Projekten ist Knowhow ein entscheidender Faktor für Zeit und Kosten
• Vorgesetzte oder Product Owner sollten darauf achten, dass Knowhow auch dokumentiert wird
• im Idealfall gehört die Know-How-Dokumentation zur Definition of Done einer User Story
• natürlich hat schriftliche Dokumentation auch ihre Grenzen
• deshalb ist Know-How Verteilung im Team wichtig
• entsprechend sollte ein Team z.B. aus 2 Entwicklern und 2 Testern zusammengesetzt sein
• so kann z.B. technisches Know-How innerhalb der Tester oder Anwendungs-Know-How übergreifend zwischen Entwicklern und Testern ausgetauscht werden
• oder z.B. eine erfahrene und eine unerfahrene Person zusammenarbeiten

Abhängigkeiten reduzieren

• es ist wichtig, Abhängigkeiten zwischen Teams zu reduzieren
• klassisches Beispiel: Entwickler einer Testumgebung und Tester, die die Testumgebung benutzen sollen
• ein Tester sollte Zugriff auf den Quellcode der Testumgebung haben und selbst Änderungen vornehmen können
• Testumgebungsentwickler sollten auch selbst Testfälle der Tester ausführen können

Teams

• wie bereits bei den oberen Punkten "Scrum" und "Know-How" geschrieben, sind cross-funktionale Teams mit erfahrenen und unerfahrenen Leuten wichtig
• nur unerfahrene Leute in einem Team sind keine gute Voraussetzung für ein erfolgreiches Projekt
• wenn auch noch der Manager keine Ahnung von Software-Entwicklung hat, wird es sehr schwierig
• damit ist gemeint, dass z.B. grundlegende Schritte im Software-Entwicklung-Prozess nicht eingehalten werden, wie z.B. Unit-Tests, Coverage-Tests, Memory-Leak-Tests, Systemtests, Fehlerbehandlung, ...
• außerdem sollten sowohl Tester als auch Entwickler in einem Team an derselben User-Story arbeiten
• es macht wenig Sinn, wenn Entwickler an einer User-Story arbeiten und Tester an einer anderen User-Story

Software

• Log-Daten immer auf einem zusätzlichen Computer speichern
  • keine zeitkritische Software auf einem Log-Computer laufen lassen
  • ansonsten könnte die Festplatten-Aktivität die zeitkritische Software blockieren
• Mutex (mutual exclusion) unlock führt nicht zu einem Threadwechsel
  • nach Mutex unlock kann lediglich der Mutex wieder gelockt werden
  • es muss kein Threadwechsel stattfinden, der Mutex kann auch vom gleichen Thread wieder gelockt werden
  • dieses Verhalten kann dazu führen, dass immer nur ein Thread aktiv ist und andere Threads, die auf den Mutex warten, blockiert sind
  • bei einigen Betriebssystemen kann man einen Threadwechsel durch den Aufruf von sched_yield() oder usleep(1) erzwingen
• Software-Architektur
  • am Anfang eines Projekts einen Überblick verschaffen
  • etwas mehr Zeit nehmen, um zu schauen, ob man Software wiederverwenden kann
  • bei der Architektur überlegen: wie kann man ein Projekt möglichst effizient umsetzen

Letzte Änderung: 2024-08-24