SlideShare ist ein Scribd-Unternehmen logo
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 Welt
Was 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 Hype
Und 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
https://www.youtube.com/watch?v=a-BOSpxYJ9M&feature=youtu.be
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 Maag
zur 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_CONTE
NT_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 Studie
Gleichmacherei 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 Ansatz
M-SPICE© (VDI 5702)
ISO 13485
ISO 14971
ISO 60601
CFR21
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 Gesetz
Widerspricht 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… 1964
Conway'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ösungsansatz
Das Ergebnis zählt
Inhalt
Lösungsansatz
„Methodenlose“ Entwicklung
Das 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 Gesetz
Organisationen, 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ösungsansatz
Methodenlose Entwicklung
Das machen, welches das Ergebnis bringt
1. Überdimensioniert beginnen
2. 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 finden
5. Kommunikation Einfordern [Meeting Support Record] [Conway]
6. Ausbildung Einfordern [Conway]
(BSP: 4 Std / Tag– Domänen untereinander)  Probleme kommen auf lösen
7. Das Team selbst die beste Methode finden lassen (Agile)
8. Aufwändige Aktionen Agil in Themenkomplexen entwickeln –
Bsp. Requirements & Architektur
9. Aufwändig planen – PUFFER realistisch einschätzen
Inhalt
▪ Konflikte Agile Methode zur Norm 26262
▪ „Probleme“
▪ Lösungsansatz
▪ Umsetzung
Lösungsansatz
Das Ergebnis zählt
Umsetzung User Stories
1. Teamaufsatz in Bezug auf „Must haves, before can do“ verändern
Grundsä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 1
SYS
Architektur
SYS Integration
SW RQ HW RQ Me 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 2
SI 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 3
Safety 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
Modulerstelle
r
Integrator
Tester
Grau optional
Finally
Was es so an Studien gibt
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
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
Siehe auch Vortrag Dave Thomas
▪ Benutzen Sie jegliche Norm.
▪ Benutzen Sie jegliche Methode.
▪ Benutzen Sie jegliches Werkzeug.
▪ Benutzen Sie was auch immer.
▪ Um besser zu werden
Danke
蔡荣耀Thomas Arends
Repräsentanz Deutscher Mittelstand
Schillerstr. 12/1,
73249 Wernau
Tel D - Mob | +49 176 42682164
Tel D - FeN | +49 7153 750 9918
Tel C - Mob | +86 159 50 153 049
Skype# +49 176 42682164
ta@deutscher-mittestand.com
Backup
Kundenanforderunge
n
Systemanforderunge
n
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) /Unbekannt
Dauer für die Gestehung
Reviews
Investitionen & Ausgaben
Für jeden Test zusätzlich:
Dauer für die Implementierung
Dauer 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
▪ Quora
https://www.quora.com/In-a-nutshell-why-do-a-lot-of-developers-dislike-Agile-
What-are-better-project-management-paradigm-alternatives
Manifesto for Agile Software Development

Weitere ähnliche Inhalte

Was ist angesagt?

Agil vs. klassisch in der Geräteentwicklung - mit der richtigen Symbiose zum...
Agil vs. klassisch in der Geräteentwicklung - mit der richtigen Symbiose zum...Agil vs. klassisch in der Geräteentwicklung - mit der richtigen Symbiose zum...
Agil vs. klassisch in der Geräteentwicklung - mit der richtigen Symbiose zum...
Marc Bless
 
Hurra wir werden agil - aber wie?
Hurra wir werden agil - aber wie?Hurra wir werden agil - aber wie?
Hurra wir werden agil - aber wie?
Frank Düsterbeck
 
Agilität im Systems Engineering – geht das?
Agilität im Systems Engineering – geht das?Agilität im Systems Engineering – geht das?
Agilität im Systems Engineering – geht das?
HOOD Group
 
Wozu Agilität? Klassisches Projektmanagement funktioniert doch auch sehr gut!
Wozu Agilität? Klassisches Projektmanagement funktioniert doch auch sehr gut!Wozu Agilität? Klassisches Projektmanagement funktioniert doch auch sehr gut!
Wozu Agilität? Klassisches Projektmanagement funktioniert doch auch sehr gut!
Frank Lange
 
Keynote Highspeed Produktentwicklung - bis an die Grenzen des physikalisch Ma...
Keynote Highspeed Produktentwicklung - bis an die Grenzen des physikalisch Ma...Keynote Highspeed Produktentwicklung - bis an die Grenzen des physikalisch Ma...
Keynote Highspeed Produktentwicklung - bis an die Grenzen des physikalisch Ma...
Frank Lange
 
Agile! Welche Rolle spielt das Management
Agile! Welche Rolle spielt das ManagementAgile! Welche Rolle spielt das Management
Agile! Welche Rolle spielt das Management
pragmatic solutions gmbh
 
Schöner scheitern – Die beliebtesten Missverständnisse im agilen RE
Schöner scheitern – Die beliebtesten Missverständnisse im agilen RESchöner scheitern – Die beliebtesten Missverständnisse im agilen RE
Schöner scheitern – Die beliebtesten Missverständnisse im agilen RE
oose
 
DevOps - Programmierst Du noch oder betreibst Du schon?
DevOps - Programmierst Du noch oder betreibst Du schon?DevOps - Programmierst Du noch oder betreibst Du schon?
DevOps - Programmierst Du noch oder betreibst Du schon?
Jean-Pierre König
 
Scrum und Lean-Startup
Scrum und Lean-StartupScrum und Lean-Startup
Scrum und Lean-Startup
Stefan ROOCK
 
Traditionelles Projektmanagement und SCRUM
Traditionelles Projektmanagement und SCRUMTraditionelles Projektmanagement und SCRUM
Traditionelles Projektmanagement und SCRUM
Felix Ruessel
 
Shades of Scrum (Urs Reupke, Stefan Roock), SEACON 2015 in Hamburg
Shades of Scrum (Urs Reupke, Stefan Roock), SEACON 2015 in HamburgShades of Scrum (Urs Reupke, Stefan Roock), SEACON 2015 in Hamburg
Shades of Scrum (Urs Reupke, Stefan Roock), SEACON 2015 in Hamburg
Stefan ROOCK
 
Bessere Software schneller liefern
Bessere Software schneller liefernBessere Software schneller liefern
Bessere Software schneller liefern
Mayflower GmbH
 
E-Commerce vs Architektur CodeTalks.Commerce_2018
E-Commerce vs Architektur CodeTalks.Commerce_2018E-Commerce vs Architektur CodeTalks.Commerce_2018
E-Commerce vs Architektur CodeTalks.Commerce_2018
Johann-Peter Hartmann
 
Scrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für ProgrammiererScrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für Programmierer
Tobias Schlüter
 
Scrum zum Anfassen
Scrum zum AnfassenScrum zum Anfassen
Scrum zum Anfassen
Tilman Moser
 
Scrum & Kanban im Agenturgeschäft
Scrum & Kanban im AgenturgeschäftScrum & Kanban im Agenturgeschäft
Scrum & Kanban im Agenturgeschäft
Paul Herwarth von Bittenfeld
 
DevOps und ITIL: Waffenbrüder oder Feinde?
DevOps und ITIL: Waffenbrüder oder Feinde?DevOps und ITIL: Waffenbrüder oder Feinde?
DevOps und ITIL: Waffenbrüder oder Feinde?
OPITZ CONSULTING Deutschland
 
Agile Softwareentwicklung mit Lotus Notes
Agile Softwareentwicklung mit Lotus NotesAgile Softwareentwicklung mit Lotus Notes
Agile Softwareentwicklung mit Lotus Notes
Werner Motzet
 
Agil ist nicht genug
Agil ist nicht genugAgil ist nicht genug
Agil ist nicht genug
Frank Düsterbeck
 
Lean Project Management
Lean Project ManagementLean Project Management
Lean Project Management
Jürgen Rohr
 

Was ist angesagt? (20)

Agil vs. klassisch in der Geräteentwicklung - mit der richtigen Symbiose zum...
Agil vs. klassisch in der Geräteentwicklung - mit der richtigen Symbiose zum...Agil vs. klassisch in der Geräteentwicklung - mit der richtigen Symbiose zum...
Agil vs. klassisch in der Geräteentwicklung - mit der richtigen Symbiose zum...
 
Hurra wir werden agil - aber wie?
Hurra wir werden agil - aber wie?Hurra wir werden agil - aber wie?
Hurra wir werden agil - aber wie?
 
Agilität im Systems Engineering – geht das?
Agilität im Systems Engineering – geht das?Agilität im Systems Engineering – geht das?
Agilität im Systems Engineering – geht das?
 
Wozu Agilität? Klassisches Projektmanagement funktioniert doch auch sehr gut!
Wozu Agilität? Klassisches Projektmanagement funktioniert doch auch sehr gut!Wozu Agilität? Klassisches Projektmanagement funktioniert doch auch sehr gut!
Wozu Agilität? Klassisches Projektmanagement funktioniert doch auch sehr gut!
 
Keynote Highspeed Produktentwicklung - bis an die Grenzen des physikalisch Ma...
Keynote Highspeed Produktentwicklung - bis an die Grenzen des physikalisch Ma...Keynote Highspeed Produktentwicklung - bis an die Grenzen des physikalisch Ma...
Keynote Highspeed Produktentwicklung - bis an die Grenzen des physikalisch Ma...
 
Agile! Welche Rolle spielt das Management
Agile! Welche Rolle spielt das ManagementAgile! Welche Rolle spielt das Management
Agile! Welche Rolle spielt das Management
 
Schöner scheitern – Die beliebtesten Missverständnisse im agilen RE
Schöner scheitern – Die beliebtesten Missverständnisse im agilen RESchöner scheitern – Die beliebtesten Missverständnisse im agilen RE
Schöner scheitern – Die beliebtesten Missverständnisse im agilen RE
 
DevOps - Programmierst Du noch oder betreibst Du schon?
DevOps - Programmierst Du noch oder betreibst Du schon?DevOps - Programmierst Du noch oder betreibst Du schon?
DevOps - Programmierst Du noch oder betreibst Du schon?
 
Scrum und Lean-Startup
Scrum und Lean-StartupScrum und Lean-Startup
Scrum und Lean-Startup
 
Traditionelles Projektmanagement und SCRUM
Traditionelles Projektmanagement und SCRUMTraditionelles Projektmanagement und SCRUM
Traditionelles Projektmanagement und SCRUM
 
Shades of Scrum (Urs Reupke, Stefan Roock), SEACON 2015 in Hamburg
Shades of Scrum (Urs Reupke, Stefan Roock), SEACON 2015 in HamburgShades of Scrum (Urs Reupke, Stefan Roock), SEACON 2015 in Hamburg
Shades of Scrum (Urs Reupke, Stefan Roock), SEACON 2015 in Hamburg
 
Bessere Software schneller liefern
Bessere Software schneller liefernBessere Software schneller liefern
Bessere Software schneller liefern
 
E-Commerce vs Architektur CodeTalks.Commerce_2018
E-Commerce vs Architektur CodeTalks.Commerce_2018E-Commerce vs Architektur CodeTalks.Commerce_2018
E-Commerce vs Architektur CodeTalks.Commerce_2018
 
Scrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für ProgrammiererScrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für Programmierer
 
Scrum zum Anfassen
Scrum zum AnfassenScrum zum Anfassen
Scrum zum Anfassen
 
Scrum & Kanban im Agenturgeschäft
Scrum & Kanban im AgenturgeschäftScrum & Kanban im Agenturgeschäft
Scrum & Kanban im Agenturgeschäft
 
DevOps und ITIL: Waffenbrüder oder Feinde?
DevOps und ITIL: Waffenbrüder oder Feinde?DevOps und ITIL: Waffenbrüder oder Feinde?
DevOps und ITIL: Waffenbrüder oder Feinde?
 
Agile Softwareentwicklung mit Lotus Notes
Agile Softwareentwicklung mit Lotus NotesAgile Softwareentwicklung mit Lotus Notes
Agile Softwareentwicklung mit Lotus Notes
 
Agil ist nicht genug
Agil ist nicht genugAgil ist nicht genug
Agil ist nicht genug
 
Lean Project Management
Lean Project ManagementLean Project Management
Lean Project Management
 

Ähnlich wie Agil in der Normativen Welt

Agile SEO - webinale 2015
Agile SEO - webinale 2015Agile SEO - webinale 2015
Agile SEO - webinale 2015
André Scharf
 
Agile, DevOps, Continuous Delivery: Was ist das und wie betrifft es mich als ...
Agile, DevOps, Continuous Delivery: Was ist das und wie betrifft es mich als ...Agile, DevOps, Continuous Delivery: Was ist das und wie betrifft es mich als ...
Agile, DevOps, Continuous Delivery: Was ist das und wie betrifft es mich als ...
Nico Meisenzahl
 
Agiles Anforderungsmanagement bei HEC
Agiles Anforderungsmanagement bei HECAgiles Anforderungsmanagement bei HEC
Agiles Anforderungsmanagement bei HEC
Christian Seedig
 
Lean Startup und agile Methodiken – Hype oder Fortschritt ?
Lean Startup und agile Methodiken – Hype oder Fortschritt ?Lean Startup und agile Methodiken – Hype oder Fortschritt ?
Lean Startup und agile Methodiken – Hype oder Fortschritt ?
Heico Koch
 
AGILE BEYOND BUZZWORD BINGO (MAGAZIN)
AGILE BEYOND BUZZWORD BINGO (MAGAZIN)AGILE BEYOND BUZZWORD BINGO (MAGAZIN)
AGILE BEYOND BUZZWORD BINGO (MAGAZIN)
Marc Wagner
 
ScALeD: Agile Skalierung jenseits von Skalierungsframeworks
ScALeD: Agile Skalierung jenseits von SkalierungsframeworksScALeD: Agile Skalierung jenseits von Skalierungsframeworks
ScALeD: Agile Skalierung jenseits von Skalierungsframeworks
Stefan ROOCK
 
Continuous Documentation statt Endless Specification - Fokus auf die nachhalt...
Continuous Documentation statt Endless Specification - Fokus auf die nachhalt...Continuous Documentation statt Endless Specification - Fokus auf die nachhalt...
Continuous Documentation statt Endless Specification - Fokus auf die nachhalt...
HOOD Group
 
Agile developmentphp usergroup
Agile developmentphp usergroupAgile developmentphp usergroup
Agile developmentphp usergroupCypher Deimos
 
Scrum - Wissen kompakt
Scrum - Wissen kompaktScrum - Wissen kompakt
Scrum - Wissen kompakt
Frank Dostert
 
Anwendung von agilen / lean Praktiken bei About You
Anwendung von agilen / lean Praktiken bei About YouAnwendung von agilen / lean Praktiken bei About You
Anwendung von agilen / lean Praktiken bei About You
Alexander Fedtke
 
OKR, Ziele und Zielsysteme im Agilen
OKR, Ziele und Zielsysteme im AgilenOKR, Ziele und Zielsysteme im Agilen
OKR, Ziele und Zielsysteme im Agilen
Björn Schotte
 
AgileAustriaConference2023_Brücken bauen: Wie Agilität und die ISO 9001 Hand ...
AgileAustriaConference2023_Brücken bauen: Wie Agilität und die ISO 9001 Hand ...AgileAustriaConference2023_Brücken bauen: Wie Agilität und die ISO 9001 Hand ...
AgileAustriaConference2023_Brücken bauen: Wie Agilität und die ISO 9001 Hand ...
Agile Austria Conference
 
Das Mindset von DevOps
Das Mindset von DevOpsDas Mindset von DevOps
Das Mindset von DevOps
ChristinaLerch1
 
ISO 26262 und Agil? Aber sicher!
ISO 26262 und Agil? Aber sicher!ISO 26262 und Agil? Aber sicher!
ISO 26262 und Agil? Aber sicher!
HOOD Group
 
edutrainment Webtalk Agiles Arbeiten
edutrainment Webtalk Agiles Arbeitenedutrainment Webtalk Agiles Arbeiten
edutrainment Webtalk Agiles Arbeiten
edutrainment company
 
Agile Organisationsstruktur - Ein Überblick
Agile Organisationsstruktur - Ein ÜberblickAgile Organisationsstruktur - Ein Überblick
Agile Organisationsstruktur - Ein Überblick
Marc Wagner
 
Lego Workshop Scrum Einführung
Lego Workshop Scrum EinführungLego Workshop Scrum Einführung
Lego Workshop Scrum Einführung
Torsten Irländer
 
Product owner: Wunderkind oder Sündenbock? Sibylle Peter
Product owner: Wunderkind oder Sündenbock? Sibylle PeterProduct owner: Wunderkind oder Sündenbock? Sibylle Peter
Product owner: Wunderkind oder Sündenbock? Sibylle Peter
Corimbus GmbH
 
IAK13 Darwin und die Kreativen
IAK13 Darwin und die KreativenIAK13 Darwin und die Kreativen
IAK13 Darwin und die Kreativen
Webster59
 
Agiles Management für erfolgreiche IT-Projekte
Agiles Management für erfolgreiche IT-ProjekteAgiles Management für erfolgreiche IT-Projekte
Agiles Management für erfolgreiche IT-Projekte
JustRelate
 

Ähnlich wie Agil in der Normativen Welt (20)

Agile SEO - webinale 2015
Agile SEO - webinale 2015Agile SEO - webinale 2015
Agile SEO - webinale 2015
 
Agile, DevOps, Continuous Delivery: Was ist das und wie betrifft es mich als ...
Agile, DevOps, Continuous Delivery: Was ist das und wie betrifft es mich als ...Agile, DevOps, Continuous Delivery: Was ist das und wie betrifft es mich als ...
Agile, DevOps, Continuous Delivery: Was ist das und wie betrifft es mich als ...
 
Agiles Anforderungsmanagement bei HEC
Agiles Anforderungsmanagement bei HECAgiles Anforderungsmanagement bei HEC
Agiles Anforderungsmanagement bei HEC
 
Lean Startup und agile Methodiken – Hype oder Fortschritt ?
Lean Startup und agile Methodiken – Hype oder Fortschritt ?Lean Startup und agile Methodiken – Hype oder Fortschritt ?
Lean Startup und agile Methodiken – Hype oder Fortschritt ?
 
AGILE BEYOND BUZZWORD BINGO (MAGAZIN)
AGILE BEYOND BUZZWORD BINGO (MAGAZIN)AGILE BEYOND BUZZWORD BINGO (MAGAZIN)
AGILE BEYOND BUZZWORD BINGO (MAGAZIN)
 
ScALeD: Agile Skalierung jenseits von Skalierungsframeworks
ScALeD: Agile Skalierung jenseits von SkalierungsframeworksScALeD: Agile Skalierung jenseits von Skalierungsframeworks
ScALeD: Agile Skalierung jenseits von Skalierungsframeworks
 
Continuous Documentation statt Endless Specification - Fokus auf die nachhalt...
Continuous Documentation statt Endless Specification - Fokus auf die nachhalt...Continuous Documentation statt Endless Specification - Fokus auf die nachhalt...
Continuous Documentation statt Endless Specification - Fokus auf die nachhalt...
 
Agile developmentphp usergroup
Agile developmentphp usergroupAgile developmentphp usergroup
Agile developmentphp usergroup
 
Scrum - Wissen kompakt
Scrum - Wissen kompaktScrum - Wissen kompakt
Scrum - Wissen kompakt
 
Anwendung von agilen / lean Praktiken bei About You
Anwendung von agilen / lean Praktiken bei About YouAnwendung von agilen / lean Praktiken bei About You
Anwendung von agilen / lean Praktiken bei About You
 
OKR, Ziele und Zielsysteme im Agilen
OKR, Ziele und Zielsysteme im AgilenOKR, Ziele und Zielsysteme im Agilen
OKR, Ziele und Zielsysteme im Agilen
 
AgileAustriaConference2023_Brücken bauen: Wie Agilität und die ISO 9001 Hand ...
AgileAustriaConference2023_Brücken bauen: Wie Agilität und die ISO 9001 Hand ...AgileAustriaConference2023_Brücken bauen: Wie Agilität und die ISO 9001 Hand ...
AgileAustriaConference2023_Brücken bauen: Wie Agilität und die ISO 9001 Hand ...
 
Das Mindset von DevOps
Das Mindset von DevOpsDas Mindset von DevOps
Das Mindset von DevOps
 
ISO 26262 und Agil? Aber sicher!
ISO 26262 und Agil? Aber sicher!ISO 26262 und Agil? Aber sicher!
ISO 26262 und Agil? Aber sicher!
 
edutrainment Webtalk Agiles Arbeiten
edutrainment Webtalk Agiles Arbeitenedutrainment Webtalk Agiles Arbeiten
edutrainment Webtalk Agiles Arbeiten
 
Agile Organisationsstruktur - Ein Überblick
Agile Organisationsstruktur - Ein ÜberblickAgile Organisationsstruktur - Ein Überblick
Agile Organisationsstruktur - Ein Überblick
 
Lego Workshop Scrum Einführung
Lego Workshop Scrum EinführungLego Workshop Scrum Einführung
Lego Workshop Scrum Einführung
 
Product owner: Wunderkind oder Sündenbock? Sibylle Peter
Product owner: Wunderkind oder Sündenbock? Sibylle PeterProduct owner: Wunderkind oder Sündenbock? Sibylle Peter
Product owner: Wunderkind oder Sündenbock? Sibylle Peter
 
IAK13 Darwin und die Kreativen
IAK13 Darwin und die KreativenIAK13 Darwin und die Kreativen
IAK13 Darwin und die Kreativen
 
Agiles Management für erfolgreiche IT-Projekte
Agiles Management für erfolgreiche IT-ProjekteAgiles Management für erfolgreiche IT-Projekte
Agiles Management für erfolgreiche IT-Projekte
 

Agil in der Normativen Welt

  • 1. AGILE in der Normativen Welt Es wird ein wenig ketzerisch
  • 2. 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
  • 3. 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
  • 4. Agile in der Normativen Welt Was ist die Beste Entwicklungsmethode? ▪ Agile mit Scrum & oder Kanban ▪ LESS ▪ SAFe® ▪ V-Modell mit Agilität ▪ CMMI SPIRAL Woran erkennt man das Beste Modell?
  • 5. 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
  • 6. 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.
  • 7. Agile Hype Und ein paar ketzerische Kommentare
  • 9. 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.
  • 10. AGILE hier SAFe® So ganz scheint es nicht zu passen
  • 15. 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“
  • 16. Studie der Fa. Kugler Maag zur 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
  • 17. 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_CONTE NT_PDF/2-22_agile- automotive_survey- 2015.pdf
  • 18. 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
  • 19. 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.
  • 21. 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
  • 22. Ergebnis der Studie Gleichmacherei 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.
  • 23. 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.
  • 24. Agiler Ansatz M-SPICE© (VDI 5702) ISO 13485 ISO 14971 ISO 60601 CFR21 SPICE © Grundlegende Anforderungen  Erst mal die Normen
  • 25. 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)
  • 26. Process House ISO15504 330xx 65 Processes > 250 Work Products
  • 27. Das MSPICE© Prozesshaus ISO 62304 ist ähnlich
  • 30. Zusammenfassung ▪ Klares V-Model ▪ Entwicklung beginnen von den Top Anforderungen ▪ Traceability und Konsistenz ist ein MUSS!
  • 31. Wie löst man das Alles? Das Langzeitergebnis zählt
  • 32. 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 Gesetz Widerspricht 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
  • 33. ▪ 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
  • 34. ▪ 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
  • 35. Inhalt ▪ Konflikte Agile Methode zur ▪ „Probleme“ ▪ Lösungsansatz ▪ Umsetzung
  • 36. 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)
  • 37. Wer oder was ist Conway… 1964 Conway's law ▪organizations which design systems ... ▪are constrained to produce designs which are copies of the communication structures of these organizations
  • 38. Inhalt ▪ Konflikte Agile Methode zur Norm 26262 ▪ „Probleme“ ▪ Lösungsansatz ▪ Umsetzung
  • 40. Lösungsansatz „Methodenlose“ Entwicklung Das 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 Gesetz Organisationen, 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
  • 41. Lösungsansatz Methodenlose Entwicklung Das machen, welches das Ergebnis bringt 1. Überdimensioniert beginnen 2. 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 finden 5. Kommunikation Einfordern [Meeting Support Record] [Conway] 6. Ausbildung Einfordern [Conway] (BSP: 4 Std / Tag– Domänen untereinander)  Probleme kommen auf lösen 7. Das Team selbst die beste Methode finden lassen (Agile) 8. Aufwändige Aktionen Agil in Themenkomplexen entwickeln – Bsp. Requirements & Architektur 9. Aufwändig planen – PUFFER realistisch einschätzen
  • 42. Inhalt ▪ Konflikte Agile Methode zur Norm 26262 ▪ „Probleme“ ▪ Lösungsansatz ▪ Umsetzung
  • 44. Umsetzung User Stories 1. Teamaufsatz in Bezug auf „Must haves, before can do“ verändern Grundsä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 1 SYS Architektur SYS Integration SW RQ HW RQ Me RQ
  • 45. 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 2 SI RQ1 Grau optional
  • 46. Umsetzung Architekturebene SYS Architektur SYS Integration SW RQ1 HW RQ1 ME RQ1 SW Tester 1 HW Tester 1 ME Tester 1 Agile Team 3 Safety RQ1
  • 47. Umsetzung SWE / HWE 3. In den SWE/HWE/Ebenen wird entsprechen weiter gearbeitet SWE/ HWE RQ Modul Tester Architekt Agile Team 4 FUSI RQ1 Modulerstelle r Integrator Tester Grau optional
  • 48. Finally Was es so an Studien gibt
  • 50. 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. --
  • 51. 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. --
  • 52. 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. --
  • 54. 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
  • 55. 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
  • 56. Die grundlegende Idee einer jeden Veränderung Siehe auch Vortrag Dave Thomas ▪ Benutzen Sie jegliche Norm. ▪ Benutzen Sie jegliche Methode. ▪ Benutzen Sie jegliches Werkzeug. ▪ Benutzen Sie was auch immer. ▪ Um besser zu werden
  • 57. Danke 蔡荣耀Thomas Arends Repräsentanz Deutscher Mittelstand Schillerstr. 12/1, 73249 Wernau Tel D - Mob | +49 176 42682164 Tel D - FeN | +49 7153 750 9918 Tel C - Mob | +86 159 50 153 049 Skype# +49 176 42682164 ta@deutscher-mittestand.com
  • 59. Kundenanforderunge n Systemanforderunge n 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) /Unbekannt Dauer für die Gestehung Reviews Investitionen & Ausgaben Für jeden Test zusätzlich: Dauer für die Implementierung Dauer der Durchführung Projekt Management Qualitäts Management Änderungsmanagement, Problemmanagement, Konfigurationsmanagement
  • 60. 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.
  • 61. 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
  • 63. Manifesto for Agile Software Development

Hinweis der Redaktion

  1. Yep – wild es geht bei einem intelligenten Zusammenschluss
  2. Das Ergebnis dürfte real sein