Dipl.-Inform. Peter Rösler ReviewConsult

Präsentation zum Thema: "Dipl.-Inform. Peter Rösler ReviewConsult"—  Präsentation transkript:

1 Dipl.-Inform. Peter Rösler ReviewConsult
Agile Inspektionen Übersicht 1. Wasserfallmodell und klassische Inspektionen 2. Agile Software-Entwicklung Prinzipien Pair Programming und anderes „Reviewartiges“ in der agilen Software-Entwicklung 3. Agile Inspektionen (auch für Wasserfallprojekte) 4. Diskussion: wie agil sind Agile Inspektionen wirklich? Datei zuletzt geändert: , , (erstellt) „Wartungshinweis“: Footer von Folie 1 ist unabhängig vom Folienmaster Folie zuletzt geändert am: , (erstellt) Agile Inspektionen ESE-Kongress Dipl.-Inform. Peter Rösler ReviewConsult

2 1. Wasserfallmodell und klassische Inspektionen
Die in diesem Beitrag betrachteten „Software-Inspektionen“ werden oft auch als „Software-Reviews“, „Peer Reviews“ oder „Fagan/Gilb style inspections“ bezeichnet. Definitionen: „major defect” (im Gegensatz zu „minor defect”) : Fehler, der möglicherweise erheblich höhere Kosten verursacht, wenn er später gefunden wird als jetzt. 1 Seite = 300 Wörter [4] Im Folgenden gilt auch: „Artefakte“ = „Dokumente“ Folie zuletzt geändert am: , (erstellt), Notizen zuletzt geändert am: Peter Rösler

3 Typisches Wasserfall- bzw. V-Modell
z.B. 2 Jahre t Fachkonzept Anforderungsdefinition Design Codierung Modultest Integrationstest Systemtest Abnahmetest RVW RVW Folie zuletzt geändert am: , , (erstellt), Notizen zuletzt geändert am: Mit den Reviews in den Testphasen werden Testpläne und Testfälle inspiziert. G.T : Dargestellt ist das sogenannte V-Modell und nicht das Wasserfallmodell. Der Unterschied liegt allerdings lediglich in der Unterteilung der Testphase in mehrere Tests und der Darstellung als V. Peter Rösler RVW = Review / Inspektion

4 Anteil von Korrekturtätigkeiten am Gesamtaufwand
44 % 56 % (Korrekturtätigkeiten) (reine Erstellung der Software) Ca. 2/3 des Rework-aufwands kann durch Reviews vermieden werden! (einmaliges) Durchspielen der Testfälle Spezifizieren der Testfälle Folie zuletzt geändert am: , , , Notizen zuletzt geändert am: „Rework“ wird oft auch „cost of non-quality“ genannt. Die Aussage "Ca. 2/3 des Reworkaufwands kann durch Reviews vermieden werden" ergibt sich aus der Aussage "geringere Entwicklungskosten (25-35%)" auf Folie "Nutzen von Reviews". 2/3 von 44% sind 29%, was genau im Bereich 25-35% liegt. Reworkanteil wird durch die Fehlerfindeeigenschaften der Reviewtechnik reduziert. Reworkanteil und Productionsanteil werden durch die Prozeßverbesserungseigenschaften der Reviewtechnik reduziert. „Rework“-Farben können wie folgt geändert werden: zuerst Gruppierung aufheben(!), dann Farbkästchen neben Rework anclicken, bei Diagramm „Reihe Rework“ auswählen, „Datenreihen formatieren“, etc. Anforderungs- definition Grobkonzept Feinspezifikation Codierung & Modultest Integrations- und Systemtest Quelle: Wheeler 1996, Software inspection: an industry best practice, p 9 Peter Rösler

5 Aufwand für 100%ige Reviewabdeckung
Gilb: ca % des Projektaufwands (Radice: ca. 8-20%) Einsparung: z.B h eingespart durch 250 gefundene Mj defects Aufwand: z.B. 500 h verteilt auf 25 Reviews Folie zuletzt geändert am: (erstellt, P.Rösler), Notizen zuletzt geändert am: Radice ISBN , p49: The upfront cost of Inspections seems to vary between 8-20% of budget for the project in organizations that are 65% or more effective in removing defects with Inspections. SI p 27: The cost of running Inspection is approximately 10-15% of the development budget. Die grüne Fläche geht genau genommen noch weiter nach rechts bis in die Testphasen hinein, weil z.B. auch Testspezifikationen mit Reviews geprüft werden müssen. Mj defects, die am Ende des Projekts auftauchen, sind im Durchschnitt teurer als am Anfang, und daher in der Grafik mit größerer Fläche dargestellt. Dass 1 gefundener Mj defect durchschnittlich 8 h Folgekosten einspart, wurde aus Folie "The downstream alternative cost of quality" übernommen (dort 9,3 h Folgekosten, Quelle: SI p315). Dass 500 h Reviewaufwand für 250 gefundene Mj defects nötig sind (Effizienz = 0,5 Mj/h), stimmt mit den Siemens-Daten aus Folie "Ein Dokument mit 2 Methoden geprüft (2)" überein, ist aber um Faktor 2 pessimistischer als sonst in der Literatur angegeben (sonst 1 Mj/h, s.a. Folie "The downstream alternative cost of quality"). Angenommen, die 500 h Reviewaufwand sind 12,5% des Projektaufwandes, dann handelt es sich um ein Projekt mit Gesamtaufwand 4000h = 2,35 MitarbeiterJahre. Notizen aus Folie „Mitarbeiterberg mit und ohne Reviews" : Reviews sind eine Investition in den frühen Projektphasen. In der 1. Hälfte der Produktentwicklung nehmen Reviews % des Projektaufwands ein. ROI = 4:1 Peter Rösler Details siehe Notizseite

6 Review-Varianten (nach Graham)
Walkthrough: Aktivität: Verstehen Autor leitet die Gruppe durch das Dokument und die dahinter stehenden Gedankenprozesse, so dass alle dasselbe verstehen und Einigkeit erzielt werden kann, was zu ändern ist. Walkthrough [Presentation Review] Review: Aktivität: Entscheiden Gruppe diskutiert das Dokument und trifft Entscheidungen über den Inhalt, z.B. wie etwas gemacht werden soll, Ja/Nein-Entscheidungen. Management-Review [Projektstatus-Review] Inspektion Inspection: Hauptaktivität: Fehler finden Formale Einzel- und Gruppen-Prüfaktivität nach genau festgelegten Regeln, unter Verwendung von Vorgängerdokumenten und Standards. Folie zuletzt geändert am: , , , , Notizen zuletzt geändert am: , Danach Video „Candid Inspection“ zeigen Der IEEE Std nennt noch „Audits“ und „Technical Reviews“ Peter Rösler

7 Rollen in einer Inspektion
Moderator Autor Protokollführer Reviewer Vorleser/Reader (nur wenn „double checking“ gemacht wird) Ein Teilnehmer kann mehrere Rollen übernehmen. Folie zuletzt geändert am: , (Bild), , , Notizen zuletzt geändert am: Die Folie zeigt die Rollen der Teilnehmer einer "Inspektion". Die Rolle des “Readers” wird selten eingesetzt. Vgl. auch SI p 186. Einzige Einschränkung: der Autor darf zusätzlich höchstens die Rolle eines Reviewers übernehmen. Peter Rösler

8 Phasen einer Inspektion nach Gilb/Graham
Sources Product Checklists Change Requests to Project and Process Data Summary Master Plan Inspection Issue Log Brainstorm Exited Entry Planning Kickoff Individual Checking Logging Brainstorming Edit Followup Exit Folie zuletzt geändert am: , , (Animation), (Wort „Individual“ ergänzt), , Notizen zuletzt geändert am: Die Folie zeigt die Phasen einer "Inspektion". Genau genommen müsste noch ein Pfeil von "Inspection Issue Log" zu "Edit" gehen, aber ich lasse Gilb's Folie unverändert. Source: Tom Gilb, Team Leader Course Peter Rösler

9 Phase „Individual Checking“
Von den Fehlern, die das Reviewteam insgesamt entdeckt, werden 80% im „Individual Checking“ gefunden und 20% im „Logging meeting“, sofern dort mit „Double Checking“ erneut Fehlersuche betrieben wird. [2] Da in den meisten durchgeführten Reviews auf „Double Checking“ verzichtet wird, werden in der Praxis eher 95% der durch das Reviewteam entdeckten Fehler im „Individual Checking“ gefunden. [3] Folie zuletzt geändert am: , (Animation), Peter Rösler

10 Für Wasserfall-Projekte: geringere Entwicklungskosten (25-35%)
Nutzen von Reviews Für Wasserfall-Projekte: geringere Entwicklungskosten (25-35%) kürzere Entwicklungszeiten (25-35%) geringere Wartungskosten (Faktor 10-30) höhere Zuverlässigkeit ( mal weniger Fehler) Folie zuletzt geändert am: , (Animation), , , Notizen zuletzt geändert am: Im seinem neueren Buch SI p 24 (s.a. p 17-19) bringt Gilb etwas andere Zahlen: net productivity increases of 30% to 100% (p 19: 30 Inspection Projekte erzeugten doppelt soviel LOCs wie 30 Structured walkthrough Projekte) - net timescale reductions of 10% to 30% - reduction in maintenance costs (2/3 due to defect elimination) by one order of magnitude Bsp. Imperial Chemical Industries ICI in GB, 400, abgeschaffte Reviews, 10* billiger zu warten Bsp. Project Orbit IBM LOCs Betriebssystem, statt 800 nur 8 Fehler Bsp. Abteilung mit 50 Mitarbeitern: 25-35% entspricht 20 neuen Mitarbeitern, die kein Gehalt und keine Räume bekommen. Fagan schreibt in The immediate and long-term effects of using this process [FAGAN INSPECTIONS plus Process Improvement (Anm. Rösler 2007)], as reported by users of the process, are evident in the following results: - 10 – 20X Reduction in customer reported defects. - 2X Increase in productivity % Reduction in Time to Shipment (Cycle Time.) - 50% Increase in meeting schedules and maintaining budgets % - 50% Improvement in Customer Satisfaction. Source: Gilb1988, Principles of Software Engineering Management, Table 12.2 vgl. auch SI p 24 Peter Rösler

11 Black-Box-Sicht auf Inspektionen
(Kosten) Out (Nutzen) gefundene Major Defects d.h. eingesparte Reworkstunden Prozessverbesserungs- Vorschläge Arbeits-stunden Inspektion Kennzahlen Fehlerdichte etc. Folie zuletzt geändert am: , (erstellt), Notizen zuletzt geändert am: Lernkurve des Autors evtl. geringere zukünftige Fehlerrate Peter Rösler Source: Peter Rösler,

12 2. Agile Software-Entwicklung 2.1 Prinzipien
Agiles Manifest (2001, Utah) als Wertesystem: Prozesse und Werkzeuge sind wichtiger als Individuen und Interaktionen Funktionierende Software umfangreiche Dokumentation ist wichtiger als Zusammenarbeit mit dem Kunden Vertragsverhandlungen ist wichtiger als Reaktion auf Änderungen Verfolgung eines festgelegten Plans ist wichtiger als Folie zuletzt geändert am: , (erstellt), Notizen zuletzt geändert am: 17 Erstunterzeichner, darunter Kent Beck (XP), Alistair Cockburn (Crystal), Ken Schwaber und Jeff Sutherland (Scrum). Peter Rösler

13 Das System entsteht in vielen Iterationen
Iteration n … t Iteration 2 Iterationen (oder „sprints“) dauern üblicherweise 1 bis 4 Wochen. Am Ende jeder Iteration steht ein getestetes und lauffähiges System („potentially shippable code“) mit neu dazu gekommener Funktionalität. Folie zuletzt geändert am: , (erstellt), Notizen zuletzt geändert am: Freigabe einer Produktversion nach Abschluß eines oder mehrerer → Sprints. Grundsätzlich hat der → Product Owner nach jedem Sprint die Option, ein Release der bis dahin implementierten Funktionalität zu initiieren. Oft wird die inkrementelle Software-Entwicklung mit einer Spirale oder einem Kreis abgebildet: (Stand ) Peter Rösler

14 Vorteile gegenüber Wasserfall
Schnelle Reaktionsmöglichkeit auf sich ändernde Anforderungen oder Prioritäten Sehr früher Return on Investment (Schon nach der ersten Iteration hat der Kunde ein lauffähiges System, das er produktiv einsetzen kann.) Ein komplettes Scheitern des Projekts (kein lauffähiger Code), wie bei Wasserfall-Projekten oft der Fall (vgl. CHAOS-Report), ist wenig wahrscheinlich. … (und viele weitere Vorteile) Folie zuletzt geändert am: , (erstellt), Notizen zuletzt geändert am: Die Kosten der schlimmsten Mj defects sind nach oben begrenzt, bei wöchentlichem Inkrement geht maximal verloren: 1 Arbeitswoche * Anzahl Mitarbeiter beim Wasserfallmodell unter Umständen: 2 Jahre * Anzahl Mitarbeiter G.T : Beim Wasserfall- und V-Modell führt Zeitdruck zu Einsparungen am Test und damit zu Qualitätsmängeln. Bei der inkrementellen/iterativen Softwareentwicklung zu evtl. eingeschränkter Funktion bei der nächsten Auslieferung, aber nicht zu Qualitätsverlusten. Peter Rösler

15 Viele Iterationen bedeuten auch viel Testaufwand.
Testautomatisierung Viele Iterationen bedeuten auch viel Testaufwand. In jeder Iteration muss nicht nur die neue Funktionalität, sondern wegen möglicher Seiteneffekte die gesamte Software durchgetestet werden. Manuelle Tests sind aufwändig (Schreckensszenario: in jeder Iteration sitzen Tester da, starten manuell Skripts, um die Datenbank zu füllen, klappern die gesamte Benutzeroberfläche manuell ab, denken jedes Mal nach, ob die angezeigten Werte stimmen, …) Lösung: möglichst vollautomatische Regressionstests Folie zuletzt geändert am: , , (erstellt), Notizen zuletzt geändert am: hohen Testüberdeckungsgrad erwähnen. automatisierte Regressionstests (z.B. mit JUnit) (werden uns beim Refactoring auch helfen) s.a. Folien (Test Driven Development) Peter Rösler

16 Problem Aufwandskurve
Wenn die neue Funktionalität in jeder Iteration auf die jeweils bequemste Art und Weise eingebaut wird (z.B. durch „Rucksäcke“ oder andere Anti-Pattern wie „Spaghetti-Code“ oder „Copy-and-Paste“), dann wird die Software schnell unwartbar. aus: Wunderatsch, 1999 Die Produktivität des Teams („velocity/speed“) wird in den Folge-Iterationen immer geringer. Die „Aufwandskurve“ (Arbeitstage je Feature) steigt also steil an. Vorbeugende Lösung: ständiges „Refactoring“ Folie zuletzt geändert am: , , (erstellt), Notizen zuletzt geändert am: Anti-Pattern sind wiederkehrende schlechte Lösungen, die man an Strukturen erkennen kann, z. B. – Spaghetti-Code, viele if, while und repeat-Schleifen gemischt, intensive Nutzung der Möglichkeiten mit break, früher: goto – Cut-and-Paste-Programmierung: „was oben funktionierte, funktioniert hier auch“ – allmächtige Klassen, kennen jedes Objekt, sitzen als Spinne im Klassendiagramm, immer „gute“ Quelle für Erweiterungen – Rucksack-Programmierung: bei vergessenem Sonderfall in allen betroffenen Methoden if (Sonderfall){ Reaktion } else { altes Programm} Hartmut Wunderatsch, 1999: in nicht strukturierten Programmen (Lieder/Lippert/Roock): Leider lässt sich eine flache Aufwandskurve nicht allein durch ein agiles Projektmanagement (z.B. mit Scrum) erreichen. Agile Projekte können sogar - naiv durchgeführt - noch schneller steile Aufwandskurven produzieren als bei klassischen Vorgehensweisen. Peter Rösler

17 Refactoring Refactoring (Refaktorisierung/Restrukturierung): Umbau von Code, um ihn in eine optimale Form zu bringen, also wartbarer zu machen (ohne dabei die Funktionalität zu verändern) Beim manuellen Refactoring können ungewollt wieder Fehler eingebaut werden. => „Sicherheitsnetz“ aus automatischen Regressions-tests (mit hohem Testüberdeckungsgrad) nötig Entwicklungsumgebungen (z.B. Eclipse-SDK) unterstützen durch automatisierte Refactorings (Verschieben von Klassen, Umbenennen von Bezeichnern, etc.) Folie zuletzt geändert am: , (erstellt), Notizen zuletzt geändert am: Software Development Kit (SDK) Stefan Hug (PTV AG): Eclipse wird vorwiegend in der Java Entwicklung genutzt. Wir entwickeln in C++ mit Visual Studio. Hierzu nutzen wir Visual Assist X von Whole Tomato ( Dieses Tool bietet für C++ als PlugIn furs Visual Studio von Microsoft eben solche Refactoring Mechanismen an. Unsere Entwickler sind davon sehr begeistert. Peter Rösler Details siehe Notizseite

18 Test-Driven Development (TDD)
Neuer Code wird zyklisch wie folgt erstellt: „Red-Green-Refactor“-Zyklus: 1. Ein Test wird geschrieben, der zunächst fehlschlägt. (Im Test-Framework rot dargestellt.) 2. Genau so viel neuer Code wird implementiert, dass der Test erfolgreich durchläuft. (Wird grün dargestellt, sobald der Code richtig ist.) z.B. JUnit 3. Code (und Test!) werden refaktorisiert. (Wird grün dargestellt, wenn beim Umbau keine Fehler eingebaut wurden.) Folie zuletzt geändert am: , (erstellt), Notizen zuletzt geändert am: Quelle u.a.: Unklar: Gibt es eine Anforderungsdefinition oder nicht? Begriff "Mikroiterationen" Stefan Hug (PTV AG): wir verwenden CppUnit. Ein Zyklus ist meist wenige Minuten lang. Peter Rösler Quellen siehe Notizseite

19 Test-Driven Development (2)
Prinzipien von TDD: kontinuierliche Designverbesserung, einfaches Design und Test-First TDD ist also keine Test-, sondern eine Designstrategie. Das Test-First Prinzip von TDD fördert einen hohen Testüberdeckungsgrad und eine möglichst vollständige Testautomatisierung. T-Shirt von codesmack Folie zuletzt geändert am: , (erstellt), Notizen zuletzt geändert am: Peter Rösler

20 Pair Programming in XP (Extreme Programming)
2.2 Pair Programming und anderes „Reviewartiges“ in der agilen Software-Entwicklung Drei Beispiele aus unterschiedlichen agilen Methoden werden vorgestellt: Pair Programming in XP (Extreme Programming) Design- und Code-Reviews in FDD (Feature Driven Development) Sprint Review Meetings in Scrum Folie zuletzt geändert am: , (erstellt), Notizen zuletzt geändert am: Peter Rösler

21 aus http://en.wikipedia.org/wiki/ Pair_programming
Pair Programming in XP Der „Pilot“ („Driver“) schreibt den Code. Der „Navigator“ („Observer“) prüft den Code und denkt über Verbesserungen am Design nach. Wenn nötig, wird sofort diskutiert. Die Rollen werden oft gewechselt, z.B. alle paar Minuten. („Let me drive“) Die Paarzusammensetzungen im Team werden beispielsweise zweimal am Tag gewechselt. Folie zuletzt geändert am: , (erstellt), Notizen zuletzt geändert am: aus Pair_programming Peter Rösler Quellen siehe Notizseite

22 Pair Programming in XP (2)
Vorteile: Höhere Qualität (je nach Studie 15% bis 50%) viele Fehler können sofort entdeckt werden ein besseres Design kann gefunden werden Die Partner lernen voneinander. Mindestens zwei Entwickler kennen sich mit jedem Teil des Codes sehr gut aus. (Gut für den „Lastwagenfaktor“) Aufwand: Nicht etwa 100% mehr als bei Einzelprogrammierung, sondern (je nach Studie) 15% bis 85% mehr. (Diesem Mehraufwand stehen durch die verbesserte Qualität Einsparungen später im Projekt gegenüber.) Folie zuletzt geändert am: , (erstellt), Notizen zuletzt geändert am: Zahlen aus (Stand ) Dort auch erwähnt: A full-scale meta-analysis of pair programming experimental studies, from before or during 2007, (Hannay et al. 2009) confirms "that you cannot expect faster and better and cheaper". Higher quality for complex tasks costs higher effort, reduced duration for simpler tasks comes with noticeably lower quality - the meta-analysis "suggests that pair programming is not uniformly beneficial or effective". Truck Factor (definition): "The number of people on your team who have to be hit with a truck before the project is in serious trouble" ( ) Peter Rösler Quellen siehe Notizseite

23 Design- und Code-Reviews in FDD
Für jedes zu entwickelnde Feature gibt es folgende Meilensteine: Domain Walkthrough Design Design Inspection (Peer review your design and acceptance tests with stakeholders) Code Code Inspection (Peer review code and acceptance tests) Promote to Build Der Chef-Programmierer als Leiter des Teams bestimmt den Grad der Formalität der jeweiligen Inspektion. Folie zuletzt geändert am: , (erstellt), Notizen zuletzt geändert am: Design Inspection = Entwurfsinspektion Testen und Code-Inspektionen: Zunächst muss man die anderen Methoden fragen, welches Ziel sie mit Testen verfolgen. Die Antwort ist: „Fehler beseitigen”. Dieses Ziel wird in FDD sogar noch stärker betont, aber nicht nur durch Testen, weil Testen einer der am wenigsten effektivsten Wege zur Fehlerbeseitigung ist. Das ist nicht spekulativ, sondern in der IT sehr gut untersucht und gemessen (z.B. von Capers Jones). Inspektionen sind die effektivste Form der Fehlerbeseitigung und darüber hinaus eine sehr gute Teambildungsaktivität, weil sie die Teamkultur aktiv verbreiten genauso wie syntaktische und semantische Standards. Artikel_JM_ _FDD3_EntwirfJeFeature.pdf Das Sequenzdiagramm wird später ins Versionskontrollsystem eingecheckt, dabei werden gegebenenfalls verworfene Designalternativen und bewusst getroffenen Designentscheidungen dokumentiert. ... Der Entwurf wird per Design-Inspektion überprüft. Eine Design-Inspektion ist ein gemeinsames Treffen, bei dem die Sequenzdiagramme und die entstandenen Klassen- und Methodenrümpfe gemeinsam begutachtet werden. Dabei wird sowohl erneut auf der Ebene des Gesamtzusammenhangs geprüft, ob die Lösung angemessen ist, als auch auf Ebene der Details (Klassen- und Methodenrümpfe) entschieden, ob die Umsetzung gut gewählt ist. Während der Inspektion werden je Klasse gewünschte Veränderungen am Entwurf notiert und der entsprechende Entwickler (Class-Owner) vermerkt sich diese auch auf seiner Aufgabenliste. Wenn der Entwurf verifiziert wurde, kann mit der Implementierung begonnen werden. Code-Inspektionen durchführen: Der Chefentwickler entscheidet, ob Code-Inspektionen vor oder nach dem Erstellen von Unit-Tests durchgeführt werden. A code inspection with the feature team members or with other project members is held either before or after the unit test task. The decision to inspect within the feature team or with other project team members is that of the Chief Programmer. The decision to inspect before or after unit test is that of the Chief Programmer. Peter Rösler Quellen siehe Notizseite

24 Design- und Code-Reviews in FDD (2)
Inspektionen in FDD: Gefahr von psychologischen Problemen ist minimiert, weil der Owner des zu prüfenden Artefakts das gesamte Feature-Team ist (statt einer Einzelperson) FDD bezieht sich auf wissenschaftliche Untersuchungen: Code-Inspektionen beseitigen Fehler mit weniger Aufwand als Tests. Weitere positive Wirkungen: Wissenstransfer, Programmierrichtlinien und andere Prozess-Standards setzen sich durch, etc. Fazit: FDD vertraut voll auf klassische Inspektionen. Folie zuletzt geändert am: , (erstellt), Notizen zuletzt geändert am: wiki.ipponsoft.de/graphics/FDD.doc Prozess #1: Entwickle ein Gesamtmodell (Rollen: alle Projektbeteiligte) Prozess #2: Erstelle eine Feature-Liste (Rollen: in der Regel nur die Chefprogrammierer) Prozess #3: Plane je Feature (Rollen: Projektleiter, Entwicklungsleiter, Chefprogrammierer) Prozess #4: Entwurf je Feature (Rollen: Chefprogrammierer, Entwickler) Prozess #5: Konstruiere je Feature (Rollen: Entwickler) Peter Rösler

25 Sprint Review Meetings in Scrum
An Ende eines Sprints erfolgt ein informelles Review durch Team, Product Owner und Stakeholder. Dazu wird das Ergebnis des Sprints (die laufende Software, keine Folien!) durch das Team vorgeführt. („The demo“) Product Owner und Stakeholder geben Feedback, das in die weitere Arbeit mit einfließt. Folie zuletzt geändert am: , (erstellt), Notizen zuletzt geändert am: Meeting am Ende eines jeden → Sprints innerhalb einer 4-stündigen → Time-Box. Hier zeigt das Team selbst – nicht irgendein übergeordneter Manager – dem → Product Owner und anderen interessierten Personen live am funktionierenden System, was es innerhalb des Sprints erreicht hat. Wichtig: keine Dummies, kein Powerpoint! Nur fertige Produktfunktionalität darf vorgeführt werden. Mountain Goat Software, LLC dasselbe in Stefan Hug (PTV AG): In der Product Owner Schulung hab ich folgenden wichtigen Aspekt gelernt. Damit der Product Owner im Review keine (negativen) Überraschungen erlebt, nimmt der Product Owner ein Item (Backlog Item) beim Team ab sobald es nach Meinung des Teams fertiggestellt ist (also während des Sprints). Ein Item ist erst dann „Done“ wenn der PO (der die Anforderungen der Steakholder kennen sollte) das Item abgenommen hat (gerne können auch schon hier einzelne Steakholder eingeladen werden). So soll sichergestellt werden, dass nicht erst während eines Reviews am Endes des Sprints festgestellt wird dass ein Feature gar nicht, nicht vollständig, oder nicht nach den Wünschen der Steakholder erfüllt wurde. Durch die PO Abnahme während des Sprints können also noch Nacharbeiten oder Verbesserungen im laufenden Sprint erfolgen. Zu "die laufende Software, keine Folien!": Ja, Das ist die reine Lehre. Bei uns gibt es aber trotzdem Folien bzw. Wiki Seiten für jedes Review, sozusagen als Doku der Demo. Source: Mountain Goat Software Peter Rösler Quellen siehe Notizseite

26 Sprint Review Meetings in Scrum (2)
Kein Review im Sinne einer Inspektion, welche Fehler auf Dokument-Ebene finden will. Es gibt eher einige Merkmale eines Abnahmetests. Behauptung: Scrum hat keine „reviewartigen“ Mechanismen im Sinne von Inspektionen. Empfehlung: Scrum (mindestens) um Pair Programming oder Inspektionen ergänzen. Source: Mountain Goat Software Folie zuletzt geändert am: , (erstellt), Notizen zuletzt geändert am: Peter Rösler

27 Agile Inspektionen* wurden von Tom Gilb im Jahr 2005 vorgestellt [1].
- Autor des Buches „Software Inspection“ (1993, Coautor Dorothy Graham) - Mit seinem Buch „Software Metrics“ (1976) war er der Ideengeber für CMM/CMMI Level 4. - „Erster Agilist“ Mike Cohn: „I’ve always considered Tom to have been the original agilist. In 1989, he wrote about short iterations (each should be no more than 2% of the total project schedule). This was long before the rest of us had it figured out.“ Tom Gilb Agile Inspektionen sind besonders in Wasserfall-Projekten nützlich, weil es dort keine kurzen Feedback-Schleifen (z.B. in Form von Iterationen) gibt. Folie zuletzt geändert am: , (erstellt), Notizen zuletzt geändert am: (Stand ): He is an independent teacher, consultant and writer. He has published nine books, including the early coining of the term "Software Metrics" (1976) which is the recognized foundation ideas for IBM CMM / SEI CMM/CMMI Level 4. He is directly recognized as the idea source for parts of the Agile and Extreme programming methods (primarily the incremental cycles). Tom and Kai have recently developed their own Agile Inspections and Agile Evolutionary Project Management processes, that are being successfully used by clients. (Stand ) p18 "Value-Driven Development Principles and Values – Agility is the Tool, Not the Master" by Tom Gilb: And its first principle “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”, is central to the ideas in this article. It is not strange that I agree, since many of the Agilistas, for example Kent Beck, explicitly point to my 1988 book as a source of some of their ideas [4, 5, 6, 7, 8, 9, 12]. 5. Mike Cohn, “I’ve always considered Tom to have been the original agilist. In 1989, he wrote about short iterations (each should be no more than 2% of the total project schedule). This was long before the rest of us had it figured out.” * Andere Bezeichnungen: „Extreme Inspections“, „Agile Specification Quality Control (SQC)“ [5] Peter Rösler

28 Eine Beobachtung als Ausgangspunkt
Bei klassischen Inspektionen: Die Autoren beginnen manchmal aufgrund der Review-Erfahrungen, deutlich fehlerfreier zu arbeiten. Eine signifikante Lernkurve kann erreicht werden. Folie zuletzt geändert am: , (erstellt), Notizen zuletzt geändert am: Es folgen vier Folien mit Beispielen. Peter Rösler

29 Marie’s persönliche Lernkurve
Geschätzte verbleibende Major defects / Seite 28 13 4 3 5 10 15 20 25 1 2 30 6 7 Reihenfolge der Dokumente, die einem Review unterzogen wurden Marie Lambertsson’s Lernkurve, Ericsson, Stockholm, 1997 Folie zuletzt geändert am: , , Notizen zuletzt geändert am: Quelle: Tom Gilb Peter Rösler

30 Gary’s persönliche Lernkurve
80 gefundene Major defects (~ insgesamt vorhanden!) 40 23 8 20 60 80 100 1 2 3 4 5 Gefundene Major defects / Seite Februar April Reviews von Gary’s Design-Dokumenten “Gary” bei McDonnell-Douglas Folie zuletzt geändert am: , (Animation), , , Notizen zuletzt geändert am: begin -Aus Gilb‘s Original-Folie incl. Notizansicht:- Early defect removal also pays dividends in terms of personal skills. Take the case of “Gary” at McDonald Douglas. From a standing start, he participated in 5 successive Inspections of his own software designs (ignore the hard hat!). Note that, as Author of the 5 documents, he was required to join the Inspection team that was looking for his errors. The first document revealed an average defect density of 80 majors per page – a frightening number, but actually quite typical. By the time he’d fixed them all, though, Gary had learnt so much about how to write good design documents, that his second Inspected design was only half as buggy. Each successive document was only half as buggy as its predecessors, and by the fifth – well, I had to cheat there, because the graphing tool wouldn’t let me graph an observation of zero, so I had to put in one spurious defect! Here’s how McDonald-Douglas felt about the personal value of Inspections: “We find an hour of doing Inspection is worth ten hours of company classroom training.” A McDonnell-Douglas line manager “Even if Inspection did not have all the other measurable quality and cost benefits which we are finding, then it would still pay off for the training value alone.” A McDonnellDouglas Director end -Aus Gilb‘s Original-Folie incl. Notizansicht- Andere Quelle (welche weiß ich nicht mehr): 3 mal schneller lernt man Quelle: Douglas Aircraft, 1988, private report to Tom Gilb Peter Rösler

31 Lernkurve einer gesamten Organisation
Weiteres Beispiel bei Douglas, 1988: innerhalb des ersten Jahres stieg die Qualität um Faktor 60, gemessen am Anteil der Konstruktions-zeichnungen, die abgelehnt und korrigiert werden mussten (0.5% gegenüber ca. 30% vorher). Gefundene Major defects / Seite 5 10 15 20 25 18 Monate später (~1994) 1-1,5 British Aerospace, Eurofighter Projekt, Wharton vor Tom Gilb’s Review-Training Folie zuletzt geändert am: , (Animation), , (erstellt), Notizen zuletzt geändert am: For the Raytheon example see “Raytheon Electronic Systems Experience in Software Process Improvement” ( [Gilb slides: “RAYTHEon 95 Study SLIDES MASTER.ppt”] Tom told me on : at British Aerospace, Eurofighter, they had time delay, one reason was the software, he teached Inspections, they had 20 Mj/p and 18 months later only Mj/p. ch008 Specification Quality Control.pdf (preliminary version of Gilb’s “Competitive Engineering”, ISBN ): My own experience in industrial measurement of defects suggests that technical documents, initially and routinely, contain at least 20–60, and often far more, ‘major’ engineering specification defects in each ‘logical’ page (300 non-commentary words). Through systematic use of feedback from SQC to specification writers, this level can be brought down to well under one remaining major defect/page (British Aerospace, Eurofighter Project, Wharton, achieved this in 18 months) (Personal Communication). Do not confuse with the SQC ‘Checking’ sub-process! The aircraft factory traditionally used the term ‘checking’ for a process done by a group of people who specialized in this, called ‘checkers.’ The process checked engineering drawings against the official engineering drawing specification rules, which were in a large handbook – so large that copies were not given to inform individual engineers what the rules were! In 1988 we proved, with hard data on a large scale, for the engineering directors, that the SQC process was far more effective at finding interesting engineering defects than the traditional ‘checking’ process. We ended up within the first year with sixty times better quality in terms of rejected and reworked drawings (0.5% versus earlier about 30% reworked). Weiteres Beispiel bei Raytheon: siehe Notizansicht der Folie. Quelle: Tom Gilb Peter Rösler

32 Lernkurve und positive Motivation
Der normale Entwickler ist i.A. fähig, seine Fehlerrate um 50% zu senken nach jedem Zyklus von persönlichem Lernen und Feedback. (Tom Gilb’s pers. Erfahrung, 1988 und später). Diese Reduktion ist nur zu erwarten, wenn die Autoren positive Motivation haben, Dokumente mit guter Qualität zu produzieren. Quantifizierte Exit-Kriterien, die vom Management verlangt werden, können eine solche Motivation sein. Es gibt keine Hinweise, dass die Autoren signifikant länger brauchen, um diese Dokumente zu produzieren! (Tom Gilb, Review Symposium 06/2005) Niels Malotaux: »Die ’Null-Fehler’-Haltung führt meiner Erfahrung nach sofort zu 50% weniger Fehlern.« Folie zuletzt geändert am: , , , , Notizen zuletzt geändert am: DesignReviewsINCOSE04.pdf (4 SQP VOL. 7, NO. 1/© 2004, ASQ) Figure 4: The individual engineer is generally capable of reducing the defect injection density by 50% per cycle of personal learning and feedback (Tom Gilb, Personal Experience, 1988 and later). Gilb, Competitive Engineering (ISBN ) p227: „The specification writer will learn about current agreed rules and their peer’s interpretations of these rules. As a result they are likely, by my industrial experience, to learn to produce a specification with half the number of defects next time. (Ultimately, after several SQC experiences for the writer, about 100 times cleaner – using major defect reduction as the measure – specification is usually achieved!)” Tom Gilb (Review Symposium 06/2005): 50% reduction per cycle of learning gibt’s nur, wenn Motivation dazu kommt, z.B. Manager verlangt Exit-Kriterium 1 Mj/p. Niels Malotaux (Review Symposium 06/2005): er hat erlebt, dass die Haltung „Zero Defects“ allein schon eine Halbierung der Fehler bewirkt. Niels Malotaux (01/2006): The Zero-defects asymptotic curve is actually the learning curve. See my booklet on testing chapter 8: "When Phil Crosby first started to apply Zero Defects as performance standard in 1961, the error rates dropped 40% almost immediately. In my projects I've observed similar effects.". See also chapter 9 on Attitude and the Experience story. Quelle: Gilb‘s Review Symposium 06/2005 Peter Rösler

33 Grundidee der Agilen Inspektionen
Der Schwerpunkt der Inspektionen wird verschoben weg vom frühzeitigen Fehler finden und korrigieren („cleanup“-Modus) hin zum Schätzen der Fehlerdichte der Dokumente, um die Entwickler zu motivieren, zu lernen wie man von vorne herein fehlerfreier arbeitet. Die Kosten für Inspektionen sinken enorm: Stichproben reichen aus (statt 100% der Dokumente zu prüfen), denn der Zweck ist jetzt „Messen“ statt „cleanup“-Modus. Folie zuletzt geändert am: , , (erstellt), Notizen zuletzt geändert am: Peter Rösler

34 Ziel von Agilen Inspektionen
Hauptziel: Die Entwickler zu motivieren, ihre Fehlerrate zu senken Zusätzliche (klassische) Inspektions-Ziele: Verhindern, dass zu fehlerhafte Dokumente in die folgenden SW-Entwicklungsphasen gelangen (Terminverzögerungen und Qualitätsprobleme wären sonst die Folge) Haupttaktik: numerische Exit-Kriterien wie „maximal 1,0 Mj / p“. Gültige Prozess-Standards lehren und durchsetzen Folie zuletzt geändert am: , (erstellt), Notizen zuletzt geändert am: Peter Rösler

35 Allgemeine Prinzipien von Agilen Inspektionen
Wenige Seiten auf einmal (z.B. 1 bis 3 Seiten) Evtl. frühzeitig (erste 5% eines großen Dokuments) Kontinuierlich (z.B. jede Woche), bis die Arbeit fertig ist Für jeden Entwickler (jeder einzelne Autor muss persönlich motiviert und trainiert werden) Folie zuletzt geändert am: , (erstellt), Notizen zuletzt geändert am: "1 bis 3 Seiten" aus Agile_SQC_INCOSE05.pdf übernommen Peter Rösler

36 Ablauf einer Agilen Inspektion (1)
Eine Stichprobe wird ausgewählt (z.B. 1 Seite) und gegen ca. 3 bis 7 Regeln geprüft, z.B. Clarity („clear enough to test“) Unambiguous („to the intended readership“) Consistent („with other statements in the same or related documents“) Completeness („compared to sources“) Für Anforderungsdokumente: „no design“ Die Reviewer sollen alle Abweichungen von diesen Regeln identifizieren und klassifizieren. Die Mj Defects werden an den Moderator berichtet. Folie zuletzt geändert am: , (erstellt), Notizen zuletzt geändert am: sources = Vorgängerdokumente (aus den SW-Entwicklungsphasen vorher) Peter Rösler

37 Ablauf (2) An der Prüfsitzung nehmen beispielsweise zwei Reviewer teil, Dauer ca Minuten. Geprüft wird mit optimaler Inspektionsrate. Ein trainierter Moderator ist anwesend und leitet den Prozess. Danach wird die geschätzte Anzahl der tatsächlich vorhandenen Fehler aus der Gesamtzahl der gefundenen Fehler berechnet. (Berechnungsgrundlage: typischerweise findet das Team in diesem Setting ein Drittel der vorhandenen Fehler.) Folie zuletzt geändert am: , (erstellt), Notizen zuletzt geändert am: Es gibt genauere Verfahren zur Abschätzung der vorhandenen Fehler, z.B. 1. Die Effektivität wird abgeschätzt durch den Vergleich der realen Inspektionsrate mit der für den jeweiligen Dokumenttyp optimalen Inspektionsrate. 2. Die Effektivität wird durch die Capture-Recapture-Methode abgeschätzt. (vgl. Foliensatz "Mit Stichproben-Reviews die Dauer von Testphasen vorhersagen" vom , Tutorial auf Software-QS-Tag 2010, Rösler/Schlich). Peter Rösler Details siehe Notizseite

38 Maßnahmen werden festgelegt
Ablauf (3) Als Exit-Kriterium wird anfangs ein Wert wie beispielsweise „maximal 10 Mj / p“ angesetzt. Nach ein paar Monaten „Kulturänderung“ sollte man das Limit eher bei „maximal 1 Mj / p“ ansetzen. Maßnahmen werden festgelegt Bei sehr hoher Fehlerdichte (z.B. 10 Mj / p oder mehr): Es wäre unökonomisch, die anderen Seiten des Dokuments zu prüfen, um „alle Fehler“ zu finden, oder die bisher gefundenen Fehler zu korrigieren. Es würden trotzdem zu viele Mj Defects unentdeckt bleiben. Beste Alternative: Autor oder jemand anderes schreibt Dokument neu. (Hier sieht man, dass eine frühzeitige Agile Inspektion Sinn macht, z.B. schon wenn 5% des Dokuments fertig sind.) Folie zuletzt geändert am: , (erstellt), Notizen zuletzt geändert am: Peter Rösler

39 Prüfung ohne Vorgängerdokumente
Anders als bei klassischen Inspektionen wird nicht gegen die Vorgängerdokumente geprüft, sondern nur gegen das Wissen der Reviewer. Dadurch wird die Prüfung beschleunigt, allerdings ist das Ergebnis ungenauer. (Wenn aber die Stichprobe ergibt, dass die Fehlerdichte 50 Mj / p oder mehr beträgt, was laut Gilb [1] durchaus normal ist, dann besitzt allein das schon genug Aussagekraft.) Folie zuletzt geändert am: , , (erstellt), Notizen zuletzt geändert am: Peter Rösler

40 Gilb's Paradigmenwechsel
Die unmittelbare Lösung gegen hohe Fehlerdichten ist nicht, die gefundenen Fehler aus dem Dokument zu entfernen, und ist nicht, den SW-Entwicklungs- Prozess zu ändern! Die effektivste praktikable Lösung: Sicherstellen, dass jeder Autor das Exit-Kriterium der maximalen Fehlerdichte ernst nimmt. (Im Durchschnitt sollte nach jeder Agilen Inspektion die Fehlerrate eines Autors um ca. 50% sinken.) sehr überraschend für Qualitäts-sicherer Folie zuletzt geändert am: , , (erstellt), Notizen zuletzt geändert am: Peter Rösler

41 Black-Box-Sicht auf Agile Inspektionen
(Kosten) Out (Nutzen) gefundene Major Defects „egal“ Dienen nur zum Messen der Fehler- dichte und um dem Autor zu zeigen, welche Art von Fehlern er macht. „egal“ wenige Arbeits-stunden (Stichprobe) Prozessverbesserungs- Vorschläge Agile Inspektion Kennzahlen (Fehlerdichte) Lernkurve des Autors Folie zuletzt geändert am: , , (erstellt), Notizen zuletzt geändert am: G.T : Meine Interpretation: Klassische und agile Inspektion sind eigentlich das Gleiche. Sie liefern ja auch die gleichen Ergebnisse. Allerdings werden die Rollen o vorrangiges Ergebnis o erfreulicher Nebeneffekt vertauscht. Ausgehend von der klassischen Inspektion bewirkt dieser Wechsel, dass auch die "agile"(?) Inspektion kleinerer Ausschnitte das Ziel erreicht. Geringere Fehlerrate (ca. 50%. Kumuliert über mehrere Inspektionen ist eine um eine Größenordnung niedrigere Fehlerrate gut erreichbar, vgl. Folien 29-31) Peter Rösler Source: Peter Rösler,

42 4. Wie agil sind Agile Inspektionen wirklich?
Contra: Da Agile Inspektionen besonders in Wasserfall-Projekten nützlich sind, ist das Wort „agil“ in dieser Hinsicht irreführend. Pro: Agile Inspektionen sind viel leichtgewichtiger als klassische Inspektionen. (Einfacherer Prozess, deutlich weniger Aufwand) Mit Agilen Inspektionen sind viele kurze Feedback-schleifen möglich. (Das entspricht voll dem Grundgedanken der agilen Vorgehensmodelle.) Folie zuletzt geändert am: , (erstellt), Notizen zuletzt geändert am: agil! Peter Rösler

43 Literatur zu Inspektionen
1.  Gilb, Tom: Agile Specification Quality Control. Cutter IT Journal, Vol. 18, No. 1, pp , January 2005. 2. Gilb, Tom / Graham, Dorothy: Software Inspection, Addison-Wesley, 1993, 3.  Radice, Ronald A.: High Quality Low Cost Software Inspections, Paradoxicon Publishing, 2002 4. (Download Center, Stand ), “Optimizing Inspection” von Tom Gilb, S. 2 5. Gilb, Tom: Competitive Engineering, Butterworth-Heinemann, 2005 Folie zuletzt geändert am: , , Genaue Seitenangaben: 1. Gilb, Tom / Graham, Dorothy: Software Inspection, Addison-Wesley, 1993, S. 78, 381, 435 2. Radice, Ronald A.: High Quality Low Cost Software Inspections, Paradoxicon Publ., 2002, S. 159, 403 3. (Download Center, Stand ), “Optimizing Inspection” von T. Gilb 4. Michelmann, Rotraut / Michelmann Walter U.: Effizient lesen, Gabler Verlag, 1995, S. 63 5. Buzan, Tony: Speed Reading, mvg-verlag, Landsberg-München, 8. Auflage 2002, S 6. (Forum, Stand ), Topic “Insp., Qual. Control”, Thread “Completeness of candidate doc.”, Posting Kai Gilb 7. Gorski, J. / Jarzebowicz A.: Development and validation of a HAZOP-based inspection of UML models, in: Proc. of the 3rd World Congress for Software Quality, Erlangen, 2005, S. I-352 Peter Rösler PowerPoint-Folien und Textfassung des Vortrags: