Glossar Agile in Automotive

Vorstellung ausgewählter agiler Methoden und Konzepte

Hier finden Sie Erläuterungen zu weit verbreiteten agilen Methoden und Konzepten, um die Entwicklung Software-bestimmter Systeme effektiver zu gestalten.

Continuous Integration (CI)

Continuous Integration (CI, fortlaufende Integration) hat das Ziel Integrationsprobleme zu reduzieren, die zum Beispiel durch Änderungen verschiedener Teammitglieder entstehen können. Änderungen werden ein oder mehrere Male am Tag zu einer gemeinsamen Baseline zusammen-geführt. Voraussetzung für CI ist ein gemeinsames Repository zur Quellcode-Verwaltung, welches das Ein- und Auschecken des Quellcodes geführt unterstützt und synchronisiert. Konflikte und Widersprüche werden dabei aufgezeigt und im Team entsprechend aufgelöst. Die Integration selbst wird automatisiert durchgeführt, d.h. übersetzt und zusammen-gebunden zu einem Komplettprodukt.

Weiter beinhaltet CI statische und dynamische Tests, z.B. statische Codeanalysen und automatisierte Unit- und Integrationstests. Die Entwickler erhalten Statusberichte und Qualitäts- und Performance-Metriken. Der Integrationsprozess ist dann abgeschlossen, wenn alle Fehler behoben wurden und ein lauffähiges Produkt entstanden ist.

CI-Prinzipien

  • Häufig Einchecken – mindestens täglich
  • Kein Einchecken von ungetestetem Code
  • Schnelles Feedback für jedes Einchecken
  • Die Behebung eines Problems hat die höchste Priorität
  • Wer das Problem verursacht hat, kümmert sich um die Lösung

Extreme Programming (XP)

Extreme Programming (XP) ist ein Software-Entwicklungsmethodik, die dazu bestimmt ist, Software-Qualität und Reaktionsfähigkeit auf sich ändernde Kundenanforderungen zu verbessern. Als Element der agilen Softwareentwicklung werden häufige „Releases“ in kurzen Entwicklungszyklen propagiert. Andere Elemente des Extreme Programming sind: Programmieren in Paaren oder umfangreiche Code-Reviews, Unit-Tests des Codes, eine flache  Managementstruktur, Einfachheit und Klarheit im Code, erwartet Veränderungen in den Anforderungen des Kunden über die Laufzeit und besseres Problemverständnis und häufige Kommunikation mit dem Kunden und unter den Programmierern.

Feature-Driven Development (FDD)

Feature-Driven Development (FDD) ist eine modellorientierte, zyklische, um eine Basisreihe von Best Practices gebaut, angetrieben von der Erzielung eines Mehrwertes für den Kunden:

  • Domain Object Modeling. Domain-Objekt-Modellierung besteht aus der Erforschung und Erklärung der Domäne des zu lösenden Problems. Das daraus resultierende Domain-Objektmodell stellt einen übergreifenden Rahmen, in dem die Features hinzuzufügen sind.
  • Developing by Feature: Jede Funktion, die zu komplex ist, um innerhalb von zwei Wochen durchgeführt zu werden, wird weiter in kleinere Funktionen zerlegt, bis jedes Teilproblem ist klein genug, um in einer Funktion aufgerufen zu werden. Das macht es leichter, richtig zu liefern und Funktionen des Systems zu erweitern oder zu ändern.
  • Individual Class (Code) Ownership: Iindividuelle Klasse Eigentum bedeutet, dass verschiedene Teile oder Gruppierung von Code auf einem einzigen Eigentümer zugeordnet sind. Der Eigentümer ist für die Konsistenz, Performance und konzeptionelle Integrität der Klasse verantwortlich.
  • Feature Teams:Ein Feature-Team ist ein kleines, dynamisch gebildetes Team, das eine kleine Funktion entwickelt. Dadurch betrachten mehrere Personen jede Design-Entscheidung und auch mehrere Design-Optionen werden immer ausgewertet, bevor eine ausgewählt wird.
  • Inspections: Inspections (Kontrollen) werden durchgeführt, um eine gute Qualität von Design und Code zu gewährleisten, vor allem durch Erkennung von Fehlern.
  • Configuration Management: Konfigurationsmanagement hilft bei der Identifizierung vom Quellcode für alle Funktionen, die bisher abgeschlossen wurden und  um eine Änderungshistorie der Klassen zu erhalten, wenn sie von  Feature-Teams weiter entwickelt wurden.
  • Regular Builds: Regelmäßige Builds  gewährleisten ein aktuelles System gibt, welches dem Kunden nachgewiesen werden kann, und hilft Fehlers des Quellcodes frühzeitig bei der Integration der Funktionen zu erkennen.
  • Visibility of progress and results: Durch häufige, angemessene und genaue Fortschrittsberichterstattung auf allen Ebenen innerhalb und außerhalb des Projekts, basierend auf abgeschlossenen Arbeiten werden  Manager beim Steuern des Projekts unterstützt.

Test Driven Development (TDD)

Test Driven Development (TDD) entwickelt auf Basis von Anforderungen und Grobentwurf schrittweise zunächst die Tests, die ein Feature erfüllen muss, anschließend den minimalen Code, der die Tests erfüllt. Dieses Vorgehen stellt sicher dass Anforderungen und Entwurf durch den Code umgesetzt werden und treibt ebenfalls die Klärung der Anforderungen voran. Die Tests stellen einen ausführbaren Teil des Detailentwurfs dar, der zwingend immer aktuell ist.

Drei Schritte in einer TDD-Iteration:

  1. RED – In diesem Schritt wird ein Testfall geschrieben. Dabei nimmt der Autor die Sicht des Anwenders ein und kann sich voll auf das Verhalten des zu erstellenden Codes konzentrieren.
  2. GREEN – Im zweiten Schritt der Iteration geht es darum, den Test so schnell als möglich erfolgreich zum Durchlaufen zu bewegen. Es kommt dabei nicht auf guten Programmierstil oder effektiven Code an. Erlaubt ist alles, was den Test erfolgreich macht: Feste Rückgabewerte, fest codierte Parameter, alles ist möglich und in diesem Schritt auch erlaubt.
  3. REFACTOR – Der Test ist jetzt erfolgreich. Im letzten Schritt einer Iteration geht es darum, den Code ins Reine zu bringen. Wie die gesamte Entwicklung wird auch die Restrukturierung in kleinen Schritten durchgeführt. Nach jeder Restrukturierung wird der Test erneut gestartet. Ist der Test weiterhin erfolgreich, kann mit der nächsten Restrukturierung fortgefahren werden. Schlägt der Test fehl, nimmt man die letzte Restrukturierung zurück.

Die oben genannten Schritte werden, für eine zu erstellende Komponente, so lange durchgeführt, bis alle Anforderungen implementiert sind.

Vorteile von TDD: Testbarkeit; Modulares Design mit reduzierten Abhängigkeiten und geringer Codekomplexität; Tests, die nicht nur das testen, was der Code implementiert.

User Story

Eine User Story beschreibt ein Szenario aus der Perspektive des Anwenders und beantwortet dabei die Fragen WER? WAS? WARUM?

Ein oft verwendetes Muster sieht wie folgt aus:

  • ‘Der ...’ (wer: Rolle) ‘möchte ...
  • (was: Anwendungs-Anforderung)
  • ‘weil ...’ (warum: Nutzen)

Zu jeder User Story werden Akzeptanzkriterien formuliert. Die besten Kriterien ergeben sich aus konkreten Beispielen von erwarteten Ereignissen die sich zur Überprüfung eignen. Die Akzeptanzkriterien bilden den Anfangspunkt für das Schreiben von Akzeptanztests, die nachweisen müssen, dass die User Story wie erwartet implementiert ist. Oft wird erst durch diese klar, welcher Aufwand hinter einer Benutzergeschichte steht oder welche Granularität sie verlangt. Es kann sich z.B. herausstellen, dass der Product Owner viel mehr erwartet, als das Team auf den ersten Blick sieht. User Stories bilden z.B. die Grundlage der Beschreibung von Features die im Product Backlog vom Product Owner priorisiert werden. Um eine gute User Story zu erkennen sind folgende Eigenschaften hilfreich: unabhängig gegenüber anderen User Stories, verhandelbar in seinen Details, wertvoll, schätzbar, testbar.

Kontakt
Softwaredrives