Hinter den Kulissen: Softwareentwicklung trifft auf Rugby

Als ich das erste Mal den Begriff „Scrum“ im Zusammenhang mit Creo hörte, musste ich sofort an meine Tage als Rugbyspieler in der Schulmannschaft in England zurückdenken! Im Rugby bedeutet „Scrum“ nämlich „Gedränge“. Ich sah daher sofort drei Lagen von ineinander verkeilten Spielern vor mir, die inmitten haariger Beine in Kniestrümpfen um den Ball kämpften. Aber das war mit „Scrum“ in diesem Zusammenhang wohl nicht gemeint. Scrum ist auch der Name des Entwicklungsansatzes, den PTC für Creo verwendet und der nicht im Entferntesten mit dem britischen Sport verbunden ist. Frei nach Wikipedia: Scrum ist ein iteratives, inkrementelles Projektmanagement-Verfahren, das oft bei der agilen Softwareentwicklung verwendet wird. Scrum wurde erstmals 1986 von Hirotaka Takeuchi und Ikujiro Nonaka als neues Konzept beschrieben, das die Geschwindigkeit und Flexibilität bei der Entwicklung neuer Produkte beschleunigen sollte. Sie verglichen dieses neue Verfahren, bei dem die einzelnen Phasen sich stark überschneiden und der gesamte Prozess in seinen verschiedenen Phasen von einem einzigen interdisziplinären Team abgewickelt wird, mit Rugby. Beim Rugby versucht die ganze Mannschaft die Distanz als Einheit zu überwinden, indem sie den Ball hin- und herpasst.“ Ich bat Michael Pfrommer, VP Creo Product Development, die Bedeutung von Scrum für PTC und seine Produkte zu erklären.
GH:
Scrum ist ein für PTC relativ neues Verfahren. Aber nicht jeder weiß, wie die Softwareentwicklung vor Scrum oder ähnlichen Methoden der agilen Softwareentwicklung vonstatten ging. Können Sie diese beschreiben? Pfrommer: Vor Scrum wurde eine Softwareversion in der Regel in mehreren Phasen entwickelt: Forschung, Entwurf, Entwicklung. Dabei gab es offizielle Stage-Gates, die mehrere Monate oder Jahre dauern konnten. Scrum liefert viel schneller greifbare Ergebnisse, wobei der Schwerpunkt darauf liegt, Projekte in leicht verdaulichen Zyklen, den so genannten Sprints, vorwärts zu bringen. GH: Ich habe von Scrum Masters, Sprint Owners usw. gehört. Was hat es denn damit auf sich? Pfrommer: Scrum ist ein Prozessgerüst, das mehrere Verfahren und vordefinierte Rollen enthält. Bei PTC sind die wichtigsten Rollen für Scrum: Der Scrum Master, der die Prozesse verwaltet und sicherstellt, dass alle Teams die Scrum-regeln einhalten (ersetzt in der Regel den Projektmanager). Bei PTC haben wir aufgrund der zahlreichen Scrum-Teams sogar mehrere Scrum Masters. Der Product Owner, der die Interessensvertreter und das Unternehmen vertritt. Der Product Owner überwacht die Produktanforderungen für das freigegebene kommerzielle Produkt. Hierzu gehören funktionelle und nicht funktionelle Anforderungen (Infrastruktur), die externe Schnittstelle sowie Daten- und Performance-Vorgaben. Bei PTC handelt es sich bei dieser Person in der Regel um ein Mitglied des Produktmanagement-Teams. Die Freigabe erfolgt erst, wenn der Product Owner sich vergewissert hat, dass die wichtigsten Anforderungen erfüllt wurden. Aber der Product Owner arbeitet keinesfalls willkürlich. Bei PTC werden die Produktanforderungen als ausführliche Serie von Kundenerfahrungen (Epics) entwickelt. Der Sprint Owner ist bei PTC das Produktdefinitionsteam, das die einzelnen Sprints ausgehend von den Anforderungen durchführt. Sie untergliedern die Epics vom Product Owner in übersichtliche Abschnitte, die in einem Sprint erledigt werden können. Wir bezeichnen diese Abschnitte als Product Storys. Das Team ist eine interdisziplinäre Gruppe, die die eigentlichen Analyse-, Konstruktions-, Implementierungs- und Testtätigkeiten usw. durchführt. Alle Rollen zusammen bilden das Scrum Team, das dafür verantwortlich ist, das Produkt oder zumindest ein lauffähiges, inkrementell verbessertes Produkt zu liefern. Das Team wird von einem Scrum Coach geleitet und besteht aus einem Product Owner, Entwicklern usw. GH: Warum gibt es bei PTC sowohl einen Product Owner als auch einen Sprint Owner? Sie scheinen sich in ihrer Funktion sehr ähnlich zu sein. Pfrommer: Der Product Owner ist letztendlich derjenige, der die Produktanforderungen im Auge behält und versteht, welche Anforderungen für eine erfolgreiche Version erfüllt werden müssen. Die Person, die diese Rolle inne hat, wird auch in kommerzielle Aspekte wie Lizenzierung, Verpackung und Preispolitik involviert. Der Sprint Owner konzentriert sich hingegen ausschließlich darauf, dass für jeden Sprint die richtigen Anforderungen festgelegt werden und dass die Anforderungen im Rahmen des Sprints erfüllt werden können. GH: Das hört sich sehr kompliziert an. Können Sie uns den Prozess einmal Schritt für Schritt erklären? Pfrommer: So kompliziert ist das gar nicht, besonders nicht im Vergleich zu den traditionellen Prozessen. Das Kernstück des Scrum-Prozesses ist der Sprint. Bei jedem Sprint, der in der Regel über vier Wochen geht, erstellt das Team ein lauffähiges, inkrementell verbessertes Produkt (d.h., alle während des Sprints hinzugekommenen Elemente funktionieren und wurden getestet). Die Features, die in einem Sprint bearbeitet werden, stammen aus den Epics, die nichts anderes sind als priorisierte, grobe Arbeitsanforderungen des Product Owners. Der Sprint Owner untergliedert diese Epics in Storys und hält dann Sprint-Planungsbesprechungen ab, in denen festgelegt wird, welche Storys beim nächsten Sprint bearbeitet werden und welche in den ProduktBacklog aufgenommen werden. Bei dieser Besprechung schätzt das Team, welche Storys während des nächsten Sprints abgearbeitet werden können. Sobald der Sprint definiert ist, dürfen die betreffenden Storys nicht mehr geändert werden. Die Anforderungen werden also fixiert. Die Entwicklung wird im Rahmen einer Time Box durchgeführt, die so festgelegt wird, dass der Sprint pünktlich abgeschlossen sein muss. Nicht erledigte Storys werden nicht berücksichtigt und gelangen wieder in das Produkt-Backlog. Nach Abschluss des Sprints zeigt das Team, wie die Software verwendet wird. GH: Worin sehen Sie für PTC die größten Vorteile des Scrum-Verfahrens? Pfrommer: Scrum hat meiner Meinung nach drei wesentliche Vorteile: Erstens erleben wir bei jedem Sprint eine schnelle Weiterentwicklung des Produkts, und das Verfahren ist transparent und schrittweise aufgebaut. So erhalten wir alle paar Wochen greifbare Ergebnisse. Zweitens ist uns klar geworden, dass sich im Projektverlauf die Vorstellung darüber, was gewünscht und gebraucht wird, verändern kann. Dank der neuen Technologien in Creo bietet Scrum eine Plattform, auf der das Team mit unvorhergesehenen Herausforderungen umgehen kann, was bei den traditionellen voraussagenden oder geplanten Verfahren kaum möglich ist. Drittens verfügen wir nach jedem abgeschlossenen Sprint über einen potenziellen Release Candidate. GH: Ist dies das erste Mal, dass diese Vorgehensweise bei PTC verwendet wird? Pfrommer: Nein. Wir arbeiten seit Jahren für viele unserer Produkte mit agilen Verfahren; bei Creo Elements/Direct 17.0 gingen wir ziemlich genau nach Vorschrift vor. Das war einer der Gründe, warum wir lange vor der Produktveröffentlichung schon Sneak Peeks der neuen Funktionalitäten zeigen konnten. Das Gleiche gilt für Creo: Wir konnten die Produktfunktionen schon neun Monate vor der Veröffentlichung demonstrieren. GH: Das heißt, dass PTC nach jedem Sprint die Möglichkeit hätte, Creo zu veröffentlichen? Pfrommer: Ja. Und je mehr Sprints abgeschlossen sind, umso höher ist die Wahrscheinlichkeit, dass das Produkt über das Potenzial zur Freigabe verfügt. Wenn wir einen möglichen Release Candidate identifiziert haben, starten wir umfangreichere Tests in mehreren Phasen, in die wir mehr Personen einbeziehen wie interne Mitarbeiter, Softwarepartner und Kunden. GH: Wie viele Sprints sind bis zum Release Candidate für Creo 1.0 geplant? Pfrommer: Wir haben unseren letzten Sprint vor Weihnachten abgeschlossen und erwarten noch etwa drei bis vier Sprints bis zum Release Candidate für Creo 1.0. Nach unserer derzeitigen Planung werden wir im März eine Betaversion und im Juni Creo 1.0 herausbringen.

In unseren nächsten Artikeln der Rubrik „Hinter den Kulissen“ zu Creo und Scrum werden wir auf den aktuellen Status von Creo 1.0 sowie Details zu den umfangreicheren Testphasen bekannt geben. Bild: royskeane

Dieser Eintrag wurde veröffentlicht in Hinter den Kulissen und getagged , , , , , , . Bookmarken: Permanent-Link. Kommentieren oder ein Trackback hinterlassen: Trackback-URL.

Einen Kommentar schreiben

Ihre E-Mail wird niemals veröffentlicht oder verteilt. Benötigte Felder sind mit * markiert

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

Du kannst diese HTML Tags und Attribute verwenden: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <pre> <q cite=""> <s> <strike> <strong>