Agile 2008 - Ideen und Inspiration

Agile 2008 ist eine internationale Konferenz in Toronto über agile Softwareentwicklung. Sie findet vom 4. bis 8. August statt. Mit 1600 Teilnehmern aus der ganzen Welt erfreut sie sich zunehmender Beliebtheit. Natürlich kommen die meisten Teilnehmer aus den USA und Kanada.Ich habe an dieser Konferenz teilgenommen und zusammen mit Olav Maassen einen Vortrag gehalten. Ich möchte einige der inspirierenden Ideen und 'Vibes' teilen, die ich auf der Konferenz aufgeschnappt habe.

Weiter zu etwas

Eine ganze Woche lang unter Agile-Leuten zu sein, hat mir ein sehr reichhaltiges und inspirierendes Gefühl dafür gegeben, was in der Softwarebranche vor sich geht. Die Agile Alliance glänzt in diesem Jahr wirklich, weil die Konferenz viele verschiedene Menschen und Ideen beherbergte, von denen einige für Agile werben, während andere auf die Mängel von Agile hinwiesen und einige Sitzungen sogar nichts mit Agile zu tun hatten, aber dennoch mit großartigen Ideen gefüllt waren. Ich glaube, ich habe ein paar inspirierende Ideen mitgenommen, die ich weiter erforschen möchte.Was mich am meisten beeindruckt hat, ist die "Stimmung" darüber, wo die Softwareentwicklung in den nächsten Jahren große Verbesserungen erfahren wird. Zufälligerweise enthielt meine eigene Präsentation ähnliche Punkte wie die, die ich in anderen Präsentationen aufgegriffen habe. Ich war definitiv auf der richtigen Spur.Abgesehen von einigen speziellen Sitzungen, die ich in späteren Blogs beschreiben werde, gibt es zwei Hauptthemen, die ich auf dieser Konferenz aufgeschnappt habe, die vielleicht nicht offensichtlich sind. Das eine Thema nenne ich gerne Agile+ und das andere lässt sich am besten als Iteration-1 zusammenfassen

Agil+

Agile+ ist für mich alles, was ich auf der Konferenz gehört habe, was versucht, die agile Entwicklung über die aktuellen Prinzipien und Praktiken hinaus zu verbessern. Einige Ideen waren Verfeinerungen der agilen Praktiken, während andere die Softwareentwicklung erweitern und das agile Fundament ergänzen. Die Prinzipien der Theorie der Beschränkungen geben einem agilen Team eine neue Sichtweise auf seinen Prozess und mögliche Verbesserungen. Ein Manko von Scrum und XP ist, dass es für das Team keine Beschränkungen gibt, um seinen Work-in-Process zu erhöhen. Der Einsatz der Lean Kanban-Technik, um die Durchlaufzeit zu verkürzen und Engpässe aufzudecken, macht den selbstorganisierenden Aspekt von Agile zu einer viel disziplinierteren und fruchtbareren Angelegenheit. Eine offensichtliche Praxis, die erwähnt wurde, ist die sofortige Behebung von Fehlern. Lassen Sie nicht zu, dass der Tester einen Fehler meldet und dann 2 Tage wartet, um ihn zu beheben, sondern lassen Sie die Funktion so lange im 'Test', bis alle Fehler tatsächlich behoben sind, um den WIP niedrig zu halten. Dies fügt sich in ein größeres Thema der Anwendung von Lean und TOC auf die Softwareentwicklung ein, um Agile mit mehr Disziplin und Einsichten zu erweitern. Das Kanban-System ist eine sehr konkrete Umsetzung dieser Idee. David Anderson hat ein überzeugendes Argument für Kanban geliefert. Als Early Adopter würde ich gerne einige Whitepapers und Handgriffe zur Einführung von Kanban in agilen Projekten sehen. Der auffälligste Unterschied zu klassischem Agile ist der Verzicht auf Iterationen und Planungssitzungen.

Iteration -1

Scott Ambler machte die etwas zynische Bemerkung, dass es in vielen Vorträgen auf der Agile2008 darum geht, was wir in agilen Projekten tun sollten (z.B. automatisierte Akzeptanztests, Pair Programming usw.), dass aber die tatsächliche Erfahrung zeigt, dass einige Praktiken tatsächlich nicht sehr beliebt sind, obwohl sie als Diskussionsthema sehr beliebt sind (z.B. automatisierte Akzeptanztests). Agile+ wird mehr Forschung und reale Geschichten darüber bringen, was in Projekten wirklich vor sich geht, damit wir die Realität und nicht eine idealisierte Version der Realität diskutieren können. Jetzt, wo Agile im Mainstream angekommen ist, brauchen wir mehr Fakten und Zahlen, um die Akzeptanz zu erhöhen, als die anekdotischen und inspirierenden Geschichten, die wir in der Vergangenheit verwendet haben. Die Iteration-1 kam ein paar Mal zur Sprache, auch auf anderen Konferenzen. Scott Ambler erwähnte sie ausdrücklich, aber auch David Thomas, Allen Cooper und Jeff Patton haben eine Vorstellung davon. Im Kern geht es dabei um die 'möglicherweise umstrittene' Idee, Software nicht gleich in der ersten Iteration zu entwickeln. Leute wie Scott protestieren gegen die Vorstellung, dass Sie in der allerersten Iteration des Projekts mit der Codierung beginnen sollten (wie es XP und Scrum zu fördern scheinen). Jeff Sutherland würde in dieser Situation vielleicht sagen: "Ich bin mir nicht sicher, auf welchem agilen Planeten sie sich befinden...", aber ich habe den Druck bei agilen Projekten erlebt, die IDE anzuwerfen und von Anfang an mit der Codierung zu beginnen. Einige Leute behaupten, dass Sie bestimmte Schritte oder Phasen einhalten müssen, bevor Sie "potenziell lieferbare Produkte" erstellen. Was Sie nun genau tun sollten, variiert von der Modellierung bis zum Design, der Architektur, dem Interaktionsdesign oder dem Bau von Wegwerf-Software. Fast alle sind sich einig, dass Sie nicht die richtige Lösung entwickeln können, bevor Sie das gesamte Problem oder den Umfang des Projekts gesehen haben. Dieses inhärente Problem kann dazu führen, dass Sie sehr wenig Zeit auf Design oder Architektur verwenden, weil Sie nicht wissen, was die beste Lösung sein wird, bevor Sie fertig sind. Hier könnte Agile mit seinem Fokus auf Software und Feedback über das Ziel hinausschießen. Sie können dies intelligenter umgehen. Sie können mehr als nur "funktionierende Software" verwenden, um herauszufinden, was Ihr Kunde wirklich braucht. Allen Cooper sagt sogar, dass selbst eine funktionierende Software Ihnen nicht das richtige Feedback geben wird, weil die Menschen eine schlechte Vorstellung davon haben, was sie wirklich brauchen, selbst wenn sie es sehen. Es muss also mehr Zeit darauf verwendet werden, herauszufinden, welche Funktionen Ihre Benutzer wirklich brauchen. Iteration-1 beginnt also, bevor Sie mit der Codierung beginnen. Scrum beschreibt nicht, was Sie tun, bevor Sie mit der Codierung beginnen, mit Ausnahme von 'Vision und Backlog mit Funktionen bereitstellen'. Diese Lücke muss geschlossen werden. Ich sehe ein grundlegendes Dilemma bei Iteration-1, nämlich die Lean-Prinzipien der Minimierung von Verschwendung und unfertiger Arbeit. Design und Architektur können als unvalidierte Artefakte betrachtet werden, die die Zykluszeit Ihrer Funktionen erhöhen. Andererseits können Sie ein Projekt als ein diskretes Ereignis betrachten, bei dem es eine relativ feste Anzahl von Problemen zu lösen gilt. Lean (und in gewisser Weise auch Scrum) scheinen eher auf einen kontinuierlichen Fluss von Funktionen ausgerichtet zu sein. Das ist großartig, aber Sie müssen dafür sorgen, dass diese Funktionen zu einem kohärenten Satz, einer kohärenten Architektur und einem kohärenten Funktionssatz passen. Dazu brauchen Sie wieder einen Blick auf das gesamte System. Wenn Sie also ein ganz neues Projekt in einem neuen Kontext beginnen, können Sie nicht von Anfang an mit der Entwicklung von Funktionen beginnen, sondern Sie brauchen eine Iteration-1 (oder -2, -3).

Bewusste Entwicklung

Ich denke, dass der bewussten Vorbereitung und der Anwendung von Requirements Engineering, Interaktionsdesign und Architektur vor der Codierungsphase viel mehr Aufmerksamkeit geschenkt wird. Das ist natürlich ein bisschen wie Wasserfall und viel wie die RNP-Iterationen. Die Tatsache, dass die Leute es Iteration-1 nennen, zeigt, dass es ihnen immer noch ein wenig peinlich ist, es mit den agilen Prinzipien zu verbinden. Hoffentlich kommen wir darüber hinweg und geben ihr einen richtigen Namen und einen angemessenen Platz in der Softwareentwicklung.