Software Craftsmanship or The Agile Hangover - Donnerstag, 30. August 12
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Software Craftsmanship
or
The Agile Hangover
Donnerstag, 30. August 12
@benjamin Donnerstag, 30. August 12 Hallo mein Name ist Benjamin Reitzammer ... ihr findet mich unter @benjamin auf Twitter.
Craftsmanship Donnerstag, 30. August 12 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
party Donnerstag, 30. August 12 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"
fast Donnerstag, 30. August 12 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.
#fail Donnerstag, 30. August 12 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.
Something doesn‘t fit Donnerstag, 30. August 12 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.
Individuals and interactions
over processes and tools
Working software
over comprehensive documentation
Customer collaboration
over contract negotiation
Responding to change
over following a plan
Donnerstag, 30. August 12
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".
Software is the epicenter Donnerstag, 30. August 12 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.
patchwork & debt Donnerstag, 30. August 12 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.
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
Donnerstag, 30. August 12
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.Donnerstag, 30. August 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.
„Software Craftsmanship is a
family of sets of values“
Ade Oshineye
Donnerstag, 30. August 12
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.Pete McBreen Donnerstag, 30. August 12 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.
Donnerstag, 30. August 12 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.
four pillars
by Jason Gorman
Donnerstag, 30. August 12
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’we care Donnerstag, 30. August 12 zwei seiten: 1) Sorgfalt beim erstellen des Produkts 2) Richtige Betreuung unserer Kunden ... auf sie eingehen ... versuchen sie zu verstehen
we care
we practice
Donnerstag, 30. August 12
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)we care
we practice
we learn
Donnerstag, 30. August 12
learn:
neue Herausforderungen ... neue Sprachen
... aber auch neue Ansätze bei schon längst bekanntem ... z.B: TDD as if you meant itwe care
we practice
we learn
we share
Donnerstag, 30. August 12
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“Big Picture? Donnerstag, 30. August 12 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?
Agile
=
Agile + Craftsmanship
Donnerstag, 30. August 12
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"Values! Donnerstag, 30. August 12 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?
One step at a time! Donnerstag, 30. August 12 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.
Dojo Donnerstag, 30. August 12 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“
Code Review Donnerstag, 30. August 12 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-by- example Erwartungen und Werte im Team kundzutun und innerhalb kürzester Zeit zu festigen.
Pair
Programming
Donnerstag, 30. August 12
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 skillsgreat power &
great responsibility
Donnerstag, 30. August 12
Code Review & PP sind mächtige Werkzeuge ... sie brauchen
... Übung
... Zeit
... können unerwartete Ergebnisse & Herausforderungen liefern
Nehmt euch die ZeitDonnerstag, 30. August 12 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.
@softwerkskammer
www.softwerkskammer.de
Donnerstag, 30. August 12
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.Q&A Donnerstag, 30. August 12 Fragen?
References
Slide 1: http://jayperoni.com/wp-content/uploads/2010/04/blacksmith.jpg
Slide 2: (c) Benjamin Reitzammer - http://ambestengestern.de
Slide 4: http://www.flickr.com/photos/garryknight/2585477360/sizes/l/in/photostream/
Slide 5: http://www.flickr.com/photos/vestman/3210770788/sizes/l/in/photostream/
Slide 6: http://jamesriverfilm.files.wordpress.com/2010/11/the_hangover1.jpg // „Hangover“ the movie
Slide 8: (c) http://agilemanifesto.org/
Slide 9: http://www.flickr.com/photos/pdenker/6001236724/sizes/l/in/photostream/
Slide 10: http://www.flickr.com/photos/library_of_congress/2178266265/sizes/o/in/photostream/
Slide 12: http://www.flickr.com/photos/macwagen/445096625/sizes/o/
Slide 13: http://www.flickr.com/photos/hey__paul/5935779408/sizes/l/in/photostream/
Slide 14: http://www.mcbreen.ab.ca/
Slide 15:
http://wapedia.mobi/thumb/82ed508/en/fixed/470/313/Dave_Thomas_speaking_at_the_Pasadena_Rails_Studio.jpg
http://en.wikipedia.org/wiki/File:Andy_Hunt_programmer.jpg
http://www.butunclebob.com/files/images/BobAtRails.jpg
http://www.flickr.com/photos/adewale_oshineye/5191953188/sizes/l/in/photostream/
https://twimg0-a.akamaihd.net/profile_images/1095172835/Dave_-_Cropped_-_Square.jpg
http://blog.adsdevshop.com/wp-content/uploads/2010/08/3856480371_6772dbb3b7_o.jpg
Slide 16: http://www.flickr.com/photos/65105715@N02/6913333017/sizes/l/in/photostream/
Slide 23: http://www.flickr.com/photos/wwworks/1384952210/sizes/o/
Slide 24: http://www.flickr.com/photos/joeflood/3127703805/sizes/o/
Slide 25: http://www.flickr.com/photos/15216811@N06/5576722335/sizes/l/in/photostream/
Slide 26: http://www.flickr.com/photos/fraserspeirs/3394902061/sizes/l/in/photostream/
Slide 27: http://www.flickr.com/photos/damienpollet/5048830734/sizes/l/in/photostream/
Slide 28: http://www.flickr.com/photos/b-crowe/7015246943/sizes/l/in/photostream/
Slide 29: http://j1mbo.de/wp-content/uploads/bla_bla_bla.jpg
Slide 30: (c) http://www.softwerkskammer.de
Donnerstag, 30. August 12
This talk was strongly influenced by the "Agile Hangover" theme from Sandro MancusoSie können auch lesen
