Agile Testing Days Berlin – Key Note Mary and Tom Poppendieck

2 Kommentare

The One Thing You Need to Know … About Software Development

„Korrektheit kann zu jedem Zeitpunkt bestätigt werden“ ist der Untertitel von Marys Keynote und er startete mit einem klaren Statement, dass „Wasserfall“ einfach nicht funktioniert. Also, dann mal hören, was funktioniert 🙂

Die Frage ist, wie man mit der Komplexität umgeht, und die Antwort ist zu einem gewissen Grad „Teile und Herrsche“. Es folgten ein paar geschichtliche Hinweise, wie das zu erreichen sei. In den 70er-Jahren war alles „Strukturiert“ (Strukturiertes Design, Strukturierte Maintenance, etc), aber das hat das Problem nicht wirklich lösen können, wie wir heute wissen. Was wir wirklich wollen, ist das man gar nicht erst anfängt, die Probleme zu injezieren. Eine frühe Antwort darauf kam von Edsger Disjkstra in der Form einer mehrschichtigen Architektur, jede Schicht ist eine virtuelle Maschine zu der darüberliegenden Schicht.

Nach langen Diskussionen über Architektur mit Tom Gilb gestern Abend in der Hotel-Lobby, zittern meine Finger ein wenig, wenn ich hier über Architektur schreibe 🙂 … aber zurück zu Mary. Die Frage ist, wie Software auf den verschiedenen Ebenen funktioniert; z.B. Unit Testing und Business Level Testing.

Der nächste in der geschichtlichen Abfolge ist Harlan Mills mit dem Ansatz des Top-Down-Programming, der helfen sollte die Schwierigkeiten bei der Integration zu verhindern. Es ist eine Schrittweise integration, die als eine frühe Version von Continuous Integration angesehen werden kann, welche wir heutzutage diskutieren. Zusammengenommen mit der Diskussion mit Tom Gilb gestern abend sieht es so aus, als ob einige agilen Ideen nicht sooo neu sind.

Nächster ist Dave Parnas und seine „Kriterien zur Dekomposition“. Das erinnert mich daran, was Rom gestern gesagt hat, dass viele Architekten in Wahrheit nur Dekomposition betreiben, und keine Architektur, aber das ist schon wieder eine andere Geschichte. Die Idee ist, das Programm aufzuteilen, um zukünftige Änderungen einfacher durchführen zu können … das kommt dem Nahe, was Uwe anpreist: „Architektur, um Maintenance zu unterstützen“ (Sorry Uwe, falls das zu sehr verkürzt ist). Oh, sorry, ich muss zugeben, dass ich zu langsam war, um mit der geschichtlichen Betrachtung mitzuhalten, aber wir werden aufholen (Ab jetzt werden Andreas und ich am Blog post pairen, sehr cool).

1976 wurde festgestellt, dass das Hauptplroblem in der Softwareentwicklung die Wartungskosten (schon wieder!) sind und die Lösung zu dem Problem ist natürlich die Fehler zu früh wie möglich zu finden. Und dafür braucht man kürzere Entwicklungszyklen, als man mit dem Wasserfallprozess bekommen kann.

1981 betritt Tom Gilb die Szene mit dem Konzept ein System mit einer kurzen Zusammenfassung von messbaren Geschäftszielen anzufangen. Diese müssen unmissverständlich und testbar sein, und dürfen kein Design vorwergnehmen (das ist ja Aufgabe der Architekten). Hmm, das hört sich sehr vertraut an, das war der Kernpunkt seiner Keynote gestern. Es ist immer hilfreich diese Kreuzzusammenhänge zu sehen. Also zurück zu

„Prevent defects injection in the first place!“

Wie lernt man denn die Fehler nicht zu injizieren? Ok, was ist ein „Defect Injection Process“? Er fängt mit einer Spezifikation an, und ein Team schreibt den Code und ein anderes Team schreibt die Tests. Sorry, aber das passt am Ende einfach nicht zusammen, wir haben einen „Defect Injection Process“. Nächste Idee: Kombiniere das Schreiben der Tests zusammen mit der Spezifikation und schreibe dann den Code, um die Erwartungen des Tests zu erfüllen.

Zurück zur Komplexitätsbewältigung und der Frage wie man mit der Komplexität umgeht. Die Antwort ist nicht (nur) „Teile und Herrsche“ sondern „Teile entlang Verantwortlichkeiten und Werten“ (auch etwas, was Uwe uns immer wieder predigt, vertikale Teilung statt horizontaler). Dies hat sich zu den drei Regeln schlanker (lean) Entwicklung fortgesetzt:

  • Design macht einen Unterschied
  • Korrektheit kann zu jedem Zeitpunkt bestätigt werden
  • Fehler sind eine Möglichkeit, um daraus zu Lernen

Mary führt einige high-level Beispiele an, wie man ein System entwickeln kann. Natürlich macht sie ein paar Bonuspunkte, weil sie das iPhone als gutes Beispiel für ein solches, gutes allumfassendes Systemdesign.

Jetzt wird es wieder konkreter und die Frage ist wie viel Zeit eines Release-Zyklus dafür benutzt wird Fehler zu finden und zu beheben (System hardening). Die Antwort ist, dass die besten Unternehmen höchstens 10% dafür aufwenden, während andere dafür bis zu 50% aufwenden. Aber das Ziel kann nicht sein, so viel wertvoller Entwicklungszeit darauf zu verwenden, also muss man die Fehler schon früher im Prozess finden. Und damit kommt Mary zurück zum Thema die Korrektheit zu jedem Zeitpunkt bestätigen zu können, und nicht erst am Ende des Release-Zyklus.

“No correlation between size of the code base and bug rate: Complexity handled completely.” (from an example developing an embedded system)

Jetzt wird es Agil: wir haben kurze und stabile iterationen. Und die Interessenten (Stakeholder) bekommen und geben Feedback in jeder Iteration. Und es wären nicht die „Agile Testing Days“ ohne ein gutes Beispiel wie automatisierte Unit Tests der IBM zu einem sehr erfolgreichen Projekt bei der Einführung von Agilität geholfen hätten. Hört sich an wie Continuous Integration und frühes automatisiertes Testen, auch ohne FitNesse und Robot.

“People do not want software, they want something else.”

Grundsätzlich wollen Kunden ihre höchstprioren Ziele umgesetzt sehen, und damit deren Probleme gelöst bekommen. Mary bewirbt TDD um das zu erreichen:

“The biggest defect is tolerating defects.”

Mary betont, dass man aus Fehlern lernen muss, weil sie fehlendes Verständnis andeuten. Es ist immer eine Gelegenheit zu Lernen. Trotzdem, in einem sehr disziplinierten Programm entwischen nur einige, wenige Fehler.

Ok, da wir hier ja über „lean“ sprechen kommen natürlich noch ein paar Beispiele von Toyota :). Mary beschreibt wie Toyota von der aktuellen Situation ihrer Vision näher kommen. Dazu muss mit jedem Schritt ein Hinderniss überwunden werden, also mit jedem Schritt näher zu Vision gelern werden.

Zusammenfassend (sagt Andreas), vieles davon wurde auch schon in dem Tutorial am Montag besprochen, aber was war gut, dass nochmal verdichten in Erinnerung gerufen zu bekommen.

Thomas Jaspers

Langjährige Erfahrung in agilen Softwareprojekten unter Einsatz von Java-Enterprise-Technologien. Schwerpunkt im Bereich der Testautomatisierung (Konzepte und Open-Source Werkzeuge).

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentare

  • Uwe Friedrichsen

    Erst einmal Glückwunsch, Du hast meine Gedanken richtig wiedergegeben … und wenn Ihr erst auf die agile Testing Days fahren müsst, um die Idee dahinter zu verstehen, dann war es das Geld schon wert … 🙂

    Nein, jetzt ernsthaft: Ich denke, es ist bezeichnend, dass das gesamte agile Geschehen von Leuten wieder in einen gesamtheitlichen Kontext gerückt wird, die schon länger bei dem „IT-Zirkus“ dabei sind (wobei „IT-Zirkus durchaus nett gemeint ist).

    Sie sind – wie ich auch – davon überzeugt, dass Agilität eigentlich seit jeher (auch bevor es den Namen hatte) extrem wichtig ist, um erfolgreich Ergebnisse in komplexen Umfeldern erzielen zu können. Deshalb engagieren sie sich ja auch im Kontext der agilen Bewegung.

    Nur ist es eben nicht so, wie es gerne von dem ein oder anderen „Evangelisten“ dargestellt wird, dass deswegen alles, was wir in den letzten 40 Jahren mühsam gelernt haben, nicht mehr benötigt wird bzw. einfach „Blödsinn“ und nutzlos ist.

    So hatte Tom Gilb mit seiner Keynote absolut recht, wenn er sagte, dass das Gesetz „Garbage in –> Garbage out“ auch in Zeiten der Agilität noch gilt. Egal, ob ich Requirements, Use Cases oder User Stories erfassen, wenn ich Müll hereinschreibe, dann wird das Ergebnis nicht das liefern, was ich haben will … profan „Bug“ genannt.

    Ob seine formale Beschreibung da weiterhilft, sei einmal dahingestellt. Ich habe bislang noch keine formalen Spezifikationen gesehen, die an der Stelle wirklich geholfen haben. Vielleicht klappt das in sehr technischen Umfeldern (auf der Fachseite), aber nicht da, wo ich üblicherweise unterwegs bin, nämlich bei eher nicht-technischen Fachseiten. Da hilft aus meiner Erfahrung nur ein agiler Grundwert, nämlich Kommunikation, Kommunikation, Kommunikation.

    Ebenso hat – wenn man es zu Ende denkt – David Parnas 1972, also vor fast 40 Jahren eigentlich so ziemlich alles Wichtige über Anwendungsarchitektur und -design gesagt, nur haben wir bis heute immer noch nicht die Kurve gekriegt, das umzusetzen. Stattdessen verstecken wir uns hinter immer neuen Konzepten, Schlagwörtern und Hypes, bauen immer neue Nebenkriegsschauplätze auf, anstatt einmal die echten, schon lange bekannten Probleme ernsthaft anzugehen.

    Warum das so ist, weiß ich nicht genau, aber ich denke, dass es daran liegt, dass wir in dem Fall einige unangenehme Wahrheiten akzeptieren müssten. Aber ich denke, dass ist eigentlich eine andere Diskussion … 😉

    Auf jeden Fall herzlichen Dank an Euch beide für Euer fleißiges Bloggen von der Konferenz und die vielen Eindrücke, die Ihr damit vermittelt!

  • Andreas Ebbert-Karroum

    Ah, ich sehe Du hast Dich mit Deiner Kommentarlänge schon gut an unsere neue Standard-Blogpostlänge angepasst 😉

    Tom Gilbs formale Sprache zur Beschreibung von Anforderungen „Planguage“ soll übrigens explizit gerade die qualitativen Aspekte (lies: nicht-funktionale Anforderungen, ein Stichwort bei dem Tom Gilb in die Luft geht, wer will kann es gerne probieren 🙂 ) vollständig abgedeckt werden. Eine kurze Google-Suche hat aber nichts relevantes zutage befördert. 🙁

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.