<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=249668922118530&amp;ev=PageView&amp;noscript=1">

Agile Entwicklung @ DocuWare

Von Dr. Michael Berger • 17. Juli 2013
Teilen

Im  Jahr 2011 änderte DocuWare seinen gesamten Entwicklungsprozess. Seit 2012 arbeiten wir nun agil, mit Scrum- und Kanban-Methoden. DocuWare Version 6 war die erste Software, die mit dem neuen Verfahren hergestellt wurde. In diesem Beitrag möchte ich einige Eckpfeiler aufzeigen und Erkenntnisse über den Prozess und die Vorteile, die wir bisher gewonnen haben, mit Ihnen teilen.

Unser neues Verfahren in Kürze:


• Wir haben jetzt zwei feste Release-Termine pro Jahr. Unser halbjährliches Release ist auf acht Sprints im Drei-Wochen-Takt verteilt.
• Zu Beginn eines Sprints planen wir den Arbeitsaufwand. Anschließend beginnen wir mit der Programmierung (Coding) und testen die Ergebnisse; mögliche Fehler (Bugs) werden direkt im Sprint erkannt und behoben. Am Ende eines Sprints werden die Resultate dem Produktmanagement präsentiert und technisch, nach einer strengen Definition of Done, ausgewertet.

• Innerhalb des Release-Zeitraums sind auch die Übersetzungen fertig, so dass alle DocuWare-Sprachversionen zur selben Zeit bereitstehen.
• Wir haben mehrere - thematisch ausgerichtete - Entwicklungsteams, die sich auf zwei Länder verteilen. Jedes Team arbeitet an einem bestimmten Modul oder einem Teil des gesamten Produkts. Einige Teams, etwa CoreServices und Setup, arbeiten hauptsächlich anderen Teams zu.
• Jedem Team gehören ein oder zwei Quality-Assurance-Tester an; sie sitzen sogar mit den Entwicklern in einem Raum. Auf drei Sprints folgt ein Hardening Sprint (Verfestigungsphase), auf Basis dessen wir eine umfassende integrierte Version erstellen. Zu diesem Zeitpunkt liegt der Fokus auf der Fehler-Behebung (Bug-Fixing) und Optimierung. Nach dem Verfestigen (Hardening) verwenden wir diese Version für ein Update unserer DocuWare-Inhouse-Installation.
• Die Produktabteilung plant im Voraus: Produktmanager (Product Owner) füllen einen sogenannten Product Backlog für das Team aus, erhalten Schätzungen vom Team und planen die Sprints und Releases basierend auf diesen Informationen sowie basierend auf den allgemeinen Produktprioritäten. Die Entwicklungsteams können technische Themen dem Backlog hinzufügen. Die Produktmanager diskutieren und koordinieren die Pläne untereinander.
• Neben seiner technischen Koordinations- und Führungsfunktion trägt der Scrum-Master dafür Sorge, dass das Team produktiv und effizient sein kann.
• Um die interne Entwicklung zu koordinieren, haben wir ein Architektur- und ein Infrastruktur-Team.
• Der gesamte Prozess basiert auf dem „Microsoft Team Foundation Server“ und nutzt das Scrum-Tool „Urban Turtle“ sowie viele andere.

Die Vorteile für DocuWare:


• Wir konnten durch den geänderten Entwicklungsprozess die Transparenz deutlich steigern. Es werden Detaileinblicke in den Planungs- und Ausführungsstatus gewährleistet und Parameter können nachverfolgt werden. Ebenso haben wir ein hohes Maß an Disziplin im Informations- und Provisioning-Tracking erreicht.
• Statt nach mehreren Monaten erhalten wir nun lauffähige Software nach drei Wochen. Die Ergebnisse können durch die Produktabteilung überprüft und Änderungswünsche sofort behandelt werden.
• Seit die Ergebnisse in den Sprints getestet werden, können gefundene Bugs sofort behoben werden - was zu einer deutlich erhöhten Qualitätsverbesserung führt.
• Es gibt eine klare Trennung der Zuständigkeiten zwischen dem definitionsorientierten Produktmanager, der technischen Ausführung mit Qualitätsprüfung durch das Team und dem Scrum-Master als Prozess-Treiber.
• Die eingeführten Abschlussbesprechungen und täglichen Meetings haben das Gefühl der Teamzugehörigkeit bekräftigt. Teams arbeiten richtig als Teams zusammen, mit einem hohen Maß an Wissen, vielen Aufgaben und Interessenteilung. Darüber hinaus haben wir viel in unsere Entwicklungsinfrastruktur investiert und sie verändert, um den agilen Prozess zu unterstützen. Derzeit produzieren wir  alle 20 Minuten eine Continuous _Integration-Version unserer Software. Während aller  Nightly Builds werden gleichzeitig Unit-Tests ausgeführt. Nach einem erfolgreichen Nightly Build laufen verschiedene automatisierte Installations-(deployment) und Integrationstests. Jeden Morgen werden die Ergebnisse überprüft und entsprechende Maßnahmen in die Wege geleitet. All diese Maßnahmen sowie die frühen Tests während der Sprints haben die Software-Qualität erhöht.

Fazit:

Der Wechsel wurde gut umgesetzt, ist stabil und erfolgreich. Insgesamt reduzieren die Methoden Abfall und steigern die Effizienz. Das resultiert letztlich in einer höheren Kundenzufriedenheit und einer gesteigerten Lead-Generierung.

Natürlich interessiert es mich, welche Erfahrung Sie mit agilen Entwicklungsverfahren haben. Ich freue mich auf Ihr Feedback oder Fragen.

Kommentar