Freelancer und Selbständige müssen flexibel sein und sich immer neuen Gegebenheiten anpassen. Einfach ohne Kontakt zur Außenwelt wochenlang vor sich hin arbeiten, das geht im heutigen Arbeitsleben mit Meetings, Scrums, Brainstorming und Co nicht mehr. Besonders deutlich wird das im IT-Bereich, mit dem ich in meinem Berufsleben täglich zu tun habe. Dort begegnet mir immer wieder die Methodik der agilen Softwareentwicklung.
Grund genug, mich heute auf meinem Blog mit diesem Thema zu beschäftigen und für euch die Vor- und Nachteile dieser Entwicklungsmethode zu beleuchten.
Immer schön beweglich bleiben
Bei der agilen Softwareentwicklung geht es – wie der Name schon sagt – darum, die Entwicklung eines Produkts oder Programms einfach und beweglich (agil) zu gestalten. Große Projekte teilt ihr in kleine Teilschritte (sogenannte Iterations) ein und definiert für jeden ein Ziel. Die Entwicklerteams arbeiten gemeinsam daran, diese Zwischenziele zu erreichen.
Sogenannte weiche Kriterien wie Kommunikation, Rücksichtnahme und Flexibilität solltet ihr bei dieser Methode groß schreiben! Was ihr sonst noch braucht, um in Sachen Entwicklung richtig agil unterwegs zu sein:
- Regelmäßige Meetings, Praxistests und Rücksprachen mit dem Kunden. Sie verhindern, dass ihr am Ende eine Software entwickelt, die nicht den Anforderungen entspricht.
- Darin haltet ihr die Projektgeschichte und die Features, die ihr benötigt, fest.
- Das sogenannte Product Backlog ist eure To-Do-Liste, in der ihr alle Aufgaben auflistet, die ihr noch erledigen müsst.
Ihr braucht einen ausführlichen Überblick darüber, was bei der agilen Softwareentwicklung wichtig ist? Seit 2001 gibt es das Manifest für agile Softwareentwicklung, in dem vier Werte und zwölf Prinzipien verankert sind, die ihr befolgen solltet.
Mit kleinen Schritten und guter Kommunikation zum Ziel
Wenn ihr diese Prinzipien befolgt, ergeben sich viele Vorteile der agilen Methode. Zunächst einmal, was den Umfang eines Projekts angeht. Ihr steht als Entwickler nicht mehr vor einem großen Berg, an dessen Gipfel irgendwo das Ziel steht, sondern ihr arbeitet es in vielen kleineren Schritten gemeinsam ab. Da ihr für jeden Schritt ein Etappenziel definiert habt, fallen euch Fehler früh auf und ihr könnt schnell darauf reagieren.
Ein weiterer Vorteil ist die direkte und fortlaufende Kommunikation. Wer jetzt denkt, ich hab aber keinen Bock auf diese ständigen sinnlosen Meetings, dem sei gesagt: Sie finden zwar oft und regelmäßig statt, aber sie sind kurz und effizient gestaltet. Also kein endloses Bla Bla ohne Ziel. Im Netz findet ihr viele kreative Ideen, sogenannte Fun Retrospectives, mit denen ihr euch vorher auflockern könnt. Im Meeting erklärt dann jedes Team wo es gerade steht was sie noch zu erledigen ist und wo es Probleme gibt. In diese Kommunikation bezieht ihr auch eure Kunden früh ein. So könnt ihr seine Wünsche gleich aufnehmen und in der nächsten Runde berücksichtigen. So gibt`s am Ende keine bösen Überraschungen.
Mehr Struktur und mehr Transparenz
Auch die Arbeitszeit, die ihr für ein komplettes Projekt noch braucht, könnt ihr mit der agilen Methode gut ermitteln. Denn jedem Feature, das die fertige Software haben soll, teilt ihr je nach seinem Umfang Punkte zu. Aus der Punktezahl, die ein Team pro Durchlauf abarbeitet, könnt ihr dann jederzeit auf die Arbeitszeit schließen, die ihr bis zum Projektende noch benötigt.
Durch die agile Entwicklungsmethode bekommt euer Projekt mehr Struktur und Transparenz. Die Wahrscheinlichkeit, dass ihr am Ende für den Papierkorb entwickelt, verringert sich. Aber nicht für jeden Entwickler, jedes Team und jedes Projekt ist diese Methode geeignet. Wenn ihr und euer Team in euren Arbeitsabläufen jahrelang eingespielt seid, solltet ihr vorher gut überlegen, ob eine neue Methode euch weiterbringt. Da bei der agilen Softwareentwicklung die Ergebnisse stark von der Motivation und den individuellen Fähigkeiten der Teammitglieder abhängen, sollten diese Lust darauf haben, etwas Neues auszuprobieren. Auch bei kleineren oder vertrauten Projekten lohnt sich der Aufwand, einen neuen Ansatz zu starten, nicht immer. Hier gilt der Grundsatz: Never change a winning team, oder in diesem Fall: a winning procedure.
