Agile Awareness Workshop 2008 - Die Sicht der Delegierten.

Der kürzlich bei Xebia India abgehaltene Workshop zum Thema Agile Awareness war eine großartige Lernerfahrung für alle Neulinge der agilen Arbeitsweise. Die Delegierten, die an der Veranstaltung teilnahmen, stammten aus den unterschiedlichsten Bereichen, vom Teamleiter über den Projektmanager bis hin zum Softwareentwickler. Das machte die ganze Veranstaltung sehr interessant. Sie begann mit dem Thema "Die Probleme, mit denen wir bei der Softwareentwicklung im Allgemeinen konfrontiert sind". Und die Antworten, die wir erhielten, waren ziemlich einhellig.

• Unrealistische Fristen
• Schlechte Schätzung
• Überschüssige Dokumentation
• Unzureichende Tests

und der von uns allen am meisten hervorgehobene Punkt war "Änderung der Anforderungen". Nachdem wir unsere größten 'Blocker' ausgesprochen hatten, waren wir offenbar bereit, den Sprung in die agile Welt zu wagen. Das Schlagwort hier lautet "Iterativ-Inkremental". Das bedeutet einfach, dass Sie iterativ Fortschritte machen, indem Sie der Struktur etwas hinzufügen, egal wie klein die Schritte auch sein mögen - ganz anders als bei den "traditionellen" Methoden. Einfach ausgedrückt, bei den traditionellen Methoden ist der Höhepunkt erst erreicht, wenn Sie die "Alles-auf-einmal-Lieferung-Phase" erreicht haben, d.h. wenn Ihr Projekt abgeschlossen ist. Schön formuliert von Craig Larman : "Normalerweise wächst ein partielles System inkrementell mit neuen Funktionen, Iteration für Iteration, mit anderen Worten, inkrementelle Entwicklung."

Das Wörterbuch definiert Agilität als "Flinkheit oder Flexibilität". Im Zusammenhang mit dem Paradigma der Softwareentwicklung geht es darum, anpassungsfähig zu sein und nicht vorausschauend oder starr. Veränderung ist ein Naturgesetz. Wir sollten also keine Angst vor Veränderungen haben. Vielmehr sollten wir planen, wie wir uns den Veränderungen entsprechend verhalten. Diejenigen, die sich über die erforderlichen Änderungen aufregen, sind starr in ihrem Ansatz. Und Agile verlangt, dass man flexibel ist, wenn es darum geht, Änderungen zu akzeptieren. Die meisten Delegierten haben bereits die Erfahrung gemacht, wie schmerzhaft es ist, Anforderungen zu ändern. Daher waren wir gespannt, wie Agile uns in diesem Bereich helfen würde Das wurde sehr gut erklärt: In der Softwareentwicklung ist es unmöglich, "eingefrorene Anforderungen" zu haben. Das liegt daran, dass wir die Zeit einfach nicht einfrieren können. Wir haben also in der Regel eine Vielzahl von Anforderungen vom Kunden, die er in späteren Phasen ändern, aktualisieren oder streichen kann. . Von diesen Anforderungen konzentrieren wir uns zunächst auf die "Hochrisiko"- und "Hochwert"-Anforderungen. Hohe Risiken müssen frühzeitig in der Entwicklungsphase angegangen werden und ein hoher Wert bedeutet mehr Gewinn für das Unternehmen. Abgesehen davon haben wir auch MoSCoW-Techniken, um unsere Anforderungen zu priorisieren. Für diejenigen, die sich fragen, was MoSCoW mit Agile und Software zu tun hat, schauen Sie sich das an:

• MoSCoW
  MoSCoW ist eine Methode zur Priorisierung von Elementen. Im Rahmen von DSDM wird die MoSCoW-Technik verwendet, um Anforderungen zu priorisieren. Es ist ein Akronym, das für steht:

Sie MÜSSEN diese Anforderung haben, um die geschäftlichen Anforderungen zu erfüllen.

SOLLTE diese Anforderung haben, wenn dies möglich ist, aber der Erfolg des Projekts hängt nicht davon ab.

KÖNNTE diese Anforderung haben, wenn sie die Eignung der geschäftlichen Anforderungen des Projekts nicht beeinträchtigt.

WOLLTE diese Anforderung zu einem späteren Zeitpunkt erfüllen, wenn noch etwas Zeit übrig ist (oder bei der zukünftigen Entwicklung des Systems).

Es wurde auch kurz das Agile Manifest erwähnt, auf das die vier Punkte folgen:

1. Funktionierende Software über umfassende Dokumente. (Einfach gesagt: Alles, was zählt, ist, was funktioniert!!!)
2. Customer Collaboration over Contract Negotiation...(Collaborates klingt definitiv positiver als Negotiates)
3. Reagieren Sie auf Veränderungen (auf jeden Fall mit einem Plan!)
4. Individuen und Interaktionen vor Prozessen und Tools.

Kurze Iterationen, TDD, ein potenziell auslieferungsfähiges Produkt (oder funktionierende Software) am Ende jeder Iteration, Individuen und Interaktionen statt Prozesse - das ist alles, was wir tun müssen. Um die agile Arbeitsweise zusammenzufassen, möchte ich es so formulieren: PRIORTIZE --> DO SOMETHING (ITERATION) --> GET FEEDBACK -->IMPROVE N GET GOING. Die beiden Dinge, die mir persönlich auffallen, sind:

• Feedback erhalten
• Früh scheitern.

Ich war erstaunt zu sehen, wie "echt" diese Art der Entwicklung ist. Feedback war etwas, das wir immer angenommen/gegeben haben. Sei es beim Einkaufen mit Freunden oder in der Rubrik "Verbesserungsmöglichkeiten" in Magazinen oder Zeitungen - wir alle wollen uns verbessern. Ein weiterer Punkt ist, früh zu scheitern. Es ist immer gut, wenn Sie früh scheitern, sich verbessern und dann Ihre Aufgabe gewinnen. Und als Entwickler sollten wir auch darauf achten. Nachdem wir in der Sitzung "Warum Agile?" den Begriff Agile kennengelernt hatten, waren wir nun bereit, einen Blick auf die verschiedenen Technologien zu werfen, die zu Agile gehören. Unser erstes Ziel waren die SCRUM-Techniken. Ich hatte das Wort "SCRUM" schon einmal gehört, das mit dem Rugby-Team zu tun hat. Das ist der Moment, in dem sich die Mannschaft zusammenfindet, um ihren Aktionsplan für die nächsten Minuten des Spiels zu besprechen. Wir haben uns gefragt, wie das hier hineinpasst. Dazu wurde uns gesagt, dass die Teams selbstorganisiert und funktionsübergreifend sein sollten, um agil zu arbeiten. Wenn wir crossfunktional sagen, bedeutet das, dass ein Team in jeder Hinsicht versiert und vollständig sein sollte. Dies kann eine sehr verbreitete Debatte über den Vorrang von Generalisten vor Spezialisten anheizen, die in der Branche seit langem geführt wird. Ich bin auf einen sehr nützlichen Blog zu diesem Thema gestoßen, der zufällig von einem der Redner dieser Veranstaltung geschrieben wurde. Der andere wichtige Aspekt ist die Selbstdisziplin im Team. Und ich glaube, das ist es, was dieses einfache Konzept zu einem schwer zu befolgenden macht. Wir mögen es nicht, diszipliniert zu sein ... das ist das allgemeine Wort. Danach wurden wir in die verschiedenen Rollen eingeführt, die es in Scrum gibt. Um einen kurzen Abriss zu geben: Product Backlog, Scrum Master, Sprint und Sprint Backlog, Committed Backlog, Burndown Chart. Ein weiterer wichtiger Punkt, der meine Aufmerksamkeit erregte, war "Verantwortung wird nie gegeben, sondern übernommen". Ich stimme dem zu. "Gegebene" Verantwortung ist eher eine Anweisung. Wie jemand treffend gesagt hat: "Man kann Innovation nicht anweisen". Später in der Sitzung sprachen wir über die Details der Iteration. Eine Iteration ist ein kurzer Zeitraum von 2-4 Wochen, in dem ein Team einen kompletten Entwicklungszyklus durchläuft. Bei Agile ist alles Teil einer Iteration, von der Aufnahme der Anforderungen in das Sprint-Backlog bis hin zu den Sprint-Retrospektiven.In dieser ganzen Diskussion war es etwas schwierig, in Bezug auf die Punkte Geschwindigkeit und Komplexität zu denken. Wahrscheinlich weil das Gehirn damit beschäftigt war, Hungersignale zu empfangen!!!) Nach der Pause für die Snacks ging es um eXtremeProgramming, die zweite Variante von Agile. Dieser Name war etwas schwieriger zu verstehen als die früheren. Es begann mit dem Hinweis, dass alles, was getan wird, einen geschäftlichen Wert haben und Sinn machen sollte. Es war also klar, dass dies aus der Perspektive des Entwicklers geschah. Von den vier Hebeln eines Projekts, nämlich:

1. Zeit
2. Umfang
3. Qualität
4. Kosten

agile Team spielt mit dem Hebel der Funktionalität, d.h. dem Umfang. Es ist sehr verbreitet, dass etwa 60% der Funktionen eines Produkts nie genutzt werden und etwa 20% intensiv genutzt werden. Um noch einmal auf die Assoziation von Agilität im wirklichen Leben zurückzukommen: Ich glaube, dass nicht jeder ein geborenes Genie ist. Aber zwei gewöhnliche Köpfe, die zusammenarbeiten, können definitiv zu außergewöhnlichen Ergebnissen kommen. Und das ist, einfach ausgedrückt, das Pair Programming in Agile. Zweifellos ist es eine Win-Win-Situation, wenn Sie beide gut zusammenarbeiten. Aber ich habe mir eine Frage gestellt: Was ist, wenn Sie und Ihr Paar nicht gut zusammenpassen? Das könnte sich katastrophal auf die Produktivität des Projekts auswirken. Wir haben dann eine Reihe von intelligenten Möglichkeiten diskutiert, wie man solche Situationen im Team überwinden kann. Im Laufe der Diskussion stellte einer der Redner eine wirklich interessante Lösung vor, nämlich " CC und BCC". Diejenigen, die sich wundern: CC ist Kommunikationbei Kaffee und BCC ist Bullshit-Kommunikationbei Kaffee. In der Tat kann bei einem Kaffee eine Menge passieren :) An dieser Stelle möchte ich einen der Redner zitieren: Man braucht viel "Mut", um mit Agile zu arbeiten. Ich denke, das ist absolut richtig. Wenn Sie agil arbeiten, müssen Sie alle Ihre Hemmungen ablegen. Sprechen Sie alle Ihre Probleme an. Diskutieren Sie mit dem Team und machen Sie weiter. Wie vielen von uns fällt es wirklich leicht zu sagen: "Ich stecke mit diesem Problem fest und weiß nicht, was ich tun soll"? Dies erfordert besonders viel "Mut", da agiles Arbeiten die volle Interaktion im Team fördert. Bis zum Ende dieser Sitzung war ich zufrieden, da ich nun klarstellen konnte, dass XP auf der Ebene der Entwickler spricht, während SCRUM auf der Ebene des Projektmanagements spricht. Wie wir in der Softwarebranche sagen, geht nichts über Theoriesitzungen. Also war auch hier eine praktische Sitzung angesagt. Es hat wirklich Spaß gemacht, die "einfachen und realistischen Regeln von Agile" anzuwenden. Wir haben zwei Iterationen durchlaufen, bei denen wir eine User Story erhalten haben. Wir mussten planen und jeder Benutzergeschichte Komplexitätspunkte zuweisen. Nach dieser Planung mussten wir uns auf die Geschichten festlegen, die wir in der vorgegebenen Zeit für realisierbar hielten. Und es waren nicht die Punkte, die ein Team zum Sieger machten, sondern wie viel man aus den Fehlern gelernt hatte. Wir hatten nach jeder Iteration eine Sprint-Retrospektive. Das war das eigentliche Lernen des Tages. Am Ende dieses Praxistags waren wir nun wirklich vertraut mit Komplexitätspunkten und dem Geschwindigkeitskonzept. Zusammenfassend möchte ich sagen, dass die agile Entwicklungsmethode keine Revolution, sondern eine Evolution ist. Es geht darum, sich auf seine Wurzeln zu besinnen, genauer gesagt, zu seinen Wurzeln zurückzukehren. Feedback annehmen, in kleinen Schritten arbeiten und sich verbessern, früh scheitern - das ist alles, was wir in unseren Anfängen getan haben, aber dann in Vergessenheit geraten ist. Bei Agile geht es nicht darum, die Softwareentwicklung zu revolutionieren, sondern das Eis der starren Denkweise zu brechen!! Es ist an der Zeit, dass wir uns befreien und die Schönheit der agilen Entwicklungsmethode schätzen lernen. Ich gratuliere den Referenten für ihre Bemühungen, die bei den meisten von uns definitiv den Funken entzündet haben.