ZA019 - Sprints & Weekly Builds im Systems Engineering
10.07.2012 
26 Minuten
Zusammenfassung
Eine kurze und knackige Episode in der ich über meine Erfahrungen mit dem Einsatz von agilen Methoden im Systems Engineering berichte. Als Troubleshooter brauche ich pragmatische und effiziente Vorgehensweisen um Projekte wieder in die Spur zu bekommen. Schon seit 2003 nutze ich dazu drei verschiedene Methoden (Releaseplanung, Sprints, Weekly Builds) und erweitere deren Einsatz kontinuierlich (Kanban).
Der Inhalt dieser Episode:
- Warum setze ich agile Methoden ein?
- Wie ist die Situation der Entwicklungsprojekte?
- Welche Methoden habe ich eingesetzt?
- Welche positiven Ergebnisse wurden erzielt?
- Welche Herausforderungen waren zu lösen?
Themen: Releaseplanung, Sprints, Scrum, Daily Build and Smoke Test, Kanban, SW-Kanban, Lernkurven beim Einsatz der Methoden.
Verweis auf andere Episoden:
- ZA003: In die Glaskugel schauen – Sinnvolle Releasestrategien & Aufwände schätzen
- ZA009: Interkulturelle Entwicklerteams
- ZA012: Zehn Tipps zum Troubleshooting
- ZA017: Embedded Software in innovativen Systemen
Abonnieren Sie den kostenlosen Podcast und erhalten Sie zukünftig alle neuen Episoden direkt auf Ihr Smartphone:
- Klicken Sie hier um in iTunes zu abonnieren
- Klicken Sie hier um über RSS zu abonnieren (non-iTunes feed)
Hallo,
danke für den Podcast. Die agile Entwicklung hat mich ebenfalls bereits vor Jahren überzeugt und wir haben unsere Teams agilisiert. In den meisten Projekten nutzen wir Scrum. Manchmal auch Kanban.
Am 28. September findet übrigens in Konstanz am Bodensee die "Agile Bodensee" statt! Jurgen Appelo wird als Keynote-Speaker kommen: http://www.agile-bodensee.com
Hallo,
vielen Dank für das Feedback.
Die Konferenz schaut sehr interessant aus. Wenn ich es schaffe, komme ich vorbei.
Schönen Gruß aus Köln,
Maik Pfingsten
Danke für deinen Podcast. Das war knapp, knackig und vor allem praxisbezogen. Mir gefällt dein Ansatz nicht dogmatisch strickt einer Lehre zu folgen.
Praktisch alle agilen Methoden sind ja aus der Praxis heraus entstanden weil die Leute eben mit der jeweiligen Situation unzufrieden waren. Sobald allerdings eine Methode zu strikt definiert wird oder zum Standard erhoben wird geht eben genau diese Individualität verloren.
Cherry picking – die optimale Strategie.
Hallo Mike,
danke dir für dein Feedback!
Ich denke, weglassen ist die große Kunst in einem Projekt.
Vielleicht sehen wir uns auf einem Hörertreffen?
Schönen Gruß aus Köln,
Maik
Hallo Maik,
ehrlich gesagt hat für mich der Inhalt dieses Podcasts leider nicht die Erwartungen erfüllt, die durch den sehr interessant klingenden Titel suggeriert wurden. "Sprints & Weekly Builds für Embedded/Real-Time Software Systeme" wäre meines Erachtens zutreffender gewesen.
Das iterativ-inkrementelles Vorgehen (Nichts anderes sind die Sprints in Scrum) in der Software-Entwicklung, egal in welchem Kontext, gut ist und häufiger zum Erfolg führt, ist ja mittlerweile keine besonders neue Erkenntnis mehr und auch durch empirische Daten belegbar. Es ist auch nicht so, das dieses Vorgehensmodell aus Scrum kommt, sondern Scrum als agiles Inspect & Adapt-Framework hat den iterativ-inkrementellen Ansatz übernommen. Erstmals erwähnt und beschrieben wurde dieses Vorgehen von der NASA schon in den 1960er Jahren, die Space Shuttle Software wurde zwischen 1978 und 1980 in dieser Art und Weise entwickelt. 1985 fand der iterativ-inkrementelle Ansatz seinen Weg in den DOD-STD-2167A.
Und wenn ich Dich in deinem Podcast nicht völlig missverstanden habe, ging es ja in deinem Praxisbeispiel aus der Automobilindustrie um ein Software-Entwicklungsprojekt. Zwar ist die Software in diesem Fall ja Teil eines komplexen, technischen Systems, aber das System (d.h. das Auto) – und darum geht es ja im Systems Engineering, wenn man der INCOSE-Definition folgt – wurde ja wohl nicht iterativ-inkrementell entwickelt?
Doch genau das wäre ja mal sehr spannend und innovativ gewesen: ein interdisziplinäres(!) Systementwicklungsprojekt (Mechanik, Elektrik, Elektronik, Hydraulik, Hardware, Software, …) mit Hilfe eines solchen Ansatzes zu entwickeln.
Und noch ein paar weitere Anmerkungen: warum eigentlich nur Weekly Builds? Warum kein Daily Build oder Continuous Build/Continuous Integration? Die Feedback-Schleife bei Fehlern wäre noch deutlich kürzer und eventuell ist dann das Wochenende für die Entwickler nicht gefährdet? ;-)
Viele Grüße,
Stephan Roth
Hallo Stephan,
vielen Dank für dein kritisches Feedback.
Ja, du hast recht, die von mir beschriebene Vorgehensweise habe ich das Erste mal 2005 eingesetzt und sie war hauptsächlich auf die Software im Projekt fokussiert. Wir mussten diese Vorgehensweise erst mal etablieren (Requirements, Planung, Konfigurationsmanagement, Bugtracking, Changemanagement) und der größte Nutzen lag (in der Situation) in der Softwareentwicklung und dem Systemtest. Zu der damaligen Zeit war Scrum und Continious Integration keinem von uns ein Begriff.
Mit dieser Episode habe ich zwei Gedanken:
Auch wenn der iterativ-inkrementelle Ansatz mittlerweile bekannt und seinen Nutzen belegt ist, erlebe ich immer noch viele Projekte, die diesen Ansatz nicht kennen. So möchte ich meine Erfahrungen weitergeben und zum Denken anregen.
Ich finde, ebenso wie du, den Ansatz auf der Systemebene sehr spannend. Aufgrund der bisherigen Iterationszeiten in der Elektronik/Mechanik/Optik ist das leider nicht so einfach umsetzbar, da nicht jeden Tag/Woche eine funktionsfähige Hardware produziert werden kann, bzw. es kostet einfach zu viel. Ich denke gerade bei der modellbasierten Entwicklung und in Verbindung mit modernen Rapid Protoyping Mothoden (3D-Drucker etc.) wird es aber deutlich einfacher und auch kostengünstiger.
Vielleicht findet sich in der Hörerschaft jemanden, der dazu etwas erzählen kann? Dazu würde ich gerne im Rahmen einer Episode ein Gespräch führen.
Schönen Gruß aus Köln,
Maik