Praxistipps für Entwickler beim Einsatz von Scrum

Vom agilen Vorgehensmodell Scrum und seinen Abläufen liest und hört man an allen Ecken, auch in unserem Blog. Schlagwörter wie Sprint-Planning, Review und Retrospektive sind jedem schnell geläufig, der sich ein wenig mit Scrum beschäftigt. Recht schwierig wird es jedoch, wenn der Entwickler selbst nach Möglichkeiten sucht, um Scrum am besten in seinem Team anzuwenden.

Scrum stellt nämlich auch an die Entwicklungsmethoden an sich andere Anforderungen als klassische Vorgehensweisen. Einige Tipps können dem Entwicklungsteam sehr helfen. In diesem Artikel wollen wir Best Practices aus der der Erfahrung mit “Agile” bei //SEIBERT/MEDIA schildern.

Arbeiten an der wichtigsten Anforderung

Scrum an sich verfolgt bereits den Ansatz, dass das Team sich bei der Entwicklung streng an der Priorität der User-Stories orientieren soll. Wie jedoch sieht das dann genau aus? Arbeitet jeder Entwickler an einer Story, Entwickler A an der Story mit der höchsten Priorität, Entwickler B an der Story mit der nächsthohen Priorität usw.?

Nein, so weit irgendwie möglich, sollten alle Entwickler gemeinsam an der wichtigsten Story arbeiten. (Sicherlich muss der Umfang einer Aufgabe berücksichtigt werden, damit diese Vorgehensweise funktionieren kann. Eine Aufgabe, die zu klein ist, lässt sich nicht sinnvoll in Einzelarbeiten aufteilen.)

Das klingt zunächst wohl etwas abenteuerlich, setzt es doch eine ganz andere Arbeitsweise voraus als im klassischen Projekt, in dem jeder Entwickler einen komplett abgetrennten Bereich hat.

Richtig betrieben, sind die Ergebnisse jedoch erstaunlich. Damit das Vorgehen funktioniert, müssen die Entwickler wirklich eng zusammenarbeiten; sie müssen ständig miteinander kommunizieren, da jedes Teammitglied wissen muss, wie der Kollege seinen Teil der Aufgabe angeht und wie später alles zusammenpassen könnte.

Ein Effekt: Die tatsächlich als am wichtigsten definierte Story wird zuerst fertig. Außerdem ist jeder Entwickler darüber im Bilde, wie die Umsetzung erfolgt ist – ohne die Gefahr von Wissenslücken, wenn z.B. ein Programmierer ausfällt.

Auch das Fachwissen lässt sich so sehr gut streuen: Ein Mitarbeiter, der noch nicht viel Erfahrung in einem bestimmten Bereich hat, wird auch einmal dort eine Aufgabe übernehmen müssen. Durch die enge Kopplung mit den Kollegen gelingt die Einarbeitung sehr effektiv und schnell. Im Idealfall sollte jeder Entwickler jede Aufgabe im Team übernehmen können.

Integration

Die Integrationspraxis ist ein wesentlicher Bestandteil der agilen Entwicklung mit Scrum. Integration bedeutet dabei, die Änderungen, die ein Entwickler durchgeführt hat, mit denen der anderen Entwickler im Team zusammenzuführen. Das erfolgt unter Nutzung eines Versionsverwaltungssystems wie SVN oder git.

Bei der Integration ist es sinnvoll, im Team einige Regeln zu verankern, die Klarheit schaffen und Probleme und Konflikte vermeiden. Werden sie nicht beachtet, sind hoher Mehraufwand und doppelte Arbeit kaum zu vermeidende Folgen.

Early Integration
Early Integration ist eine Richtlinie, die den Entwickler dazu anhält, seine Änderungen möglichst frühzeitig mit denen der Kollegen zusammenzuführen. Allerdings tendieren Entwickler dazu, ihre Änderungen erst zu integrieren, wenn ein Großteil der neuen Funktionalität, an der sie gerade arbeiten, fertig ist. Das führt jedoch häufig zu Schwierigkeiten: Je mehr Zeit vergeht, desto umfangreicher sind auch die Änderungen, die die anderen in dieser Zeit durchgeführt haben.

So ist oft zu beobachten, dass Entwickler mehrere Tage lang an einer Funktion arbeiten und beim Versuch, diese schließlich zu integrieren, eine böse Überraschung erleben. In der Regel steigt der Aufwand der Integration mit der Entwicklungszeit erheblich.

Die frühe Integration hat einige zentrale Vorteile:

  • Es ist einfach möglich, sich mit dem Entwickler abzustimmen, der die Änderung durchgeführt hat, die gerade einen Konflikt verursacht.
  • Die eigenen Änderungen stehen anderen Entwicklern zeitnah zur Verfügung.
  • Probleme lassen sich frühzeitig erkennen, bspw. wenn die einzelnen Teile einer Änderung nicht zusammenpassen oder nicht miteinander funktionieren. Auch hierin steckt eine Menge zeitliches Einsparpotenzial, wenn diese Herausforderungen nicht erst nach langer Entwicklungszeit erkannt werden.

Integrations-Token
Ein kleines, aber nützliches Hilfsmittel ist ein Integrations-Token. Das kann ein Stofftier, ein Hut oder ein anderes beliebiges Symbol sein. Wenn ein Entwickler seine Änderungen integrieren will, nimmt er sich den Token. Für alle anderen bedeutet das, dass sie warten müssen und selbst nicht integrieren können, bis der Token wieder freigegeben ist.

Der große Vorteil besteht darin, dass alle Entwickler darüber informiert sind, wenn ein Teammitglied gerade integriert. So lassen sich Konflikte effektiv vermeiden. Es ist sehr ärgerlich, wenn man gerade die Änderungen der Kollegen mit den eigenen zusammengeführt hat und seine Modifizierungen eigentlich nur noch einspielen muss – und dann feststellt, dass jemand dazwischengegrätscht ist. Nicht selten heißt das, noch einmal komplett neu anfangen zu müssen.

Das ohne ein solches Hilfsmittel übliche Chaos, das viele Entwickler als “normal” empfinden, lässt sich auf diese sehr Weise enorm reduzieren.

Die Erfahrung zeigt, dass es trotz einer solchen Regel durchaus auch mal knallen kann: Ein Entwickler hält sich nicht an die Vorschrift und spielt noch schnell etwas ein, obwohl ein anderer mitten im Integrieren ist. Dieser Kollege regt sich zurecht auf – und spätestens ab jetzt halten sich alle an die Regel.

Integration Server
Natürlich muss jeder Programmierer seine Ergebnisse auf seiner Entwicklungsumgebung testen. Noch wichtiger ist allerdings ein Test auf einem dedizierten Integration Server. So lassen sich bestimmte häufig auftretende Fehler vermeiden, z.B. Plattformbesonderheiten auf dem Entwicklungssystem, vergessene Commits usw.

Kurzmitteilungen an das ganze Team
Hat ein Entwickler etwas verändert, was das ganze Team betreffen könnte, ist es sinnvoll, es sogleich allen mitzuteilen – am einfachsten durch einen Ruf in die Runde. Das führt zu einem schnellen Informationsfluss, alle Entwickler sind sofort im Bilde und die Gefahr doppelter Arbeiten sowie unnötiger Suchen nach Problemen sinkt.

Außerdem weiß jeder, wen er in diesem Fall bei auftretenden Problemen ansprechen kann. Hat ein Kollege bspw. “Durch meine Umstellung funktioniert der Login gerade nicht!” gerufen, ist klar, an wen man sich diesbezüglich wenden muss.

Das Ablenkungspotenzial durch diese Statusmeldungen ist sicherlich nicht zu unterschätzen. Doch sofern es sich wirklich um kurze Mitteilungen handelt, die nicht aus mehr als ein, zwei Sätzen bestehen, wird das Team nicht völlig aus der Konzentration gerissen und findet erfahrungsgemäß schnell wieder zurück in die Arbeit.

Software-Architektur

Eine Frage, die sich Entwickler bei der praktischen Anwendung von Scrum stellen, ist die Herangehensweise bei der Software-Architektur. Wo bei Wasserfallmodellen ein Architekt die Software zunächst in ihren Grundzügen entwirft, ist in Scrum-Projekten bekanntlich eine iterative Vorgehensweise gefragt.

Da User-Stories schrittweise implementiert werden, erscheint es nicht zielführend, die Anwendung im Vorfeld komplett zu durchdenken. Zwar ist es natürlich auch im Scrum-Projekt sinnvoll, sich schon abzeichnende Aufgaben gleich in der Architektur vorzusehen, ebenso legitim und oft auch sinnvoll ist es jedoch, zunächst einen einfacheren Weg zu wählen und das intensive Nachdenken über die Anforderung, die erst in einem späteren Sprint umzusetzen ist, zurückzustellen.

Häufig kommt es zudem vor, dass ein Entwickler vor einer Entscheidung steht, wie er eine gewisse Struktur architektonisch gestalten soll. Es ist durchaus angebracht, in einem solchen Fall eine spontane Abstimmung mit dem Team oder einem Teil des Teams durchzuführen und die Planung gemeinsam zu durchdenken. Die Vorteile: Die Ideen und Bedenken der Kollegen gehen mit in die Lösungsfindung ein, sie sind zudem in die Entwicklung der Struktur involviert und kennen sich in ihr aus. Resultate sind eine bessere Struktur und weniger Wissensinseln.

Räumliche Nähe des Teams

Alle bis hierhin angesprochen Punkte machen deutlich: Es ist sehr wichtig, dass das Team möglichst nahe beisammen sitzt, um schnell und einfach kommunizieren zu können. “Alle in einem Raum” ist die Idealsituation. Jede Abweichung erschwert die Umsetzung der erwähnten Best Practices.

Fazit

Die dargestellten Tipps sollen helfen, die Software-Entwicklung mit Scrum zu unterstützen und bessere Ergebnisse zu erzielen. Wie man sieht, haben die meisten Vorschläge wenig mit technischen Hilfsmitteln zu tun, sondern vielmehr mit der Kommunikation im Team und mit organisatorischen Regeln.

Bei der Optimierung des Scrum-Prozesses sind Offenheit und auch Experimente gefragt: Das Team muss Vorgehensweisen ausprobieren und dann beurteilen, ob sie funktionieren oder eben nicht. Und wenn etwas nicht funktioniert, sollte man es auch konsequent wieder sein lassen bzw. es auf jeden Fall anpassen. Das ist der wichtige Lernprozess in Scrum, der insbesondere in der Retrospektive erzielt wird.

Welche ähnlichen oder ganz anderen Erfahrungen haben Sie als Entwickler in der Scrum-Praxis gesammelt? Lassen Sie es uns gerne per Kommentar wissen. :-)

Weiterführende Informationen

Haben Sie Fragen zu agilen Vorgehensweisen in der Software-Entwicklung? Möchten Sie Agilität in Ihrem Unternehmen einführen? Bei //SEIBERT/MEDIA ist “Agile” in Projekten an der Tagesordnung. Mit mehreren Zehntausend Stunden Projekterfahrung in internen und externen Projekten mit agilen Entwicklungsmethoden gehört //SEIBERT/MEDIA zu den erfahrenen und großen Anbietern für Scrum in Deutschland. Gerne helfen wir Ihnen bei der Etablierung agiler Prinzipien und Verfahren – sprechen Sie uns einfach unverbindlich an.

Ausführliche Informationen zu unseren Agile-Dienstleistungen finden Sie in unserem Agile-Orientierungsangebot mit Leistungsbeschreibungen und Beispielkalkulationen.

Welche Vorteile bietet mir als Kunde ein Scrum-Projekt?
Agile vs. Wasserfall-Modell: Was die Forschung sagt
Die Scrum-Meetings und ihre Bedeutung
Agile Projekte und Scrum in der Praxis: Elemente, Nutzen, Tools, Hürden
Scrum in der Praxis: Ein Team startet durch

Hinterlassen Sie eine Antwort

Kommentare