Mit Agile, Scrum und Co.

Die drei größten Herausforderungen der IT-Entwicklung

06.03.2013 von Markus Maurer
Die Entwicklungs- und Bereitstellungsprozesse für wichtige Geschäftsanwendungen verändern sich. Darauf müssen Entwickler reagieren. Wir zeigen wo Probleme lauern.
Die drei größten Herausforderungen der IT-Entwicklung.
Foto: Fotolia, Surflifes

Die Veränderungen betreffen geschäftskritische Applikationen wie zum Beispiel Softwaresysteme der Banken, die den Betrieb von Geldautomaten steuern. Auch Online-Werkzeuge für Vertriebs- und Supportaufgaben oder webbasierte IT-Dienste öffentlicher Behörden zur Informierung der Öffentlichkeit sind typische Beispiele für diesen Trend.

Aufgrund neuer Geräteplattformen und Bereitstellungstechnologien stoßen die bisherigen Strategien zur Applikationsentwicklung dabei an ihre Grenzen. Je größer der Bedarf ist, desto schwieriger wird es, die hohen Zugriffszahlen und den Support der Systeme sicherzustellen. Neue Entwicklungsmethoden wie Agile, Scrum und Kanban erhöhen die Produktivität der Entwickler und werden den wachsenden Geschäftsanforderungen gerecht, aber sie wirken sich auch auf den gesamten Abstimmungsprozess aus.

Agile Softwareentwicklung 2010
ActiF
Requirement-Management (RM) und Implementierung (IMP) sind ist voll abgedeckt, keine Unterstützung gibt es für Wartung (W) und Betrieb (B). Auch der Test (T) ist schwach ausgeprägt. Besser schneidet AcriF bei der Integration (INT), Projekt-Management (PM), Qualitäts-Management (QM) und Systemdesign (SD) ab.
Adaptive Software Development (ASD)
ASD schneidet nur im Qualitäts-Management (QM) sehr gut ab. Disziplinen wie Integration (INT), Wartung (W), und Betrieb (B) werden überhaupt nicht abgedeckt. Projekt- und Requirement-Management (PM/RM), Systemdesign (SD), Implementierung (IMP) und Test (T) sind schwach ausgeprägt.
Agile Enterprise
Agile Enterprise leistet vollständige Unterstützung in den Bereichen Projekt-Management (PM), Requirements-Management (RM), Implementierung (IMP) und Test (T). Nicht ganz so gut sieht es bei der Integration/Einführung (INT), dem Qualitäts-Management (QM) oder dem Systemdesign/technische Konzeption (SD) aus. Schwachpunkt ist die Wartung (W), für den Betrieb (B) kommt überhaupt keine Unterstützung.
Agile Model Driven Development
AMDD deckt unter den Disziplinen des Software Engineering die des Test (T) vollständig ab. Gute Unterstützung gibt es auch für die Bereiche Integration/Einführung (INT), Wartung (W) und Betrieb (B) sowie für Implementierung (IMP). Auf mittlerem Niveau bewegen sich das Qualitäts-Management (QM), Requirements-Management (RM) und das Systemdesign/technische Konzeption (SD) während für Projekt-Management (PM) nur wenig Unterstützung kommt.
Behavior Driven Development
Behavior Driven Development schneidet nur im Requirements-Management (RM) sehr gut ab, gefolgt vom Qualitäts-Management (QM). Keine Punkte gibt es im Bereich Wartung (W), Betrieb (B) und Projekt-Management (PM). Die Disziplinen Systemdesign (SD), Implementierung (IMP), Test (T) und Integration (INT) schwächeln.
Crystal
Crystal hat seine Stärke im Bereich Test (T), auch das Qualitäts-Management (QM) und die Implementierung (IMP) werden gut abgedeckt. Mittel bis schwach ausgeprägt sind dagegen Projekt-Management (PM), Requirement-Management (RM), Integration/Einführung (INT) und Wartung (W). Keine Unterstützung gibt es für Betrieb (B) und Systemdesign/technische Konzeption (SD).
Design Driven Development
D3 unterstützt nur wenige Disziplinen im Software Engineering. Am ehesten gilt dies noch für das Requirement-Management (RM), schwache Abdeckung gibt es auch in den Bereichen Systemdesign/technische Konzeption (SD), Implementierung (IMP), Test (T) und Qualitäts-Management (QM). Keine Unterstützung gibt es für Integration/Einführung (INT), Wartung (W), Betrieb (B) und Projekt-Management (PM).
Dynamic System Development Method
DSDM spiel seine Stärken in den Bereichen Requirements-Management (RM), Systemdesign/technische Konzeption (SD), Implementierung (IMP), Test (T) und Integration/Einführung (INT) aus. Weniger gut werden die Aspekte der Wartung (W), des Betriebs (B) sowie des Projekt- (PM) und Qualitäts-Managements (QM) abgedeckt.
Eclipse Way Process
Aufgrund der Kombination unterschiedlicher Techniken im Eclipse Way Process ergeben sich zahlreiche Stärken. Disziplinen im Software Engineering, die vollständig abgedeckt werden, sind Projekt-Management (PM), Requirements-Management (RM), Systemdesign/technische Konzeption (SD), Implementierung (IMP) und Test (T). Nicht ganz so gut schneidet Integration/Einführung (INT) ab. Eine schwache Abdeckung gibt es für Wartung (W) und Qualtitäts-Management (QM), während Betrieb (B) überhaupt nicht unterstützt wird.
Evolutionary Process For Integrating Cots-Based Systems (Epic)
Epic hat seine besondere Stärke im Projekt-Management (PM). Recht gut abgedeckt werden auch Qualitäts-Management (QM), Requirements-Management (RM), Systemdesign/technische Konzeption (SD), Test (T) und Integration/Einführung (INT). Mittlere Abdeckung gibt es für den Bereich Implementierung (IMP), während Wartung (W) und Betrieb (B) überhaupt keine Unterstützung finden.
Evolutionary Project Management & Product Development (EVO)
Projekt-Management (PM) und Test (T) sind die Stärken des EVO-Vorgehens. Schwächer fallen Systemdesign/technische Konzeption (SD), Qualitäts-Management (QM), Requirements-Management (RM), Implementierung (IMP) und Integration/Einführung (INT) aus. Die Bereiche Wartung (W) und Betrieb (B) werden überhaupt nicht abgedeckt.
Extreme Programming
Extreme Programming (XP) deckt unter den Disziplinen des Software Engineering die Implementierung (IMP) und den Test (T) vollständig ab. Gute Unterstützung gibt es auch für die Bereiche Qualitäts-Management (QM) und Requirements-Management (RM). Mittlere Abdeckung erfährt das Systemdesign/technische Konzeption (SD) sowie die Integration/Einführung (INT), während Wartung (W) und Projekt-Management (PM) nur schwach ausgeprägt sind. Der Betrieb (B) ist nicht abgebildet.
Feature Driven Development
FDD deckt die Aspekte des Systemdesign/technische Konzeption (SD) vollständig ab. Nicht ganz so gut sieht es beim Projekt-Management (PM), Qualitäts-Management (QM), Requirements-Management (RM) und bei der Implementierung (IMP) aus. Wenig Abdeckung gibt es für Test (T) und Integration/Einführung (INT). Wartung (W) und Betrieb (B) werden überhaupt nicht unterstützt.
Iconix
Iconix deckt die Bereiche Qualitäts-Management (QM), Requirements-Management (RM), Systemdesign (SD), Implementierung (IMP) und Test (T) vollständig ab. Recht gut ist die Methode auch, wenn es um die Integration (INT) und das Projekt-Management (PM) geht. Defizite gibt es bei der Wartung (W), der Betrieb (B) wird überhaupt nicht berücksichtigt.
Internet-Speed Development
Internet-Speed Development ist im Bereich Integration und Einführung (INT) hervorragend. Keine Abdeckung erfährt der Bereich Wartung (W) und Qualitäts-Management (QM). Mäßige bis gute Abdeckung erzielt die Methode bei Betrieb (B), Projekt-Management (PM), Requirements-Management (RM), Systemdesign/technische Konzeption (SD), Implementierung (IMP) und Test (T).
Lean Software Development
Lean Software Development zeigt seine Stärken vor allem in den Bereichen Qualitäts-Management (QM) und Test (T). Auch das Systemdesign/technische Konzeption (SD) und die Implementierung (IMP) sind gut abgedeckt. Vergleichsweise schwach ausgeprägt sind dagegen die Bereiche Requirements-Management (RM), Integration und Einführung (INT), Wartung (W), Betrieb (B) und Projekt-Management (PM).
Microsoft Solutions Framework (MSF)
Das Microsoft Solutions Framework for Agile Software Development deckt die Bereiche Projekt-Management (PM), Implementierung (IMP) und Test (T) gut ab. Mittlere Unterstützung gibt es für Qualitäts-Management (QM), Requirements-Management (RM), Systemdesign/technische Konzeption (SD)sowie Integration/Einführung (INT). Wartung (W) und Betrieb (B) erfahren dagegen keine Abdeckung.
Mobile-D
Gute bis mittlere Abdeckung bietet Mobile-D für die Software-Engineering-Disziplinen Test (T), Implementierung (IMP), Requirements-Management (RM), Qualitäts-Management (QM) und Projekt-Management (PM). Schwach ausgeprägt sind Systemdesign/technische Konzeption (SD) und Integration/Einführung (INT). Keine Unterstützung gibt es für Wartung (W) und Betrieb (B).
Rapid Application Development
RAD deckt die Belange der Implementierung (IMP) voll ab, gut ist die Methode in den Bereichen Test (T) und Integration/Einführung (INT). Mittlere bis schwache Abdeckung gibt es fürs Requirements-Management (RM), Qualitäts-Management (QM), Projekt-Management (PM) und für die Wartung (W). Systemdesign/technische Konzeption (SD) und Betrieb (B) sind nicht berücksichtigt.
Scrum
Scrum punktet in den Software-Engineering-Disziplinen Projekt-Management (PM) und Requirements-Management (RM). Gut abgedeckt sind auch das Qualitäts-Management (QM) und die Integration/Einführung (INT). Nur mäßige Unterstützung gibt es dagegen für Systemdesign/technische Konzeption (SD), Implementierung (IMP), Test (T) und Wartung (W). Der Betrieb (B) ist nicht abgedeckt.
Test Driven Development
Seine Stärken zeigt TDD naturgemäß im Bereich Test (T), aber auch bei der Implementierung (IMP). Gute bis mittlere Abdeckung gibt es für das Qualitäts-Management (QM) und die Integration/Einführung (INT), während Wartung (W) und Requirements-Management (RM) nur schwach ausgeprägt sind. Keine Unterstützung erfahren die Disziplinen Betrieb (B), Projekt-Management (PM) sowie Systemdesign und technische Konzeption (SD).
Unified Process
Unter den Disziplinen im Software Engineering deckt UP das Requirements-Management (RM), das Systemdesign/technische Konzeption (SD) und die Implementierung (IMP) vollständig ab. Gute Unterstützung gibt es auch für die Bereiche Test (T) und Integration/Einführung (INT). Schwach ausgeprägt sind dagegen die Wartung (W), das Projekt-Management (PM) und das Qualitäts-Management (QM). Den Betrieb (B) unterstützt die Methode nicht.
Agile Unified Process
Der Agile Unified Process (AUP) deckt die Disziplinen Projekt-Management (PM) und Implementierung (IMP) vollständig ab. Gute Unterstützung kommt auch für das Requirements-Management (RM), das Systemdesign/technische Konzeption (SD), den Test (T) und die Integration/Einführung (INT). Schwach ist die Methode dagegen in den Bereichen Qualitäts-Management (QM) und Wartung (W), während der Betrieb (B) überhaupt nicht unterstützt wird.
Essential Unified Process
EssUP hat seine Stärken in den Software-Engineering-Disziplinen Projekt-Management (PM), Systemdesign/technische Konzeption (SD) und Implementierung (IMP). Gut abgedeckt sind auch Test (T), Integration/Einführung (INT) und Requirements-Management (RM). Etwas schwächer ist die Methode beim Qualitäts-Management (QM) und bei der Wartung (W) - der Betrieb (B) wird überhaupt nicht unterstützt.
Open Unified Process
Der Open Unified Process deckt die Software-Engineering-Disziplinen Projekt-Management (PM), Requirements-Management (RM), Systemdesign/technische Konzeption (SD) und Implementierung (IMP) vollständig ab. Auch die Bereiche Test (T) und Integration/Einführung (INT) werden gut unterstützt. Schwach ist OpenUP dagegen bei der Wartung (W), während der Betrieb (B) überhaupt nicht berücksichtigt wird.
Usability Driven Development
Usability Driven Development besitzt seine Stärken in den Bereichen Test (T) und Integration/Einführung (INT). Gut bis befriedigend ist die Methode auch beim Qualitäts-Management (QM), Requirements-Management (RM), Systemdesign/technische Konzeption (SD), bei der Implementierung (IMP) und beim Projekt-Management (PM). Schwächen gibt es bei der Wartung (W), der Betrieb (B) wird nicht unterstützt.

Herausforderung Nummer 1: Wirtschafts- oder IT-Vorgaben?

Jede Methode zur Applikationsentwicklung führt zu anderen Konsequenzen und wirkt sich unterschiedlich auf den Gesamtprozess aus. So ist eine häufige Fehlerquelle, wie Anfragen innerhalb des Unternehmens nach Applikationsfunktionen und –aktualisierungen gehandhabt werden, oder aber wie das Release-Management für Neuentwicklungen im Unternehmen erfolgt. Im Spannungsfeld zwischen Anforderungen an Geschäftsvorgaben und IT-Betrieb entstehen häufig zeitliche Verzögerungen — mit den entsprechenden, finanziellen Folgekosten. Für unproduktive Kommunikationsabläufe kann es die unterschiedlichsten Gründe geben. Bei den meisten Unternehmen liegt es daran, dass Workflow-Abfolgen und –Auswirkungen unterschiedlich beschrieben werden, Übergabeprozesse nicht geregelt sind und Änderungen manuell durchgeführt werden.

Die Kernproblematik dabei ist die klassische Frage, ob Wirtschafts- oder IT-Vorgaben im Vordergrund stehen. Zwar gibt es noch die eine oder andere Firma, die Geschäftsführung und IT-Verantwortung strikt trennt, aber das ist mittlerweile die Ausnahme. Lange schon ist die IT-Abteilung nicht mehr ein abgesondertes Fachgremium, das mit Hintergrundaufgaben betraut ist. In den meisten Firmenzentralen hat sich vielmehr die Erkenntnis durchgesetzt, dass es ein entscheidender Wettbewerbsvorteil ist, aus der vorhandenen Laufzeitumgebung das Maximale herauszuholen. Im Rahmen ihrer Tätigkeit müssen Entwickler dabei geschäftliches Fachwissen für die Fertigstellung ihrer Programme und Werkzeuge nachweisen. Dieser Trend hin zu einer stärkeren Kundenorientierung der IT sorgt für eine gemeinsame Sprache und hilft der Entwicklungs- und Geschäftsabteilung bei der Vermeidung von Missverständnissen.

Herausforderung Nummer 2: Übergabe zwischen verschiedenen Entwicklungsschritten im Gesamtprozess.

Die Übergabe an verschiedenen Stufen des Entwicklungsprozesses ist ebenfalls kritisch. Viele Unternehmen haben deshalb in die Automatisierung ihrer IT-Entwicklung investiert. Allerdings gelingt es nur wenigen Organisationen, die wichtigen Komponenten des Application-Lifecycle-Prozesses miteinander zu verbinden und so die Lücke zwischen Applikationsentwicklung und operativem Geschäft zu schließen. Für eine zuverlässige Anwendungsbereitstellung müssen Organisationen die Entwicklung besserer Applikationen mit flüssigeren Prozessabläufen kombinieren und die Software-Auslieferung auf Endanwenderseite beschleunigen.

Das unabhängige Marktforschungsinstitut Gartner warnt vor großen Software-Programmteilen, die nur in IT-Silos im Rahmen des Entwicklungsprozesses vorliegen. Aus Sicht der Analysten sind die Gründe dafür, dass die Entwicklungsteams gewachsen oder mit einer größeren Zahl an Softwareprogrammen befasst sind als zuvor. Für das Management der verschiedenen Programmierschritte und für das operative Geschäft wären aber automatisierte und integrierte Prozessabläufe notwendig. Der Trend geht also zu einer Orchestrierung der Applikationsentwicklung, was nicht gleichbedeutend mit der Abkehr von allen bisher eingesetzten Werkzeugen und Lösungen ist. Vielmehr sollten Unternehmen diese Technologien in den Gesamtablauf integrieren und weiter nutzen.

Herausforderung Nummer 3: Manuelle Anpassungsprozesse.

Beim Release-Management gibt es in den meisten Unternehmen keine automatisierten Prozesse zur korrekten Auslieferung von sorgfältig programmierten Applikationen. Häufig erfolgt die Bereitstellung über immer wieder neu erstellte Skripte und manuelle Anpassungsprozesse, die Mitarbeiter unnötig binden. Paradoxe Folge: IT-Entwickler programmieren einerseits Anwendungen, die Geschäftsabläufe optimieren, nutzen die Vorteile der Technologien aber nicht selber. Wie bei der Programmierung sollten sie auch bei der Auslieferung höchste Qualitätsmaßstäbe ansetzen und die Release-Management-Prozesse automatisieren. Auf diese Weise verhindern sie, dass für den Bereitstellungsprozess unnötig viel Zeit und Arbeitsaufwand anfällt. Zugleich vermeiden sie eine häufige Ursache fehlgeschlagener Installationen.

Zur Optimierung ihrer Application-Delivery-Strategie müssen Unternehmen sich einer Reihe unbequemer Fragen stellen. Werden wir besser, schneller und effizienter bei der Anwendungsbereitstellung? An welchen Stellen haben wir Engpässe? Welche Abhängigkeiten erhöhen die unternehmerischen Risiken? Halten wir die Kostenobergrenze ein? Und können wir unsere Applikationen planmäßig ausliefern? Bei allen Entwicklungsprozessen im Unternehmen ist es essenziell, diese Leistungskennzahlen hinsichtlich Fortschritt und Erfüllungsgrad einsehen zu können.

Der nächste Schritt beim Application Lifecycle Management

Ein weiterer Fragenkatalog zielt auf die Herangehensweise der Entwicklungsteams und wie sie sich auf das Application-Lifecycle-Konzept auswirkt. Beispiel agile Softwareentwicklung und die Folgen für das Release-Management: Im Rahmen eines agilen Softwareentwicklungsprozesses sollen Programmierteams effektiver und unbürokratischer arbeiten können. Allerdings bewirkt der Wechsel von vierteljährlichen Status-Updates zuschnellen Codereviews auch, dass die Anzahl von Releases um den Faktor zehn nach oben schießt. Das Release-Management-Team steht daher unter größerem Druck, die identifizierten Probleme ohne Zusatzbudget zu lösen.

Der Software-Bereitstellungsablauf in Produktionsumgebungen ist der sensibelste Teil des Applikationsentwicklungsprozesses. Eine größere Prozessautomatisierung vermeidet hier unerwünschte Auswirkungen, insbesondere zu Beginn und am Ende des Entwicklungszyklus. Nur durch Automatisierung können Unternehmen eine größere Produktivität ohne bedeutende Neuinvestitionen erreichen. Der Zwang zu manuellen Bereitstellungsprozessen entfällt, wiederkehrende Abläufe lassen sich beschleunigen und unnötige Kosten vermeiden.

Der nächste Schritt bei der Anwendungsbereitstellung ist es, den gesamten Lebenszyklus von Applikationen unternehmensweit im Gesamtüberblick zu behalten. Dazu gehört, dass der Application-Delivery-Prozess im Unternehmen transparenter wird und dass die Entwicklungsabteilung entlastet wird. Durch Orchestrierung der IT-Abläufe gekoppelt mit zuverlässigen Prozessen zur Applikationsbereitstellung lassen sich Wertschöpfungspotenziale und die aktuelle Infrastruktur optimal nutzen,um für den Geschäftserfolg wegweisende Applikationen zu entwickeln. (ph)