Jutta Eckstein (www.jeckstein.com) berichtet zunächst über die Geschichte der agilen Software Enwicklung, geht aufs agile Manifest ein, schildert das agile Wertesystem und deren Prinzipien.
Wie sieht jetzt aber Software Development in grossen Projekten aus (Gross heisst hier mehr als 12 Members)?
Neben dem allgemeinenen Erläuterungen zum agilen Vorgehen im Allgemeinen habe ich folgende Punkte herausgenommen, die neu für mich sind:
1. Feature-Teams
Wenn mehrere Teams an einem Feature arbeiten, z.B. Datenbank Team, Business Analyst Team und Sofware Developer Team, so ist es wichtig, dass jedes Team einen Teil der Verantwortung für ein Feature übernimmt. Wenn nicht, kommt es leicht zu Situationen, wo ein Team am Ende argumentiert:
"Ja, wir waren ja fertig, aber die anderen nicht, weil ...".
Um das zu vermeiden gibt es pro Feature aus jedem Team einen Verantwortlichen - in der Summe dann das Feature Team.
2. Done-Done
Bei einem Multi-Team Projekt kommt es schnell vor, das ein Team ein Feature auf Done setzt, teamübergreifend das aber nicht der Fall ist. Dafür verwendet man einen neuen Zustand für ein Feature: Done-Done, was soviel bedeutet, wie dass ein Feature vom Feature Team auf Done gesetzt wurde und definitiv done ist.
3. Resourcen-Sharing
Um die Kommunikation zu beschleunigen werden die Resourcen der Teams in einem rotierendem Modus ausgetauscht. Damit sind alle Team Members auch teamübergreifend immer syncronisiert.
4. Communication faciliator
Um sicherzustellen, das alle Informationen fliessen und das gesamte Team fokussiert an den Kundenwünsch arbeitet, sollte ein Chief Architect eingesetzt werden. Er ist zentrale Anlaufstelle für neue Ideen, technische Fragen und für generelle Problemstellungen.
5. Common Development Culture
Es ist wichtig, dass es eine gemeinsame "Entwicklungs-Kultur" gibt. Dazu zählen Code-Guidelines, Code Reviews, extreme Programming, Unit Testing und so weiter. Um das gesamte Team auf dem laufenden zu halten bietet sich eine Projektplattform an, z.B. ein Wiki.
6. Staged Retrospective
Jedes Team macht ein eigenes Review Meeting und bringt die Top 3 Verbesserungsvorschläge bei einem Gesamt-Review-Meeting ein, bei dem von jedem Team nur eine Delegation gesandt anwesend ist.
Ok, hat jemand damit schon Erfahrungen gesammelt? Ich persönlich habe bisher nur in Teams < 8 Mitgliedern gearbeitet.
Keine Kommentare:
Kommentar veröffentlichen