Gute Developer Skills steigern die Produktivität

Was zeichnet gute Scrum-Teams aus (Teil 2)
Kommentare

Was muss ein agiles Team können? Zuverlässig und effektiv liefern
Zuverlässig liefern fängt mit der Aufwandsschätzung für die Entwicklung an. Softwaresysteme sind Unikate und daher ist jede Schätzung

Was muss ein agiles Team können? Zuverlässig und effektiv liefern

Zuverlässig liefern fängt mit der Aufwandsschätzung für die Entwicklung an. Softwaresysteme sind Unikate und daher ist jede Schätzung mit einem Unsicherheitsfaktor behaftet. Um so wichtiger ist es, diese Schätzung regelmäßig zu überprüfen, anzupassen und damit das Projekt steuerbar zu machen. Daraus folgt, dass man möglichst früh Feedback einholen muss: man muss die Leute fragen, die sich auskennen – das Realisierungsteam.

In der agilen Softwareentwicklung, hier soll dies spezifisch für Scrum erläutert werden, wird dies dadurch erreicht, dass ausschließlich das Team dafür zuständig ist, die Menge der umsetzbaren Features zu schätzen. Das beinhaltet, die Anforderungen zu verstehen, das heißt, das Interesse und Verständnis für das zu erstellende Gesamtprodukt zu haben und zu erarbeiten. Eine Vorstellung von der Lösung und den dafür notwendigen Aufwänden zu erarbeiten. Eine gemeinsame Vorgehensweise zu verfolgen, sodass das erstellte Produkt-Inkrement in sich konsistent ist und zusammenpasst sowie ein Commitment als Team abzugeben, dieses geplante Inkrement auch lauffähig zu machen.

Dies erfordert Einsichten, Fähigkeiten und Motivation sowohl von den individuellen Teammitgliedern als auch von dem Team als Ganzem. In Scrum wird dies zu Beginn jeder Iteration (Sprint) praktiziert und am Ende des Sprints wird das Erreichte als lauffähige Software präsentiert.

Änderungen aufnehmen

In Scrum haben die Sprints eine feste Länge, die so festgelegt wird, dass man die Anforderungen über einen Sprint stabil halten kann. Das sind in der Regel zwischen zwei und vier Wochen und soll eine effektive Arbeit ermöglichen. Das heißt allerdings im Umkehrschluss, dass zu Beginn der nächsten Sprint-Planung neue Anforderungen oder Änderungen an schon realisierter Software auftreten können.

Die Implikationen von Änderungen müssen verstanden werden. Das ist zwingend eine Aufgabe des gesamten Teams, denn ein zeitnaher Überblick über alle Teile des Realisierungsstands ist von einer oder wenigen Personen nicht zu leisten. Das heißt auch, dass alle notwendigen Rollen und Fähigkeiten im Team vertreten sein müssen, damit dieser Austausch reibungslos funktionieren kann. Insbesondere hat sich immer wieder gezeigt, dass auch Tester und Architekten zwingend Teil des Teams sein müssen. Das führt auch dazu, dass die Teammitglieder in den verschiedenen Rollen ständig voneinander lernen, sodass agile Hochleistungsteams in der Regel eine wesentlich weniger starre Arbeitsteilung haben als dies in einer herkömmlichen Organisation üblich ist.

Durch die Möglichkeit, im laufenden Projekt geänderte Anforderungen aufzunehmen, kann der Vorbereitungsaufwand für ein Projekt erheblich verringert werden. Im Normalfall verkürzen sich die Projektlaufzeit und damit die Zeit bis zur Auslieferung erheblich.

Probleme erkennen und zurückmelden

Mit den beschriebenen Regeln haben wir auch eine gute Voraussetzung, damit Probleme in den Anforderungen frühzeitig erkannt und kommuniziert werden. Das hilft sicherzustellen, dass die Entwickler nicht nur Software gut entwickeln, sondern auch viele Probleme im Zusammenspiel von Features und in der Konsistenz des Produkts erkennen und weitergeben können. In Scrum gibt es dafür zwei spezialisierte Meetings am Ende eines Sprints:

  • Im Review präsentiert das Team das erreichte Softwareinkrement. Das erfordert, dass man sich auf einen gemeinsamen Stand bringt und diesen konsistent darstellen kann.
  • In der Retrospektive werden Möglichkeiten zur weiteren Verbesserungen identifiziert und für den weiteren Projektverlauf eingeplant.

In vielen Fällen kann ein Kunde oder Product Owner technische Details nicht in der Tiefe beurteilen und ist daher darauf angewiesen, eine zeitnahe und transparente Information über technische Risiken vom Team zu bekommen.

Fertige Software liefern

Wir haben jetzt viel über das Team, seine Struktur und die Zusammenarbeit diskutiert. Das wichtigste Element dabei ist das erzielte Ergebnis, d. h. die Menge und die Qualität der erstellten Software. Diese Software muss unter den Rahmenbedingungen einer sich ändernden Landschaft funktional bleiben und weiter wachsen:

  • Die fertiggestellte Software muss über eine ausreichende Menge automatisierter Tests verfügen. Es ist völlig utopisch, veränderte Software im Projektverlauf immer wieder manuell zu testen.
  • Die Software muss änderbar bleiben. Dies klingt zunächst wie eine zwar unbestreitbare Forderung, aber auch wie ein frommer Wunsch. Dazu gibt es aber inzwischen einen breiten Erfahrungsschatz und einiges an Theorie. Der Stand der Kunst heute ist Test-first-Entwicklung bzw. testgetriebene Entwicklung (Test-driven Development, TDD). Das ist eine sehr disziplinierte Art der Entwicklung, die einen hohen Grad an Qualität und Änderbarkeit hervorbringt.

In Scrum hat man zur Sicherstellung dieser Qualität einfache Konzepte zur Übergabe und Abnahme etabliert. Das Team erhält klar definierte Aufgaben und liefert ein definiertes, abnehmbares Ergebnis:

  • Definition of Ready (DoR): kooperative Ausarbeitung der Aufgaben, frühes Feedback über Lücken und technische Probleme bei der Umsetzung. Bedingung: der Product Owner nimmt sich die Zeit, die Aufgaben mit dem Team detailliert zu diskutieren. Nutzen: keine verschwendete Arbeitszeit durch missverstandene Vorgaben und damit nutzlose Software.
  • Definition of Done (DoD): Am Ende jeden Sprints wird ein fertiges Inkrement von Software geliefert. Fertig heißt dabei getestet – möglichst mit automatisierten Regressionstests und möglichst weit integriert. Je weiter das gelingt, umso weniger offene Probleme und damit Risiken verbleiben in der Entwicklung.
Ständige Weiterentwicklung

Eine Schlüsselrolle bildet dabei auch die ständige Verbesserung der Fähigkeiten und des Handwerkszeugs des Teams. Ein wesentliches Element ist das regelmäßige Lernen in Retrospektiven. Oft sind in Organisationen schon solche Meetings als Lessons Learned eingeführt, allerdings oft nur am Ende von Projekten oder Produktentwicklungen. Die größte Wirkung entfalten diese allerdings, wenn sie häufig und zeitnah in die Arbeit eingebunden sind und wenn die Ergebnisse direkt nutzbar gemacht werden können.

Ein noch intensiveres Mittel ist als Pair Programming bekannt geworden. Dabei teilen sich zwei Entwickler zeitweise einen Bildschirm. Einer nimmt die Position an der Tastatur ein, während der andere als eine Art Pilot arbeitet, die Aktionen kommentiert und Ratschläge gibt – oder auch parallel Informationen nachschlägt; in regelmäßigen Abständen werden diese Rollen vertauscht. Es ist als Mittel zur Verbreitung von Kenntnissen und Fähigkeiten im Team fast unschlagbar.

Was sollte ein Entwickler können

Was sind nun die konkreten Fähigkeiten, Kompetenzen und Rahmenbedingungen, mit denen das Team ausgestattet werden muss?:

  1. Technische Skills
  2. Team-Skills zur Übernahme von Verantwortung, Überblick über – und Interesse für – die Hintergründe und Geschäftsgrundlagen der Aufgabenstellung
  3. Teamkompetenzen: Selbstorganisation im Rahmen ihrer Aufgaben

In den letzten Jahren hat sich ein Verständnis herausgebildet, wie man verlässlich gute Projekterfolge erzielen kann. Dazu sind verschiedene Elemente nötig:

  • Eine klare, belastbare Formulierung der Anforderungen einschließlich detaillierter Abnahmekriterien
  • Teams, die die Umsetzung ihrer Aufgaben selbständig organisieren
  • Ein Rahmen, der Motivation und ständige Verbesserung erlaubt und ermutigt
  • Ein Kanon von technischen Skills, die es erlauben, hochwertige, änderbare Software zu erstellen
  • Eine Vertrauenskultur im Unternehmen, durch die auch das Lernen durch Fehler ermöglicht wird
Arbeiten im selbstorganisierten Team

In der agilen Praxis steht das Team im Mittelpunkt der Realisierungsarbeit. Durch die kooperative Organisation der Arbeit ist die Bandbreite und die Effektivität der Kommunikation im Team ein wichtiger Faktor. Man kann fast sagen sie bestimmt die Entwicklungsgeschwindigkeit. Das kann man nicht von außen steuern, deshalb ist Selbstorganisation des Teams eine der zentralen Voraussetzungen für eine effektive und verlässliche Projektarbeit, ist die Fähigkeit zur Teamarbeit unerlässlich.

Teamstruktur: Alle Kompetenzen, die zur Realisierung nötig sind, gehören in das Team. Das betrifft insbesondere die Tester, die intensiv und täglich mit den Entwicklern zusammenarbeiten müssen. Das ermöglicht eine hohe Bandbreite beim Informationsaustausch und beim gegenseitigen Lernen. Das betrifft – wenn irgend möglich – auch andere Spezialisten, die zumindest für einige Sprints im Team mitarbeiten sollen wie Architekten, UI-Spezialisten und andere. Nicht vergessen: Latenzzeiten durch Kommunikation über Teamgrenzen hinweg stören enorm eine produktive Arbeit.

Vertrauenskultur: Notwendig ist auch eine Vertrauenskultur – Selbstorganisation muss wachsen und auch einen verlässlichen Rahmen/Freiraum haben, sonst entsteht sie nicht und stabilisiert sich nicht.

Scrum-Teams haben es schwer, erfolgreich zu sein, wenn sie keine agilen Engineering-Techniken beherrschen. Aus dieser Erfahrung ist eine Strömung zu einer Konsolidierung entstanden, in der Scrum-Entwickler neben Teamfähigkeiten eine Ausbildung in den grundlegenden Techniken erhalten sollten.

Der Certified Scrum Developer

Die Scrum Alliance hat darauf aufbauend einen Katalog von „Agile Engineering Skills“ veröffentlicht, der den derzeitigen Konsens über gutes Software-Engineering in einem agilen Kontext zusammenfasst und die Gelegenheit bietet, eine Zertifizierung für diese Kenntnisse zu erwerben. Diese technischen Praktiken umfassen:

  • Automatisierte Tests und testgetriebene Entwicklung: Jeder Schritt der Entwicklung sollte sofort durch Tests abgesichert werden und wenn möglich durch einen vorher geschriebenen Test motiviert werden. Die Tests erlangen dadurch die Funktion einer ausführbaren Spezifikation.
  • Kontinuierliche Integration: Die Entwickler sollten ihre Arbeit mehrmals täglich in das gemeinsame Code-Repository einchecken und die Suite der automatisierten Rests sollte kontinuierlich fehlerfrei ablaufen.
  • Refactoring und das kontinuierliche Beseitigen und Vermeiden technischer Schulden in der Software. In jedem Entwicklungsschritt werden die schon bestehenden Codebestandteile auf Redundanz und Schwächen überprüft und ggf. konsolidiert. Diese kontinuierliche Tätigkeit vermeidet viel höhere Risiken und Aufwände, die entstehen, wenn die Software später schlecht änderbar wird und nicht mehr adäquat an neue Anforderungen angepasst werden kann.
  • Das Verständnis für emergente Architektur, d.h. das Fithalten der Software für Anpassungen und Erweiterungen. Mit diesen Techniken können wesentlich tiefgreifendere Änderungen in der Architektur mit vergleichbar geringem Aufwand eingebracht werden. Damit ist es machbar, mit viel weniger Vorarbeiten und Festlegungen mit der Realisierung zu starten und Feedback von Anwendern einzuholen.
  • Pair Programming zum schnellen Verbreiten von Know-how im Team und zur Vermeidung von Wissensmonopolen einzelner Teammitglieder. Das vermeidet das große Risiko, wenn zentrale Teile eines Softwaresystems nur von einem Teammitglied betreut werden.

Diese Praktiken und Skills ergänzen das Projektmanagement-Framework von Scrum um mächtige Techniken. Sie sichern ab, dass nicht nur der Prozesseffektiv gestaltet ist, sondern dass auch eine hohe handwerkliche Qualität der Software gewährleistet wird.

Das Feedback über den Projektfortschritt kann möglichst aussagekräftig gestaltet werden, wenn der Stand durch eine vollständige Suite lauffähiger Tests abgesichert ist. Das Ansammeln von „technischen Schulden“, d.h. das Vor-sich-herschieben ungelöster Probleme und ungetesteter Softwareteile wird dadurch vermieden.

Die Qualifikation des Certified Scrum Developer, wie sie in Deutschland von den agilen Coaches bei ScrumCenter.com angeboten wird, umfasst ein mindestens fünftägiges Training, in denen die Grundlagen und Regeln von Scrum und diese technischen Fertigkeiten im Zusammenhang und in Teamarbeit vermittelt, eingeübt und überprüft werden.

Schluss

Mit den hier beschriebenen Rahmenbedingungen und Skills kann man eine nachhaltige Verbesserung sowohl des Prozesses als auch der handwerklichen Softwarequalität erzielen. Allerdings ist es manchmal eine hohe Hürde, dass man viele altvertraute Gewohnheiten ändern und Rollen anders verteilen muss. In vielen Firmen bedeutet das einen tiefgreifenden Eingriff in die Strukturen. Für viele Manager löst das auch ein Nachdenken über ihre zukünftige Rolle aus, wenn die Teams einen Teil der Planung und Steuerung selbstständig übernehmen. Manche werden es aber sicher als Befreiung erleben, in einem vertrauensvollen Verhältnis mit dem Team arbeiten zu können, und statt Routine-Steuerungsaufgaben, Wissen und Ideen zwischen Teams zu vermitteln. Sie haben Raum dafür, strategischere Planung durchzuführen und ihre eigentlichen Aufgaben als Manager wahrzunehmen.

Christoph Mathis ist zertifizierter Scrum-Trainer und -Coach bei ScrumCenter.com und begleitet und treibt die umfassende Einführung von Scrum als Teil eines Change-Prozesses. Er hat langjährige Erfahrung sowohl als Teammitglied als auch in der Leitung von Softwareprojekten und er konnte Erfahrungen bei Scrum-Einführungen in Großunternehmen sammeln, bei der viele „angrenzende“ betroffene Gebiete von agilen Engineering-Themen über Organisationsstrukturen bis hin zu Konsequenzen auf die Personalentwicklung ebenfalls betrachtet wurden.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -