Gute Developer Skills steigern die Produktivität

Was zeichnet gute Scrum-Teams aus
Kommentare

Projekte werden durch ihre Mitarbeiter erfolgreich. Ein erfolgreiches Team steht hinter seinem Produkt, arbeitet nach gemeinsamen Regeln und versteht vor allem sein Handwerk.

Schon lange sucht man nach dem Patentrezept für das ideale Team, das verlässlich, korrekt und effektiv Anforderungen in laufende Software übersetzt. Schafft man das besser durch einen optimalen Prozess, durch eine herausragende Projektleitung, durch die Auswahl von Spitzenprogrammierern oder eine Kombination von allem? Es scheint, dass das Ziel immer wieder entgleitet, auch wenn man viel Aufwand und Know-how in die Planung investiert. Mehr Prozess und mehr Planung bewirken nur manchmal das gewünschte. Dann wieder wird ein Projekt nur deshalb zum Erfolg, weil man die Regeln missachtet und Abkürzungen und andere Maßnahmen einsetzt, die nach dem vorgeschriebenen Prozess eigentlich strikt verboten sind. Es scheint, dass es immer wieder auf die Mitarbeiter hinausläuft und dass man zu kurz greift, wenn man nur die Projektleitung optimiert.

Erfolgreiche Projekte brauchen agiles Vorgehen

Softwareentwicklung ist in der übergroßen Mehrzahl der Fälle nicht vollständig planbar. Das haben viele kostspielige Erfahrungen in den letzten Jahren gezeigt. Als Folgerung daraus muss man sich auf neue Erkenntnisse und Änderungen in den Anforderungen einstellen und diese im Prozess, in der Planung und bei der Qualifikation der beteiligten Mitarbeiter berücksichtigen. Die agilen Entwicklungsmethoden bauen auf diesen Erkenntnissen auf und haben in den letzten Jahren eine steile Karriere von einer exotischen Idee zum Mainstream zurückgelegt. Sie unterstützen eine Herstellungsmethode von Software, die sich auf laufende Änderungen in den Anforderungen und in der Umgebung einstellt. Dabei haben sich zwei Hauptströmungen besonders verbreitet: Scrum als ein Projektmanagement-Framework und Extreme Programming (XP) mit dem Schwerpunkt auf Programmierpraktiken. Diese beiden Methoden ergänzen sich nahtlos, viele erfolgreiche Teams haben beide miteinander kombiniert.

Wenn man also ein erfolgreiches agiles Team definieren könnte, so müsste dieses Team zuverlässig und effektiv liefern, d. h. Anforderungen in Software umzusetzen. Änderungen in den Anforderungen zu jeder Zeit im Projektverlauf aufnehmen, ohne dass die Qualität der Software leidet, Probleme in der Aufgabenstellung und bei der Realisierung frühzeitig erkennen und Feedback geben. Die Software in einem fertigen Zustand liefern, sodass der Fertigstellungsgrad des Produkts jederzeit feststellbar ist, sowie sich und die Fähigkeiten seiner Mitglieder ständig weiterentwickeln, sodass sie ihre Leistungsfähigkeit ständig hoch halten bzw. ausbauen.

Scrum und die agilen Softwaretechniken

Scrum beruht auf wenigen einfachen Regeln:

  • Feste Iterationslängen (Sprints)
  • Vorgaben der Prioritäten durch den Product Owner und eine disziplinierte Einhaltung der vorgegebenen Businessprioritäten
  • Commitment für eine Aufgabenmenge pro Sprint ausschließlich durch das Team
  • Regelmäßiges Feedback durch Reviews der Ergebnisse am Ende jeden Sprints
  • Retrospektiven, d.h. die Identifikation von Verbesserungspotenzial ebenfalls nach jedem Sprint und das Einbringen in das laufende Projekt

Mit der Einhaltung dieser Regeln allein kann man die Produktivität in jedem Projekt verbessern. Schätzungen werden genauer und parallel immer wieder angepasst. Das laufende Projekt kann kontinuierlich gesteuert werden und beruht nicht ausschließlich auf der initialen Planung, ist also nicht mehr ein „Blindflug“ nach dem Start der Implementierung.

Viele Teams haben diesen Verbesserungsprozess genutzt, um auch ihre technischen Skills und Praktiken zu verbessern. Trotzdem hat sich bei Scrum hartnäckig das Problem gehalten, dass manche Teams jetzt zuverlässig mittelmäßige Software produzieren. Das führte zu einer emotionalen Diskussion in der agilen Community, die unter der Überschrift „Flaccid Scrum“, d. h. schlappes Scrum, lief. Daraus hat sich ein Konsens herausgebildet, dass es nötig ist, eine Ausbildung anzubieten, die die erforderlichen Engineering Skills vermittelt.

Was ist Scrum

Scrum ist im Kern ein minimalistisches Framework zum Projektmanagement, das dabei hilft, ein selbstorganisiertes Team effektiv arbeiten zu lassen und dabei optimal in die Organisation einzubetten. Es gibt bei Scrum drei Rollen:

  • Product Owner
  • Scrum Master
  • Teammitglied

Scrum kennt minimal drei Artefakte:

  • Der Product Backlog
  • Der Sprint Backlog
  • Der Burn-down Chart

Und mindestens vier Meetingtypen:

  • Sprint Planning
  • Sprint Report
  • Daily Scrum
  • Retrospektive

Der Product Owner ist für die Erstellung und Pflege einer priorisierten Liste offener Features verantwortlich. Das ist der Product Backlog, eine vollständige dynamische Todo-Liste für das Projekt. Vor jedem Sprint entscheidet das Team in einem Sprint-Planning-Meeting, wie viele der am höchsten priorisierten Features es im Sprint liefern kann. Das Team bestimmt, welche Tasks dazu nötig sind und schreibt sie in das Sprint Backlog.

Während des Sprints synchronisiert sich das Team in einem Daily-Scrum-Meeting und verfolgt den Fortschritt im Burn-down Chart. Der Scrum Master coacht das Team, beseitigt Hindernisse und stellt sicher, dass das Team effektiv arbeiten kann. Während des Sprints wird werthaltige Funktionalität entwickelt und ein „potentially shippable Product Increment“ erstellt, das vom Team während des Sprint-Review-Meetings präsentiert wird. Nach dem Sprint erarbeitet das Scrum-Team in einer Retrospektive, welche Potenziale für die Verbesserung der Arbeit bestehen. Eine Änderung der Aufgaben erfolgt nur zu Beginn eines Sprints.

Scrum in der Praxis

In der Praxis haben sich eine Reihe weiterer Praktiken als hilfreich erwiesen und werden in der Mehrzahl der Projekte mit dem Kernframework zusammen eingesetzt. Diese Kombination bildet dann die konkrete Implementierung von Scrum im Projekt bzw. in der Firma:

  • User Stories
  • Agile Engineering-Praktiken, wie sie im Kasten „Grundlagen eXtreme Programming (XP)“ beschrieben sind
  • Kombination der Scrum-Master-Ausbildung mit Soft Skills zur effektiven Moderation von Teams
Grundlagen eXtreme Programming (XP)

XP wurde um das Jahr 2000 herum als erste agile Methode einer breiteren Öffentlichkeit bekannt. Man kann XP als eine Sammlung von Aktivitäten und Praktiken beschreiben. Dazu beruht XP auf klar definierten Werten. Die Praktiken in XP hängen relativ lose zusammen. Wir beschreiben sie hier nach Themengebieten.

Entwicklungsaktivitäten

Pair Programming: Entwickler arbeiten in Paaren und diskutieren beim Entwickeln Lösungsmöglichkeiten und Alternativen. Einer übernimmt die Rolle des „Piloten“ an der Tastatur, der andere agiert als „Copilot“ und beobachtet, kommentiert, recherchiert etc. In kurzen Abständen werden die Rollen vertauscht und mehrmals am Tag wechseln die Entwickler die Partner. Der Effekt ist ein äußerst schneller Informationsaustausch im Team.

Test first: Testfälle werden vor dem Implementierungscode geschrieben und dienen als Konkretisierung der Anforderungen. Danach wird die minimale Implementierung geschrieben, mit der der Test gutgeht. Danach folgt ein Refactoring-Schritt und der Zyklus beginnt wieder.

Refactoring ist eine Gruppe von kleinen Transformationsschritten, mit denen der Code vereinfacht, konsolidiert und verbessert wird. Beim Refactoring sollte das Verhalten des Programms nicht verändert werden, alle Tests sollten jederzeit laufen. Es gibt einen umfassenden Katalog von solchen Refactoring-Patterns.

Keep it simple – Halte es einfach: Man schreibt „the simplest solution that can possibly work“, die einfachstmögliche Lösung – das vermeidet auch Verschwendung, d.h. Code, der niemals genutzt wird.

Kontinuerliche Integration verlangt von jedem Entwickler, in kurzen Zyklen seinen Code im Versionsverwaltungssystem einzuchecken (mindestens täglich). Ein automatischer Lauf compiliert den gesamten Code und lässt alle automatischen Tests laufen. Wenn ein Fehler auftritt, wird die Arbeit des Teams sofort unterbrochen und der Fehler behoben.

Team Activities

Kurze Iterationen: Die Entwicklung wird in Iterationen von ein bis drei Wochen betrieben. Am Ende jeder Iteration steht getestete, integrierte Funktionalität.

Co-Location: Das Team arbeitet in einem Raum oder aneinander angrenzenden Räumen. Das ermöglicht direkte und visuelle Kommunikation, z. B mit Taskboard und Flipcharts.

Tägliches Stand-up-Meeting: Das Team trifft sich täglich zu einem kurzen Meeting im Stehen. Jedes Teammitglied sagt, was es erreicht hat und was es als Nächstes plant. Probleme werden genannt, aber nicht im Meeting gelöst.

Retrospektiven: Nach einer Iteration und wichtigen Meilensteinen bespricht das Team die Arbeit und Verbesserungspotenzial.

Kundenpraktiken

Häufige Releases: Der Kunde bekommt neue Versionen im Takt von ein bis drei Monaten und gibt dem Team Feedback.

Automatisierte Akzeptanztests: Kunden spezifizieren funktionale Akzeptanztests. Oft hilft das Team mit spezialisierten Testrahmen. Die Tests müssen zu Ende jeder Iteration laufen.

Requirements durch Konversation: Der Kunde ist während des Projekts für Antworten und Klarstellungen verfügbar.

Planung der Iteration: Eine Iteration startet mit einem Planungsmeeting. Der Kunde präsentiert die priorisierten User Stories und erklärt sie dem Team. Das Team identifiziert die Tasks zur Umsetzung und schätzt den Aufwand. Das erfolgt für eine Story nach der anderen, bis die Kapazität für die Iteration ausgefüllt ist. Typischerweise plant man dieselbe Menge von Stories, die in der vorigen Iteration umgesetzt wurde („Yesterday’s Weather“).

User Stories: Der Kunde schreibt Anforderungen in der Form von einfachen Geschichten auf Karteikarten, meist in der Form „Als ein will ich , damit „. Eine User Story muss nur so viele Informationen enthalten, dass es zum Einstieg in eine Diskussion ausreicht.

Managementpraktiken

Angenommene Verantwortung: Verantwortung kann nur übernommen, niemals vergeben werden. Das bedeutet, dass ausschließlich das Team eine bestimmte Menge von Stories übernehmen kann. Das widerspricht der Praxis in vielen Organisationen trotz der Erfahrung, dass Entwickler unter Zeitdruck kontinuierlich schlechtere Qualität liefern.

Nachhaltige Geschwindigkeit: Entwicklungsprojekte brauchen die Kreativität aller Teammitglieder. Das funktioniert nicht mit erschöpften Entwicklern, wie viele empirische Untersuchungen zeigen. Das Ergebnis ist nicht höhere Produktivität, sondern nur schlechterer Code mit mehr Fehlern.

Prinzipien und Werte

XP beruht den fünf Werten: Kommunikation, Einfachheit, Feedback, Mut und Respekt. Als „Brücke“ zu den Werten, die manchmal sehr abstrakt erscheinen, wurde Prinzipien definiert:

  • Benutze Feedback: Feedback ist unverzichtbar zum Lernen und zur Anpassung an veränderte Bedingungen und eine veränderte Umgebung.
  • Starte einfach (Assume Simplicity): Behandle jedes Problem, als ob die Lösung extrem einfach wäre.
  • Akzeptiere Veränderungen (Embrace Change): Arbeite nicht gegen Veränderungen, sondern akzeptiere sie als Teil der Umgebung, arbeite produktiv in einer sich ändernden Umgebung.

Zusammenfassung: XP hat einen reichhaltigen Katalog von Praktiken. Das macht es leicht, einige davon auszuwählen und anzuwenden. Besonders die technischen Praktiken werden deshalb oft mit Scrum kombiniert.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -