Agile=modern=gut?
Agile Softwareentwicklung ist heutzutage in aller Munde. Fast muss es einem etwas peinlich sein, noch nicht agil zu entwickeln. Oder (Gott bewahre) gar nicht so genau zu wissen was sich eigentlich dahinter verbirgt. Was also bedeutet agile Softwareentwicklung wirklich? Und ist sie auch für mein IT-Projekt geeignet?
Zunächst mal muss man festhalten, dass es „die agile Softwareentwicklung“ an sich gar nicht gibt. Vielmehr existieren eine Reihe von neuen Stilrichtungen und sie setzen neue Techniken in unterschiedlichem Maße und in verschiedenen Kombinationen ein. Die bekanntesten sind:
- Scrum
- Extreme Programming (XP)
- Test-Driven Development (TDD)
- Kanban
Die von diesen Entwicklungsprozessen eingesetzten Techniken sind auf jeden Fall sehr innovativ, ihr Nutzen wird jedoch teilweise sehr unterschiedlich bewertet. Darunter finden sich beispielsweise:
- User-Stories als Anforderungen
- Pair-Programming
- Test-First Entwicklung
- Ständiges Refactoring als fester Bestandteil der Entwicklung
- Release early – Release often
- Collective Code-Ownership
- Iterationen mit zeitlich fixiertem Umfang
Um es gleich vorweg zu nehmen: Ich glaube, dass alle diese Techniken bei der Durchführung von Softwareprojekten eine große Hilfe sein können. Allerdings müssen Sie sich über eines im Klaren sein:
Agile Softwareentwicklung ist nicht die Verwendung neuer Techniken – Agile Softwareentwicklung ist zuerst und vor allem ein Paradigmenwechsel!
Agil zu sein macht nur dann Sinn, wenn Sie auch neue Denkmuster etablieren – und zwar auf allen Ebenen bis hin zum Kunden, nicht nur in der Codierung. Das ist ein Prozess, der nicht von heute auf morgen stattfinden wird.
Worin besteht also der Paradigmenwechsel? Der vielleicht wichtigste Punkt dabei ist die „Umverteilung“ der Verantwortung weg von einzelnen Personen hin zum Team. Aufgaben, die vorher klar einzelnen Personen zugeordnet waren, werden jetzt von allen Teammitgliedern erledigt. Die Aufwandsschätzung z.B. wird gemeinsam durchgeführt. Es gibt keinen Chefentwickler mehr, der für das Design zuständig ist: Jeder designt das Feature, welches er gerade entwickelt und jeder kann ein vorhandenes Design ändern, wenn er es für richtig hält. Es gibt auch keine Zuordnung von Entwicklern zu bestimmten Codeteilen. Stattdessen kennt jeder Entwickler (mehr oder weniger) den gesamten Code und manipuliert diesen auch bei Bedarf.
Das erfordert ein neues Bewusstsein der beteiligten Entwickler und eine Übernahme dieser neuen Verantwortung. So etwas muss über einen längeren Zeitraum geübt und auch immer wieder problematisiert werden, bis es irgendwann „von alleine“ funktioniert. Rechnen Sie also damit, dass es eine Weile dauert und dass während dieser Zeit die Produktivität nicht größer ist als vorher (sie kann sogar leicht sinken).
Viele Teams glauben, dass sie agil entwickeln, haben aber tatsächlich lediglich einige agile Techniken übernommen, ohne die dazugehörige Philosophie zu adaptieren. Das kann sogar kontraproduktiv werden und dem Projekt am Ende mehr schaden als nützen.
Fazit: Agile Softwareentwicklung ist auf jeden Fall eine spannende Sache mit viel Potential. Wie so oft bei IT-Projekten muss man aber eine Menge richtig machen, um dieses Potential auch auszuschöpfen. Und man braucht die richtigen Mitarbeiter dafür, Menschen, die keine Angst vor Verantwortung haben und offen für neue Techniken sind.
Passendes Spiel-Kapitel: Team & Vertrauen
Der Paradigmenwechsel weg vom Chefentwickler hin zur Verantwortung des gesamten Teams ist Kern jeder agilen Methode. Im Kapitel „Team & Vertrauen“ des PM-Spiels erleben Sie, wie Rollenverteilung, Teamgeist und Produktivität zusammenhängen.