Agil, flink und wendig, angepasst an die Umgebung, an das Projekt, an das Unternehmen. So sehe ich das. Im Gegensatz dazu steht der dogmatische Ansatz oder stupide Methodeneinsatz.
Ist agil jetzt einfacher und besser? Weiß nicht. Agil bedeutet flexibel zu sein und vor allem zu bleiben. Harte Arbeit an sich selbst. Obwohl… so hart ist es nicht. Es ist tägliche Arbeit und darf Spaß machen.
Dazu eine kleine „TDD“-Anekdote:
Vor einigen Monaten diskutierte ich mit einem Kollegen aus dem agilen Kreis über Testgetriebene Entwicklung. Sein Standpunkt war, dass es völlig egal sei ob man testgetrieben Software erstellt oder nicht. Auch ohne Tests lässt sich funktionsfähige Software erstellen. Solche Sätze vergesse ich nicht und sie wirken nach.
Intuitiv spürt man, wenn Menschen etwas Kluges, Sinnreiches vermitteln oder die hohe Kunst der Manipulation anwenden um ihre eigenen Vorteile zu erlangen. So hat es ein Jahr und ein paar Ansätze bis ich diese Situation und diesen Satz verstanden habe.
Es ist wirklich egal ob man testgetriebene Software entwickelt. Gutes Software Design kann auch konventionell entstehen. Ein disziplinierter und autodidaktischer Entwickler kann ohne Wimpernzucken alle Clean-Code Prinzipien einhalten, Abstraktionslevel berücksichtigen und eine Single Responsibility Klassenstruktur erzeugen. Ich glaube das es geht und ein Projekt dennoch zum Erfolg führen kann.
Ich unterstelle jedoch auch dass viele Entwickler weder diese Disziplin besitzen, noch Autodidakten sind. Der testgetriebene Ansatz bietet einen Rahmen um die genannten Prinzipien leichter, also überschaubarer, einzuhalten und die Wartbarkeit und Erweiterbarkeit einfacher zu halten.
Was heißt das nun in Bezug auf die Agilität?
- in der Lage zu sein beides zu Können: TDD und konventionelles Design.
- Entscheiden zu können wann welche Methode angebracht ist und in einem Projekt oder Team gebraucht wird.
Scheinbar hat Agilität wirklich etwas von Können zu tun, weniger mit Erfahrung.
