Wie seerene die agile Softwareentwicklung verbessert

Apr 10, 2013 | CIO Wissen

Softwareentwicklung ist eine der komplexesten Aufgaben, die es gibt. Deshalb überschreiten Projekte regelmäßig ihre Budgets und Fristen. In der Vergangenheit wurde angenommen, Software-Projekte könnten von Anfang bis Ende geplant werden. Aber moderne Software-Entwicklungsmethoden gehen davon aus, dass Projektpläne oder technische Konzepte, die zu Beginn gemacht worden sind, mit hoher Wahrscheinlichkeit geändert und angepasst werden müssen. Und zwar aufgrund von Änderungen der Anforderungen und Herausforderungen, die sich ergeben, mit denen niemand zu Beginn gerechnet hat. Die neuen Software-Entwicklungsmethoden werden „agile Softwareentwicklung“ genannt.
 

Wie agile Softwareentwicklung funktioniert

Agile Software-Entwicklungsmethoden basieren auf iterativer und inkrementeller Entwicklung, bei denen Anforderungen und Lösungen durch die Zusammenarbeit zwischen selbstorganisierten, funktionsübergreifenden Teams entstehen. Agile Softwareentwicklung befördert adaptive Planung, evolutionäre Entwicklung und Lieferung sowie einen iterativen Ansatz mit Time-Boxing und fördert eine schnelle und flexible Reaktion auf Veränderungen. Es ist ein Rahmenkonzept, das die geplanten Interaktionen während des gesamten Entwicklungszyklus fördert.

Eine weit verbreitete Methode in der agilen Softwareentwicklung ist Scrum. Zusammengefasst funktioniert Scrum wie folgt:

  • Der Product Owner legt die Geschäftsanforderungen für die Software auf einer sehr abstrakten Ebene fest, die als User Stories bezeichnet werden. Eine User Story ist in sich abgeschlossen und nennt eine Aufgabe, die der Benutzer mit der Software durchführen möchte. Sie beschreibt nicht, wie die Software auszusehen hat oder die Anforderungen umgesetzt werden sollen.
  • Sobald der Product Owner alle User Stories erstellt hat, werden diese priorisiert und dem „Scrum-Team“ präsentiert. Das Scrum-Team ist ein Team von Entwicklern, das mit den halbautonomen Arbeitsgruppen in der Automobilindustrie vergleichbar ist. Das Scrum-Team befasst sich mit den User Stories und bewertet, wie viel Aufwand es bedeutet, um jede User Story umzusetzen.
  • Die eigentliche Softwareentwicklung erfolgt in „Sprints“. Sprints sind Zeiträume von etwa zwei Wochen. Im Idealfall ist am Ende eines Sprints eine neue Funktion vollständig implementiert. Diese Vorgehensweise soll Projekte davor bewahren, dass nach vielen Monaten der Programmierung nichts geliefert werden kann, weil wesentliche Teile nicht abgeschlossen wurden. Zu Beginn eines Sprints bestimmt das Scrum-Team, welche User Stories im Sprint umgesetzt werden. Jeden Tag gibt es ein kurzes Sprint-Treffen, bei dem die Fortschritte und Herausforderungen diskutiert werden. Nur zu Beginn eines Sprints werden die Anforderungen und die technische Umsetzung einer User Story definiert. Dies hat den Vorteil, dass Anpassungen und Änderungen bereits in den vergangenen Sprints enthalten sind, sodass die Schaffung von ganzheitlichen Konzepten, die bereits zum Zeitpunkt der Umsetzung überholt sind, vermieden werden kann. Idealerweise werden alle geplanten User Stories am Ende des Sprints realisiert. Wenn nicht, werden die nicht abgeschlossenen User Stories im nächsten Sprint umgesetzt, in dem dann weniger neue User Stories geplant und umgesetzt werden.
  • Ein zentrales Element der Scrum-Methode ist Transparenz. In Bewertungen am Ende eines jeden Sprints, werden die Fortschritte, begegneten Herausforderungen und Optimierungsmöglichkeiten diskutiert. Zum Beispiel, wenn nicht alle geplanten User Stories im Sprint abgeschlossen wurden, wird untersucht, was war der Grund für die Beendigung der User Stories war, um so die Planungssicherheit für die Zukunft zu verbessern.
  • Die Fertigstellung des Projekts wird in Grafiken dokumentiert, in denen beispielsweise noch nicht implementierte User Stories von der linken zu den bereits umgesetzten User Stories auf der rechten Seite wandern. Auf diese Weise können alle Teilnehmer einen schnellen Überblick darüber gewinnen, was erreicht worden ist und was noch zu tun bleibt.

Im Vergleich zu den Software-Entwicklungsmethoden der 1980er und 1990er Jahre sowie dem frühen neuen Jahrtausend, stellen die agilen Software-Entwicklungsmethoden einen Quantensprung dar. Während in der Vergangenheit zu Beginn eines Projekts, eine Menge Daten und Dokumente erstellt wurden, die teilweise bis zum Zeitpunkt der Umsetzung komplett überarbeitet werden mussten, nehmen agile Software-Entwicklungsmethoden an, dass Dinge sowieso anders als geplant passieren. Es ist also sinnvoll, die Details so spät wie möglich zu definieren und Störungen in den Prozess miteinzubeziehen.
 

Code-Qualität in agiler Softwareentwicklung bewerten

Agile Softwareentwicklung konzentriert sich vor allem auf die Änderbarkeit und Erweiterbarkeit der Software. Die meiste Zeit wird Funktionalität im ersten Sprint nur durch Prototypen umgesetzt, um so schnell wie möglich Feedback vom Product Owner zu erhalten und die Software dementsprechend anzupassen. Daher muss es möglich sein, den Code einfach anzupassen und zu verändern.

Dies führt zu der Frage: Wie kann ich es schaffen, Code zu entwickeln, der einfach immer und immer wieder neu geformt werden kann? Agile Softwareentwicklung könnte mit Töpfern verglichen werden, wo der Ton wieder und wieder geformt wird, bis er die perfekte Skulptur ergibt. Daher besteht die Herausforderung darin, den Code von Anfang formbar zu halten. Dies ist nur möglich, wenn die Komplexität gering gehalten wird, sodass der Code leicht zu verstehen ist und gut strukturiert werden kann, anstatt monolithische Codeeinheiten aufzubauen.

Um die Code-Qualität zu bewerten, setzen agile Software-Entwicklungsmethoden auf Code-Reviews. Dies bedeutet, dass der Code eines Entwicklers durch einen zweiten oder dritten Entwickler bewertet wird. Leider sind Code-Reviews sehr zeitaufwendig und damit teuer.
 

Code-Qualität in agiler Softwareentwicklung managen

Das Vorbild für agile Softwareentwicklung ist die Automobilindustrie. In den 1980er Jahren erkannte die Automobilindustrie, dass es sehr viel kostengünstiger ist, wenn ein Arbeiter, der einen Fehler entdeckt hat, das Fließband stoppt, anstatt das Auto nach der Montage wieder auseinander zu nehmen, um die Mängel zu beseitigen. Während Montage-Fehler in der Automobilindustrie einfach entfernt werden können, da ein Teil nicht montiert werden kann oder eine Lampe nicht leuchtet, wirft dies die Frage auf, wie Fehler in etwas so komplexem wie Software zu finden sind?

Neben Fehlermeldungen, die von der Entwicklungsumgebung in der Compilierungsphase ausgewiesen werden, bietet die Scrum-Methode nicht viel Unterstützung. Nach Angaben der Scrum-Methode wird die Qualität der Software in einem Sprint-Review nach einem Sprint analysiert. Wie dies geschieht, ist jedoch nicht definiert. Auch die zahlreichen Projekt-Management-Software-Lösungen, die den Scrum-Prozess ganz gut unterstützen, bieten hier wenig Hilfe.

Um zu beurteilen, wie stabil, wie leicht zu pflegen und zu erweitern die Software ist, bedarf es eines Code-Reviews. Und hier sind wir wieder bei den typischen Problemen von Software-Entwicklungsprojekten, über die wir bereits in diesem Blog berichtet haben: Ein Code-Review ist zeitaufwendig und kompliziert. Besonders für große Projekte und wenn Zeitdruck hinzu kommt, lassen sich diese einfach nicht in angemessener Dauer umsetzen. Hier kommt seereneTM ins Spiel.
 

Wie seereneTM in der agilen Softwareentwicklung hilft

Mit seereneTM können nach jedem Sprint automatisierte Code-Reviews durchgeführt werden. Diese verdeutlichen die genaue Reife der neu entwickelten Funktionalität. Darüber hinaus zeigt seereneTM genau, in welchem Code-Segment Refactorings im nächsten Sprint nützlich sind, um die langfristigen Kosten für Wartung und Erweiterungen so gering wie möglich zu halten. Mit ihren Softwarekarten passt seereneTM deshalb ausgezeichnet zum Transparenz-Ansatz von Scrum.

Wenn die Softwarekarten zum Beispiel auf die anderen Grafiken der Scrum-Methode übertragen werden, kann das gesamte Management-Team die Handlungsfelder auf einen Blick erkennen und sie in die Planung des nächsten Sprints einbeziehen.

Pin It on Pinterest