AGILE in der Normativen Welt

Es wird ein wenig ketzerisch

Thomas Arends

58 Jahre

Verheiratet 4 Kinder

Inhaber Geschäftsführer Deutscher Mittelstand Ltd.

Ø Geschäftsführung, CPO, Projektleitung, Qualitätsleitung,Task Force Management

Ø Automotive, Aerospace, Industrial, Financial/Legal, Medical, Pharma

Ø V-Modell, Agile, SAFe®, LESS, CMMI, RUP, SCRUM, Kanban

Europa Distributor für Kovair ALM, Kovair Omnibus, Kovair Quick Synch

Inhalt

▪ Agil

▪ Agile Hype

▪ SAFe® - ein Dämpfer?

▪ Agile Studie Kugler Maag

▪ Methodenstudie Namecook

▪ Normative Anforderungen

▪ Lösungsansatz

▪ Was es so an Studien gibt

Erst werde ich Ihnen Agilität vermiesen um dann zu zeigen wie es trotzdem geht

Agile in der Normativen WeltWas ist die Beste Entwicklungsmethode?

▪ Agile mit Scrum & oder Kanban

▪ LESS

▪ SAFe®

▪ V-Modell mit Agilität

▪ CMMI SPIRAL

Woran erkennt man das Beste Modell?

Was ist Agil?

▪ Bessere Wege, Software zu entwickeln, indem wir es selbst tun und Anderen dabei helfen.

▪ Individuen und Interaktionen mehr als Prozesse und Werkzeuge

▪ Funktionierende Software mehr als umfassende Dokumentation

▪ Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung

▪ Reagieren auf Veränderung mehr als das Befolgen eines Plans

http://agilemanifesto.org/

Das Untere wird meist nicht mehr gelesen:

Obwohl wir die Werte auf der „unteren“ Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein

Agilität als Irrweg

▪ Studien Zeigen, dass die Methode (Agil, Waterfall…) völlig unwichtig ist um gute Qualität zu erreichen, ERFAHRUNG macht es! (Seite 18)

▪ Ebenso zeigen Studien (und Aussagen von Mitarbeitern in der Automobilindustrie und in der Medizin), dass Agil (trotz SAFe® und LESS …) NICHT skaliert/nicht anwendbar ist, sobald es um besondere normative Anforderungen geht.

▪ Agil widerspricht dem V-Modell nicht!

▪ Wer etwas anders behauptet hat entweder das Eine, oder das Andere oder beide NICHT VERSTANDEN.

Agile HypeUnd ein paar ketzerische Kommentare

HYPE?

Grundlegende Ideen

Kurzer Exkurs in die Biologie.

Selbstorganisation führt maximal zu einem losen Einzellerverbund.

Alle höher organisierten Organismen egal ob Pflanzen, Tiere oder was auch immer folgen einem hierarchischen System.

Und die Kollegen von der Engineering Abteilung der Biologie hatten ein paar mehr Jahre Zeit um etwas zu entwickeln.

Abschauen und Kopieren erlaubt à Bionik.

AGILE hier SAFe® So ganz scheint es nicht zu passen

SAFe® als HYPE?P 147

SAFe®P 339

SAFe®P 343

Zusammnengassung

Build In Quality

Value Stream Level is Optional

Value Stream Level is most fundamental

oder

Stellen Sie sich vor

Ihre Mitarbeiter liefern Ihnen so ein „Unsafe“

Studie der Fa. Kugler Maagzur Anwendung von AGILE

Einstimmige Ansicht der Befragten:

Nach agilen Methoden und Prinzipien "blind" wie "durch das Buch beschrieben zu arbeiten hätte zum Scheitern geführt

Deshalb machen die Befragten “cherry picking" und implementieren solche agile Praktiken, die für sie nützlich sind

Studie der Fa. Kugler Maag

Einstimmige Ansicht der Befragten:

▪ Agile skaliert nicht (Trotz LESS & SAFE*)

▪ Mangel an Vorausplanung und

▪ Managementwiderstand

▪ Das größte Problem:, agile Elemente in eine nicht agile Umgebung zu bringen, die Fähigkeit, die Organisationskultur, die Projektkomplexität und die Kundenzusammenarbeit zu verändern

*Diese Aussage habe ich zugefügt nach mehreren Gesprächen mit Entwicklern bei deutschen Automotive OEM‘s und Tier 1 Zulieferen

Quelle: http://www.kuglermaag.de/fileadmin/05_CONTENT_PDF/2-22_agile-automotive_survey-2015.pdf

Kurze Zusammenfassung

▪ Project Manager scheinen sehr intelligent zu reagieren.

▪ Sie machen das was notwendig ist so dass das gewünschte Ergebnis erreicht wird.

▪ Sie nahmen/nehmen das (egal woher es kommt) was Ihnen hilft besser zu werden.

▪ Es scheint „unlösbare“ Wiedersprüche zu geben

Weitere Studienresultate

Weitere Studienresultate, welche in dem angegebenen Dokument (Kugler Maag) zu finden sind.

• Low Performer und High Performer haben Probleme in solchen Projekten.• Low Performer mit der Transparenz.• High Performer verlieren ihren Heldenstatus.

Qualität

Ergebnisse einer Studie von Namecook 2015!Effizienz und Qualität verschiedener Methodden

▪ Alle Methoden erreichen Ihr Ziel▪ Agile Methoden sind schnell

▪ Qualitätslastige Methoden sind qualitativ hochwertig

▪ Kostenvarianz unterschiedlicher Methoden bei gleicher Last 1->4

Rather to do with joining a cult but a technical decision

▪ In general choosing a development method has

Ergebnis der StudieGleichmacherei in der Agilität

▪ Ich persönlich habe kein Problem damit das Low Performer auffallen und sich unwohl fühlen.

▪ Ich habe aber ein großes Problem damit, wenn die Highperformer nicht weiterhin exzellent genutzt werden. Sie werden gehen.

▪ Jeder der nicht das Gefühl hat das seine Beiträge wertgeschätzt werden▪ Wird knötterig

▪ Arbeitet gegen diese Menschen welche ihn nicht wertschätzen oder wendet sich von diesen ab.

▪ Auf lange Sicht wird er die Firma nicht mehr unterstützen, und selbst wenn es bloß darauf hinausläuft dass er nicht mehr vollen Einsatz zeigt.

Interessenskonflikt

▪ Sicherheit / Qualität und Agile gehören beide zu unseren wichtigen Themen.

▪ Agile is not strong on quality so it is only number 8 out of 10

▪ Hat Sicherheit für Ihr Unternehmen hat ein Anreizsystem?

▪ Bei SCRUM gibt es das:

Der Product Owner wird an der Wirtschaftlichkeit der Increments gemessen.

Agiler AnsatzM-SPICE© (VDI 5702) ISO 13485ISO 14971ISO 60601CFR21 SPICE © Grundlegende Anforderungen à Erst mal die Normen

ISO 15504 / 330xx SPICE®

▪ Software Process Improvement and Capability Determination(SPICE)

▪ ISO/IEC 15504 / 330xx Information technology – Process assessment, also termed (SPICE), is

• a set of technical standards documents

• for the computer software development process and

• related business management functions. (This is the mostly overlooked information out of the Norm)

Basic for Medical SPICE® (VDI5702)

Process House ISO15504 330xx

65 Processes > 250 Work Products

Das MSPICE© Prozesshaus

ISO 62304 ist ähnlich

Das MSPICE© Prozesshaus(Standalone mapping)

Medical SPICE VDI 5702

Zusammenfassung

▪ Klares V-Model

▪ Entwicklung beginnen von den Top Anforderungen

▪ Traceability und Konsistenz ist ein MUSS!

Wie löst man das Alles?Das Langzeitergebnis zählt

Agile Methode Widersprüche zur Norm & Abhängigkeiten -1

Agile Methode▪ Menschen und Interaktionen stehen über Prozessen und Werkzeugen

à Conway Gesetz

*Was ist “funktionierend?”

▪ Funktionierende* Software steht über einer umfassenden Dokumentation à Conway GesetzWiderspricht scheinbar der gesetzlich und der seitens der Norm geforderten Dokumentationspflicht

▪ Reagieren auf Veränderung steht über dem Befolgen eines Plans à Standard [TOC & EKS und „Conway“]

▪ Zufriedenstellung des Kunden durch frühe und kontinuierliche Auslieferung von wertvoller Software.Widerspricht der Notwendigkeit einer Sicherheitsarchitektur sowie der Modularität vs. Schnittstellen

▪ Agile Prozesse nutzen Veränderungen (selbst spät in der Entwicklung) zum Wettbewerbsvorteil des Kunden. à Conway Gesetz

▪ Lieferung von funktionierender Software in regelmäßigen, bevorzugt kurzen Zeitspannen (wenige Wochen oder Monate)

▪ Widerspricht der Notwendigkeit aus der Norm Konzepte und Architektur zu haben bevor man weiter arbeitet

Agile Methode Widersprüche zur Norm & Abhängigkeiten -2

▪ Nahezu tägliche Zusammenarbeit von Fachexperten und Entwicklern während des Projektes (Bsp.: Gemeinsamer Code-Besitz (Collective Code Ownership)) è(Conway und Ausbildung)

▪ Bereitstellung des Umfeldes und der Unterstützung, welche von motivierten Individuen für die Aufgabenerfüllung benötigt wird [Diese Anforderung ist undefiniert à Ermittlung des notwendigen Umfeldes durch Umfrage]

▪ Informationsübertragung nach Möglichkeit im Gespräch von Angesicht zu Angesicht

▪ Widerspricht anscheinend der Notwendigkeit zur Dokumentation

▪ Als wichtigstes Fortschrittsmaß gilt die Funktionsfähigkeit der Software

▪ Widerspricht anscheinend der Notwendigkeit Interfaces

▪ Einhalten eines gleichmäßigen Arbeitstempos von Auftraggebern, Entwicklern und Benutzern für eine nachhaltige Entwicklungà Planung Strukturierung

▪ Ständiges Augenmerk auf technische Exzellenz und gutes Design

▪ à Widerspricht den Architekturen welche ggf. durch Anforderungen geändert werden)

▪ Einfachheit ist essenziell (KISS-Prinzip) [Wie kann man das machen .. FTA FMEA FMEDA….]

▪ Selbstorganisation der Teams bei Planung und Umsetzung è(Ideen vorgeben)

▪ Selbstreflexion der Teams über das eigene Verhalten zur Anpassung im Hinblick auf Effizienzsteigerungè Ziele müssen vorgegeben werden

Agile Methode Widersprüche zur Norm & Abhängigkeiten -3

Inhalt

▪ Konflikte Agile Methode zur

▪ „Probleme“

▪ Lösungsansatz

▪ Umsetzung

Probleme

▪ Arbeitsprodukte müssen vorliegen, BEVOR agiert wird

▪ Gewisse Arbeitsprodukte müssen erstellt werden BEVOR weitere Entwicklung stattfinden kann

▪ Schnittstellen zwischen den Modulen (Grob anfangen à verfeinern und downsizen)(Widerspruch Einkauf – möglichst Billig)

▪ Skalierung der Teams (Agile Methode Selbst finden)

Wer oder was ist Conway… 1964Conway's law

▪ organizations which design systems ...

▪ are constrained to produce designs which are copies of the communication structures of these organizations

Inhalt

▪ Konflikte Agile Methode zur Norm 26262

▪ „Probleme“

▪ Lösungsansatz

▪ Umsetzung

LösungsansatzDas Ergebnis zähltInhalt

Lösungsansatz„Methodenlose“ EntwicklungDas machen, welches das Ergebnis bringt

1. Ergebnis definieren/ Zieldefinition (muss vorhanden sein) [Wer definiert] (Zeit, Aufwand, Qualität ….)

2. Entpolitisieren èMeinungen entfernenà Prozesse / Ergebnisse [Kennzahlen]Weder ist das V-Modell, noch die Agile Methode richtig, das Ergebnis bestimmt den Weg à auf die Kompetenz der Mitarbeiter setzen

3. Conway GesetzOrganisationen, die Systeme entwerfen, […] sind auf Entwürfe festgelegt, welche die Kommunikationsstrukturen dieser Organisationen abbilden.Ausbildung untereinanderè Stärkere Kommunikation der Teams untereinander è Ausbildung

4. Theorie der Abhängigkeiten (TOC [Theory of constraints])Engpass finden und auslasten (Bedingung à Kennzahlen)

5. EKS(Engpass orientierte Strategie)Konzentration auf die Kompetenzen à Lösungen hinzukaufen

LösungsansatzMethodenlose EntwicklungDas machen, welches das Ergebnis bringt

1. Überdimensioniert beginnen2. Downsizing, wenn überhaupt in einem späten (C/ D( Muster

(widerspricht dem Wunsch des Einkaufs)3. Prio 1 Themen zuerst 4. In der Vorentwicklung (A & B Muster)

MEHR investieren um dort die Lösungen zu finden5. Kommunikation Einfordern [Meeting Support Record] [Conway]6. Ausbildung Einfordern [Conway]

(BSP: 4 Std / Tag– Domänen untereinander) à Probleme kommen auf èlösen

7. Statische Anforderungen der Norm (Mental) ausgliedern8. Das Team selbst die beste Methode finden lassen (Agile)9. Aufwändige Aktionen Agil in Themenkomplexen entwickeln –

Bsp. Requirements & Architektur10. Aufwändig planen – PUFFER realistisch einschätzen

Inhalt

▪ Konflikte Agile Methode zur Norm 26262

▪ „Probleme“

▪ Lösungsansatz

▪ Umsetzung

LösungsansatzDas Ergebnis zählt

Umsetzung User Stories

1. Teamaufsatz in Bezug auf „Must haves, before can do“ verändernGrundsätzlich sind im Thema User Stories die System Requirements Ingenieure, Architekten und Tester der Systemebene VOLL beteiligt.

2. „Abschnittsweise“ Bearbeitung der US

US

RQ (1) RQ Tester (1)

Agile Team 1SYS Architektur

SYS Integration

SW RQ HW RQ HW RQ

Umsetzung Systemebene

RQ1 RQ Tester (1)

SYS Architektur SYS Integration

SW RQ1 HW RQ1

ME RQ1

SW Tester 1 HW Tester 1

ME Tester 1

Agile Team 2SI RQ1

Grau optional

Umsetzung Architekturebene

SYS Architektur SYS Integration

SW RQ1 HW RQ1

ME RQ1

SW Tester 1 HW Tester 1

ME Tester 1

Agile Team 3Safety RQ1

Umsetzung SWE / HWE

3. In den SWE/HWE/Ebenen wird entsprechen weiter gearbeitet

SWE/ HWE RQ

Modul Tester

Architekt

Agile Team 4

FUSI RQ1

Modulersteller

Integrator

Tester

Grau optional

FinallyWas es so an Studien gibt

Barry Boehm und Victor Basili▪ Softwarefehler, die erst spät im Lebenszyklus einer Software – also z. B. nach der Auslieferung –

gefunden werden, verursachen bis zu 100-mal mehr Kosten als solche, die frühzeitig entdeckt werden. Dies spricht für den konsequenten Einsatz von Techniken zur Fehlervermeidung, insbesondere auch in den frühen Phasen eines Projektes.

▪ 40 bis 50 Prozent des Gesamtaufwandes eines Softwareprojekts entstehen durch eigentlich vermeidbare Nacharbeit. Eine deutlicheReduktion dieses Aufwandes kann vor allem durch Verbesserungen in den Bereichen Entwicklungsprozess, Softwarearchitektur und Risikomanagement erreicht werden.

▪ 80 % der vermeidbaren Nacharbeit werden von nur 20 % der Fehler verursacht. Fehlermanagement kann helfen, die kritischen Bereiche einer Anwendung zu identifizieren. Diese können dann einem Refactoring unterzogen werden.

▪ 80 % der Fehler treten in nur 20 % der Module oder Komponenten auf.Über die Hälfte aller Module und Komponenten ist fehlerfrei. Dieser Tatsache sollte man z. B. durch automatisierte Codeanalysen Rechnung tragen. Diese Analysen geben schon früh im Lebenszyklus eines Projektes wertvolle Hinweise auf potenziell fehleranfällige Module.

▪ 90 % aller Ausfälle eines Systems werden von nur 10 % der Fehler verursacht. Es ist offensichtlich, dass der komplette Stillstand eines produktiven Systems zu den schwerwiegendsten Fehlerszenarien gehört. Jeder einzelne frühzeitig identifizierte oder vermiedene Fehler aus diesen kritischen 10 % rechtfertigt schon für sich die Maßnahmen zur Fehlervermeidung in einem Projekt Zurück

Optimierungspotential

▪ 40 bis 50 Prozent des Gesamtaufwandes eines Softwareprojekts entstehen durch eigentlich vermeidbare Nacharbeit. Eine deutliche Reduktion dieses Aufwandes kann vor allem durch Verbesserungen in den Bereichen Entwicklungsprozess, Softwarearchitektur und Risikomanagement erreicht werden

▪ è Selbst mit zusätzlichem Aufwand zur Vermeidung lassen sich MINDESTENS > 20% der Entwicklungskosten sparen

▪ 100 Mann Projekt auf 3 Jahre = >10 Millionen Einsparung

▪ 25 Mann Projekt auf 3 Jahre = > 2,5 Mio Einsparung

▪ Pro Person auf 3 Jahre 125.000

Zurück

Die grundlegende Idee einer jeden Veränderung

▪ Benutzen Sie jegliche Norm.

▪ Benutzen Sie jegliche Methode.

▪ Benutzen Sie jegliches Werkzeug.

▪ Benutzen Sie was auch immer.

▪ Um besser zu werden

Danke蔡荣耀Thomas ArendsRepräsentanz Deutscher MittelstandSchillerstr. 12/1,73249 WernauTel D - Mob | +49 176 42682164Tel D - FeN | +49 7153 750 9918Tel C - Mob | +86 159 50 153 049Skype# +49 176 42682164ta@deutscher-mittestand.com

Backup

Kundenanforderungen

Systemanforderungen

System Architektur System Integration

System Qualifikation

Domänen Anforderungen

Domänen Architektur

Domänen Detail Design Detail Tests

Integration

Domänen Test

1:n

1:n

1:n

1:n

1:n

1:n

1:n

1:n

n:1

n:1

Für jedes Element:Bekannt(Wiederverwendung) /UnbekanntDauer für die GestehungReviewsInvestitionen & Ausgaben

Für jeden Test zusätzlich:Dauer für die ImplementierungDauer der Durchführung

Projekt Management

Qualitäts ManagementÄnderungsmanagement, Problemmanagement, Konfigurationsmanagement

12 Prinzipen

1. Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.

2. Heisse Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.

3. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.

4. Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.

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.

6. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.

12 Prinzipen

7. Funktionierende Software ist das wichtigste Fortschrittsmaß.

8. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.

9. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.

10. Einfachheit -- die Kunst, die Menge nicht getaner Arbeit zu maximieren -- ist essenziell.

11. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.

12. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an

Quelle

▪ Quorahttps://www.quora.com/In-a-nutshell-why-do-a-lot-of-developers-dislike-Agile-What-are-better-project-management-paradigm-alternatives

Namecook Studie

Software Schedules, Staff, Effort, Productivity

Methodologies Schedule Staff Effort FP Development

Months Months Month Cost

1 Extreme (XP) 11.78 7 84 11.89 $630,860

2 Agile/scrum 11.82 7 84 11.85 $633,043

3 TSP 12.02 7 86 11.64 $644,070

4 CMMI 5/ spiral 12.45 7 83 12.05 $622,257

5 OO 12.78 8 107 9.31 $805,156

6 RUP 13.11 8 101 9.58 $756,157

7 Pair/iterative 13.15 12 155 9.21 $1,160,492

8 CMMI 3/iterative 13.34 8 107 9.37 $800,113

9 Proofs/waterfall 13.71 12 161 6.21 $1,207,500

10 CMMI 1/waterfall 15.85 10 158 6.51 $1,188,870

Average 13 8.6 112.6 9.762 $844,852

As can be seen the software development methods that yield the shortest schedules for applications of 1000 function points are the XP and Agile methods, with TSP coming in third.

--

Software Defect Potentials, Removal, and Delivery

Methodologies Defect Defect Defects Hi Sev.

Potential Removal Delivered Defects

1 TSP 2,700 96.79% 87 16

2 CMMI 5/ spiral 3,000 95.95% 122 22

3 RUP 3,900 95.07% 192 36

4 Extreme (XP) 4,500 93.36% 299 55

5 OO 4,950 93.74% 310 57

6 Pair/iterative 4,700 92.93% 332 61

7 Proofs/waterfall 4,650 92.21% 362 67

8 Agile/scrum 4,800 92.30% 370 68

9 CMMI 3/ Iter. 4,500 91.18% 397 73

10 CMMI 1/ Water. 6,000 78.76% 1,274 236

Average 4,370 92.23% 374 69

When the focus of the evaluation turns to quality rather than speed, TSP, CMMI 5, and RUP are on top, followed by XP. Agile is not strong on quality so it is only number 8 out of 10. The Agile lack of quality measures and failure to use inspections will also have an impact in the next comparison.

--

Total Cost of Ownership (TCO) and Cost of Quality (COQ)

Methodologies TCO COQ Percent

1 TSP $1,026,660 $298,699 29.09%

2 CMMI 5/ spiral $1,034,300 $377,880 36.53%

3 Extreme (XP) $1,318,539 $627,106 47.56%

4 RUP $1,360,857 $506,199 37.20%

5 Agile/scrum $1,467,957 $774,142 52.74%

6 OO $1,617,839 $735,388 45.45%

7 CMMI 3/iterative $1,748,043 $925,929 52.97%

8 Pair/iterative $2,107,861 $756,467 35.89%

9 Proofs/waterfall $2,216,167 $863,929 38.98%

10 CMMI 1/waterfall $3,944,159 $2,804,224 71.10%

Average $1,784,238 $866,996 44.75%

Some of the newer methods such as Agile and XP have not been in use long enough to show really long-range findings over 10 years or more. In this article TCO is limited to only five years of usage, because there is almost no data older than that for Agile. The figures for TCO include development, five years of enhancement, five years of maintenance or defect repairs, and five years of customer support. While the Software Risk Master tool predicts those values separately, in this article they are all combined together into a single figure. The figures for COQ consolidate all direct costs for finding and fixing bugs from the start of requirements through five years of customer usage.11.6.3.5.1 Table 3: Total Cost of Ownership (TCO): Cost of Quality (COQ)Because applications developed using the TSP, CMMI 5, and RUP methodologies are deployed with low numbers of defects it is fairly easy to enhance them, maintain them, and support them. Therefore the 5-year total cost of ownership clearly favors the quality-related methods rather than the speed-related methods. Agile is not bad, but with a COQ of more than 50% Agile needs to take quality more seriously up front. The COQ percentages reveal a chronic problem for software applications. We have so many bugs that finding and fixing bugs is the major cost of both development and total cost of ownership.

--

Spiral