Software Projekte, die mit agilen Methoden wie Scrum oder eXtreme Programming entwickelt werden, stellen hohe Ansprüche an die Entwickler im Team und erfordern neue Fähigkeiten und Denkweisen.
Andrew Hunt und David Thomas haben 2001 mit dem „The Pragmatic Programmer “ bereits ein Standard-Werk über den modernen Anwendungsentwickler geschrieben. Der Fokus liegt dabei aber auf Praktiken, Werkzeugen und Design-Paradigmen die dem Programmierer helfen besseren Code zu entwickeln.
Für agile Projekte reicht es aber aus meiner Sicht nicht aus nur ein „Pragmatic Programmer“ zu sein und in diesem Artikel möchte ich daher den Fokus auf den Entwickler in einem Scrum Team setzen. Ich sage hier explizit nicht „Programmierer“ sondern „Entwickler“, weil der Begriff Programmierer aus meiner Sicht zu sehr auf das codieren beschränkt ist und weniger die Tätigkeiten beschreibt, die zusätzlich notwendig sind, um guten Code zu erzeugen. (beispielsweise Design und Test)
Die Wurzeln von Scrum liegen laut Ken Schwaber (einem der Erfinder von Scrum) vor allem in einem Artikel der im Januar 1986 im Harvard Business Journal erschienen ist: „The New New Product Development Game“. Der Artikel beschäftigt sich damit, welche Kriterien eine erfolgreiche Produktentwicklung ausmachen und leitet daraus eine Kernthese ab:
„Stop playing the relay race – play rugby“.
Was frei Übersetzt bedeutet, dass man nicht mehr sequenziell („Wasserfall“), sondern ganzheitlich Produkte entwickeln soll.
Scrum hat die grundsätzliche Characteristiken für erfolgreiche Produkt Entwicklungen aufgegriffen und integriert. Beispielsweise Selbstorganisation der Teams, überlappende Entwicklungsphasen und unterschwellige Kontrolle. Diese Ansätze wurden um Ideen aus der iterativen, inkrementellen Entwicklung und der „Lean “ Welt erweitert. Die Scrum Alliance bietet heute Schulungen und Zertifizierungen zum Scrum Master und Product Owner an – nur was ist mit dem Entwickler? Liegt der Erfolg eines Projekts nicht vor allem im Team? Was bedeutet eigentlich Selbstorganisation, lauffähige Software alle 2-4 Wochen und überlappende Entwicklungsphasen für den Entwickler in einem Scrum Team?
Grundsätzlich glaube ich, dass die Arbeitsweise des Entwicklers in agilen Projekten im Vergleich zum Wasserfallmodell fundamental anders ist und deshalb auch andere, neue Fähigkeiten verlangt werden.
Beginnen wir mit einem der wichtigsten Dinge innerhalb agiler Projekte: Die Selbstorganisation des Teams – Selbstorganisation bedeutet, dass man als Entwickler nicht mehr von außen gesteuert wird, sondern sich mit den Teammitgliedern über die Zusammenarbeit abstimmt. Es bedeutet aber auch, dass man viel mehr Verantwortung übernimmt, mehr miteinander reden und diskutieren muss, Konflikte löst, sich selber organisiert, Aufwände schätzt und Commitments einhält. Dinge die in klassischen Projekten andere Rollen ausgeführt haben und aus meiner Erfahrung nicht gerade die Kernkompetenzen eines Programmierers sind. Es ist aber für den Erfolg von agilen Projekten fundamental erforderlich, dass sich Teams selber organisieren können – weshalb man auch die Entwickler mit entsprechenden Skills ausstatten sollte. Von vielen Organisationen weiß ich, dass Sozialkompetenztrainings vor allem den Führungskräften vorbehalten sind. Durch die Umkehr von „Command and Control“ müssen aus meiner Sicht vor allem auch die Teammitglieder, also auch die Entwickler geschult werden, im Team zu arbeiten. Dazu gehören beispielsweise Konfliktfähigkeit, Kommunikationsfähigkeit, Kompromissfähigkeit, Kritikfähigkeit, Toleranz und Verantwortung. Teammitglieder müssen die Stärken und Schwächen der Kollegen besser einschätzen zu können, was beispielsweise durch Methoden wie das Team Management System oder DISG erreicht werden kann. Wir haben nach der Einführung von Scrum bei codecentric festgestellt, dass wir neben den technischen und methodischen Skills auch die Sozialkompetenz schulen müssen, wenn wir erfolgreiche, agile Projekte durchführen wollen. Mit Hilfe externer Trainer haben wir ein spezielles Programm für uns ausgearbeitet, um die beschriebenen Fähigkeiten jedes Mitarbeiters nachhaltig zu verbessern.
Neben der Selbstorganisation erfordert aber auch die Überlappung der Entwicklungsphasen ganz neue Denkweisen bei uns Entwicklern. In den klassischen, sequentiellen Vorgehensmodellen wurden die Anforderungen im Detail ausgearbeitet, i.d.R. in ausführlichen Anforderungsdokumenten und detaillierten UML Diagrammen. Als Entwickler hat man diese Spezifikationen dann in lauffähigen Code umgesetzt und „Entwickler-getestet“ – für die eigentliche Qualitätssicherung waren andere Teams verantwortlich. Bei agilen Projekten verschwimmen die Grenzen zwischen Anforderungsmanagement, Analysten, Testern und Programmierern und als Entwickler muss man sich auch mit den „ungeliebten“ Randgebieten rumschlagen. D.h. aus meiner Sicht beispielsweise, dass man nicht nur mit Unit-Test auskommt, sondern in die Testgetriebene Entwicklung auch eher fachliche Integrations- und Akzeptanztests integrieren muss – i.d.R. werden diese dann gemeinsam mit Domänen Experten und erfahrenen Testern erstellt. Gerade wenn diese Tests für spätere Regressions-Phasen automatisiert werden (aus meiner Sicht ein Muss bei iterativ, inkrementeller Entwicklung), muss der Entwickler stärker involviert werden, um die speziellen Herausforderungen bei der Automatisierung, wie beispielsweise Testdaten-Setup, zu entwickeln. Geht man sogar soweit, dass man nicht nur bei Unit-Tests Test-Driven entwickelt , sondern auch bei den Integrations- und Akzeptanztest, sind entsprechendes Wissen um Vorgehen und Werkzeugen essentiell. Seien wir mal ehrlich: Man ist doch schon froh, wenn man Entwickler dazu bekommt TDD für Unit Tests anzuwenden oder überhaupt gute und ausreichende Unit Tests zu schreiben – das müssen wir durch entsprechendes Training/Coaching ändern.
Um diese Akzeptanztests zu erstellen und die wenig detaillierten User Stories umsetzen zu können, muss sich ein Entwickler viel intensiver mit der Fachlogik und den entsprechenden Personen im Team auseinandersetzen. Hierfür sind Kommunikationsfähigkeiten, aber auch entsprechende Praktiken, wie beispielsweise Domain Driven Design notwendig. In vielen Projekten sehe ich leider, dass sich Entwickler weniger mit der Domäne und mehr mit Frameworks wie Spring oder Hibernate beschäftigen; Generatoren, die aus Datenbankmodellen ein Objektmodell generieren sind eine nette technische Spielerei, hilfreich bei der Strukturierung und Kommunikation der Domäne sind sie allerdings nicht. Das objekt-relationale Mapping wird dann zu einer relationalen Objektgenerierung und oftmals zu einer Wartbarkeits-Falle. Auch das ist aus meiner Sicht auf die zu starke Technologiefokussierung zurückzuführen, die man dann auch in der Struktur der Komponenten wiederfindet, die eher auf Basis von Maven -Vorgaben oder Technologie-Layern geschnitten werden, als auf Basis fachlicher Zusammenhänge und Service-Grenzen. Hier ist es meiner Meinung nach unbedingt notwendig Entwickler dahingehend zu schulen und zu coachen, dass Sie die Domaine als Kommunikationsinstrument mit den Fachabteilungen nutzen – so entstehen ganz „natürlich“ fachlich sinnvolle Strukturen und Domainen.
Um alle 2-4 Wochen fertige Software auszuliefern, darf man als Entwickler aber auch nicht die Technologien, Werkzeuge und agilen Entwicklungspraktiken vernachlässigen. Continuous Integration (z.B. Hudson, CruiseControl ), automatisierte Build-Werkzeuge (z.B. Maven , Ant ), Code Qualität Werkzeuge (z.B. Findbugs , PMD , Checkstyle ), automatisierte Testwerkzeuge (z.B. JUnit , Robotframework , easyMock , DBUnit , JMeter ), Codeverwaltung (z.B. git , Subversion), Bugtracker (z.B. Jira , Trac ), Dokumentationswerkzeuge (Wiki, UML-Toos, Javadoc, etc.) sind dabei nur ein Auszug aus dem Portfolio eines modernen, agilen Entwicklers. Um dieses Portfolio optimal nutzen zu können und in eine „Definition of Done“ zu gießen, müssen die Teammitglieder auch im Umgang mit diesen Werkzeugen und Praktiken geschult werden. Dave Thomas, Co-Autor des „Pragmatischen Programmierers“, spricht sogar von „Code Katas“: Er zieht damit eine Parallele zum Karate, wo Katas bestimmte Trainingseinheiten sind, die immer und immer wieder wiederholt werden, um sie zu perfektionieren. Als Organisation müssen wir den Entwicklern also nicht nur entsprechendes Basis-Training geben, sondern auch Freiräume, um zu üben.
Neben ScrumMaster und Product Ownern müssen natürlich auch die Teammitglieder in Scrum geschult werden, denn die meisten Dinge in Scrum betreffen das Team und dieses muss über das Verständnis den Nutzen erkennen können. Beispielsweise, dass das Daily Scrum nicht für den Scrum Master gehalten wird (dieser muss ja nicht einmal mit anwesend sein, sondern nur dafür sorgen, dass es stattfindet), sondern um sich im Team auf den neusten Stand zu bringen und ggf. Probleme transparent zu machen. (Oft sieht man, dass der Scrum Master reihum die drei Fragen stellt und sich Antworten abholt…ein großes Missverständnis des Daily Scrums!) Oder dass das Burndown-Diagramm nicht zur Kontrolle des Teams durch Scrum Master oder Product Owner (oder sogar den Chef) gedacht ist, sondern als Hilfsmittel für das Team, die eigenen Commitments besser einhalten und überwachen zu können.
Am Ende bleibt noch festzustellen, dass insbesondere die Organisationen umdenken müssen. Das Spektrum des Agilen Entwicklers ist deutlich größer als die Summe der Technologien und erfordert viel Training und Übung – zudem einen hohen Erfahrungsaustausch im Team und innerhalb der Organisation, was schon bei „The New New Product Development Game“ festgestellt wurde: „Multilearning“ und „Organizational Transfer of Learning“ sind zwei der sechs wichtigen Erfolgsfaktoren in der Produktenwicklung! Agile Organisationen müssen also lernen, dass Training kein „Incentive“ ist, sondern ein absolutes Muss für alle Team Mitglieder eines agilen Projekts. Dazu gehören neben den Technologien und Werkzeugen auch Schulungen und Coachings um die Sozialkompetenz im Team nachhaltig zu stärken und agile Methoden, Praktiken und Paradigmen zu verstehen. Damit sich das aufgebaute Wissen der Entwickler auch außerhalb des Teams positiv wirken kann, müssen zudem Foren geschaffen werden, so dass sich die Entwickler im Unternehmen regelmäßig treffen und austauschen können. Diese Investition in die eigenen Mitarbeiter wird sich sehr schnell auszahlen!
War dieser Beitrag hilfreich?
Weitere Beiträge
von Mirko Novakovic
21.2.2014 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Mirko Novakovic
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.