Produktivität ist eine wichtige Kennzahl in der Softwareentwicklung. Sie bestimmt, welchen Softwareumfang eine Organisation unter Einhaltung bestimmter Qualitätskriterien mit einem bestimmten Aufwand erstellen kann. Über unsere Erfahrungen mit ihrer Messung und Optimierung haben wir schon mehrere Beiträge veröffentlicht. Eine hohe Produktivität in der Softwareentwicklung alleine sagt jedoch noch nichts darüber aus, wie schnell ein neues Feature einer Anwendung in Produktion für die Anwender nutzbar ist – die sogenannte Time to Production. Damit beschäftigt sich meine neue Beitragsserie.
Beitragsserie: "Time to Production"
- Wie viel Agilität ist gut für die Softwareentwicklung?
- DevOps – der agile Systembetrieb
- DevSecOps – die Deployment-Pipeline für sichere Software
Was bedeutet “agil”?
Kaum ein Buzzword wurde in den letzten 15 Jahren so missverständlich verwendet wie “agil”. Dabei haben sich einige falsche Assoziationen bis heute gehalten – beispielsweise: “Agile Softwareentwicklung ist Scrum”. Das ist falsch, denn Scrum ist eines von vielen agilen Vorgehensmodellen. Zudem dürfte es aufgrund von Eigenschaften wie Timeboxing (der Endtermin eines Sprints ist fix, nur dessen Umfang ist variabel) und dem Fehlen eines Projektleiters (es gibt nur einen Scrum Master, den Moderator eines selbstorganisierenden Teams) in der kommerziellen auftragsbezogenen Softwareentwicklung selten zu finden sein. Ein weiteres Märchen ist, dass agile Softwareentwicklung neu ist oder mit dem Agilen Manifest erfunden wurde. Ansätze finden sich bereits im 1986 beschriebenen Spiralmodell von Boehm. Ohne Zweifel steht jedoch das Adjektiv “agil” in vielen Teilbereichen der Softwareentwicklung für Eigenschaften, die einer schnellen Bereitstellung neuer, funktionierender Software sehr förderlich sind.
Die agile Aufbauorganisation
Unsere Erfahrungen belegen, dass agile Teams mit möglichst wenig starren Rollen und Spezialisierungen produktiver sind und eine bessere Qualität produzieren. Eine kollektive Verantwortung für die Qualität, ein offener Umgang mit Wissen und eine Belohnung der Teamleistung bringen die Organisation weiter als Flaschenhälse, die durch die Verfügbarkeit einzelner Experten verursacht werden. Hier bewahrheitet sich die alte Weisheit, dass das Team mehr ist als die Summe der einzelnen Mitglieder. Als erfolgskritisch erweist sich auch immer wieder die Zusammenarbeit mit dem Kunden, Auftraggeber bzw. Produktverantwortlichen. Je enger der Product Owner in die Arbeit des Teams einbezogen ist, desto zielführender kann feinjustiert werden: Entscheidungen werden schneller getroffen und späte Änderungen vermieden.
Automatisierung ist der Schlüssel zur Continuous Delivery
Eine wichtige Grundvoraussetzung für die schnelle Verfügbarkeit eines neuen Features sind naturgemäß kurze Entwicklungszyklen – von der Analyse einer Anforderung über die Konzeption bis zur Bereitstellung des funktionierenden Codes in der lauffähigen Anwendung. Viele der Prozessschritte lassen sich mit den heute zur Verfügung stehenden Werkzeugen gut automatisieren. Die Stichworte lauten hier modellbasierte Entwicklung und Codegenerierung, kontinuierliche Integration mit automatischer Codeanalyse und automatisierte funktionale Tests mit nachfolgendem Deployment auf einem produktionsnahen System. Dabei sind der Automatisierung allerdings Grenzen gesetzt, denn nur der Mensch selbst kann entscheiden, wie ein fachliches Feature im Hinblick auf die beste User Experience umzusetzen ist und wie robust die Umsetzung gegenüber ungeplanter Verwendung durch einen Anwender oder gezielten Angriffen durch einen kreativen Hacker sein muss.
Agiles Projektmanagement
In jedem Entwicklungsprozess müssen aus den umzusetzenden Anforderungen Aufgaben abgeleitet, aufgrund ihrer Abhängigkeiten priorisiert, Risiken identifiziert sowie die auftragskonforme Abarbeitung der Aufgaben kontrolliert und gelenkt werden. Unsere Erfahrung ist, dass dies keine Tätigkeit ist, die man einem selbstorganisierenden Team überlassen sollte, sondern dass diese von einem Projektleiter ausgeführt werden muss. Agil wird das Projektmanagement durch den geschickten Einsatz von Tools. Dabei ist besonders die Verwendung eines Ticketing-Systems wie beispielsweise Jira von Vorteil. Hier werden Aufgaben durch Tickets abgebildet und die Bearbeiter gewährleisten durch die zeitnahe Pflege des Ticketstatus sowie der Fertigstellungsgrade und das Buchen der benötigten Arbeitszeit eine größtmögliche Transparenz über den Projektfortschritt. Besonders bewährt hat sich die Verwendung des Pull-Prinzips, bei dem der Bearbeiter ein neues Ticket erst dann aus der Menge der noch offenen Tickets “zieht” (durch Statusänderung), wenn er auch Zeit für seine Bearbeitung hat und das letzte Ticket abgeschlossen wurde. Ein einfaches Prinzip, das – wie viele scheinbar neue Errungenschaften agiler Vorgehensmodelle – nicht wirklich neu ist: Die Toyota Motor Corporation hat mit dem Pull-Prinzip bereits 1947 unter der Bezeichnung Kanban ihre Produktivität gegenüber den Mitbewerbern aus Europa und den USA entscheidend steigern können.
Standardisierung und Wiederverwendung
Zu einem agilen Anforderungs- und Produktmanagement gehören Standardisierung und Wiederverwendung: Standardisierung reduziert den Aufwand zur Umsetzung von Anforderungen, Wiederverwendung vermeidet ihn meist völlig. Aktuelle Messungen belegen die um einen Faktor bis 200 höhere Produktivität bei der Entwicklung individueller Anwendungen auf Basis wiederverwendeter Komponenten und einem hohen Standardisierungsgrad. Zu diesem Thema empfehle ich auch den Beitrag “Individueller Standard: Mass Customization in der Softwareentwicklung”.
Ohne Erfolgskontrolle keine Verbesserung
Neben Retrospektiven des Teams sind Metriken und regelmäßige Messungen wichtige Hilfsmittel, um Verbesserungspotenziale zu finden und die Wirksamkeit umgesetzter Maßnahmen zu überprüfen (siehe zu diesem Thema auch: “Produktiver Durchblick: Monitoring in der Softwareentwicklung”). Dabei sind Entwicklungsrichtung und Kontinuität des Kennzahlenverlaufs wichtiger als die Geschwindigkeit: Viele kleine Schritte in die richtige Richtung führen zuverlässig zum Ziel.
Alle beschriebenen Maßnahmen sind charakteristisch für die agile Softwareentwicklung und dienen dem Ziel, neue Anforderungen eines Product Owners möglichst schnell nutzbar zu machen, d.h. einer möglichst kurzen Time to Production. Das Problem an dieser Betrachtung ist jedoch, dass der Entwicklungsprozess bei der Übergabe eines Change an den Betreiber endet und eine noch so schnelle Entwicklung neuer Features oft durch die Change-Prozesse der Systemadministratoren ausgebremst wird. Der nächste Beitrag in dieser Reihe beschäftigt sich deshalb unter dem Titel “DevOps – der agile Systembetrieb” mit der Frage, ob der auf die Übergabe nachfolgende Prozess nicht auch agil sein kann.
Welche Erfahrungen haben Sie mit dem Einsatz agiler Methoden in der Softwareentwicklung gemacht
Bildquelle: Shutterstock
