Body of Knowledge
Standards und Regularien
Kernpunkte:
- Standards und Regularien sind oft an Reifegradmodellen ausgerichtet
- Prozess- und Produktqualität muss kontinuierlich sichergestellt werden (Plan – Do – Check – Act)
- Die Qualitätsziele von Standards können durch spezifischen Anpassungen und ergänzende Rollen auch in agilen Projekten erreicht werden
- Die agilen Werte bleiben dabei erhalten
Wie erfüllen agile Organisationen notwendige Standards und Regularien?
Die Erfüllung von Standards wie z. B. Automotive SPICE® und ISO26262 (Functional Safety) erfordert eine Anpassung agiler Planungs- und Qualitätssicherungselemente. Es ist eine Überprüfung agiler Vorgehensweisen in Bezug auf die relevanten Prozessziele und die Prozessergebnisse notwendig.
So muss der Kunde im Sinne agiler Vorgehensmodelle in der Interpretation von Standards nicht zwangsläufig gleich der Endkunde sein, sondern könnte auch ein Unternehmensinterner Kunde sein. Und kontinuierliche Auslieferung von Software bedeutet nicht tägliche Updates in Maschinen oder Fahrzeugen.
Wichtig ist jedoch, dass bei Anpassungen agiler Vorgehensmodelle die agilen Werte gewahrt bleiben. So muss z. B. nach einem Scrum-Sprint nicht zwingend immer gleich Software ausgeliefert werden, aber werthaltige Ergebnisse. Werthaltig ist ein Ergebnis dann, wenn es für den gedachten Zweck sinnvoll nutzbar ist.
Da Standards- und Regularien häufig branchenspezifisch sind, sollen hier nachfolgend auf spezifische Themen zu einzelnen Standards eingegangen werden, wie beispielsweise „Agile Prinzipien und ISO26262“. Einer allgemeinen Darstellung des Themas „Agilität“ in der jeweiligen Branche widmen wir uns in Agile in Branchen.
Agile Prinzipien und Funktionale Sicherheit - ISO 26262
Hinweis:
Anmerkung zu den Agilen Prinzipien aus Sicht der ISO26262 und der Umsetzbarkeit in automotiven Serienprojekten: Hierbei handelt es sich um eine Interpretation der Agilen Prinzipien durch den Arbeitskreises „Agile Softwareentwicklung bei sicherheitsrelevanten Systemen“ der Themenplattform Automotive des ZVEI.
Die deutsche Version der agilen Prinzipien sind im nachfolgenden Text jeweils als blaue Überschriften dargestellt (siehe auch http://agilemanifesto.org/iso/de/principles.html).
Agile Prinzipien und Funktionale Sicherheit - ISO 26262
1. Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.
Der „Kunde“ ist nicht automatisch der Endkunde. Customer interpretieren wir als Stakeholder, was interne Kunden, Standards und Normen wie ASPICE und ISO26262 einschließt.
„Kontinuierliche Auslieferung wertvoller Software“ bedeutet: „Kontinuierliche Lieferung von wertvollen Ergebnissen“ (und nicht nur Software). „Wertvoll“ ist, wenn das Ergebnis für den gedachten Zweck sinnvoll nutzbar ist.
„Kontinuierliche Auslieferung“ bedeutet nicht, dass automatisch „täglich“ Software in Fahrzeugen im Feld aktualisiert wird.
„Kontinuierliche Auslieferung“ ist nur in Verbindung mit „wertvoll“ zu sehen. Bei „wertvoll“ ist der für die gedachte Nutzung des Ergebnisses benötigte Mindestreifegrad zu berücksichtigen; eine Regelung kann durch eine “Definition of Done” und Akzeptanzkriterien erfolgen.
2. Heisse Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
„Heisse Anforderungsänderungen willkommen“ bedeutet, dass eine Organisation/Projekt darauf ausgerichtet ist mit Änderungen umzugehen. Es bedeutet nicht, dass jederzeit Änderungen bedingungslos umgesetzt werden.
Ein stringenter Prozess für die Behandlung von Änderungsanträgen ist erforderlich. Das ermöglicht die Auswirkungen von Änderungsanträgen hinsichtlich der relevanten Stakeholder zu beurteilen.
Prozesse und Strukturen sind so zu definieren, dass ein Projekt in der Lage ist, späte Änderungen kontrolliert umzusetzen.
Änderungen sind im Backlog einplanen und entsprechend der Sprintplanung umsetzen. Dazu gehört auch eine transparente Kommunikation an den Kunden.
3. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.
Siehe Punkt 1 für eine Beschreibung zu „wertvolle Software“. “Software” bedeutet hier wieder alle Arten von Ergebnissen.
Das Bevorzugen kurzer Zyklen führt zu einer Lieferung kleinerer, aber sinnvoll für die geplante Verwendung nutzbarer Ergebnispakete (Delta) innerhalb der Entwicklungskette. Dadurch können Ergebnisse frühzeitig bestätigt oder Korrekturmaßnahmen rechtzeitig ergriffen werden.
Eine geplante Integration aller Teilergebnisse in einem Projekt verbunden mit einem Integrationstest ist notwendig und wird nicht automatisch durch „kontinuierliche Auslieferung“ geleistet.
4. Geschäftsleute und Entwickler müssen während des Projektes täglich zusammenarbeiten.
Kontinuierliche fachübergreifende und problemorientierte Zusammenarbeit im Sinne des Projektergebnisses. Z.B. nicht jeder Entwickler soll seine eigene Interpretation der ISO26262 vornehmen, sondern auf die entsprechenden Experten zugehen.
5. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.
In Übereinstimmung mit ISO26262 Band 2 Kapitel 5 und 6 („Safety Culture“).
Gebe so viel Vertrauen wie möglich an das Team. Prüfe so viel wie notwendig im Sinne der besonderen Sorgfaltspflicht.
6. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.
Diese Aussage bedeutet nicht, dass sich alle Mitglieder eines Teams in einem Raum befinden müssen.
Entwicklungsrelevante Information sind nachvollziehbar zu dokumentieren.
7. Funktionierende Software ist das wichtigste Fortschrittsmaß.
„Funktionierende Software“ ist im Sinne von Punkt 1 „wertvolle Software“ zu verstehen.
Im Kontext der ISO26262 ist „funktionierend“ hier nicht auf den einfachen Nachweis der spezifizierten Funktion reduzieren, sondern dass eine gewisse Robustheit vorliegt sowie ein vorhersehbarer Fehlgebrauch abgesichert ist.
8. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
In Übereinstimmung mit ISO26262 Band 2 Kapitel 5 und 6 („Safety Culture“). Für die Entwicklung sicherheitsrelevanter Software/Systeme braucht es Mitarbeiter, die nicht ständig überlastet sind.
9. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.
Zu „technische Exzellenz“ und „gutes Design“ siehe entsprechende Prinzipien und Empfehlungen der ISO26262, z.B. Design Prinzipien wie „Einfachheit“ (Simplicity).
10. Einfachheit -- die Kunst, die Menge nicht getaner Arbeit zu maximieren -- ist essenziell.
Übereinstimmung zwischen agilen, und lean Prinzipien sowie der ISO26262. Bearbeite das, was im Sinne der Arbeitsaufgabe notwendig ist. Vermeide Verschwendung, vermeide unnötige und doppelte Arbeit.
11. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
Diese Aussage gilt im Rahmen des von außen an das Team herangetragenen Qualitätsanspruchs und der Erwartungen der Stakeholder (siehe Punkt 1).
12. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.
Bei der Umsetzung von Änderungen ist eine Begründung zu nennen, dokumentierte Umsetzung von Änderungen.
Zur Vermeidung von lokaler Optimierung stelle „Leitplanken“ für ein Team auf, anhand derer es die Grenzen seiner Selbstoptimierung erkennt. Bei Änderungsvorschlägen, die über diese „Grenzen“ hinausgehen, ist eine Bewertung im Sinne der Gesamtorganisation notwendig, z.B. um sicherzustellen dass eine gewisse Mindestsorgfaltspflicht eingehalten wird.