Software soll zugleich wertschöpfend, kostengünstig, schnell einsetzbar und qualitativ hochwertig sein, aber auch der Entwicklungsprozess soll sich nachvollziehen lassen. Das sind die Herausforderungen vor denen Application Lifecycle Management (ALM) und agile Entwicklung als Lösungsangebote stehen.

Business Technology hat einige ALM-Lösungsanbieter zu diesen Aspekten befragt und wird in den kommenden Wochen deren Antworten veröffentlichen.

Heute: Christian Binder, Platform Strategy Manager, Microsoft Deutschland GmbH

Wie sieht Ihr Modell eines zeitgemäßen Application Lifecycle Managements aus?

Christian Binder: Konzeptionell muss sich ein modernes ALM-Werkzeug durch eine Reihe von Basisfunktionen auszeichnen. Eine hohe Flexibilität und Anpassbarkeit des Entwicklungsprozesses als auch eine nahtlose Toolintegration bei möglichst geringem administrativem Aufwand sind einige davon.

Immer wieder gern unterschätzt ist die Komplexität von Kommunikation, die eines der kritischen Faktoren eines jeden Softwareprojekts darstellt und sich mit der Anzahl der Projektmitarbeiter auch noch potenziert. Eine weitere Hürde, die aber meist erst später im Projekt bemerkt wird, ist das Fehlen eines leistungsfähigen und umfangreichen APIs, das die einfache Erweiterung der ALM-Plattform ermöglicht und somit auch in der Praxis die ALM-Plattform in heterogenen Entwicklungsumgebungen integrierbar macht. Auch müssen für alle beteiligten Rollen des Entwicklungsprozesses wie z.B. Projektleiter, Analysten, Entwickler oder Tester die geeigneten Werkzeuge zur Verfügung stehen. So wird z.B. ein Projektleiter nicht mit einer Entwicklungsumgebung arbeiten wollen, sondern die zeitliche Projektplanung lieber in bekannten Werkzeugen wie z.B. Microsoft Project vornehmen. Nur ein solches System kann bei den vielfach so unterschiedlichen Anforderungen der Entwicklungsteams als solide Grundlage fungieren. Visual Studio Team System bietet hier eine ganzheitliche Lösung. Der Visual Studio Team Foundation Server (TFS) ist das Backend, das Build-, Version Control-, Reporting-, Projektportal- und Prozess-Services zur Verfügung stellt. Hierbei basiert der Team Foundation Server auf einer reinen Web-Service-Architektur, die auch verteilte Entwicklungsteams effizient und sicher anbindet. Auf der Client-Seite konsumieren die Visual Studio Team Suite oder eine der rollenspezifischen Editionen, wie die Developer-, Database-, Tester- oder Architektur-Edition den Team Foundation Server.

So bietet z.B. die Database Edition zusätzliche Funktionen für den DB-Entwickler wie das Versionieren, Abgleich und Deployment des DB-Schemas oder das Erstellen von DB Unit Tests. Projektleiter und Analysten verwenden die Microsoft-Project- und Microsoft-Excel-Integration, um Projektinhalte zu bearbeiten. Für Microsoft Outlook und Microsoft Word gibt es Partnerlösungen, die das Erfassen von Projektinhalten und Anforderungen erheblich vereinfachen. Das Projektportal des Team Foundation Servers dient als zentrale Dokumentenablage und Kommunikationsplattform, die auch den aktuellen Projektstatus via Reports transparent vorhält. Projektleiter bedienen sich aber auch gerne bei Microsoft Excel, um mit Pivot-Tabellen ad hoc Projektdaten aus dem Datawarehouse zu aggregieren. Visual Studio Team System Web Access bietet einen vollwertigen Webclient an, der direkten Zugriff aus dem Browser ermöglicht und somit auch nicht Windows Clients an den TFS anbindet. Für die Eclipse IDE steht eine TFS-Integration von einem Partner bereit, wodurch Java und .Net Teams mit einem Backend, dem TFS, arbeiten können.

Wie passen agile Methoden (Scrum, XP, Lean etc.) zu diesem Modell?

Binder: Visual Studio Team System kann jegliche Entwicklungsmethoden unterstützen, da es auf einer generischen Workflow Engine basiert. Nach der Installation steht automatisch ein agiler (MSF for Agile Software Development) und ein formaler Prozess (MSF for CMMI Process Improvement) zur Verfügung. Frei verfügbar sind verschiedene agile und formale Prozess-Templates, wie z.B. für SCRUM, XP, KANBAN als auch das V-Model XT, RUP usw. Selbstverständlich kann der Entwicklungsprozess via Editor noch angepasst werden, um projektspezifische Anforderungen im Entwicklungsprozess zu realisieren.

Wie unterstützen Ihre Lösungen agile Entwicklungsprojekte? Legt sich der Kunde damit auf eine Methode fest? Lassen sich beispielsweise Testing-Tools oder Projektmanagement-Tools einbinden?

Binder: Visual Studio Team System legt sich nur innerhalb eines Teamprojekts für einen Entwicklungsprozess fest, so können problemlos mehrere Teams auf einem TFS mit unterschiedlichen agilen oder formalen Entwicklungsprozessen arbeiten. Bewährte Development-Praktiken wie z.B. Continuous Integration oder Peer Code Reviews werden direkt unterstützt und helfen agilen Teams, diese schnell zu verwenden.

Das TFS API ermöglicht einen einfachen Weg, andere Tools anzubinden. Viele Hersteller nutzen das API, um Ihre Produkte direkt zu intergieren z.B. Borland CaliberRM, Compuware TestPartner, Mindjet Requirements Manager, Sparx Systems Enterprise Architect, Teamprise, Artiso Workitem Manager usw.

Wo sehen Sie für ALM die Vorteile von agilen Entwicklungsprozessen und wo die Grenzen?

Binder: Agile Vorgehensmodelle werden immer beliebter, da durch die hohe Flexibilität die meisten Projektanforderungen effizienter in den Entwicklungsprozess einfließen, und damit die realen Projektanforderungen besser umgesetzt werden können.

Für die meisten Projekte ist ein agiler Prozess der effizienteste Weg, das Projekt zu realisieren. Für mich ist ein agiler Prozess immer die erste Wahl, dennoch gibt es Projektanforderungen, die sich nur mit einem formalen Prozess abbilden lassen. Werden Zertifizierungen oder besonders hohe Anforderungen an Stabilität und Ausfallsicherheit gefordert, wie es z.B. in der Luftfahrt oder kritischen Prozesssteuerungen gefordert wird, sind formale Prozesse die richtige Wahl. Grundsätzlich definiert also das Projekt den optimalen Prozess. Projektleiter sollten nicht unterschätzen, dass ein Team erst einen neuen Prozess adaptieren muss, also eine gewisse Zeit benötigt, diesen Prozess effizient zu leben und somit erwartet produktiv zu sein. In der Praxis fokussieren Entwicklungsteams aber auf spezielle Domänen, die in der Regel häufig einen Prozesstyp verwenden. Wer allerdings aus historischen Gründen einen formalen Prozess anwendet, sollte nochmals die Anforderungen an den Prozess verifizieren, vielleicht ist ein agiler Prozess eine Option, wodurch das Team deutlich effizienter agieren könnte.

Entwickeln Sie selbst agil? Wie und warum machen Sie das?

Binder: Mehrere Divisionen in Microsoft nutzen agile Prozesse mit VSTS, wobei Scrum weitverbreitet ist. Warum? Weil Sie sich bewährt haben und in Kombination mit Development Patterns, wie z.B. Continuous Integration, Peer Code Reviews, Test Driven Development, Gated Checkins, Code Coverage, Statische Code Analyse, sehr gute Ergebnisse liefern. Momentan (Juli 2008) verwenden in der Developer Division ca. 2500 Entwickler VSTS im Produkt-Development. In Quincy, WA, USA, wird im Datacenter zentral die VSTS-Infrastruktur der Developer Division betrieben, die die weltweit verteilten Teams nutzen. Allein In VSTS Version Control befinden sich 2,607,236 MB komprimierte Daten. Die hohe interne VSTS-Nutzung gibt direkte Impulse für die nächsten VSTS-Generationen, was sich sehr positiv auf den Funktionsumfang und die Stabilität des Produkts auswirkt.