Hochautomatisiertes Fahren findet auch in der Cloud statt

Vollautonomes Fahren ist in aller Munde. Die einen erwarten mehr Sicherheit im Straßenverkehr. Die anderen haben Angst vor der Autonomie künstlicher Intelligenzen und den ethischen Konsequenzen. Tatsächlich ist das vollautonome Fahren (Stufe 5 des autonomen Fahrens1 ) auf unseren Autobahnen noch Zukunftsmusik. Längst real hingegen sind die immer ausgereifteren Fahrerassistenzsysteme in modernen Fahrzeugen, die das Leben des Fahrers erleichtern und die Sicherheit verbessern sollen. Diese Assistenzsysteme nehmen aktuell die Hürde zur Stufe 3, dem hochautomatisierten Fahren (HAF). Und das findet nicht nur im Fahrzeug statt, sondern auch in der Cloud. Warum das so ist und was das für die Softwareentwicklung bedeutet, lest ihr hier.

Fahrzeugsensordaten reichen für hochautonomes Fahren nicht aus

Heutige Fahrerassistenzfunktionen basieren meist auf der Auswertung der Daten unterschiedlicher Sensoren und Systeme eines Fahrzeugs wie Kamera, Ultraschall, Lidar oder Radar. Diese erkennen jeweils Teilausschnitte der Umgebung und werden zu einem einheitlichen Umfeldmodell zusammengefügt. Dieses Umfeldmodell stellt verschiedenste Informationen zu bewegten Objekten, statischen Hindernissen, Straßenverläufen und mehr bereit. Das „Sichtfeld“ des Fahrzeugs ist auf dieses Umfeld eingeschränkt.

Das allerdings reicht nicht aus, um den Weg zum hochautomatisierten Fahren konsequent weiterzugehen. Vielmehr muss das bisherige Umfeldmodell zur Berechnung und Kontrolle des Fahrwegs deutlich erweitert werden. Dies geschieht mit Informationen, die von außerhalb der Sensorreichweite kommen. Mit ihnen lassen sich die Fahrfunktionen dynamisch verbessern und sogar ganz neue Fahrfunktionen entwickeln. Damit werden IT-Systeme, die sich außerhalb des Fahrzeugs befinden, erstmals Teil fahrdynamischer Fahrzeugfunktionen.

IT-Systeme außerhalb des Fahrzeugs werden Teil der Fahrerassistenzsysteme

Mit den neuen Fahrzeugvarianten vieler Hersteller kommen weitere Fahrzeugfunktionen auf die Straße, die durch IT-Systeme in der Cloud unterstützt und erweitert werden. Das Backend in der Cloud hält zum Beispiel das Kartenmaterial aktuell und liefert dynamische Informationen. Diese Informationen basieren sowohl auf externen Informationsquellen als auch aus aggregierten Sensordaten vieler Fahrzeuge. IT-Systeme im Hintergrund sammeln diese Daten aus unterschiedlichen Quellen, bereiten sie auf und liefern sie wieder an die Fahrzeuge aus.

Ein solches HAF-IT-System ermittelt zunächst, ob die jeweilige Information für ein Fahrzeug relevant ist. Der Standort des Fahrzeugs dient dabei als Basis, und alle im Umkreis dieses Standorts auftretenden Events sind potenziell für ein Fahrzeug relevant. Der Umkreis wird dabei abhängig von der Art des Events festgelegt. Da sich der Standort eines Fahrzeugs bei der Fahrt ständig ändert, ist es essentiell, dass nur die jeweils veränderte Information an das Fahrzeug übertragen wird.

Fahrzeug und HAF-System sind in ständigem Austausch

Das IT System stellt unterschiedliche Informationen über Umfeldbedingungen wie etwa Geschwindigkeitsbegrenzungen, Baustellen oder Ampelphasen zur Verfügung. Diese können als sogenannte Events an die Fahrzeuge übertragen werden. Die Fahrzeuge können sich für eine oder mehrere Eventarten anmelden, so dass sie Benachrichtigungen zu den jeweiligen Events erhalten.

Dabei kann es ganz unterschiedliche Arten von Events geben, an denen die Fahrzeuge beziehungsweise ihre Fahrer interessiert sein können, zum Beispiel Informationen zu variablen, elektronischen Geschwindigkeitsbegrenzungen. Diese können aufgrund von Verkehrsbedingungen, Baustellen oder anderen Gegebenheiten unterschiedliche Werte anzeigen. Eine weitere Eventart sind Warnungen vor gefährlichen Fahrbedingungen wie Glatteis. Solche frühzeitigen Warnungen sollen helfen Unfälle zu vermeiden.

Über Streckenfreigabe-Events kann dem Fahrzeug außerdem mitgeteilt werden, welche Teilabschnitte für autonomes Fahren geeignet sind. Außerdem sind RTTI-Informationen zur aktuellen Verkehrslage möglich sowie Events, die Daten zur Dauer von Ampelphasen übertragen. Mit letzteren ist es prinzipiell möglich, die Geschwindigkeit entsprechend zu ermitteln, um bei der nächsten Ampel bei grün anzukommen.

Ein IT-System für HAF bildet die die Grundlage für eine übergreifende Plattform, die weitere digitale Services in den Bereichen Gefahrenwarnung, Navigation, Verkehrsinformationen und Parken ermöglicht. Dabei gilt auch hier, dass die Automobilhersteller erst einen Teil dieser Eventarten umgesetzt haben und vieles noch Zukunftsmusik ist.

Ein agiler cloudbasierter Ansatz ist Erfolgsfaktor für HAF-Systeme

Damit das hochautomatisierte Fahren mit Unterstützung eines IT-Systems im Hintergrund zuverlässig funktioniert und auch in Zukunft erweitert werden kann, sind die Anforderungen an die entwickelte Backend-Software hoch. Ausfallsicherheit und Performanz sind genauso sicherzustellen, wie die Skalierbarkeit für zukünftige Erweiterungen.

Zusammen mit Kunden und Partnern entwickelt doubleSlash HAF-Backendsysteme, die Informationen sammeln, auswerten und die daraus berechneten dynamischen Informationen an die Fahrzeugflotte verteilen. Bei der Entwicklung haben unsere Experten folgende Erfolgsfaktoren identifiziert:

Cloudbasierter Ansatz und Microservice Architektur

Das technologische Fundament einer HAF-Anwendung stellt die Kunden-Cloud dar. Die cloudbasierte Anwendung dient dazu, die Hochverfügbarkeit des Systems in allen Regionen zu garantieren und eine stetig wachsende Fahrzeugflotte bedienen zu können.

Das IT-System basiert auf einer flexiblen Microservice-Architektur mit fachlich getrennten, unabhängigen Services. Für Monitoring und Logging werden aktuelle Cloud-Technologien eingesetzt.

SAFe – agile Zusammenarbeit im großen Stil

Ein agiles Vorgehensmodell macht flexible Reaktionen auf Veränderungen möglich. Da das Projekt in einem größeren Gesamtkontext mit verschiedenen IT-Systemen im Bereich automatisiertes Fahren zu sehen ist, bietet sich hier das Modell SAFe („Scaled Agile Framework“) an.

Das agile Manifest ist die Grundlage für SAFe, daraus werden – wie für Scrum – die SAFe Prinzipien abgeleitet. SAFe geht jedoch noch einen Schritt weiter, denn das Rahmenwerk ist zur Koordination mehrerer agiler Teams und Projekte gedacht. Diese Scrum Teams arbeiten auf ein gemeinsames Ziel hin, ihre Projekte sind Teil eines größeren Produkts. Durch den Zusammenschluss der einzelnen Teams lassen sich Abhängigkeiten identifizieren und Redundanzen vermeiden. Ihre Sprints haben einen gemeinsamen Takt, und die Ergebnisse der einzelnen Teams werden durch eine übergreifende Planung auf der Program Increment Ebene aufeinander abgestimmt.2

 

Fazit

Für hochautomatisiertes Fahren (HAF) werden zahlreiche Informationen außerhalb der Sensorreichweite eines Fahrzeuges benötigt, damit das Fahrerassistenzsystem lernen kann. Dafür liefern IT-Systeme außerhalb des Fahrzeuges aufbereitete dynamische Informationen auf Basis unterschiedlichster Informationsquellen. Für solche Systeme gelten besonders hohe Anforderungen an Themen wie Performanz, Ausfallsicherheit und Skalierbarkeit. Um dies zu gewährleisten, setzen wir auf aktuelle Cloud-Technologien und ein agiles, aber skalierbares Vorgehensmodell. Mit letzterem lässt sich schnell und flexibel auf Veränderungen reagieren – ohne jedoch Abhängigkeiten zu anderen Projekten im Gesamtkontext außer Acht zu lassen.

 

Beispiel: Technolgy Stack auf Basis Amazon Webservices
Amazon Web Services (AWS)

  • Amazon Elastic Compute Cloud (EC2)
  • Amazon Elastic Kubernetes Service (EKS)
  • Amazon Relational Database Service (RDS)
  • Amazon Virtual Private Cloud (VPC)
  • AWS Security Groups
  • Amazon CloudWatch
  • Amazon Route 53
  • AWS Lambda
Kubernetes
Docker
Terraform
Grafana
Kibana
Agile Toolchain
Atlassian Confluence, Jira, Bitbucket
Gitlab
Mehr zum Technology Stack erfährst du hier

 

Mehr zum Thema autonomes Fahren:

Von Driver-Only bis Roboter-Taxi – die Herausforderungen beim automatisierten Fahren

 


Quellen:

1 https://www.adac.de/rund-ums-fahrzeug/ausstattung-technik-zubehoer/assistenzsysteme/fahrerassistenzsysteme/

2 https://www.scaledagileframework.com/

Agiles Projektmanagement Quiz – Part 2: Sprint Backlog – Der Sprint kann los gehen!

Let’s Quiz

Herzlich willkommen zum Agiles-Projektmanagement-Quiz – Part 2. Hier kannst Du Deine Scrum-Kenntnisse und Dein Projektmanagementwissen an realen Projektbeispielen testen. Es geht es um eine konkrete Projektsituation, die wir selbst erlebt haben und für die wir eine Lösung finden mussten.

Das heutige Quiz beschreibt eine Projektsituation aus einem agilen Projekt, in dem das Vorgehensmodell Scrum eingesetzt wurde. Scrum beschreibt einen iterativen Prozess für die Softwareentwicklung, die Planung erfolgt in Sprints. Weitere Informationen gibt es in der Quiz-Beschreibung zum ersten Quiz.

Im ersten Teil der vierteiligen Quizreihe „Sprint Planning – Aller Anfang ist schwer“ ging es um die Planung des Sprints. Dies erfolgt im Rahmen eines Sprint Planning Meetings, in dem die Arbeitspakete festgelegt und geplant werden, die in diesem Sprint umgesetzt werden. Diese User Stories bilden das Sprint Backlog.

Die Stories im Sprint Backlog müssen so spezifiziert sein, dass sie umgesetzt werden können. Denn nur, wenn alle benötigten Informationen in einer User Story enthalten sind, darf diese im Sprint Planning in den Sprint gezogen werden.

Sprint Backlog – Bereit zur Umsetzung

Im heutigen Quiz geht es um dieses Sprint Backlog. Wir haben im Sprint Planning 1 geklärt, welche der fertig spezifizierten User Stories in diesem Sprint umgesetzt werden müssen. Aus dem Sprint Planning 2 geht hervor, wie sich die Stories konkret umsetzen lassen. Daraus ist unser Sprint Backlog entstanden.

Das wäre zumindest die Idealvorstellung. Häufig ist es jedoch so, dass Stories im Sprint landen, die nicht ausreichend spezifiziert sind, so dass eine konkrete Planung der Umsetzung nicht möglich ist. Doch wie lässt sich dies verhindern?

Im Scrum Guide ist beschrieben, dass eine Story „ready“ sein sollte, um im Sprint Planning durch das Entwicklungsteam ausgewählt werden zu können. Deshalb ist es von zentraler Wichtigkeit, dass alle Projektbeteiligten ein gemeinsames Verständnis davon haben, was „ready“ bedeutet. Um dies sicherzustellen, ist es hilfreich eine „Definition of Ready (DoR)“ festzulegen, die genau dies definiert. Es handelt sich dabei um eine Liste von Kriterien, die an User Stories gestellt werden. Die DoR ist die Anforderung des Scrum-Teams an die Qualität und an die Informationen einer User Story. Der Product Owner sorgt dafür, dass diese Qualität im Product Backlog gewahrt ist. Die Idee dahinter ist, dass nur vage beschriebene User Stories nicht in einen Sprint gelangen können, sondern nur solche, die der DoR entsprechen.

Typische Anforderungen in einer DoR sind:

  • User Story ist User-zentriert beschrieben
  • Akzeptanzkriterien (funktional und nicht funktional) sind beschrieben
  • Abhängigkeiten sind beschrieben
  • Rahmenbedingungen und Voraussetzungen sind beschrieben
  • Alle Referenzen für die Umsetzung liegen vor (z.B. CI-Guidelines, Usability-Guidlines)
  • Der Business Value ist bewertet
  • Die Schätzung liegt vor
  • Testfälle liegen vor

Der Praxisfall – ein Prototyp für eine Messe

Die Projektsituation entstand im Kontext Condition Monitoring und Predictive Maintenance. Im konkreten Projekt hat das Team in vier Sprints einen Prototyp für eine Messe realisiert. Da der Prototyp auf der Messe vorgestellt werden sollte, war es entscheidend, am Tag der Messe eine funktionsfähige Anwendung zur Verfügung zu haben. Es musste also in möglichst kurzer Zeit eine Anwendung fertiggestellt werden, die zwar noch nicht produktiv einsetzbar ist, aber potenziellen Endanwendern einen möglichst großen Funktionsumfang präsentiert.

Im ersten Sprint war die Qualität der fachlichen User Stories, nach Coaching der Product Owner durch doubleSlash, recht gut, und die Arbeit schritt voran. In der Tabelle siehst Du den aktuellen Stand.

SprintSprint LängeSprint BacklogTechn./fachl. User StoriesAusreichend spezifiziert
11 Woche167/9Alle

In einem verlängerten Sprint Planning konnten User Stories geeignet geschnitten und die offenen Fragen geklärt werden.

22 Wochen3222/1010 fachliche User Stories sind nicht ausreichend spezifiziert, aber für den Sprint angenommen.
32 Wochen??Das Backlog ist unvollständig!
41 Woche??Das Backlog ist leer!

Das Projekt befindet sich jetzt einen Tag vor Abschluss von Sprint 2. Es fehlen immer noch einige der Nachspezifikationen für die angenommenen 10 fachlichen User Stories.
Ein erneutes Coaching-Angebot, um beim Verfassen der User Stories zu unterstützen, haben die Product Owner aus Kapazitätsgründen abgelehnt.

Fragen:

Frage 1: Welche Auswirkungen haben die fehlenden Spezifikationen auf das Ergebnis des laufenden Sprints?

Frage 2: Welche Risiken siehst Du für das Projektergebnis?

Frage 3: Was kann der Projektleiter tun, um das Projekt erfolgreich abzuschließen?

Auch für diesen Fall gibt es nicht die richtige Lösung. Schick uns gerne Deine Antworten per Kontaktformular oder poste einen Kommentar unter diesen Beitrag, dann senden wir dir gerne die Musterlösung, das heißt unsere Empfehlung mit der Projektsituation umzugehen, per Mail zurück. Wir freuen uns auf deine Ideen!

 

Mehr agiles Projektmanagement bekommst du hier

 

Hier findest Du Teil 1, 3 und 4 der Projektmanagement-Reihe:

Zum 1. Teil des PM Quiz – Sprint Planning – Aller Anfang ist schwer

Zum 3. Teil des PM Quiz – Reporting – Ist unser Projekt erfolgreich?

Zum 4. Teil des PM Quiz – Sprint Review – Was haben wir geschafft?

 

HIer kostenfrei unsere Magic Estimation Karten zur effizienten Scrum Aufwandsschätzung

Hier kostenfrei unsere Magic Estimation Karten bestellen

 

Industrialisierte Absicherung: Wie autonome Fahrfunktionen reif für den „Führerschein“ werden

„Erste autonome Fahrzeuge unterwegs. Seit Anfang 2020 gibt es in Friedrichshafen auf einer speziell ausgestatteten Strecke Testfahrten für vollständig autonome Fahrzeuge.“ So könnten Überschrift und Aufmacher in der Zeitung lauten. Wenn denn autonome Fahrzeuge in Deutschland bereits eine Zulassung – quasi einen Führerschein – hätten. Die Teststrecke wird tatsächlich bereits seit Herbst 2018 befahren1 – allerdings mit Fahrzeugen, die allesamt eine Zulassung nach heute gültigen Verkehrsstandards haben und einen menschlichen Fahrer an Bord.

Primäres Ziel ist in diesem ersten Schritt das Sammeln von Daten. Was passiert mit diesen Daten? Und wie können wir sicher sein, dass die vollautonomen Fahrzeuge irgendwann ihre „Führerscheinprüfung“ bestehen? Das Erfolgsrezept heißt „industrialisierte Absicherung“. Was das ist, schauen wir uns im Folgenden genauer an.

Sicher die richtige Entscheidung treffen

Wir als Menschen lernen in 20 bis 30 Stunden die Verkehrsregeln, das Fahrzeug zu bedienen und uns regelkonform im Straßenverkehr zu bewegen. Bis zur Führerscheinprüfung erleben wir eine überschaubare Anzahl von realen Situationen, die wir bewerten müssen, um dann korrekt zu entscheiden.

Davor haben wir aber in der Regel rund 18 Jahre unseres Lebens in der realen Welt verbracht, bis der Gesetzgeber uns die „Führerscheinreife“ bescheinigt, wir also überhaupt die Prüfung machen dürfen. Viele Situationen haben wir aus unterschiedlichen Blickwinkeln als Fußgänger, Radfahrer, Beifahrer selbst erlebt oder bei anderen beobachtet. Unser Erfahrungsschatz ist also deutlich größer als er in 20 bis 30 Fahrstunden erworben werden kann. Und er wächst mit jeder Minute, die wir am Straßenverkehr teilnehmen.

Eine autonome Fahrfunktion kann auch nur richtig entscheiden, wenn sie sich in ausreichend vielen Szenarien bewährt hat. Das alles in der realen Welt zu überprüfen dauert lange – und kann bei Fehlentscheidungen schmerzhaft sein. Deswegen braucht jede autonome Fahrfunktion (Lenken, Bremsen, Beschleunigen etc.) unzählige simulierte Szenarien, um zu lernen und die „Führerscheinreife“ zu bekommen. Erst dann darf der „künstliche Fahrer“ mit dem Fahrzeug auf die Straße – für weitere „Fahrstunden“ und zur Erlangung des „Führerscheins“.

Warum die Welt für autonome Fahrfunktionen so kompliziert ist

Nun ist eine autonome Fahrfunktion kein Mensch, sondern ein Stück Software, das aus einer Vielzahl von Algorithmen besteht, die richtig zusammenspielen müssen. Das Prinzip ist immer das Gleiche: Ein Sensor bekommt Informationen aus der realen Welt. Ein Algorithmus bewertet die Information und trifft eine Entscheidung. Ein Aktor führt die Entscheidung aus. Was muss beachtet werden?

  • Der Auslöser der Verkehrssituation: z.B. Ball rollt auf die Straße
  • Die zeitliche Verkettung, z.B. Ball rollt auf die Straße, dann rennt Kind hinterher
  • Mehrere Ereignisse gleichzeitig: z.B. nasse Straße, Fußgänger kreuzt und Auto möchte ausparken
  • Umgang mit Unschärfen: z.B. schlechte Lichtverhältnisse erschweren Identifizierung von Objekten2

Mehr zu Sensorfunktionen, Sensorik und den entscheidenden Kerntechnologien im autonomen Fahren lesen Sie hier.

Absicherungsplattform für autonome Fahrfunktionen

Bevor es auf die Straße geht, werden die Algorithmen für autonome Fahrfunktionen deshalb mit einer Vielzahl von Verkehrsszenarien trainiert. Dabei wird die Software gegen bestimmte Szenarien entwickelt und muss sich anschließend in der Verkettung Ende-zu-Ende bewähren.

Eine Absicherungsplattform bietet dem Entwickler die Möglichkeit, auf eine Datenbank mit virtuellen und realen Verkehrsszenarien zuzugreifen. In diese Datenbank könnten auch die gesammelten Daten aus der eingangs erwähnten Teststrecke in Friedrichshafen einfließen. Virtuelle Verkehrsszenarien sind immer dann wichtig, wenn bestimmte Ereignisse wie Schneefall oder Nebel einfach nicht eintreten wollen oder sehr aufwändig zu erfassen sind. Simulationsingenieure können dann aus verschiedenen Szenarien neue zusammenstellen.

So funktioniert eine Absicherungsplattform für autonome Fahrfunktionen
Abbildung: So funktioniert eine Absicherungsplattform für autonome Fahrfunktionen

In solchen Fällen werden die fertig programmierten Algorithmen mit diesen künstlich erzeugten Szenarien ausgeführt. So wird zum Beispiel das Bild vom rollenden Ball bei der Ausführung des entsprechenden Algorithmus eingespielt. Der Algorithmus verarbeitet die Information und führt die Aktion aus – ohne in einem Fahrzeug verbaut zu sein und ohne reale Situation. Auf diese Weise lassen sich Szenarien vieltausendfach parallel innerhalb wesentlich kürzerer Zeit durchspielen, als es in Realzeit möglich wäre. Anhand des Feedback können die Entwickler dann die Software immer weiter verbessern.

Wenn die Algorithmen alleine mit vielen Szenarien zurechtkommen, haben sie einen ersten Reifegrad erreicht. Im nächsten Schritt wird die Absicherung ausgeweitet: Auf jedes Verkehrsszenario folgt ein weiteres, und es wird nicht nur ein Aktor angesteuert, sondern verschiedene. Auch für diese Absicherung gibt es Feedback an die Entwickler.

Irgendwann sind alle Fahrfunktionen eines vollautonomen Fahrzeugs anhand unzähliger Szenarien trainiert. Die Ergebnisse sind dokumentiert und wiederholbar. Erst jetzt beginnt die Integration in die Hardware – das Auto. Und es folgt die nächste Stufe der Absicherung. Wenn jetzt die Aktoren richtig angesteuert werden und reagieren, haben die Fahrfunktionen die Führerscheinreife erreicht. Diesen Reifegrad kann man über eine Reporting-Komponente messen.

Damit ist unser Fahrzeug aber erst bereit für Fahrstunden auf der Teststrecke. Zusammen mit einem Fahrer – quasi dem Fahrlehrer.

Die ganze Absicherung der Software geschieht auf einer eigenen Softwareplattform. Damit werden Qualität, Wiederholbarkeit und weitestgehende Automatisierung von Softwareentwicklung und -tests sicherstellt.

Erfolgsfaktoren und Herausforderungen für eine Absicherungsplattform

Der Aufbau einer Absicherungsplattform für autonome Fahrfunktionen ist eine Herausforderung für die Softwarearchitektur und -entwicklung. Wiederholbarkeit und Skalierbarkeit sind essenziell, um die programmierten Funktionen vertrauenswürdig zu machen. Die Entwicklung von Fahrfunktionen muss genauso sorgfältig und industrialisiert ablaufen wie die Entwicklung des physischen Fahrzeugs.

Die fünf wichtigsten Erfolgsfaktoren für eine industrialisierte Absicherung sind aus unserer Sicht:

  • Hochskalierbare Plattform und Infrastruktur durch Nutzung von Container-Technologien. Dabei wird die Simulationssoftware und alle zu testenden Algorithmen in Container verpackt und kann dadurch theoretisch beliebig oft parallel aufgerufen werden.
  • Benutzerfreundliche Datenmanagement-Lösung, um das Auffinden der benötigten Szenarien zu ermöglichen. Sie werden damit für die unterschiedlichen Anforderungen von Entwicklern der KI-Komponenten sowie von Simulations- und Testingenieuren gleichermaßen nutzbar.
  • Automatisierte Berechnung von Key Performance Indikatoren nach jeder Änderung des Algorithmus inklusive Versionshistorie. Solche KPIs messen die Veränderungen der Güte des Algorithmus im Laufe der Zeit. Damit wird der Grad des Vertrauens in die Fahrfunktionen messbar.
  • Absicherung in einer möglichst Hardware nahen Umgebung, damit die Absicherungsergebnisse aussagekräftig sind.
  • Agile Zusammenarbeitsmodelle unter Einbeziehung aller Nutzergruppen und aller Partner. Nur wenn alle am Projekt beteiligten Menschen eng und nutzenorientiert zusammenarbeiten und ausreichend Möglichkeiten zur Synchronisierung haben, kann ein solches Vorhaben gelingen.

 

Fazit

Wenn voll autonome Fahrzeuge überhaupt möglich werden und im Idealfall die Sicherheit im Straßenverkehr erhöhen sollen, müssen sie besser entscheiden und reagieren als ein Mensch. Die Fahrfunktionen müssen in sehr kurzer Zeit das lernen, was ein Mensch über Jahrzehnte lernt – und noch mehr. Erst dann werden wir der Fahrfunktion vertrauen können. Eine industrialisierte Absicherungsplattform für autonome Fahrfunktionen unterstützt diesen Lernprozess bis zur Führscheinreife. Wiederholbarkeit und Skalierbarkeit sind dabei die wichtigsten Anforderungen an die Plattform.

 

Mehr über Connected Mobility Dienste des Fahrzeugs erfahren

 

Das könnte Sie auch interessieren: Mit der Cloud vielfältige Fahrszenarien lernen – Wie die Cloud bei großen Datenmengen in der Testausführung von autonomen Fahrzeugen unterstützt


Quellen:

1 https://www.suedkurier.de/region/bodenseekreis/friedrichshafen/Alle-Fakten-zur-Teststrecke-fuer-autonomes-Fahren-in-Friedrichshafen;art372474,9824810

2 https://blog.doubleslash.de/der-bias-effekt-im-machine-learning/

Mal über den Tellerrand geschaut: Was können Softwareprojekte von sozialen Projekten lernen?

Am kommenden Samstag startet in Friedrichshafen wieder das Entenrennen auf dem Seehasenfest. Ein soziales Projekt, das auch von doubleSlash wieder als Hauptsponsor unterstützt wird und über das seit über zwölf Jahren jährlich 20.000 Euro Spendengelder für bedürftige Familien in der Region eingesammelt werden. Eine Erfolgsgeschichte, von der auch Softwareprojekte lernen können? Schauen wir uns die Erfolgsfaktoren einmal genauer an.

Die Projektvision

Das Projekt begann mit der irrwitzigen Idee, 5000 gelbe Gummienten auf einem See, also ohne Strömung, in ein Ziel schwimmen zu lassen. Durch den Verkauf von „Entenlosen“ wollte der Lions Club Friedrichshafen bedürftigen Familien in der Region helfen, die sonst durch die Raster des Sozialstaates fallen. Ein Ziel, dass den Seehasenfestausschuss, die freiwillige Feuerwehr, den THW, die Firmen und Einzelhändler der Region und die Bürger so sehr begeistert hat, dass bereits im ersten Jahr alle Lose verkauft und die volle Summe von 20.000 Euro ausgeschüttet werden konnte. Damit wären wir bei dem ersten Erfolgsfaktor, für ein soziales Projekt: Eine starke Projektvision.

Das erste Rennen – Noch klein, aber es funktioniert

Das Projekt fing natürlich nicht gleich perfekt an, sondern mit einem ersten MVP (Minimum Viable Product). Übersetzt heißt das: eine kleine Version des Rennens, die funktions- und überlebensfähig ist. Die technischen Hürden um Strömung zu erzeugen, die Reihenfolge der einschwimmenden Enten zu registrieren, die Informationen zum Rennen an die Zuschauer zu vermitteln. All das wollte noch mit hohem manuellem Aufwand gemeistert werden. Die Enten waren von einem anderen Club entliehen und wurden am Renntag per Hand aus ihren Säcken gewassert und nach dem Zieleinlauf mit Körben aus dem Wasser gefischt. Das Rennen fand pünktlich statt. Die Enten wurden korrekt registriert. Die Inhaber der Gewinnerlose konnten sich über ihre Preise freuen. Der zweite Erfolgsfaktor für das soziale Projekt ist gefunden: Eine erste Version (ein MVP), die den erhofften Nutzen bereits bringt.

Sukzessive Weiterentwicklung mit vielen engagierten Beteiligten

Nach dem Rennen ist vor dem Rennen. In einer Retrospektive wurde aus Fehlern gelernt und Verbesserungspotenzial zur Skalierung identifiziert. Bei aller Liebe zur Automatisierung bestimmter Abläufe war immer klar: Das darf die Ausschüttung an die Familien nicht schmälern. D.h. alles was Rennen für Rennen investiert werden musste,  brauchte einen Sponsor. Die Preise, eigene Enten für Friedrichshafen, Chips für die Enten zum automatischen Auslesen am Ziel, ein Zieleinlauffloß mit Registrierungssensoren und dieses Jahr erstmals ein Startfloß aus Pontons. All das wäre ohne die Sponsoren und freiwilligen Helfer nicht möglich gewesen, die es zu finden und zu motivieren galt. Der dritte Erfolgsfaktor heißt also: Intensives Stakeholdermanagement.

Alle machen mit

Ein soziales Projekt dieser Größenordnung lässt sich nur umsetzen, wenn alle an einem Strang ziehen. Dazu gehört der „Product Owner“, der die Idee ins Leben gerufen hat und seit zwölf Jahren weiterentwickelt. Ebenso wichtig ist das Kernprojektteam, das sich um Planung,  Akquise der Preise, Vorbereitung der Lose, Umsetzung organisatorischer und technischer Anpassungen, Verkauf der Lose, sowie die technisch organisatorische Umsetzung des Rennens und der Preisverteilung kümmert. Dazu kommen Seehasenfestausschuss, freiwillige Feuerwehr und THW, ohne die die Organisation unmöglich wäre. Die Sponsoren von Preisen und notwendigen Investitionen. Die ehrenamtlichen Helfer und Einzelhändler, die die Lose verkaufen. Und nicht zuletzt die vielen engagierten Bürger, die jedes Jahr ihre Lose kaufen. All diese Menschen zusammen machen den Erfolg des Sozialprojektes aus. Damit wären wir bei dem vierten und vielleicht wichtigsten Erfolgsfaktor für Projekte: ein starkes Commitment aller Beteiligten.

Erfolgsfaktoren für Softwareprojekte

In Softwareprojekten sind zunehmend agile Vorgehensweisen die Arbeitsmodelle der Wahl. Man verspricht sich durch ein iteratives Vorgehen eine Verringerung der Projektrisiken. Häufig wird Scrum mit seinem einfachen und gut durchstrukturierten Rahmenwerk aus Rollen, Meetings und Artefakten als Basis verwendet. Inzwischen gibt es viele Projektmanagement Tools auf dem Markt, die ein solches agiles Vorgehen unterstützen. Trotzdem – oder vielleicht gerade deswegen – beobachten wir immer wieder, dass gerade in großen Projekten ein paar wichtige Bausteine für erfolgreiche Softwareprojekte wieder mehr in den Hintergrund geraten:

  • Das Einschwören des Teams auf eine gemeinsame Produktvision.
  • Der unbedingte Wille aller Beteiligten, den Nutzen jeder Iteration zu erreichen.
  • Transparenz und intensives Einbeziehen der Stakeholder außerhalb des Kernteams.
  • Die Zentrierung auf die Interaktion der Menschen im Projekt.

Mein Fazit:

Es lohnt sich als Kunde, Projektmanager oder Sponsor eines Softwareprojektes mal über den Tellerrand zu schauen und sich wieder auf vernachlässigte Werte zu besinnen. Und wenn im Projekt alles so läuft wie es soll, muss man das nicht als selbstverständlich nehmen und darf den Erfolg auch mal feiern.

DevOps, Microservices & Big Data: Drei Top IT-Themen, die Automobilhersteller künftig beschäftigen werden

Für einen fachlichen Austausch zwischen Mitarbeitern und ausgewählten Dienstleitern veranstaltete die BMW Group auch in diesem Jahr wieder ihre BMW IT Messe in der Münchner Zenith Halle. Im Fokus waren aktuelle Projekte und Innovationsthemen aus Business- und Fahrzeug-IT. Für das Fachpublikum gab es Informationen zu den aktuellen Trends in den IT-Projekten. Als langjähriger Partner der BMW AG waren wir mit dem 7er Pool [1] vor Ort und haben rückblickend drei Top IT-Themen identifiziert, die auf der Messe allgegenwärtig waren.

Mehr

Agile Starthilfe für Konzern IT´s – Warum die agile Transformation im Unternehmen gar nicht so leicht ist

Agile Starthilfe für ProjekteStudien zur Verbreitung agiler Methoden[1] haben ergeben, dass sich agiles Projektmanagement in den Unternehmen immer mehr durchsetzt. Aus IT Abteilungen von Konzernen wird uns in letzter Zeit sogar berichtet, dass sie inzwischen alle IT-Projekte agil abwickeln müssen. Gleichzeitig tut sich die Konzern IT schwer, ihre Softwareprojekte flächendeckend auf agil umzustellen. Wir beobachten das mitunter daran, dass wir gerade jetzt vermehrt Anfragen nach „agilen Starterpaketen“ für Softwareprojekte erhalten. Warum ist das so?

 

Mehr

DevOps Kultur: Wenn Teams die Prinzipien der agilen Softwareentwicklung ernst nehmen

Wie können Entwicklung und Betrieb im Rahmen von moderner Softwareentwicklung erfolgreich miteinander verbunden werden? Das war Thema auf einer Veranstaltung des Agile Table in Kooperation mit der deutschen Gesellschaft für Projektmanagement (GPM) bei doubleSlash. Die beiden Referenten Alexander Birk und Christoph Lukas, beide seit 18 Jahren als Freiberufler unter dem Namen pingworks tätig, brachten ihre langjährige Erfahrung in der Softwareentwicklung mit ein und stellten die Prinzipien und Herausforderungen einer DevOps Kultur vor.

Mehr

Scrum oder murcS? Warum agile Projekte scheitern und wie man das verhindern kann

Scrum Scrum Projekte liefern meist „sensationelle Ergebnisse“, so das Zitat eines unserer Kunden bei einem Workshop vergangene Woche. Trotzdem werden sie nicht immer als Erfolg gewertet. Viele Projekte fühlen sich anstrengend an. Der Fachbereich muss sich über den gesamten Projektzeitraum viel intensiver mit der entstehenden Software auseinandersetzen, als gewohnt. Die Entwickler fühlen sich von Sprint zu Sprint gehetzt. Die Scrum Master haben das Gefühl, gegen Windmühlen zu kämpfen, wenn sie für das Team Hindernisse aus dem Weg räumen wollen. In unserem „Center of Competence für Projektmanagement“ haben wir daher einen „wilden Erfahrungsaustausch“ von Entwicklern, Scrum Mastern, Product Ownern und agilen Coaches gestartet und sind auf fünf bekannte, praktisch aber oft vernachlässigte Rahmenbedingungen für erfolgreiche agile Projekte gestoßen.Mehr

Scrum auf den Hund gekommen – Von der agilen Schätzung bis zum agilen Vertrag

Als wahres Energiebündel zeigte sich Adriana Ardelean am 13.7. beim Treffen der .NET Usergroup in Friedrichshafen. Die Projektmanagerin von activeDevelop in Lippstadt teilte hier ihre langjährige Erfahrung in der Planung und Umsetzung von agilen Softwareprojekten nach Scrum. Unter dem Titel „Die agile Unsicherheitsversicherung“ verpackte sie teils skurrile, aber wirkungsvolle Ideen zum Schätzen in agilen Projekten und den Weg zu einem fairen agilen Vertrag.
Mehr

Scrum in der Geräteentwicklung: Neuer Trend oder alter Hut?

Scrum in der GeräteentwicklungIm Umfeld des Internet of Things (IoT) verschmelzen Software- und Hardwareentwicklung immer stärker miteinander. Damit ändern sich auch die Anforderungen an die Entwicklung von Geräten. Durch eine Vielzahl günstiger Hardwarekomponenten, Frameworks und Bibliotheken lassen sich schnell Prototypen entwickeln. Funktionale Komponenten aus Hard- und Software können so frühzeitig vom Anwender auf Herz und Nieren geprüft und teure Fehlentwicklungen vermieden werden. Da liegt es nahe, die ursprünglich für Software konzipierte Projektmanagement Methodik Scrum auch auf die Geräteentwicklung auszudehnen.Mehr