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, 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
  • 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
• 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

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

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

Letzte Änderung: 2024-07-04