Kolumne: A² – alles Agile

Agile Methoden – eine Einführung
Kommentare

Agile Softwareentwicklung ist aus der heutigen IT-Landschaft nicht mehr wegzudenken. Immer mehr Unternehmen haben die Vorteile dieses Ansatzes erkannt und setzen ihn vermehrt nicht nur in der Softwareentwicklung sondern im gesamten Unternehmen ein. In diesem ersten Teil der Kolumne werden wir einen Blick auf agile Methoden im Allgemeinen werfen.

Die agile Softwareentwicklung unterteilt sich vornehmlich in drei Teilbereiche: dem agilen Prinzip, den agilen Methoden und den agilen Prozessen. Agile Prinzipien sind im agilen Manifest zusammengefasst, welches aus zwölf Unterpunkten besteht. So sind z. B. die Selbstorganisation und die Selbstreflexion der Teams essenziell für die agile Softwareentwicklung.

Für mich der wichtigste Punkt im agilen Manifest ist die Zufriedenheit des Kunden, bzw. der Stakeholder, welche dadurch erreicht wird, schnell und zuverlässig gute Software bereitzustellen. Diese zwölf Prinzipien werden unter anderem dadurch erreicht, dass agile Methoden angewandt werden, welche ich im folgenden anreißen möchte.

Viele dieser Methoden spielen ihre Stärken auch deshalb aus, weil sie die Kommunikation zwischen beteiligten Parteien fördern oder forcieren. Aus eigener Erfahrung kann ich vermehrt feststellen, dass schlechte Software auch deshalb entsteht, weil an den entscheidenden menschlichen Schnittstellen zu wenig oder zu unstrukturiert kommuniziert wird.

Oft kommt es vor, dass Anforderungen interpretiert werden, wo eine konkrete Nachfrage vonnöten wäre – eine Nachfrage aber aus dem Grund ausbleibt, da die betreffende Person nicht als „schwer von Begriff“ dastehen möchte. Nachfragen bleiben auch deshalb aus, weil die Notwendigkeit nicht erkannt wurde, es vermeintlich eindeutig ist. Das Kommunikationsproblem kann durch zwei Methoden verbessert werden: dem Pair Programming und den Code-Reviews. Bei beiden Methoden arbeiten immer zwei Entwickler an einer konkreten Implementierung und reflektieren sich gegenseitig.

Pair Programming

Beim Pair Programming arbeiten zwei Entwickler gleichzeitig an der Implementierung definierter Softwarefeatures. Hierbei sitzen zwei Entwickler physisch vor einem Rechner, wobei ein Entwickler den Code schreibt und der zweite Entwickler über die Problemstellung reflektiert und den geschriebenen Code direkt kontrolliert. Fallen dem zweiten Entwickler Fehler im Code oder Missverständnisse beim Feature/Requirement auf, können sie sofort angesprochen und diskutiert werden.

Pair Programming steigert die Kommunikation zwischen den Entwicklern.

Diese Eigenschaft des Pair Programming steigert sofort die Kommunikation zwischen den Entwicklern. Insbesondere in dem Fall, das ein Missverständnis beim Requirement dazu führen würde, dass es falsch oder gar das Falsche implementiert wird. Diese Maßnahme erleichtert es den Entwicklern, Missverständnisse aufzudecken und ohne Scheu gezielt nachfragen zu können, um das Requirement richtig zu verstehen und infolgedessen richtig zu implementieren.

Das Konzept darf nicht so verstanden werden, dass immer der gleiche Entwickler schreibt und der zweite kontrolliert. Beide Entwickler sind gleichberechtigt in der Ausführung beider Aufgaben und müssen sich regelmäßig abwechseln. Ebenso zu empfehlen ist, dass die Zweierteams möglichst oft durchgetauscht werden. Auch dieses Prinzip erhöht die Kommunikation und damit perspektivisch die Softwarequalität.

Es ist neben vielen angesprochenen Nebeneffekten das Hauptziel des Pair Programming, dass sich die Softwarequalität erhöht. Neben der erhöhten Softwarequalität vermindert das Pair Programming auch Codeinseln, welche nur ein oder wenige Entwickler kennen; die Codebasis wird von vielen Entwicklern gepflegt und gekannt.

A² – alles Agile

  1. Agile Methoden – eine Einführung
  2. Agile Methoden: Story Cards und agile Prozesse
  3. Agile Methoden: Planung ist alles

Code-Reviews

Ähnlich wie beim Pair Programming wird hier das Vier-Augen- oder das Mehr-Augen-Prinzip für Codeteile angewandt. Mit dem Unterschied, dass nicht zwei Entwickler zur gleichen Zeit an einem Requirement entwickeln, sondern parallel. Im Anschluss daran werden die Codeteile von verschiedenen Entwicklern anhand verschiedener Kriterien überprüft. Diese Kriterien können die Requirements sein, die als Basis für den entwickelten Codeteil dienten. Ebenso können es bestimmte Regeln sein, welche beim Implementieren zu beachten sind; zu nennen wären hier Code-Style- oder Clean-Code-Regeln.

Code-Reviews sorgen für eine Erhöhung der Softwarequalität.

Ein Code-Review kann wie folgt ablaufen: Hat ein Entwickler im Team ein Requirement implementiert, bittet er einen anderen Entwickler, sich diesen Codeteil anzusehen. Dies geschieht, indem der erste Entwickler erklärt, wie er das Requirement verstanden und welche Codeteile er hierfür und warum implementiert hat. Der überprüfende Entwickler reflektiert diesen Prozess aus seiner Sichtweise und zeigt – analog zum Pair Programming – Verbesserungen auf oder weist auf Missverständnisse hin. Die Erhöhung der Softwarequalität kann ähnlich wie beim Pair Programming beobachtet werden.

Manuelle Code-Reviews, an denen zwei oder mehrere Entwickler teilnehmen, eigenen sich in besonderem Maße dafür, umgesetzte Requirements dahingehend zu überprüfen, ob Sie korrekt umgesetzt wurden und die geforderten Anforderungen abdecken. Für Coding-Style- und Clean-Code-Regeln empfiehlt es sich darüber hinaus, automatisierte Reviews in den Prozess zu übernehmen.

Da diese wiederkehrend und monoton sein können, besteht die Gefahr, dass beteiligte Entwickler Abweichungen übersehen oder die Reviews aus Zeitdruck ausgelassen werden. Automatisierte Reviews können dadurch abgebildet werden, indem sie in einen Continuous-Intergration-Prozess überführt und mithilfe eines entsprechenden CI-Servers, z. B. Jenkins, ausgeführt werden. Auf diese Weise wird sichergestellt, dass keine Code-Style- oder Clean-Code-Reviews vergessen oder übergangen werden, was wieder erheblich dazu beträgt, die Software und Codequalität zu erhöhen.

Testgetriebene Entwicklung

Neben den soeben automatisierten Code-Reviews, auch gern als statische Softwaretests bezeichnet – statisch deshalb, weil der Code für diesen Test nicht ausgeführt, sondern lediglich analysiert und gegen Regeln verglichen wird – ist eine weitere agile Methode die testgetriebene Entwicklung. Diese dabei entstehenden Tests und Testfälle sind dynamische Softwaretests, welche ebenso automatisiert ausgeführt werden sollten; auch hierfür eignet sich ein CI-Server wie Jenkins.

Bei dynamischen Softwaretests wird im Gegensatz zu den statischen Softwaretests der Code zur Ausführung gebracht. Testgetriebene Entwicklung zeichnet sich dadurch aus, dass, nicht wie im Allgemeinen im Wasserfall oder V-Modell üblich, die Tests nach der Implementierung entwickelt werden. Bei der testgetriebenen Entwicklung werden zuerst die Tests geschrieben und danach das Requirement implementiert, bis der (Unit)Test für dieses Requirement nicht mehr fehlschlägt.

PHP Magazin

Entwickler MagazinDieser Artikel ist im PHP Magazin erschienen. Das PHP Magazin deckt ein breites Spektrum an Themen ab, die für die erfolgreiche Webentwicklung unerlässlich sind.

Natürlich können Sie das PHP Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist das Entwickler Magazin ferner im Abonnement oder als Einzelheft erhältlich.

Die Vorgehensweise bei der Entwicklung von Unit Test und Units kann wie folgt beschrieben werden: Iterationen, wie sie im Allgemeinen von Scrum bekannt sind, finden auch bei der testgetriebenen Entwicklung Anwendung. Unit Test und die zu testenden Units werden parallel in kleinen, sich wiederholenden Mikroiterationen entwickelt. Die Iterationen sollten hierbei nur wenige Minuten dauern.

In den Iterationen wiederholen sich meist drei Schritte: Im ersten Schritt wird der Test für das gewünschte fehlerfreie Verhalten geschrieben. Dieser Test wird zunächst fehlschlagen. Im zweiten Schritt wird der Programmcode der Unit solange mit möglichst wenig Aufwand angepasst, bis der Test nicht mehr fehlschlägt. Beim dritten Schritt wird der soeben implementierte Codeteil sofort einem Refactoring unterzogen, um zum Beispiel Wiederholungen zu entfernen oder Teile zu abstrahieren, wo es sich anbietet. Dieses Refactoring kann gefahrlos durchführt werden, da jederzeit mit einem Testlauf sichergestellt werden kann, dass die Unit noch korrekt arbeitet.

Diese Schritte werden solange wiederholt, bis die gewünschte Funktionalität der Unit erreicht ist. Durch diese Art der Softwareentwicklung kann eine Software evolutionär und inkrementell entworfen und ständig verbessert werden. Die Unit Tests stellen nach jedem inkrementellen Verbesserungsschritt sicher, dass die Unit weiterhin das oder die gewünschten Requirements abbildet und korrekt bedient.

Refactoring

Pair Programming, mehr aber noch manuelle und automatische Code-Reviews, werden dazu führen, dass bestehende Codeteile einem Refactoring unterzogen werden müssen. Die Ziele von Refactoring-Maßnahmen sind, Quellcode – manuell oder automatisiert – strukturell zu verbessern, ohne die Abbildung der enthaltenen Requirements zu verändern. Durch diese Strukturverbesserungen wird die Lesbarkeit, die Verständlichkeit, und die Wartbar- sowie /Erweiterbarkeit der Programmteile mit dem Zweck, den Aufwand für eine spätere Fehleranalyse oder funktionale Erweiterungen zu senken, erhöht.

Besonders jene Codeteile, die bei automatisierten statischen Softwaretests aufgefallen sind, eigenen sich dafür, diese Regelverletzungen automatisch zu beheben. Hierbei kann zwischen Regelverletzungen, die durch Missachtung von Styling-Regeln entstehen und solchen, die strukturelle Regeln verletzen, unterschieden werden. Erstere lassen sich sehr gut automatisiert beheben; für die Behebung struktureller Regelverletzungen ist zumeist ein manuelles Refactoring erforderlich.

Aufmacherbild: Quality process sticky paper on glass with drops water background von Shutterstock / Urheberrecht: 10 FACE

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -