Posts mit dem Label Erfahrung werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Erfahrung werden angezeigt. Alle Posts anzeigen

Donnerstag, 4. Oktober 2007

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.

Mittwoch, 25. Juli 2007

Wann sollte man "Nein" sagen? - Teil III

Oft gewinnt man ein Projekt, hat aber nicht gerade die richtigen Resourcen beisammen. Sie, als erfahrener Scrum Master, sollen das Projekt übernehmen und bekommen ein Team zusammengestellt ...

"If we get the right people on the bus, the right people in the right seats, and the wrong people off the bus, then we’ll figure out how to take it someplace great."
Jim Collins, Unternehmensberater

Sagen Sie "Nein"

Wann sollte man "Nein" sagen? - Teil II

Sie haben ein scrum Projekt, bei dem ein Team firmenübergreifend zusammenarbeitet, weil der Kunde da so wünsch?

Der Kunde A möchte, dass Sie als IT Dienstleister B mit der internen IT von A zusammenarbeitet, um ein gemeinsames Projekt zum Erfolg zu bringen...

Sie haben das Gefühl, der Partner im Projekt spricht nicht die gleiche Sprache, komplett andere Vorgehensweise hat, eigentlich nicht mit Ihnen zusammenarbeiten möchte , künstliche Hürden aufbaut, bla, bla, bla

"The team will make or break the project"

Sagen Sie "Nein"

Wann sollte man "Nein" sagen? - Teil 1

Aus gegebenem Anlass schnell ein gutes Argument, wenn man vor der Entscheidung steht, einem agilen Projekt zu- oder abzusagen:

" Good trial lawyers don't take bad cases"

Akutell arbeite ich gerade an einem agilen Projekt mit einem Partner-Unternehmen, wo man ausdrücklich agile arbeiten möchte - die Knwo-how-, Methodik und Erfahrungsunterschiede aber so gross sind, dass man besser "Nein" sagt ...

10 Gründe, warum agile Projekte schief gehen

Wenn ein agiles Softwarentwicklungsprojekt schief geht, ist in erster Line immer die Methode schuld, nicht die Personen, die die agile Methode eingeführt bzw. umgesetzt haben. Oft eine falsche Annahme. 10 Gründe, warum agile Projekte scheitern:

#10 Gerüchten glauben, z.B.
  • agile ist besonders gut für kleine Projekte
  • totale Kostenkontrolle
  • Dokumentation ist nicht notwendig
  • agile Vorgehensweise braucht keine Analysten und Tester
  • "jeder" kann "alles" Grundsatz
  • wir machen Scrum, wir sind agile!
#9 Widersprüchliche Terminologie

Wir sagen - der Kunde versteht/interpretiert:
  • extreme - riskant
  • agile - ungenau, unbestimmt, locker
  • pair programming - doppelte Kosten
  • refactor - unnötiger Code
  • unit testing - extra Code
Wenn man es nicht erwähnt, hat man es nicht gehört - jetzt ist man agile!

# 8 Keine Schlüsselfiguren

man fokussiert auf die Entwicklung von Features, ABER es braucht einen
  • Sprint Manger
  • (Business) Analysten
  • Tester
  • Designer
  • WAI Experten
#7 Übertreibung

Beispiele:
  • Sicherstellen, das Dokumente für jemanden bestimmt sind
  • Sicherstellen, dass jede Implementierung ein Problem löst
  • Alles weglassen, was keinen Business-Value hat
  • Kein Micromanagement
  • Keine Statusdiagramme oder ähnliches
#6 Spitzfindigkeiten
  • Man braucht ne Menge Erfahrung
  • Entscheidungsträger sind nur involvierte Personen
  • "Nach Lehrbuch" Vorgehensweise
  • Alles mindestens 3 Interationen ausprobieren
  • Jede Änderung min. 3 Interationen verifizieren
  • Keine Angst, Änderungen rückgängig zu machen
#5 Mangelnde Disziplin & Schleifen lassen
  • Angst Dinge zu ändern oder Änderungen einzufordern
  • Tun und Handeln wird unterschieden - ist man wirklich agile?
  • Rituale vernachlässigen
#4 Nicht das richtige Team
  • es braucht erfahrene Führungspersonen
  • es braucht ein erfahrenes Team
  • es braucht erfahrene Mentoren für jede Rolle
  • man braucht mehr als einen "Plan"
  • Externe Epertentips einholen - und zuhören!
#3 Zu lange Interationen
  • nicht länger als 2 Wochen
  • klarer Rythmus ist erwünscht -> Dienstag -> Dienstag
  • Schneller Teams sollten kürzere Zyklen haben
  • Keine Zeit verliehren
#2 Kein guter "Sponsor"
  • der Kunde muss zum agilen Prozess passen
  • man braucht jemanden, der genug politischen Einfluss ausüben kann, um agile ein Chance zu geben
  • Überzeugung und Begeisterung für agile schaffen
  • Aus Fehlern lernen
#1 Dem Team keine Erholen lassen
  • das Team gewinnt oder verliehrt das Projekt
  • die Führungsperson ist ein wunder Punkt
  • die Umgebung/Arbeitsumfeld ist ein wunder Punkt
  • die (externe) Unterstütztung ist ein wunder Punkt
  • Personalfluktion ist ein wunder Punkt