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

Über den Autor

Andreas Schliep

Andreas Schliep ist ein Gründungsmitglied von DasScrumTeam AG. Er arbeitet als Scrum Coach und Trainer. Nach seinem Besuch der Hochschule Bremerhaven arbeitete Andreas zunächst als Softwareentwickler, Projektleiter, Teamleiter und später auch Bereichsleiter. Zu Scrum kam Andreas 2003-2004 durch seine damaligen Kollegen bei WEB.DE. Nach der Scrum Implementierung dort wechselte Andreas 2006 zur SPRiNT iT und machte sich 2008 als Coach und Trainer selbständig. Heute liegen seine Schwerpunkte neben der Einführung und dem Ausbau von Scrum insbesondere beim Qualitätsmanagement und der nachhaltigen Verbesserung von Entwicklungsteams.

  • Erfahrung mit Scrum seit Frühjahr 2004 als Scrum Master, Product Owner, Teammitglied, Coach und Trainer.
  • Einführung von Scrum bei der WEB.DE AG und ComBOTS AG
  • Betreuung von international verteilten Scrum Teams bei BenQ-Siemens
  • Betreuung von Scrum Teams bei bwin Wien Unterstützung des Übergangs von RUP zu Scrum bei UOL Brasilien
  • Weitere Scrum-Implementierungen in D/A/CH
  • Besondere Interessen: Skalierung und Verbesserungsprozesse
Tags