In den vorigen Beiträgen habe ich die Prozesse, die sich mit Anforderungen befassen, etwas beleuchtet. Die weiteren Engineering-Prozesse in Automotive SPICE, also der jeweilige Rest vom System-V und vom Software-V bergen in Verbindung mit Scrum viel weniger Unklarheiten. Wie bisher musst du Architekturen entwerfen, Implementieren, integrieren und testen (verifizieren). Hinsichtlich der Dokumentation entsteht hier nichts neues, weil Scrum und die Skalierungsframeworks hier keine Artefakte vorsehen oder vorgeben. Es ist eben die „ganz normale“ Entwicklungsarbeit mit den „ganz normalen“ Werkzeugen. Natürlich ist es essenziell, dass die Werkzeuge schnelle Zyklen unterstützen und nicht eine unnötige Bremse beim agilen Arbeiten darstellen.
Interessant ist aus agiler Sicht, wer die Tätigkeiten wann durchführt. In agilen Ansätzen gibt es bewusst keine technischen Rollen wie Systemarchitekt oder Tester mehr: Das Scrum Team, mit dem Mix aller Fertigkeiten, ist für das ganze Produkt verantwortlich. Dementsprechend werden auch alle Architektur- und Testarbeiten von den Teams in den Sprints durchgeführt. Das Arbeiten in kurzen Zyklen verursacht zunächst oft Reibung mit der aktuellen Entwicklungskultur. Entwicklungstätigkeit in kleine Stücke herunterzubrechen und auch so umzusetzen erfordert etwas Übung, im SPICE-Kontext auch hinsichtlich der Werkzeuge und der Dokumentation. In vielen Organisationen wird traditionell lange an einer 100%-Lösung von Dokumenten geschraubt, iterativ-inkrementelles Vorgehen ist hier sehr ungewohnt. Ebenso ungewohnt ist es, als Team gemeinsam Anforderungen umzusetzen und zu testen. 2-4 Teammitglieder an einem Tisch können hier viel parallelisieren: Nach einer Diskussion zum gemeinsamen Verständnis, könnten Anforderungen und Testfälle parallel zur Architekturanpassungen und Implementierung geschrieben werden.
Wie hieß es schon 1986, bevor man es “Swarming” nannte?
“Hört auf Staffellauf zu machen, spielt lieber Rugby!”
Takeuchi & Nonaka, 1986: The new new product development game.