Wie kann man generisch und wiederverwendbar entwickeln, wenn man in kurzen Zeitabschnitten liefern soll?

Geschrieben von Andreas Schliep am 21.05.2013

"Da man in Scrum meist mit User Stories arbeitet und der PO normalerweise die Umsetzung nicht interessiert, würde man denken, dass man sich prinzipiell auf den Sprint und entsprechend im Selected Product Backlog definierte Funktionalität konzentriert und die Wiederverwendbarkeit nicht beachtet, besonders wenn diese Zusatzaufwände bedeutet. Wie seht ihr das? Wie kann man generisch und wiederverwendbar entwickeln, wenn man in kurzen Zeitabschnitten fertige, auslieferbare Produkte bzw. Produktteile haben soll? ..."

Meine bisherigen Erfahrungen stammen hauptsächlich aus der firmeninternen Webentwicklung. In meinem letzten Team war das so, dass sie dem PO manchmal 2 verschiedene Story Point Schätzungen präsentiert hatten: eine für die generische, wiederverwendbare Lösung und eine für die normalerweise kostengünstigere funktionsorientierte Umsetzung. Normalerweise kam dann noch die Bemerkung des Teams dazu, dass die kostengünstigere Umsetzung zum Zusatzaufwand bei der Umsetzung einer bestimmten User Story aus dem Product Backlog führen wird. Der PO musste also entscheiden, welche Umsetzung er bereit ist in Kauf zu nehmen. Dadurch dass wir jeden Sprint nach dem Review eine neue Version des Produktes online genommen haben, war die Entscheidung des POs vom Fall zu Fall unterschiedlich. Mal hat er sich für die momentan kostengünstigere Version entschieden, um z.B. auszutesten, ob diese Funktionalität beim Benutzter überhaupt gut ankommt oder nicht."

Das mag im Webumfeld so sein. Diese Diskussionen kenne ich auch noch sehr gut aus diversen Coaching-Einsätzen. Prinzipiell sollte das Team aber einen gewissen Qualitätsstandard gemeinsam mit dem Product Owner definieren und hochhalten. So steht zum Beispiel das kontinuierliche Refactoring niemals zur Debatte. Eine Aufsplittung in generische Komponenten und funktionale Implementierungen hat stets einen nicht-agilen Beigeschmack. Diesen Kunstgriff würde ich mir nur vorbehalten, wenn die generische Komponente selbst einen hohen Wert darstellt - zum Beispiel ein bestimmtes Risiko angreift oder die Basis für eine Vielzahl von darauf aufbauenden Funktionalitäten darstellt.

Wiederverwendbarkeit, konzeptionelle Integrität, und andere nicht-funktionale Anforderungen sind zu klärende Qualitätsmerkmale (Constraints oder Abnahmekriterien), so wie viele andere auch. Ein gutes Team arbeitet diese Anforderungen durch wiederholtes und konsequentes Refactoring innerhalb ihres testgetriebenen Entwicklungszyklus immer wieder in den Code ein. Dabei sind neben KISS und YAGNI natürlich auch schon bekannte Faktoren zu berücksichtigen, wenn sie sich nicht später ohne größeren Aufwand wieder umbauen lassen. Die Erstellung von Qualität bedingt immer auch die konstante Verbesserung der Codebasis. In einem klassischen Ansatz betrachtet man vielleicht einmal geschriebenen Code als "fertig" - der o.a. Kern steht einmal, erfüllt seine Aufgaben perfekt und muss nicht mehr angepasst werden. Bei der iterativen und inkrementellen Entwicklung entsteht im ersten Sprint nur so viel vom Kern, dass man eine bestimmte einfache Funktionalität über alle Schichten realisieren kann. Dabei wird der Kern im 2. Sprint angepasst, vielleicht werden auch Funktionalitäten aus anderen Modulen in den Kern umgezogen, weil sie dort mehr Sinn machen. Dafür braucht es keinen langen initialen "Architektursprint." Zu viel Generik lenkt dabei von den User Stories ab, zu wenig Refactoring und eine fehlende Architekturvision führen hingegen zu unwartbarem Code. Die Aufgabe des Architekten ist es, die Balance zwischen funktionsgetriebener Entwicklung und solider Architektur in den Teams zu begleiten, erleichtern und moderieren.

Andreas Schliep

Andreas „Andy“ Schliep

Andy ist einer der ersten deutschsprachigen Scrum-Trainer und ein Gründungsmitglied von DasScrumTeam. Nach seinem Studium an der Hochschule Bremerhaven begann Andreas seine Karriere zunächst als Softwareentwickler, später dann als Projektleiter, Teamleiter und schließlich als Bereichsleiter. Zu Scrum fand Andreas zwischen 2003 und 2004 durch seine damaligen Kollegen bei WEB.DE. Nach der Implementierung von Scrum bei WEB.DE wechselte Andreas im Jahr 2006 zu SPRiNT iT und entschied sich 2008, als Coach und Trainer selbstständig zu machen. Heute fokussiert er sich neben der Einführung von Scrum vor allem auf agile Führungskompetenzen und die nachhaltige Transformation von Organisationen. Als Co-Autor hat Andy an der Erstellung der Lernziele der Scrum Alliance für Scrum Master, Product Owner und Entwickler mitgewirkt.

Mehr Posts zum Thema

Immer informiert mit dem DasScrumTeam Newsletter

Das Beste in Sachen Scrum. Einmal im Monat. Jeden Monat.