Posts mit dem Label agile manifesto werden angezeigt. Alle Posts anzeigen
Posts mit dem Label agile manifesto werden angezeigt. Alle Posts anzeigen

Donnerstag, 19. Juni 2008

Wie wird man agil?

Ob man sein Auto wäscht, einen Schrank von Ikea zusammenbaut oder Software entwickelt, man folgt einem Prozess, teils intuitiv oder entlang einer schriftlichen Anleitung per Text oder Piktogrammen.

Agile Softwareentwicklung ist kein Prozessmodell und es gibt nicht DEN agilen Weg. Agil ist ein Bewusstsein, eine Haltung. Das agile Manifesto fast das gedankliche Modell in 4 Werten und 12 Prinzipien zusammen.

Die agilen Werte.[http://agilemanifesto.org/]
Die agilen Pinzipien.[http://agilemanifesto.org/principles.html]

Agil sein bedeutet, dieses Werten und Prinzipien zu folgen.

Mittwoch, 10. Oktober 2007

Das Scrum Team

Zentrales Element für den Erfolg bei agiler Vorgehensweise in der Softwarentwicklung ist das Team - es ist selbstorganisierend und bezüglich Disziplin selbstregulierend.

Zweifellos braucht man dafür das "richtige" Team. Agile kann und wird nur funktionieren, wenn jeder im Team mit den agilen Prinzipien vertraut ist, diese achtet, sie stehts befolgt und weiterentwickelt.

Kritik ist gut, zu viel davon ist kontra-produktiv!

Wenn man es schaft, die Skepsis und Kritik in Neugier und Verbesserung zu überführen, dann hat man ein Team!

Nebenbei glaube ich persönlich, dass es unerlässlich ist, die *besten* im Team zu haben. Man mag sich vorstellen, dass ein Team wenn es dem agilen Manifest folgt noch lange nicht erfolgreich ist - man braucht auch das Know-How zur Umsetzung der eigentlichen Aufgabe. Ich verstehe die Projekt Methode als solche als Meta Problem. Eigentlich geht es doch darum, das Problem des Kunden/Auftraggebers zu lösen - dafür nur die *Besten*...

Donnerstag, 4. Oktober 2007

Was heisst agiles Vorgehen?

Nach dem agilen Manifest gilt das Prinzip, dass man dem Kunden in regelmässigen Intervallen funktionsfähige, getestet, dokumentierte und brauchbare Artefakte liefert, die einen Mehrwert darstellen.

Wie kommt man von einem klassischen Wasserfall zum agilen Projekt?
Ein Praxisbericht: Schritt 1: man macht den Wasserfall zunächst iterativ.

Bei einem interativen Wasserfall werden pro Iteration Artefakte erarbeitet, die in der kommenden Iteration weiterverarbeitet oder verfeinert werden (Bild oben). Damit bleiben alle Nachteile von phasen- orientiertem Projektvorgehen erhalten: Abkapseln von Anaytikern, Kunden, Testern und Entwicklern sowie Behinderung der direkten Kommunikation aller Beteiligten. (A=Analyse,D=Design,P=Produktion,T=Test)

Da man mit dem iterativen Wasserfall jedoch keine funtionstüchtigen Artefakte mit einem Mehrwert für den Kunden liefert, kommt man zwangsläufig zum Schritt 2: der iterative Mini-Wasserfall (Bild unten).

Um dem agilen Manifest gerecht zu werden und die klassische Vorgehensweise beizubehalten, macht man alle Phasen pro Iteration.
Auch hier gewinnt man nicht viel, denn erfahrungsgemäss ist die Zeit am Ende einer Iteration sehr knapp und Testing fast unmöglich. Dazu kommt, dass die Teammitglieder so noch immer entkoppelt arbeiten und wichtige Kommunikation ausbleibt.

Untersuchen Sie genau Ihre Vorgehensweise. Finden Sie sich teilweise in diesen Aussagen wieder, dann haben Sie kein agiles Vorgehen!

Grundsätze für agile Projekte

Oft stehen im Zusammenhang mit agile Software Entwicklung viele Fehlannahmen im Raum. 5 Punkte, wie man agile Grundsätze interpretieren sollte.

Agile heisst nicht, es herrscht Chaos und Anarchie, vielmehr setzt man Eigenverantwortung und Selbstdisziplin jedes Teammitglieds voraus, gepaart mit Selbstregulierung des gesamten Teams.

Planung ist bei agiler Vorgehensweise keine Aktivität bei Projektbeginn, sondern ein Dauerzustand. Man setzt sich kontinuierlich mit Zielen und deren Erreichbarkeit ausseinander, passt diese der Realität an, um mit den verfügbaren Ressourcen, Budget und Zeit das bestmögliche Ziel zu erreichen.

Es wird dokumentiert, was wichtig ist, nicht Dokumentation des Prozesses wegen. Man spricht von "lebender" Doku, da sich gesamte Dokumenation während des Projekts Veränderung erfährt.

Aus Erfahrungen lernen und diese einfliessen lassen. Prozesse/Abläufe/Wege verbessern, weglassen oder optimieren, nicht alles präzise und exakt immer wieder aufs Neue wiederholen und hier und da was weglassen, um das ganze repetierbar zu machen.

Man setzt konstante Veränderung bei agilen Methodiken voraus. Die Methode ist nur ein Rahmenwerk - jedes Team, jede Organisation und jedes Projekt hat unterschiedliche Bedingungen, die es zu adaptieren gilt.