Agile Developer Skills - JAXenter
Mitglied sein in einem agilen Entwicklerteam

Agile Developer Skills

Christoph Mathis und Andreas Wintersteiger

Agile Softwareentwicklung ist im Mainstream angekommen. Begriffe wie „Sprint“, „Backlog“, „Product Owner“ oder „Story“ sind in aller Munde. Viele Unternehmen und Teams haben ihren Entwicklungsprozess umgestellt und agile Softwareentwicklung eingeführt. Um das Versprechen auf Verbesserung auch tatsächlich einzulösen, müssen agile Entwicklungsteams die Art und Weise, wie sie arbeiten, grundlegend ändern, denn sie stehen stark geänderten Herausforderungen gegenüber.

Agile Teams sind gefordert, in regelmäßigen Zyklen funktionsfähige Software zu liefern. Das heißt also, neue Anforderungen innerhalb eher kurzer Zeiträume in lauffähige Software umzusetzen. Dahinter stecken zwei neue Herausforderungen. Erstens: Binnen kurzer Zeit hohe Qualität zu liefern, fordert Teams heraus, messerscharf zu fokussieren, nur das Gefragte zu entwickeln und ausreichend zu testen – so, dass es „ausgeliefert“ werden kann.

Zweitens: effektiv zu sein, also das Verhältnis von erreichtem Ziel zu definiertem Ziel zu optimieren. Das heißt, agile Teams müssen in der Lage sein, sich klare Ziele zu setzen und diese dann auch in hoher Qualität umsetzen. Diese Herausforderung verlangt danach, über die eigene Leistungsfähigkeit zu lernen. Die Prinzipien des agilen Manifests [1] fordern kurze und bevorzugen sogar sehr kurze Zyklen – also wenige Wochen. Durch diese Kompression des Zeitraums zwischen Anforderung und gelieferter Software entsteht die Möglichkeit für frühes und häufiges Feedback, das wiederum Probleme sichtbar macht und es Teams ermöglicht, zu lernen. Die damit auftretende Forderung liegt in der nunmehr inkrementellen Natur der Entstehung der Software. Ein Inkrement ist etwas Vollständiges, ein vertikaler Schnitt durch die Systemarchitektur, vom (User) Interface bis zur Persistenzschicht/Infrastruktur, und bringt die Herausforderung mit sich, dass Benutzerschnittstelle, Geschäftslogik und Datenschema und somit auch die gesamte Architektur inkrementell entwickelt werden – also sich damit immer wieder ändern werden. Viele Entwickler wünschen sich aber, dass Architektur und Design „von Anfang an stehen“.

Agile Entwickler haben aus der Vergangenheit gelernt, dass das immer ein Wunschdenken bleiben wird. Das sprichwörtliche Big-Upfront-Design hat – abgesehen von trivialen Fällen – nie wirklich funktioniert und wird heute als „Verschwendung“ angesehen. Eine weitere Grundforderung in den agilen Prinzipien lautet, Veränderung als Chance für gesteigerten Kundenwert zu erkennen. Agile Teams können geänderte Anforderungen zu jeder Zeit im Projektverlauf (im nächsten Inkrement) umsetzen, ohne dass die Qualität des gesamten Systems leidet. Entwickler, deren Weg durch die klassische, wasserfallorientierte Entwicklung bestimmt war, sind es jedoch gewöhnt, Veränderung, insbesondere die von Anforderungen, so lange wie möglich vom Umsetzungsprozess fernzuhalten. Dieser Umstand unterstreicht die oben genannte Forderung nach Änderbarkeit noch mehr. Agile Teams müssen in der Lage sein, „emergentes“, also über die Zeit entstehendes Design, umzusetzen, indem sie ihre Software stets änderbar halten.

Neue Herausforderungen
  • Zuverlässig und effektiv liefern
  • Inkrementell in kurzen Zyklen entwickeln
  • Änderbare Software
  • Probleme selbst lösen
  • Selbstorganisation

Softwareentwickler werden auch heute noch oft nach den Mustern des Taylorismus geführt, wo sie von ihrem Chef gesagt bekommen, was sie wie tun müssen oder noch öfter, was alles sie nicht tun dürfen. Von vielen Entwicklerteams, die wir als Coaches oder Consultants besuchen, hören wir immer wieder eine scheinbar endlose Liste an Dingen, die nicht funktionieren oder den Entwicklern das Leben schwer machen. Eine überwiegende Mehrheit dieser Themen kann aber von den Teams selbst gelöst werden. Beginnende Teams sind nicht selten überfordert von der neuen Freiheit und dem damit verbundenen Vakuum. Sie sehen sich nicht in der Lage, die nun sichtbar werdenden Probleme selbst zu lösen. Sie müssen sich zuerst „finden“ und Teamprozesse etablieren.

Um die selbst gesteckten Ziele zu erreichen, planen und organisieren agile Teams ihre Arbeit auch selbst. Damit entsteht eine kooperative Organisation der Umsetzungsarbeit innerhalb des Teams, die wiederum nach neuartigen Kommunikationsstrukturen und -mechanismen verlangt. Teammitglieder müssen sich auf einander verlassen, einander vertrauen. Sie müssen über andere Dinge und anders als bisher miteinander kommunizieren, um ihr gemeinsames Ziel zu erreichen. Selbstorganisierende Teams sind darüber hinaus in der Lage, eigene Defizite zu erkennen und daraus Maßnahmen für die ständige Weiterentwicklung abzuleiten.

Agile Techniken

Um diesen neuen Herausforderungen gegenüberzutreten, ist die Entwicklung einer Menge an Fähigkeiten notwendig, die einerseits technische Fertigkeiten repräsentieren, andererseits aber eher Soft Skills darstellen. Auf der technischen Achse handelt es sich hierbei um Fähigkeiten rund um das Entwickeln selbst, also das Wissen über Prinzipien und das zugehörige Beherrschen von konkreten Techniken und Praktiken, die den Unterschied zwischen Meister, Geselle und Azubi ausmachen. Dazu zählt natürlich auch jeweils die konkrete Werkzeugbeherrschung. Im Grunde steht hier zunächst die technische Exzellenz, also grundsätzlich Fähigkeiten, sauberen Code zu entwickeln, die Prinzipien und Praktiken aus dem objektorientierten Paradigma wie Entwurfsmuster in der täglichen Arbeit einzusetzen. Darüber hinaus zählt hierzu auch das Verständnis von Prinzipien für einen sauberen Entwurf, z. B. die S.O.L.I.D.-Prinzipien samt der zugehörigen Praktiken für deren Umsetzung. Die Gemeinschaft agiler Entwickler hat hierzu bereits viel geleistet und z. B. unter dem Titel „Clean Code“ eine Sammlung an Prinzipien und Praktiken geschaffen. Clean Code wurde von Robert C. „Uncle Bob“ Martin, einem der Mitbegründer der agilen Bewegung, mit seinem gleichnamigen Buch initiiert [2].

Unter dem Titel „Refaktorisierung“ (engl. Refactoring) verbergen sich jede Menge Praktiken, die für agile Entwickler ein Muss sind, um das Design der Software änderbar zu halten. In vielen Entwicklerteams hält sich heute immer noch die Meinung, Refaktorisierung ist ein größeres Vorhaben, das ab und zu getan werden muss. Das exakte Gegenteil ist der Fall, agile Entwickler verwenden Refactoring permanent in kleinen Schritten, damit wird es zum elementaren Schritt im täglichen Entwicklungsprozess. Refactoring muss somit auch nicht dem Management „verkauft“ werden, es gehört zu den Arbeitsschritten, die professionelle Entwickler tun. Ebenso wie Refactoring ist das funktionale Testen ein elementarer Schritt in der agilen Softwareentwicklung – es wird bei testgetriebener Entwicklung (engl. Test-driven Development, TDD) nicht nur laufend getan, sondern auch zuallererst: Die Entwickler beginnen damit, einen (Unit) Test für eine konkrete Anforderung an eine Funktion, Methode oder auch Klasse zu schreiben. Dieser Test schlägt selbstverständlich fehl, er lässt sich nicht mal übersetzen, weil die Implementierung hierfür fehlt (Phase Rot im TDD). Jeder neu hinzugekommene Test läuft automatisch mit der Suite an Unit Tests für dieses Modul ab. Nur jetzt ist es erlaubt, neuen Code zu schreiben, aber nach den oben angeführten Prinzipien nur so wenig und so einfach, um den Test ausreichend zu bedienen (Phase Grün). Nachdem nun sichergestellt wurde, dass für diese Anforderung ein Funktionstest vorhanden ist, kann das Design entsprechend unseren Prinzipien verbessert werden, wobei jeweils nur kleine Schritte gegangen werden (Phase Refactor). Neben einer sehr hohen Testabdeckung entsteht bei TDD gleichzeitig auch ein besseres Design, da die Entwickler den Entwurf nun aus der Perspektive der Benutzung, also der Schnittstellen, betrachten, wenn ein Test vor der Implementierung geschrieben wird. Aus diesem Grund wird TDD oft auch als Test-driven Design bezeichnet. Testgetriebene Entwicklung liefert also gute, änderbare und fehlerfreie Software. Dieselbe Vorgehensweise wird auch gewählt, wenn Fehler beseitigt werden oder alter Code geändert werden muss: zuerst einen Test schreiben, der den Fehler eindeutig reproduziert und dann erst den Bugfix entwickeln.

Eine konsequente Fortführung der TDD-Idee ist die akzeptanztestgetriebene Entwicklung (engl. Acceptance Test-driven Development, ATDD), wo über die oben beschriebene Schleife nochmals eine äußere Hülle gezogen wird, die mit einem Akzeptanztest beginnt. Zwischen einem fehlschlagendem und einem bestandenem Akzeptanztest liegen nun mehrerer Test-Code-Refactor-Phasen (Rot-Grün-Refactor) des TDD (Abb. 1). Wenn das Team an der Umsetzung einer User Story arbeitet, schreibt es zunächst Akzeptanztests und implementiert einen nach dem anderen mit diesem Vorgehen.

Abb. 1: Die Zyklen von TDD und ATDD
Geschrieben von
Christoph Mathis und Andreas Wintersteiger
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.