Software Craftsmanship. The Agile Hangover. Donnerstag, 30. August 12

Transkript

1 Software Craftsmanship or The Agile Hangover

2 @benjamin Hallo mein Name ist Benjamin Reitzammer... ihr findet mich auf Twitter.

3 Craftsmanship Heute will ich euch ein wenig über Software Craftsmanship erzählen. Der Begriff ist euch vielleicht schon ein paar Mal begegnet. Vor allem, wenn ihr euch mit mir mal unterhalten habt. So oder so...ich hab leider keine Spiele oder praktischen Übungen für euch, sondern eher einen Haufen abstrakter konzepte. Und eine Geschichte. Und zwar die Geschichte vom Agilen Kater

4 party Natürlich meine ich damit den Kater, den man bekommt, wenn man zuviel gefeiert hat. Die allermeisten, wenn nicht sogar alle der hier anwesenden sind doch sicherlich total begeistert von Agile und Scrum und dem ganzen Kram. Als ihr gehört habt, dass in eurem Teams oder eurer Firma Agile eingeführt werden soll, wart ihr alle so "yeah, Party"

5 fast Und es war auch eine richtige Party. Arbeit hat plötzlich wieder Spaß gemacht und man musste endlich nicht mehr 6 Monate warten bis das Newsletter Formular ein neues Feld für den Vornamen hatte. Man war auf einmal schnell. Ja, richtig gehend agil.

6 #fail Irgendwann habt ihr dann aber gemerkt, dass die verstärkte Transparenz von Scrum auch die großen Probleme transparent macht. Man kann sich plötzlich nicht mehr vor ihnen verstecken. Damit einher geht fast immer, dass die Velocity in den Sprints abnimmt. Klar, man ist schnell, aber halt doch irgendwie nicht so schnell. Klar, man kann sagen "wir sind ja noch nicht richtig agil" und versuchen seine Agilität mit irgendeiner Zertifizierung und/oder einem Maturity Model messen. Aber irgendwie hilft das auch nicht so recht.

7 Something doesn t fit Hmmm... irgendwas kann da ja nicht so richtig laufen. Irgendwas passt nicht.... also mal einen Schritt zurück und schauen was Agile denn eigentlich heißt oder heißen soll. Und was liegt dafür näher als das Agile Manifest heranzuziehen. Die Essenz von Agile sozusagen.

8 Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Alles klar... hmmm... haben wir doch alles gemacht oder?! Wir arbeiten eng zusammen, sowohl im Team als auch mit unseren Kunden. Wir machen den Prozess so einfach wie möglich... so sehr, dass wir ihn manchmal gar nicht mehr wiederfinden, weil er so schlank ist. Wir releasen oft und das einzige was zählt ist natürlich "working software".

9 Software is the epicenter Aber wenn wir nicht richtig aufgepasst haben, dann haben wir übersehen oder vergessen, dass Software eigentlich unser Hauptanliegen ist. Software steht im Mittelpunkt unseres Schaffens und ist unsere zentrale Fragestellung. Dazu kommt noch, dass wir zu den normalen und nicht-perfekten Entwicklern/Technikern gehören, und da passiert es schonmal, dass wir working software produzieren, indem wir Abkürzungen nutzen. Indem wir die schlechte Architektur einer Anwendung doch nicht überarbeiten und verbessern, weil wir es einfach nicht besser wissen, oder weil der Sprint halt doch nur zwei Wochen lang ist und am Ende ja auch ein Produktinkrement dabei rauskommen soll.

10 patchwork & debt So passiert es also ganz einfach und schnell, dass die Änderungen und Weiterentwicklungen an unserer Software nur Stückwerk sind, weil wir nur lokale Änderungen machen und damit einen Erker nach dem anderen an unser hübsch angelegtes Schlößchen bauen In Techniker Sprache nennt sich sowas dann die Anhäufung von technical debt, von technischen Schulden. Bei allem Wohlwollen und agilem Vorgehen passiert es also schnell, dass die Dinge an der Oberfläche zwar gut aussehen, es unter der Haube aber trotzdem zu stottern anfängt. Martin Fowler hat das Anfang 2009 als Flaccid Scrum bezeichnet. Als schlaffes Scrum. Andere schlaue Menschen standen natürlich auch schon vor dieser Frage und haben als Antwort darauf in 2009 das Software Craftsmanship Manifest geschrieben.

11 not only responding to change but also steadily adding value not only working software but also well-crafted software not only individuals and interactions but also a community of professionals not only customer collaboration but also productive partnerships Und wenn man sich das so durchliest, muss glaube ich jeder hier im Raum mit den Kopf nicken. Natürlich wollen wir ständig "neuen Wert schaffen", und das können wir natürlich nur mit "guter Software", die natürlich von einer "Gemeinschaft von Professionals" in "produktiven Partnerschaften" entwickelt werden kann. Und in seiner ursprünglichsten Form ist genau das Software Craftsmanship. Dieses Manifest, diese Definition.

12 Wie auch beim agilen Manifest wird's erstmal nicht genauer. Soweit so gut, aber trotzdem auch alles irgendwie noch so sehr Wischiwaschi. So sehr, dass man nicht nicht zustimmen kann. Und keine Angst, das bleibt so. so kommt es dann auch, dass es sehr viele verschiedene Definitionen und Vorstellungen davon gibt, was Software Craftsmanship denn nun eigentlich ist.

13 Software Craftsmanship is a family of sets of values Ade Oshineye Eine meiner Lieblingsdefinitionen ist die von Ade Oshineye, der gesagt hat, dass Software Craftsmanship a family of sets of values ist. Also Jeder hat seine eigene Definition und diese überlappen sich mal mehr, mal weniger.

14 Pete McBreen Pete McBreen sagt z.b. in seinem schon 2001 erschienenen Buch Software Craftsmanship The New Imperative, dass Software Craftsmanship im Grunde das Gegenteil von Software Engineering ist. Software Engineering denkt, dass die Entwicklung von Software eine Ingenieurstätigkeit ist, was darauf hinausläuft, dass Software-Entwicklung bis ins kleinste plan- und vorhersehbar ähnlich wie das bauen einer Brücke von vorne bis hinten vorherzusehen ist. Und ihr würdet vermutlich nicht hier sitzen, wenn ihr diese Einschätzung teilen würdet. Software Craftsmanship laut McBreen ist: Putting People back into Software Development... was soviel heißt wie... SW Eng hat seinen Fokus darauf gelegt SW Entwicklung als quantifizierbare, wiederholbare, messbare Tätigkeit zu beschreiben und festzulegen. Personen waren nur noch Ausführer des vorab berechneten Weges. Womit wir auch schon bei der Schwachstelle von Mcbreens Arbeit sind: sie sagt größtenteils einfach nur sei nicht Software Engineering.

15 Andere schlaue Köpfe wie Robert Uncle Bob Martin, Dave Thomas & Andy Hunt, Corey Haines, Dave Hoover und & Ade Oshineye haben noch andere schlaue Sachen über Software Craftsmanship gesagt, mit denen ich euch aber jetzt nicht stressen will.

16 four pillars by Jason Gorman Vielmehr will ich nur noch eine, und aus meiner Sicht die griffigste Definition von Software Craftsmanship zeigen. Die von Jason Gorman geprägten four pillars

17 we care zwei seiten: 1) Sorgfalt beim erstellen des Produkts 2) Richtige Betreuung unserer Kunden... auf sie eingehen... versuchen sie zu verstehen

18 we care we practice practice: 1) Kenntnis unserer Tools... richtiger Umgang muss geübt werden 2) deliberate practice... außerhalb der Arbeit bzw extra dafür Platz machen... von vorgehensweisen (z.b. TDD)

19 we care we practice we learn learn: neue Herausforderungen... neue Sprachen... aber auch neue Ansätze bei schon längst bekanntem... z.b: TDD as if you meant it

20 we care we practice we learn we share share:... Open Source hat uns ja eigtl schon gezeigt, dass und sharen von wissen weiterbring... die Community ist größer als die Summer ihrer Einzelteile... unterstützt lernen & practice... löst Problem des weitergeben von tacit knowledge... mastership ist definiert durch weiterbringen der Community

21 Big Picture? Ok, jetzt nochmal einen Schritt zurück. Ein paar Meter höher fliegen. Was bisher hatten: Das Software Craftsmanship Manifest ist als Erweiterung zum agilen Manifest entstanden. Manche sagen, es ist die Fortsetzung der Werte des agilen Manifests auf das Individuum. Es gibt aber dennoch keine einheitliche Definition, was ich persönlich für sehr gut halte, aber was solche Talks wie diesen hier natürlich auch ein wenig schwieriger gestalten. Deshalb bleibt am Ende doch noch die Frage: Was heißt das nun für meinen Alltag. Für den Alltag in agilen Projekten? Sollten wir unseren Code mit dem Hammer statt der Tastatur schreiben?

22 Agile = Agile + Craftsmanship Zunächst einmal sollte man sich eingestehen, dass man nicht agil sein kann, ohne die Werte von Software Craftsmanship. Ob man das so nennt, oder nicht, ist völlig egal. Aber wenn ihr agile Software Entwicklung macht, braucht ihr Software Craftsmanship. Ihr braucht professionelle EntwicklerInnen, die wissen wie man Systeme entwirft und umsetzt die länger halten als bis zum nächsten Rewrite in 5 Jahren und deren Wartungskosten nicht ständig und immens steigern je älter sie werden. Schließlich heißt es "responding to change" ja auch "gleichbleibende Velocity"

23 Values! Und wie könnt ihr Software Craftsmanship konkret nutzen bzw es explizit zum Teil eurer Projekte und Arbeit machen? Das läuft im Grunde auf die Frage hinaus, wie ihr es schafft die Werte von Software Craftsmanship in eure Entwicklungsteams zu tragen. Und diese Herausforderung gestaltet sich ähnlich wie die Einführung der agilen Praktiken: Schwierig Wie vermittelt oder gar misst man denn, ob die Entwickler caren? Was ist denn practice? Und wie kann ich es im stressigen Alltag unterbringen?

24 One step at a time! Und wie auch bei agilen Themen, ist es am einfachsten und effektivsten klein anzufangen. Außerdem sollte man sich nach dem Erfahrungsstand und der Veränderungsbereitschaft der Teams und des Einzelnen zu richten. Einfache Ziele setzen (welche Skills/Praktiken sind wichtig?), Formate/Praktiken aussuchen und ausprobieren, die der Übung von bestimmten Skills dienen, und schauen wie das Team reagiert. Ich kann euch nur ein paar Anregungen geben, viele davon noch nichtmal besonders neuartig.

25 Dojo Coding Dojos sind ein mittlerweile sehr bekanntes und auch verbreitetes Format, um ganz bestimmte Teilbereiche und ganz bestimmte Praktiken von Programmierung zu üben. Der zentrale Gedanke hinter Dojos ist, aus dem Alltag rauszugehen, und in eine Trainingssituation zu kommen, in der fundamentale Bewegungsabläufe immer und immer wieder geübt werden. siehe Karate Kid s wax on, wax off

26 Code Review Code Reviews sind ein weiteres, leider viel zu oft ungenutztes Format. Es dient nicht dazu Wissen in und zwischen Teams zu verteilen, sondern auch Werte. Es gibt nahezu kein besseres Format, um den Anspruch an Code Qualität zu vermitteln als Code Reviews. Sie sind das optimale Mittel, richtig genutzt versteht sich, um mittels leading-byexample Erwartungen und Werte im Team kundzutun und innerhalb kürzester Zeit zu festigen.

27 Pair Programming Pair Programming... oft missverstanden... mehrere Zwecke: 1) Ähnlich wie Code Review... PP macht auch Erwartungen & Anspruch an Code Qualität explizit 2) leading by example... explizites Vorleben von gutem Verhalten... Klima im Teams 3) Training für social skills

28 great power & great responsibility Code Review & PP sind mächtige Werkzeuge... sie brauchen... Übung... Zeit... können unerwartete Ergebnisse & Herausforderungen liefern Nehmt euch die Zeit

29 Mit der Diskussion der Einführung von Software Craftsmanship Praktiken, kann man ganze Tage und Wochen verbringen, weshalb ich hier auch schon aufhören will. Ich hoffe, euch trotz meiner vielen schwammigen Nicht-Definitionen, einen Eindruck davon gegeben zu haben was Software Craftsmanship ist.

30 @softwerkskammer Bleibt noch zu sagen, dass wenn ihr mehr über Software Craftsmanship wissen wollt, ihr mich jederzeit, auch gerne außerhalb dieses Treffens ansprechen könnt. Oder besser noch, ihr kommt mal zur Softwerkskammer Rhein-Main, die sich jeden letzten Montag im Monat trifft. Einer Gruppe von erfahrenen Entwicklern und Entwicklerinnen, die sich intensiv mit allen Fragen und Themen rund um Software Craftsmanship beschäftigt.

31 Fragen? Q&A

32 References Slide 1: Slide 2: (c) Benjamin Reitzammer - Slide 4: Slide 5: Slide 6: // Hangover the movie Slide 8: (c) Slide 9: Slide 10: Slide 12: Slide 13: paul/ /sizes/l/in/photostream/ Slide 14: Slide 15: Slide 16: Slide 23: Slide 24: Slide 25: Slide 26: Slide 27: Slide 28: Slide 29: Slide 30: (c) This talk was strongly influenced by the "Agile Hangover" theme from Sandro Mancuso