Vom 22. bis zum 26. Juni finden in Karlsruhe die Karlsruher Entwicklertage statt, zu denen ich mit zwei Vorträgen und einem Worshop beitrage:
Nachdem ein größeres Projekt kurzfristig verschoben werden musste, habe ich derzeit Kapazitäten frei für Coaching, Beratung, Retrospektiven und Schulungen rund um agile Entwicklung, Scrum und Crystal. Sprechen Sie mich an.
Wenn agile Planung richtig durchgeführt wird, leistet sie einen wichtigen Beitrag, das Projekt zum Erfolg zu führen. Dabei ist Erfolg nicht als Einhaltung von Zeit, Umfang, Budget und Qualität definiert, sondern als Beitrag zur Maximierung des Geschäftsnutzens der Software. Das bedeutet, dass agile Planung sowohl die Effektivität der Softwareentwicklung fördern sollte, als auch deren Effizienz und zwar in dieser Reihenfolge.
Zur Förderung der Effektivität werden mehrere Teilziele verfolgt:
Weitere Teilziele sollen die Effizienz der Entwicklungsarbeit optimieren:
Interessant sind aber auch Ziele, die oft mit Plänen verbunden werden, die aber von agilen Planungsverfahren explizit nicht verfolgt werden:
Agile Planung ist damit ein wichtiges Instrument für das Team und das Management, die Wertschöpfung eines Projekts nicht so sehr trotz, sondern mit Hilfe vieler Änderungen zu optimieren. Wie Jim Highsmith schreibt: Agile Projektmanager kümmern sich bevorzugt um Wertschöpfung, Teams und Anpassbarkeit. Diese sind für ein erfolgreiches Projekt wichtiger, als die Beschränkungen durch Zeit, Kosten und Anforderungen (Cutter Agile E-Mail Advisor am 13.11.2008, Cutter Consortium).
Es ist zwar noch ein wenig hin bis Weihnachten, aber trotzdem lohnt es sich, auf Obie Fernandez‘ Blog „Explain Variable Scope with Ponies“ zu schauen: Er vergleicht in einer netten Analogie die Preisfindung in einem agilen Projekt mit den Weihnachtseinkäufen von Eltern. Einziger Haken an der Analogie: In agilen Projekten stellt der Kunde die Wunschliste auf und ist an der Auswahl der konkreten „Geschenke“ (=Features) beteiligt, was Kindern sicherlich einen erheblichen Teil des Spaßes an Weihnachten rauben würde.
Das Agile Manifest war der Startschuss, Agilität als Konzept auszurollen und es hat noch immer Gültigkeit. Ein paar Leute um das Unternehmen 8th Light haben sich die Mühe gemacht, etwas weiter zu gehen und das „Manifesto for Software-Craftsmenship“ verfasst, das aber mittlerweile so viele Unterzeichner hat, dass es getrost als „werbefrei“ gelten kann:
As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:
Not only working software,
but also well-crafted softwareNot only responding to change,
but also steadily adding valueNot only individuals and interactions,
but also a community of professionalsNot only customer collaboration,
but also productive partnershipsThat is, in pursuit of the items on the left we have found the items on the right to be indispensable.
© 2009, the undersigned. this statement may be freely copied in any form, but only in its entirety through this notice.
Wer es selbst unterschreiben möchte, kann das auf dem Originallink tun: http://http://manifesto.softwarecraftsmanship.org/
Am 23. und 24. März gebe ich in München wieder das Intensivseminar „Refactoring in der Praxis oder die Kunst schmerzfreier Änderungen“ in Zusammenarbeit mit SIGS DATACOM. Der Kurs bietet die Möglichkeit, Refaktorisieren am praktischen Beispiel zu erlernen und zu vertiefen bis hin zur emergenten Entwicklung einer kleinen Architektur.
Es sind noch Plätze frei, weitere Informationen und Anmeldemöglichkeiten finden Sie hier.
Martining & Associates hat eine lange Liste von Blogs zu agiler Entwicklung zusammen getragen, die man unter http://www.agilevoices.com/aggregator/sources findet. Nicht alle Quellen sind wirklich gut und die Sammlung beschränkt sich auch auf englisch-sprachige Blogs, aber für einen Überblick finde ich die Liste hervorragend.
Ich wurde kürzlich von Peter Stevens auf der Deutschen Scrum Liste gefragt, wo man Crystal in zehn Minuten nachlesen könne. Ich denke, meine Antwort ist auch für Nicht-Scrummer interessant, deshalb hier noch mal in „voller Schönheit“ mit ein paar zusätzlichen Links.
Gibt es irgendwo ein „Crystal in 10 Minuten“? – Ein google dafür hat nichts nützliches produziert…
Starte vielleicht mal mit http://alistair.cockburn.us/Crystal+light+methods, das dürfte ca. 10 Minuten dauern.
> Oder was ist besonders an Crystal?
Der Kern in drei Sätzen:
Das ist sozusagen erstmal die Essenz agilen Arbeitens.
Basis sind Alistair Cockburns Überlegungen zur Software Entwicklung als kooperativem Spiel, sowie seine „Feldforschungen“ seit den frühen Neunziger Jahren.
Um das zu unterstützen bietet Crystal sehr viele Praktiken, die sich je nach Kontext einsetzen lassen. Allerdings nicht wie Scrum oder XP (1.0) mit dem Hinweis „So muss man es machen“, sondern mit einem „in dieser Situation haben Teams gute Erfahrung gemacht, jenes zu machen mit folgenden Konsequenzen“. Meines Wissens lassen sich sowohl alle Scrum Praktiken als auch alle XP Praktiken mit Crystal abdecken.
Crystal ist damit viel näher an einer Patternsammlung, als an einem Prozess. Deshalb redet Alistair auch von einer „Methodenfamilie“, bei denen die Methoden nach Kritikalität und Teamgröße zusammen gesetzt werden mit dem Ziel, die „Gerade noch ausreichende Methode“ zu finden. „Crystal Clear“ ist zum Beispiel für Teams bis zu 10 Personen in Projekten, bei denen es nicht um Menschenleben geht. Er deklariert Crystal auch ganz klar als Hilfe für Fortgeschrittene und nicht als Anfängermethode (siehe dazu auch http://alistair.cockburn.us/Shu+Ha+Ri). Sein Ziel ist also nicht unbedingt Minimalismus in der Beschreibung, wie es von Scrum und XP verfolgt wird, sondern Minimalismus im Einsatz.
Crystal bildet damit die Brücke zwischen den agilen „Meta-Methoden“ wie ASD (Jim Highsmith) und Lean Software Development (Mary und Tom Poppendieck) und den eher prozessartig gestalteten Verfahren wie XP und Scrum. Es ist ein Baukasten aus Praktiken mit Regeln, wie sie zusammen gesetzt werden.
Neben Alistair Cockburns Webseite gibt es zwei Bücher von ihm zu dem Thema:
Das Zertifizierungsverfahren ist noch lange nicht so ausgefeilt, wie bei Scrum, es gibt aber immerhin eine handvoll „Certified Crystal Practitioners“, die zu der Ehre gekommen sind, weil Alistair ihre Arbeit gesehen und für gut befunden hat.
Krishan Mathis fasst in seinem Beitrag „Scrum and the German V-Model XT“ das Ergebnis einer Diskussion auf dem letzten Agile Tuesday in München zusammen. Der Beitrag enthält eine sehr lesenswerte Kurzfassung des V-Modell XT und geht auch auf die „Agile Durchführungsstrategie“ ein: „There is very little overlap between this ‚agile‘ model and how Scrum structures activities“. Die Aussage lässt sich durchaus auf die meisten agilen Verfahren übertragen.
Krishan kommt zu dem Schluss, dass man den Product Owner als „Schnittstelle“ zwischen den Welten „missbrauchen“ kann, aber nicht ohne eine Warnung: „It puts however a high degree of tension on the product owner and an associated risk of project failure.“
Ich denke, für alle agilen Verfahren ist die „mechanische“ Kopplung beider Welten über eine „Schnittstelle“ eine mögliche Lösung, nicht nur für Scrum. Man sollte sich dabei aber auch darüber im klaren sein, dass man sich damit auf sehr dünnes Eis begibt. Wird vom Auftraggeber das V-Modell XT verlangt, hat das normalerweise einen von zwei Gründen:
In beiden Fällen ist der Schluss naheliegend, dass die interne Kultur des Auftraggebers so gestaltet ist, dass Mechanismen und Ideen des V-Modell XT zur Kultur passen. So kann zum Beispiel die Einhaltung von Vorschriften und unveränderten Verträgen wichtiger sein, als ein schneller RoI, selbst wenn sich das als projektgefährdend herausstellen sollte. Auch kann die Bereitschaft, individuell Verantwortung zu übernehmen, deutlich geringer sein, als zum Beispiel bei einem Startup.
Ist das der Fall, ist die Wahrscheinlichkeit hoch, dass weder Auftraggeber noch Auftragnehmer glücklich werden mit agilen Ansätzen. Der Wunsch, hinter einer V-Modell-Fassade agil zu arbeiten, sollte meines Erachtens also vom Auftraggeber ausgehen, und dieser sollte auch in der Lage sein, die notwendigen Entscheidungen zeitnah zu treffen — und später auch die Verantwortung dafür zu übernehmen. Zudem sollte man sorgfältig abgewogen haben, ob die Fassade wirklich sein muss, oder ein offener Ansatz möglich ist und man sollte sich ggf. auch mit Hilfe eines Spezialisten für Ausschreibungsrecht absichern und mit der zuständigen Innenrevision gesprochen haben.
Das klingt jetzt zwar alles wenig agil, aber man sollte sich auch im Klaren sein, dass die freundliche Gruppenleiterin, mit der man gerade verhandelt, wenig zu melden hat, wenn sich die Herrschaften des Rechnungshofes ankündigen. In diesem Sinne muss man sich nicht nur prozesstechnisch anpassen, sondern eben auch kulturell.
Aber um auch mal etwas positives zu sagen: Verglichen mit dem V-Modell 92 und 97 ist das V-Modell XT bereits ein riesiger Schritt in die richtige Richtung und hat bereits so manche Kritik an den alten Modellen aufgegriffen. Ich glaube, dass sich die Lücke in den nächsten Jahren weiter schließen wird, nachdem die Diskussion, ob agile Entwicklung überhaupt „echtes Software-Engineering“ sei zugunsten der agilen Verfahren ausgestanden sein dürfte.
Das von mir 2007 herausgegebene Heft des Cutter IT Journal mit dem Titel „Exploring the Agile Frontier“ ist derzeit im Zuge einer Marketinginitiative von Cutter kostenlos erhältlich, statt des üblichen Preises von ca. $40.00. Das Heft sammelt Analysen und Projektberichte aus Bereichen, die üblicherweise als „wenig geeignet“ für agile Verfahren gelten. Es enthält unter anderem:
Sie finden das Heft, auf der Cutter Homepage unter „Sample Our Research“ oder direkt hier.