Agile Entwicklung

Agile Entwicklung und iterative Vorgehensmodelle 3

Die verganenen Teile (Teil 1 & Teil 2) unserer Blogserie haben bereits die Konzepte von iterativer Entwicklung und agilen Vorgehensmodellen aufgezeigt. In diesem dritten und letzten Teil möchte ich einen Einblick in die Praxis bei isiCore bieten und einen Ansatz vorstellen, welchen wir für uns adaptiert haben – doch zuvor noch ein kurzer Exkurs:

Exkurs – Warum viele IT Projekte scheitern

Bevor ich näher auf die Praxis der agilen, iterativen Entwicklung eingehe, möchte ich auf eine kleine Illustration verweisen, welche mir immer wieder in den Sinn kommt, wenn es um Projektmanagement und vor allem um Kommunikation in IT Projekten geht:

Projektmanagement

  1. Wie es vom Kunde beschrieben wurde
  2. Wie der Projektleiter es verstanden hat
  3. Wie es designt wurde
  4. Wie es programmiert wurde
  5. Wie der Berater es beschrieben hat
  6. Wie das Projekt dokumentiert wurde
  7. Was installiert wurde
  8. Was dem Kunden in Rechnung gestellt wurde
  9. Was an Support geboten wurde
  10. Was der Kunde eigentlich gebraucht hätte

(Quelle: projectcartoon.com)

Eine etwas überspitzte Darstellung, die aber doch einiges an Wahrheitsgehalt aus der Praxis beinhaltet. Viel zu viele IT Projekte scheitern irgendwann im Projektverlauf – die gesamte Bandbreite potentieller Ursachen darzustellen würde bestimmt den Rahmen dieses Posts sprengen. Denn bei der Erstellung von Softwarekomponenten, bei der Integration von Systemen oder der Erstellung von Portalen gibt es zahlreiche Anforderungen, die berücksichtigt werden wollen. Oftmals stehen Kunden vor einer Problemstellung und haben vielleicht eine grobe Vorstellung von der gewünschten Lösung – es fehlt jedoch an etwas “Greif- und Erlebbarem” um die Anforderungen konkret zu machen.

Stille Post für Große

Die schriftliche Definition von Anforderungen lässt immer einen gewissen Interpretationsspielraum offen, oftmals wird der direkte Kundenkontakt ausschließlich von Verkäufern/Projektmanagern gepflegt, welcher dann seine Auffassung der ihm herangetragenen Anforderungen an die Entwicklung weitergibt. Diese Form der “Stillen Post” für Große resultiert dann jedoch zumeist nicht mehr in fröhlichem Gekicher und auch nicht in einer weiteren Zusammenarbeit.

Durch eine iterative Entwicklung, bei welcher dem Kunden so früh wie möglich Zugriff auf erste erlebbare Ergebnisse ermöglicht wird, sowie durch eine Kombination von Best-Pratice-Methoden aus der agilen Entwicklung versuchen wir bei isiCore derartige Effekte vorzubeugen. Wie wir das ganze angehen, möchte ich im folgenden erläutern:

Agile Entwicklung in der Praxis – Implementierung eines eigenen Ansatzes

Bei der Vielzahl an agilen Modellen, die sich seit aufkommen der ihnen allen gemeinsamen Ansätze entwickelt haben stellt sich die Frage, welcher Weg denn nun der “richtigerere” ist. Die angestrebten Benefits wie z.B. die Verbesserung der Produktivität im Team, eine durchgehend hohe Qualität der ausgelieferten Komponenten sowie vor allem eine gesteigerte Zufriedenheit auf Kundenseite sprechen klar für sich. Das Umfeld ändert sich jedoch rasant und nicht immer lassen sich vorhandene Modelle problemlos auf die speziellen Anforderungen übertragen.

Aufgrund unserer Erfahrung haben wir eine für uns eigene Vorgehensweise adaptiert, die sich aus unterschiedlichen Teilbereichen bekannter agiler Modelle zusammensetzt und gegebenenfalls aufgrund der jeweiligen Projektanforderungen weiter angepasst wird. Einen eigenen Ansatz zu entwickeln und ein oder mehrere Modelle auf Umfeld, Projekt und Team zu adaptieren wurde bereits 2004 von Vorreiter und Mitgründer der Agile Alliance, Jim Highsmith, propagiert.

Der von uns entwickelte Ansatz für die Praxis setzt sich aus Komponenten folgender Modelle zusammen:

  • Rational Unified Process (RUP) für Projektplanung und Disziplinen
  • Microsoft Solution Framework (MSF) mit living documents für Analyse, Planung und Dokumentation
  • Extreme Programming (XP) für die Realisierung von Programmteilen
  • Unified Modelling Language (UML) für Architekturkonzept und Architekturdokumentation

Rational Unified Process (RUP)

Die Vorgehensweise bei der Realisierung von IT-Projekten hat sich in der Geschichte oft gewandelt, wobei mehrere Modelle entstanden sind wie z.B. V-Modell, RUP, MSF, XP, SCRUM, usw. Für uns hat sich Rational Unified Process als praktikabelster Management-Ansatz herausgestellt, da Aufgaben und Phasen aus unserer Sicht durch dieses Modell am besten definiert sind.

Rational Unified Process

Disziplinen

Die Struktur der Phasen und Iterationen im RUP-Modell teilt sich in Kern-Arbeitsprozesse (Core Workflow):

  • Geschäftsprozessmodellierung (Business Modeling / Business Analysis)
    Im Rahmen der Geschäftsprozessmodellierung gilt es insbesondere Geschäftsprozesse oder Ausschnitte daraus zu dokumentieren. Die Definition von Geschäftsanforderungen und die sich eventuell ergebende Geschäftsprozessoptimierung sind Grundlage zur Vorbereitung einer Automatisierung bzw. IT-Unterstützung der Geschäftsprozesse. In diesen Bereich fallen vor allem die analysierten Anforderungen zur Systemintegration sowie die Planung der Zuständigkeiten im Zusammenhang mit der Websitepflege.
  • Anforderungsanalyse und -management (Requirements)
    Die Anforderungsanalyse zieht sich bis über die Construction-Phase hinaus, ist jedoch besonders bei Projektbeginn sehr ausgeprägt. Hier werden Anforderungen analysiert und definiert sowie laufend angepasst. Das gewonnene Feedback hat über den gesamten Prozess hinweg starken Einfluss auf die Anforderungen.
  • Analyse und Design (Analysis & Design)
    In diesen Bereich fallen vor allem die konzeptionelle Aufbereitung sowie die Software-Architektur für Integration, Design und Struktur.
  • Implementierung (Implementation)
    Im Rahmen der Implementierung werden die Entwicklungsarbeiten durchgeführt. Die Customizing von Systemen, Softwareentwicklung und Oberflächengestaltung. Die Realisierung aller funktionalen und nicht funktionalen Anforderungen ist Teil dieser Disziplin.
  • Test
    Die Erstellung von Testplänen in erster Linie in der Initialisierungs- und Elaborationsphase fallen in diesen Bereich. Aber auch die Erstellung von Unit-Tests und manuellen Tests während der Entwicklungsphase sowie Integrations- und Abnahmetests in der Transitionsphase sind Teil dieser Disziplin.
  • Auslieferung (Deployment)
    Das Deployment umfasst insbesondere die Installation im kundeneigenen Rechenzentrum oder   als Cloud-Service sowie die Inbetriebnahme.

 

und unterstützende Arbeitsprozesse (Core Supporting Workflow):

  • Konfigurations- und Änderungsmanagement (Configuration und Change Management)
    Das Änderungsmanagement nimmt eine wichtige Rolle ein. Neue Anforderungen werden als Change Requests erfasst und fließen nach Abstimmung unmittelbar in das Projekt ein. Absehbare variable Konfigurationseinstellungen werden bereits in der Software berücksichtigt, auch Veränderungen, falls erforderlich.
  • Projektmanagement (Project Management)
    Das Projektmanagement zieht sich durch alle Phasen des Projekts und umfasst die Planung, Steuerung und Kontrolle des Projektverlaufes
  • Infrastruktur (Environment)
    Unter dieser Disziplin wird der Einbezug der Systemlandschaft in sämtliche andere Bereiche (Anforderungen, Analyse, Design, Implementierung, etc.) verstanden. Systemeinrichtung, Backup, Einbindung in die IT Umgebung, Netzwerk- und Zugriffssicherheit sind hier zu sehen.

 

Phasen des RUP

  • Inception
    Diese erste Konzeptionsphase hat das Ziel einer gemeinsamen Vision, eines klaren Zieles sowie der Erstellung eines rudimentären Anwendungsfallmodelles, welches die wesentliche Funktionalität beschreibt sowie einer tentative/provisorischen Architektur. Darüber hinaus werden die wesentlichsten Risiken identifiziert und die Ausarbeitungsphase geplant.
  • Elaboration
    In dieser Phase wird ein Architekturprototyp sowie eine grobe Beschreibung der Anwendungsfälle ausgearbeitet. Planung der Konstruktionsphase, Machbarkeitstests, Systemevaluierung und erste Programmteile von Schlüsselkomponenten sind Teil der Elaborationsphase.
  • Construction
    Nachdem die Architektur ausgearbeitet wurde, konzentriert sich diese Phase auf die Entwicklung und das Testen des Produktes. In dieser Phase werden sämtliche Anforderungen unter laufender Abstimmung mit dem Kunden realisiert.
  • Transition
    Übergabephase und Release der Software an den Kunden.

Elemente des Microsoft Solution Framework (MSF)

Ein Grundsatz des MSF besteht in der Erstellung und Verwendung von living documents. Diese sind versioniert und können bis spät im Projektablauf geändert und ergänzt werden. Die Elemente des MSF sollen im Rahmen des Projektes insbesondere bei der Analyse, Planung und Dokumentation zum Einsatz kommen. Dies beinhaltet beispielsweise die Verwendung einer Source-code-Verwaltung mit Versionierung, womit eine Projektdokumentation sichergestellt wird, wie sie auch von einer ISO-Zertifizierung verlangt wird. Die Source-code Verwaltung stellt die Projektdokumentation nicht sicher, ist jedoch ein wichtiger Teil, der ein Projekt samt Änderungen nachvollziehbar macht und Qualität durch Versionierung von Quelltext schafft.

Ein für uns sehr wichtiger Ansatz besteht im Change-Management. Neue Anforderungen werden als Change-Requests erfasst und fließen nach Abstimmung von Umfang, Ziel und der mit der Änderung verbundenen Kosten in eine neue Version der living documents ein.

Extreme Programming (XP) und Test-driven development

Exteme Programming Elemente, welche zum Einsatz gebracht werden:

  • Pair programming (4-Augen-Prinzip)
  • Iterative Vorgehensweise (auch zu finden in MSF & RUP)
  • Test-driven development (Unit-tests, etc.)

Extreme Programming stellt speziell für kleinere Entwicklungsteams eine sehr gute Lösung dar. Unter Einsatz des XP-Modells kann sehr schnell und effizient entwickelt werden. Neue Funktionalität wird permanent entwickelt, integriert und getestet. Vor und während der Entwicklung werden Testpläne erstellt. Die Software kann laufend über automatisierte Test (sogenannte Unit-tests) getestet werden.

Die Methode geht davon aus, dass die Anforderungen zu Projektbeginn noch nicht komplett bekannt sind und es noch nicht möglich ist, diese hinreichend zu strukturieren bzw. noch nicht alle Informationen vorliegen, um eine verlässliche Aufwandsschätzung über die notwendige Dauer bis zum Abschluss zu geben. Im Laufe eines Projektes ändern sich nicht selten Prioritäten und Gewichtung. Zu Beginn geforderte Funktionen werden möglicherweise in einer anderen Form benötigt oder im Laufe der Zeit sogar komplett überflüssig, während sich zeitgleich an anderer Stelle neue Anforderungen ergeben können.

Ein Grundsatz von XP lautet „Expect Changes“, d.h. es wird davon ausgegangen, dass sich während des Projektverlaufes Änderungen ergeben werden. Durch die kurzen Entwicklungszyklen hat der Kunde jederzeit die Möglichkeit, steuernd auf das Projekt einzuwirken. Dadurch ist es möglich den Projektverlauf aktuellen Anforderungen anzupassen, statt überholten Anforderungen aus einer längst vergangenen Analysephase zu genügen und damit bereits bei Einführung nicht den Vorstellungen zu entsprechen.

Zudem kann durch diesen Ansatz bereits nach kurzer Zeit ein unvollständiges aber zumindest funktionstüchtiges Produkt eingesetzt werden. Die Lösung wird so greifbar und erlebbar, wodurch der Kunde bereits in einem sehr frühen Projektstadium die Kontrolle über die eingeschlagene Richtung wahrnehmen und den weiteren Projektverlauf aktiv beeinflussen kann.

Durch Unit-tests (= Test der kleinsten Einheit) und entsprechen ausgelegte Software-Architektur können Änderungen auch bis spät in den Projekt-Ablauf einfließen ohne das Projekt zu gefährden. Durch „Refactoring“ wird gewährleistet, dass Architektur und Quelltext nicht unter Änderungen leiden. Anforderungen werden voll integriert.

 

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>