Search results matching tag 'Software Craftsmanship'

Das Agile Development Framework

Jürgen Gutsch — Mon, 14 Feb 2011 06:41:00 GMT

Noch vor ein paar Monaten hatte ich mit eine Art umfassendes Handbuch für Software-Handwerker gewünscht (Siehe: Gedankenspiel: Software-Entwicklung als Handwerkskunst) und wieder sind wir diesem Handbuch ein Stück näher gekommen. Nicht mehr lang und jeder Software-Handwerker greift sich an den Allerwertesten, zückt sein Handbuch und fragt es um Rat. Ganz egal um was für ein Problem es sich gerade handelt.

Mit dem Agile Development Framework (ADF) fasst Golo Roden die Vorteile der unterschiedlichen Agilen Methoden und Ansätze zusammen zu einem gesamten Framework, dass alle Situationen abdecken kann.

Wenn man die Dokumentation zu ADF liest, fallen einem gleich die alten Bekannten aus Scrum, Extreme Programming, Kanban und der Crystal Family auf, die hier teilweise mit neuen Bezeichnungen und in leicht abgewandelter Form erscheinen. Die neu gewählten Bezeichnungen führen zu einem klaren Schnitt zwischen den bekannten Methoden und ADF.

Die Integration der Prinzipien und Praktiken der Clean-Code-Developer Initiative und der klare Verweis auf CCD runden alles ab. Es ist also nicht nur ein einfaches leeres Rahmenwerk entstanden, sondern ein Rahmenwerk mit konkreten Ideen und Vorstellungen zur Umsetzung von Code, zur Entstehung von Software und zur Weiterentwicklung der Individuen.

Golo Roden über ADF:
„Das Agile Development Framework (ADF) ist eine mehrstufige, den gesamten Entwicklungsprozess und alle beteiligten Rollen umfassende Stream-basierte agile Methode für vereinte, verstreute und verteilte Teams zur flexiblen, konstruktiven und evolutionären Entwicklung qualitativ hochwertiger Software.”

Die Beschreibung verspricht viel. Zu viel?

Nein, auf keinen Fall. Wer schon mal versucht hat eine agile Methode in einem Unternehmen einzuführen, das eigentlich kein Unternehmen ist, welches von Haus aus Software entwickelt, stößt früher oder später an Grenzen. Auch wenn die agile Methode zuerst mit Begeisterung aufgenommen und umgesetzt wird, sind diese Grenzen da und sorgen für Verwirrung und Unmut. “Agile Ja, aber ohne uns anzupassen” ist das was man zwischen den Zeilen heraushört. “Die Agile Methode behindert uns bei unserer bisherigen Art zu arbeiten.” Immer öfter werden die neu eingeführten Prozesse gestört, ignoriert und durchbrochen.

Golo verspricht viel, aber er verspricht auch eine flexible Methode die kontinuierlich eingeführt werden kann und nicht gleich im gesamten Unternehmen eingeführt werden muss, sondern die Einführung beginnt kontinuierlich bei den Individuen (“ADF White”). Sind die einzelnen Entwickler soweit, dass sie ADF leben und umsetzen kann das gesamte Team nach ADF arbeiten (“ADF Blue”). Macht letztendlich das gesamte Unternehmen mit, so haben wir “ADF Grey” erreicht:

Im Falles des obigen Unternehmens ist es eine agile Methode ohne iterative Softwareauslieferung, ohne Wartezeit, ohne das der Scrum-Master die Ausführung der Kundenprojekte behindert. Das bedeutet, für das Unternehmen ändert sich erst mal groß nichts, sondern nur für das Team und dessen Mitglieder. Die Änderungen für das Unternehmen sind erst mal Minimal. Wie früher zu Chaoszeiten, kann das Unternehmen nun wieder jederzeit eine Software ausliefern. Der kleine feine Unterschied ist, dass diese Software qualitativ hochwertiger ist als zuvor. Das Team ist ein anderes, es arbeitet anders und es ist wie ausgetauscht.

Im folgenden die Vorteile von ADF:

1 Multifunktionales Werkzeug
Das Agile Development Framework ist das Schweizer Messer unter den agilen Methoden: Da ADF den gesamten Entwicklungsprozess und alle beteiligten Rollen umfasst, werden Reibungsverluste und Aufwände vermieden – die in der Regel durch die Kombination verschiedener agiler Methoden verursacht werden.

2 Flexible und zeitnahe Entwicklung
Als Stream-basierte agile Methode ermöglicht das Agile Development Framework flexible und zeitnahe Reaktionen auf intrinsische und extrinsische Faktoren – wie den Kontext durch sich verändernde Rahmenbedingungen, den Kunden durch neue und veränderte Anforderungen und das Team durch neue Technologien und Konzepte.

3 Kosten senken und Effizienz steigern
Der Einsatz des Agile Development Frameworks führt zu qualitativ hochwertigerer Software bei gleichzeitiger Reduktion des dafür benötigten Aufwands – die Maximen Evolution, Eleganz, Kommunikation und Vertrauen führen zu Synergieeffekten, geringeren Kosten und gesteigerter Effizienz innerhalb von Teams und des ganzen Unternehmens.

4 Qualitativ hochwertige Software
Das Agile Development Framework fördert minimalistisches, klares und zielführendes Design – auf diese Art entstehen qualitativ hochwertige und elegante Lösungen, die zwar einfach, aber zugleich auch konsistent, tragfähig und für die Zukunft evolvierbar sind.

5 Bewährte Vorgehensweisen
In der Praxis bewährte Vorgehensweisen bilden die Basis des Agile Development Frameworks – auf diese Art werden etablierte und bereits erprobte Methoden mit neuen Ansätzen zu einem leistungsfähigen Ganzen kombiniert.

6 Fokus auf Ergebnisse
Im Rahmen des Agile Development Frameworks zählt das Ergebnis, nicht der Weg dorthin – es fokussiert also auf die gleichen Werte und Ziele wie der Kunde. Die Konzepte, Richtlinien und der Prozess von ADF tragen daher ihren Teil dazu bei, die gemeinsam gesetzten Ziele effizient und für alle beteiligten Rollen zufriedenstellend zu erreichen.

7 Freiraum zum Lernen und Wachsen
Individuen, Teams und Unternehmen müssen sich weiterentwickeln können – ebenso wie Ideen, der Kunde und der Kontext eines Projekts. Deshalb schafft das Agile Development Framework Freiräume zum Lernen und Wachsen und berücksichtigt die individuellen Anforderungen der einzelnen Rollen.

8 Leicht einzuführen
Das Agile Development Framework kann von Individuen, Teams und Unternehmen Schritt für Schritt eingeführt werden – dies vereinfacht die Einführung, da Aufwände und Risiken minimiert werden. Zudem kann ADF damit den individuellen Bedürfnissen angepasst werden, da eine Einführung zunächst in strategisch ausgewählten Bereichen stattfinden kann.

9 Konstruktives und zukunftsgerichtetes Vorgehen
Evolution ist die Voraussetzung, sich zeitnah an einen sich beständig verändernden Kontext optimal anzupassen. Daher verfolgt das Agile Development Framework ein konstruktives und zukunftsgerichtetes Vorgehen – allerdings nicht unreflektiert, sondern unterstützt dies durch regelmäßige Retrospektiven und aktive Reflektion.

10 Technologieneutral
Das Agile Development Framework ist unabhängig von der Wahl einer Technologie oder eines Herstellers – das bedeutet, dass Individuen, Teams und Unternehmen ADF unabhängig davon nutzen können, welche Technologie im konkreten Fall verwendet wird.

Ich bin überzeugt. dass wir mit ADF ein weiteres Werkzeug in der Hand halten, dass uns hilft dort einzugreifen, wo herkömmliche agile Methoden (“herkömmlich agil” ist IMO heute kein Paradoxon mehr *fg*) nicht greifen können oder wollen. Die Hemmschwelle in Unternehmen dürfte durch die kontinuierliche Einführung wesentlich geringer sein. Eine Einführung bis “ADF Blue” hat nur so geringe Auswirkungen auf das Unternehmen, dass dieses bei den genannten Vorteilen eigentlich keine andere Wahl hat. Eine Einführung bis “ADF White” bekommt das Unternehmen gar nicht erst zu spüren, wie auch TDD ist das eine Arbeitsweise, eine Einstellung eines einzelnen Entwicklers, dem keiner zu widersprechen hat solange das Ergebnis stimmt.

Mit ADF bin ich nun meinem universellen Software-Handwerker-Handbuch ein großes Stückchen näher :-)

Übrigens ist in der aktuellen dotnetpro (Ausgabe 03.2011, die heute am Kiosk erscheint) ein Überblick über ADF enthalten.

Gedankenspiel: Softwareentwicklung als Handwerkskunst

Jürgen Gutsch — Fri, 24 Sep 2010 13:57:29 GMT

Ob das folgende Gedankenspiel der Software-Craftsmanship-Bewegung entspricht weis ich nicht, damit habe ich mich nicht wirklich ausführlich beschäftigt. Im Gegenteil empfinde ich die Bewegung vorerst – mit ihrem Manifesto und dem ganzen Drumherum – als etwas zu extrem.

Aber ich fand alleine schon die Idee, Softwareentwicklung als Handwerkskunst zu sehen, nicht nur interessant, sonder sehe auch parallelen zu meinem Werdegang und zur Softwareentwicklung allgemein. Man muss nicht viel nachdenken um Parallelen zu entdecken.

Ich selber…

… hatte die große Ehre, bei der Firma K&K Internet GmbH in Radolfzell-Böhringen meine Ausbildung zum Fachinformatiker für Softwareanwendungsentwicklung zu machen und das Softwarehandwerk zu erlernen. Mein Gesellenstück, ein Dokumenten Management System für das CMS add.min, war damals der Höhepunkt, auf das ich auch heute noch mit Stolz zurückblicken kann. Seit dem Ende der Ausbildung 2004 konnte ich als Geselle meine Techniken verfeinern und mein Wissen vergrößern und kann jetzt – ebenfalls mit Stolz – auf eine sechsjährige Karriere als Geselle zurückblicken.

(Klingt ein wenig hochtrabend, gell? Ist aber nun mal eine Kurzfassung meiner Sicht auf die vergangenen Jahre als Softwarehandwerker.)

Und weitere Parallelen?

Außer meiner Laufbahn als Softwarehandwerker, gibt es natürlich eine ganze Reihe weiterer Parallelen, von denen ich hier die offensichtlichen mal kurz anreiße. Zum einen tue ich das um eine Diskussionsgrundlage zu schaffen, zum anderen um einen Denkanstoß zu geben und die Dinge mal von einer anderen Seite aus zu betrachten aber eigentlich schreibe ich das nur um das mal geschrieben zu haben, bevor ich den ganzen Kram nicht mehr in Worte fassen kann oder wieder vergesse. ;-)

Parallele: Werkzeuge

Für einen Schreiner ist es enorm wichtig seine Werkzeuge zu beherrschen: Nur wenn er die Hobelmaschine bedienen kann schafft er es eine gerade Tischoberfläche hinzubekommen.

Für einen Schreiner ist es wichtig, die neuesten Werkzeuge zu nutzen: Ein Hobel ist gut, aber eine Hobelmaschine ist genauer und schneller. Feile und ein Stechbeitel können eventuell das selbe wie eine Fräse, aber um einiges langsamer und ungenauer.

Die IDE und die Programmiersprache sind die wichtigsten Werkzeuge für einen Softwareentwickler. Diese sollte er bestens beherrschen können um Hochwertige Software zu entwickeln. Im Beitrag Gemeine Kenntnislücken beschreibt Ralf Westphal wieso man auf dem neuesten Stand bleiben und im Beitrag Lesen heute für Softwareentwickler wie man dazu kommt.

Auch die weiteren Werkzeuge und Hilfsmittel sind wichtig. Auf der Keynote der See# Party beschrieb Golo Roden, das man dafür sorgen muss die besten Werkzeuge zu nutzen die man für Geld kaufen kann. Und vor allem sollte man nicht nur bekannte Werkzeuge verwenden, sondern auch mal schauen was sich woanders bewährt hat.

Parallele: Prinzipien und Praktiken

Auch der Handwerker lernt Prinzipien, die ihm gewisse Handgriffe erleichtern und auch Praktiken die ihm sagen, wie man das Werkstück bearbeiten sollte. Der Handwerker hat seine Handbuch, seine Fibel in der Vorgehensweisen und bestimmte Konstanten beschrieben sind.

In der Softwareentwicklung haben Ralf Westphal und Stefan Lieser Prinzipien und Praktiken auf der clean-code-developer.de zusammengetragen. Dieses Werk ist ein wichtiger Schritt. Es bleibt jedem selber überlassen, wie er diese Prinzipien und Praktiken anwendet. Wichtig ist nur, dass sie überhaupt beachtet und angewendet werde.
Aber das alleine reicht noch nicht. Was in der Softwareentwicklung fehlt ist ein umfassendes kleines Handbuch, dass sowohl Prinzipien und Praktiken beinhaltet, als auch allgemeine Techniken und Design Patterns. Ein Buch das in jeder Gesäßtasche eines Softwarehandwerkers stecken sollte.

Parallele: Qualitätsdenken

In der Regel gibt ein Handwerker sein Produkt erst raus, wenn es seinen Qualitätsansprüchen genügt. Bei einem Tisch ist es nicht anders möglich, es ist etwas greifbares, das der Kunde berühren kann. Mängel sind sichtbar. Anders leider bei Software. Welcher Softwareentwickler kann – ganz ehrlich - von sich behaupten eine 100% hochqualitative Software an den Kunden herausgegeben zu haben? Damit meine ich nicht nur Qualität im Code, sondern auch bei der Usability.

Aber es geht auch anders:
In der letzten Ausgabe des .NET-Magazins habe ich ausführlich ein Buch vorgestellt, dass ich auch schon hier im Blog erwähnt habe: Why Software Sucks… ist ein Buch von David S. Platt das dem Softwareentwickler und dem Softwareanwender eine andere andere Sichtweise nahe bringt und auf diese Art Mängel in der Software sichtbar macht. Keiner sagt einem auf eine so ehrlich brutale Art was man die letzten Jahre falsch gemacht hat.
Zumindest offensichtliche Mängel können so schnell gefunden und beseitigt werden.

Parallele: Stolz

Die letzte Parallelität ist die Eigenschaft, auf die in der Softwareentwicklung – aus meiner Sicht – am wenigsten Wert gelegt wird. Die fast am unwichtigsten scheint. Aber die größten Probleme bereiten könnte. Was passiert mit einem, wenn man ständig ein Produkt rausgeben muss, auf das man nicht Stolz sein kann? Man verliert den Spaß an der Arbeit und den Spaß daran sich weiter zu entwickeln.

Ich weiß aus meinen kurzen Erfahrungen in der (richtigen) Handwerksarbeit (Schreiner, Gärtner und Kunststoffschlosser) das es ein unglaublich tolles Gefühl ist, seine hochwertige, fertige Arbeit in den Händen des zufriedenen Kunden zu sehen. Andersherum habe ich als Softwareentwickler zur Genüge die Erfahrung gemacht, aus Zeitdruck und Druck von oben, eine schnell zusammengebastelte Anwendung an einen zufriedenen Kunden herauszugeben und zu wissen, dass die Zufriedenheit nicht von langer Dauer ist. Der Job als Gärtner macht so – ehrlich gesagt – mehr Spaß.

Aber auch der Softwareentwickler sollte Stolz auf seine Arbeit sein können. Das geht natürlich nur, wenn die ersten drei parallelen Eigenschaften auch umgesetzt werden. Erst wenn die Werkzeuge stimmen, bestimmte Werte eingehalten werden und ein Qualitätsbewusstsein existiert, kann man eine Software bauen auf die man Stolz sein kann.

Fazit

Frage: Ist es wichtig, dass sich Softwareentwickler als Handwerker sehen?
Antwort: Nein, ich denke nicht!

Es wäre eventuell hilfreich, um auf die richtigen Werkzeuge und den Umgang damit zu beachten. Es wäre Hilfreich, um Prinzipien und Praktiken ernst zu nehmen. Es wäre eventuell Hilfreich, um ein Qualitätsdenken zu entwickeln, um dann mit Stolz auf seine Arbeit schauen zu können.

Aber letzten Endes ist es völlig egal, ob man sich als Handwerker, Architekt oder Pfarrer sieht. (Nur als Fließbandarbeiter sollte man sich nicht sehen *g*) Wichtig ist, dass man bestimmt Werte entwickelt und diese Konsequent umsetzt. Wichtig ist, dass man am Ende des Tages auf seine Arbeit stolz sein kann, dass mal alles dafür getan hat um eine höchstmögliche Qualität zu erreichen.