Agile Sofwareentwicklung

Bei der Durchführung von Softwareentwicklungsprojekten entscheiden wir gemeinsam mit dem Auftraggeber welche Vorgehensweise die am besten geeignete für das Projekt und die beteiligten Mitglieder ist. Bei den dabei eingesetzten Vorgehensweisen kann es sich um traditionelle Methoden, wie etwa den Wasserfallprozess, RUP (Rational Unified Process) usw. handeln, oder um agile (Scrum, XP, usw.). Unser Ziel ist es zeitgemäße und qualitativ hochwertige Technologien (state of the art) einzusetzen. Dabei orientieren wir uns am Projekt und den Kundenbedürfnissen die damit gestillt werden sollen. Mit den von uns eingesetzten Mitteln sind wir in der Lage eine Leistungs- und Qualitätssteigerung im Softwareentwicklungsprozess und im späteren Betrieb der Software zu erreichen.

Unsere kundenorientierten Ziele sind:

  • Kostenreduktion
  • Optimale Produtionseinführungszeit
  • Erhöhter Kapitalertrag

Wir kümmern uns um:

  • die Einhaltung allgemein gültiger Standards
  • die Erstellung und Durchführung von Tests für jedes neue Stück Code
  • die richtige Analyse und das daraus resultierende Design der Software
  • die korrekte Handhabung von Transaktionen und Persistenz
  • die Schaffung einer Infrastruktur, die:
    • eine stabile und unkomplizierte Integration neuer Teilentwicklungen ermöglicht
    • ein gutes software build management liefert
    • automatische Code-Analyse ermöglicht
    • kontinuierliche Dokumentation fördert
    • Kollaborationsdienste zur Förderung der Kommunikation bereitstellt

In Bezug auf agile Vorgehensweisen und konkret im Umgang mit Scrum in Kombination mit XP (extreme programming) können wir auf eine langjährige erfolgreiche Vergangenheit zurückblicken. Unser Haus verfügt über Scrum Master, die ihre Zertifizierung von der Scrum Alliance erhalten haben. Durch den Einsatz agiler Vorgehensweisen konnten wir im Softwareentwicklungsprozess unserer Projekte eine enorme Leistungssteigerung verzeichnen, diese sich in der Produktivität wiederspiegelt. Beim Einsatz von Scrum in der Entwicklung eines Softwareproduktes findet eine iterative und inkrementelle Entwicklung statt. Das bedeutet, dass das Produkt mit jeder Iteration, um eine gewisse Anzahl von Funktionalitäten erweitert wird.

Moderne Technologien

Wir sind stets darum bemüht die neuesten Technologien einzusetzen, die verfügbar sind. Abhängig vom jeweiligen Einsatzgebiet entscheiden wir uns für die Tools, die am Besten dafür geeignet sind.

Design

Agile Methoden zielen darauf ab schnelle auf Änderungen reagieren zu können. Aus diesem Grund muss auch das SW Design flexible sein. Die Idee von „Emergent“ Design ist es diese Anforderung an Flexibilität durch schrittweise Implementierung von Funktion gepaart mit kontinuierlichen Refactoring zu realisieren.

Aufgabenbasierte Entwicklung

Alle Implementierungsaufgaben sind mit den Anforderungen verbunden und alle Verbindungen zwischen Artifakte müssen über den ganzen Entwicklungsprozess transparent sein. Die aufgabenbasierte Methode bedeudet alle Änderunge einer Aufgabe auf die SW zu verfolgen und zu dokumenteiren. Zu jedem Zeitpunkt muss sich der Enwickler über sein Handeln bewusst sein und über die erfolgreiche Fertigstellung einer Aufgabe Bescheid wissen. Dies wird über sogenannte „Definition of Done“ und umfassende Akzeptanztests erreicht. Eine Hauptanforderung an den Entwicklungsprozess sollte auch die nahtlose Integration aller beteiligten Werzeuge sein!

Testbarer Code

Die Entwicklung von Software ist ein schwieriger und oft sehr komplexer Prozess. Es gilt, eine Vielzahl an Parametern zu berücksichtigen damit die richtige Funktionsweise des zu erstellenden Produktes erreicht wird. Um nicht erwünschte Seiteneffekte zu vermeiden und weitestgehend ausschließen zu können, bietet sich der Einsatz von Testverfahren an. Mit ihrer Hilfe lässt sich nicht nur prüfen ob ein erstelltes Modul zur Zeit der Entwicklung so funktioniert, wie es von ihm erwartet wird. Auch für später kann auf diese Weise sichergestellt werden, dass sich nichts daran geändert hat. Tests würden das zu Tage bringen sofern sie qualitativ gut genug sind. Zu diesem Zweck setzen wir Werkzeuge wie etwa TestNG/JUnit, Selenium, Cucumber, Robot Framework und viele andere ein. Unsere Tests erstrecken sich über alle Bereiche der Entwicklung. Sie beginnen bei einfachen Unit-Tests, überprüfen die gesamte in der Software abgebildete Geschäftslogik und reichen bis hin zur Gewährleistung der Einhaltung vorgegebener Akzeptanzkriterien.

Continuous Integration

Bei der Entwicklung von Software herrscht meistens, und vor allem in agilen Vorgehensweisen ein sog. Collective Code Ownership. Das bedeutet, dass mehrere Entwickler an der zu erstellenden Software arbeiten und der somit entstehende Quelltext jedem Mitglied des Entwicklungsteams gehört. Ein Problem, das sich daraus ergibt, dass mehrere Entwickler an einem Softwareprodukt Funktionalitäten implementieren, ist neben der korrekten physischen Zusammenführung von Quelltext, die richtige Zusammenführung neu erstellter Funktionalitäten auf technischer sowie auf fachlicher Ebene.

Jeder Entwickler entwickelt den von ihm zu realisierenden Teil der Software lokal an seinem Rechner. Anschließend müssen die neu entwickelten oder erweiterten Komponenten in die Gesamtsoftware „integriert“ (zusammengeführt) werden. Bei genau dieser Zusammenführung besteht die Gefahr der Entstehung eines nicht gewünschten Seiteneffektes. Durch die Implementierung eines neuen Features, kann eine bereits existierende und sich bis zum Integrationszeitpunkt richtig verhaltende Funktionalität unabsichtlich geändert oder so beeinträchtigt werden, dass sie falsch oder überhaupt nicht mehr funktioniert.

Durch den Einsatz von Continuous Integration, einem Prozess, in dem Quelltext von verschiedenen Entwicklern miteinander integriert wird, kann dieser Gefahr weitestgehend entgegengewirkt werden. Ziel ist es, Inkonsistenzen und Inkompatibilitäten zwischen dem Softwarestand auf dem lokalen Rechner der beteiligten Entwickler und dem zentralen Repository zu vermeiden. Mit Continuous Integration Systemen lassen sich Integrationen, also Zusammenführungen des Quelltextes, automatisiert und immer wieder (kontinuierlich) durchführen. Eventuelle Probleme und Konflikte werden frühzeitig erkannt und können sofort behoben werden. Zu diesem Zeitpunkt sind die Zeit, die eine Korrektur in Anspruch nimmt, sowie die anfallenden Kosten am niedrigsten. Der Entwickler weiß nach jedem Durchlauf des Continuous Integration-Prozesses, ob seine Integration erfolgreich war oder nicht.

Es gibt verschiedene Werkzeuge, mit denen man den kontinuierlichen Build-Prozess steuern kann. Darunter sind sowohl kommerzielle Produkte als auch kostenlose. Die bekanntesten unter ihnen sind Cruise Control, Continuum, Hudson und Bamboo.

Continuous Delivery

Das automatisierte Bereitstellen von Software mit verschiedenen Konfiguration auf unterschiedlichen Stufen (Prodution, Testumgebung, Entwicklungsumgebung) is essentiell, damit sich das Team voll und ganz auf die Entwicklung von technischen Funktion konzentrieren kann und die Korrektheit der SW durch Bereitstellen und Testen in der Testumgebung sichergestellt ist.

Die nächste Stufe ist Continuous Deployment und deckt das Gebiet von der automatisierten Bereitstellung und Testen nach jeder Änderunge bishin zum Bereitstellen der SW am produktiven System ab.

Kollaborationsdienste

Innerhalb eines Unternehmens und vor allem innerhalb eines laufenden Projektes ist die Kommunikation und der Informationsaustausch zwischen den Beteiligten von großer Bedeutung. Es ist wichtig, projektrelevante Informationen jederzeit und für Jedermann, der am Projekt beteiligt ist, unverfälscht zugänglich zu machen. Um Wissen innerhalb eines Projektes zu dokumentieren und gleichzeitig für alle Befugten in gleicher Weise zur Verfügung zu stellen, bedienen wir uns diverser Werkzeuge, die das ermöglichen.

  • Issue tracker wie z.B. Jira erlauben es die Ablauforganisation eines Unternehmens abzubilden.
  • Versionsverwaltungssysteme wie etwa Subversion ermöglichen die Nachvollziehbarkeit von Änderungen im Projektverlauf.
  • Die Verwendeung eines WIKI-Webs, wie etwa Twiki dient als eine Art open knowledge base in Form einer Ansammlung von HTML-Seiten.
  • Instant Messaging Systeme wie z.B. Jabber dienen der sofortigen Kommunikation und unterstützen den Informationsfluss der Beteiligten.

Kontinuierliche Dokumentation und Wissensverbreitung

Jedes Projekt wird durch seine Einzigartigkeit gekennzeichnet. Das darin erworbene Wissen sowie die Beschreibung des Projektes sollte zusammen mit den gesammelten Erfahrungen festgehalten werden. Auf diese Weise kann bei Bedarf möglichst schnell auf Informationen zurückgegriffen werden. Wenn Wissen weitergegeben werden kann, kann auf einen langwierigen erneuten Lernprozess verzichtet werden. Bei der Durchführung unserer Projekte erhält die Erstellung von Dokumentation eine sehr starke Gewichtung. Wir erachten nicht nur den erstellten Quellcode als dokumentationswürdig, sondern auch den gesamten Entwicklungsprozess. Wir unterscheiden dabei zwischen einer projektrelevanten und einer teaminternen Dokumentation.

Projektrelevante Dokumentation

Agile Vorgehensweisen erleichtern und unterstützen die Dokumentation von Projekten erheblich. Das Anforderungsmanagement sieht die Verwaltung von Anforderungen in Form von User Stories in einer dafür bestimmten Liste, dem sog. Backlog, vor. Anforderungen, die das zu erstellende Produkt bereits unterstützt und solche, die in der Zukunft umgesetzt werden sollen, sind darin dokumentiert. Daraus lassen sich die Funktionalitäten des Produktes sowie der Zeitpunkt ihrer Fertigstellung sehr leicht ermitteln.

Während des Projektverlaufes sorgen Artefakte wie ein täglich aktualisiertes Taskboard und der daraus abgeleitete Burndown-Chart für Transparenz im Projektfortschritt. Auch sie bilden eine Dokumentation, die zu jeder Zeit Rückschlüsse auf das Projekt erlaubt.

Review Meetings in denen die umgesetzten Anforderungen präsentiert werden und Retrospektiven in denen Reflektionen bezüglich Arbeits- und Vorgehensweisen durchgeführt werden, bieten Plattformen zum Informationsaustausch und ermöglichen den Einsatz von nötigen Verbesserungsmaßnahmen. (dass das alles dokumentiert wird)

Teaminterne Dokumentation

Innerhalb eines Projektteams sind es vor allem langfristige Entscheidungen in Bezug auf Analyse und Design, die dokumentiert werden müssen. Sowohl für langjährige Projektmitglieder als auch für Neuankömmlinge ist es von Vorteil möglichst schnell nachvollziehen zu können, warum ein bestimmter Lösungsweg vorgezogen wurde und welche Strategie sich dahinter verbirgt.

Die Erstellung der Dokumentation sollte nicht als Unterprojekt des eigentlichen Projektes gesehen werden. Sie ist Teil des Entwicklungsprozesses und muss auch als solcher verstanden und angewendet werden.

Die Dokumentation folgender Bereiche sollte auf keinen Fall vernachlässigt werden:

  • How-To: Enthält technische Anleitungen betreffend der Einrichtung der Entwicklungsumgebung, eingesetzter Werkzeuge, Installation der Applikation, Einrichtung der Datenbank, weitere Tipps, die die technische Infrastruktur des Projektes betreffen.
  • Coding-Guidelines: Hier stehen Standards bezüglich der Erstellung von Code, auf die das Team sich geeinigt hat. Auf diese Weise wird ein gemeinsames Qualitätsniveau festgelegt, das jeder zu erreichen bestrebt ist. Reviews stellen hier sicher, dass alle Teammitglieder diese Guidelines einhalten.
  • Technische Dokumentation: Beziehen sich auf die Architektur, Teilbereichen der Software oder daraus resultierenden einzelnen Tasks.
  • Benutzerdokumentation: Zielt auf die zukünftigen Nutzer der Software. Sie sollte als eine Art Gebrauchsanleitung für das Softwareprodukt gesehen werden, die die spätere korrekte Nutzung ermöglicht.

In unserern Projekten erachten wir einen Task erst dann als fertiggestellt, wenn die zugehörige Dokumentation auch abgeliefert wird. Durch das Durchführen von Codereviews bei denen sich der Reviewer aus Verständnisgründen auf das Vorhandensein einer Dokumentation verlassen muss, wird die Erstellung von Dokumentation sichergestellt. Sie sollte vom Implementierer während der Umsetzung erstellt werden. Werkzeuge die im Entwicklungsprozess eingesetzt werden liefern ebenfalls Daten, die in den Dokumentationsumfang aufgenommen werden können.

  • Issue Tracker: Dort aufgeführte Tasks enthalten Beschreibungen der Anforderungen zusammen mit Akzeptanzkriterien, die einzuhalten sind um eine korrekte Abnahme zu ermöglichen.
  • Build Server: Sind in der Lage automatisch generierte Dokumente zu erstellen. Dabei kann es sich z.B. um Javadoc Dateien in Form von HTML-Seiten handeln, die die neu erstellte API beschreiben. Aber auch Code-Metriken, Abhängigkeiten (Dependencies) oder Testberichte können dort generiert werden.
  • Versionsverwaltungssystem: Diese lassen sehr leicht erkennen welcher Teil der Anwendung von wem implementiert wurde. Auch der Verlauf bzw. die Evolution des Projektes lässt sich mittels eines Versionsverwaltungssystems nachvollziehen.

Ein weiterer Punkt, der natürlich nicht vergessen werden darf, ist dass der Quellcode selbst sowie die zugehörigen Tests ebenfalls als Dokumentation gelten.