Wie man ein agiles Projekt für Menschen darstellt, die sich auf Wasserfälle konzentrieren [geschlossen]

Unser Team wurde gebeten, unsere Entwicklungsbemühungen in einem Projektplan darzustellen. Niemand ist mit unserer Arbeit unzufrieden oder stellt unsere Lieferfähigkeit in Frage. Wir nehmen lediglich an einem IT-Aufruf zur Einreichung von Projektplänen teil. Das Problem ist, dass wir ein agiles Team sind und nicht über unsere Arbeit im Sinne eines formellen Projektplans nachgedacht haben.

Obwohl wir eine allgemeine Vorstellung davon haben, woran wir als nächstes arbeiten, sind wir uns nicht 100% sicher, bis wir eine Iteration planen. Bisher hat unser Team größtenteils im luftleeren Raum gearbeitet und war nicht verpflichtet, unsere Methodik oder Metriken externen Parteien vorzustellen. Wir folgen den meisten Praktiken der Extreme Programming .

Wir halten vierteljährliche Planungstreffen ab, um eine allgemeine Vorstellung von den Geschichten zu bekommen, an denen wir ein Viertel lang arbeiten werden. Unsere Geschichten sind jedoch auf 3x5-Karten dokumentiert und werden erst zu Beginn der Iteration geschätzt, in der sie bearbeitet werden sollen. Nach der Schätzung dokumentieren wir die Geschichte in Team Foundation Sever . Während einer Iteration hängen wir Code an Storys an und markieren Storys als abgeschlossen, sobald sie fertig sind. Aus diesen Daten können wir Burn-Down- und Geschwindigkeitsdiagramme erstellen. Am wichtigsten ist, dass wir unsere Durchschnittsgeschwindigkeit für eine Iteration kennen, die uns davon abhält, mehr abzubeißen, als wir kauen können.

Ich möchte die Art und Weise, wie wir entwickeln, nicht ändern, sondern unsere Entwicklungsaktivitäten in einem Bericht präsentieren, den nur jemand versteht, der mit Wasserfällen vertraut ist. In Wie sieht ein agiler Projektplan aus ? Kent McDonald macht einen guten Job und zeigt die Unterschiede zwischen agilen und Wasserfall-Projektplänen auf. Er spezifiziert die Unterschiede bei Verbrauchsgeschossen:

• Ein agiler Projektplan basiert auf Funktionen
• Ein agiler Projektplan ist in Iterationen organisiert
• Ein agiler Projektplan weist je nach Zeitrahmen unterschiedliche Detaillierungsgrade auf
• Ein agiler Projektplan gehört dem Team

Die Unterschiede erklären zu können ist großartig, aber wie lassen sich die Daten am besten präsentieren?

Zeigen Sie ihnen das halbherzige agile Manifest .

Es zeigt Ihnen definitiv, worum es beim Agile- System geht, indem Sie es mit Wasserfallmethoden vergleichen :

Individuen und Interaktionen über Prozesse und Werkzeuge
und wir haben obligatorische Prozesse und Werkzeuge, um zu steuern, wie diese Individuen (wir bevorzugen den Begriff "Ressourcen") interagieren

Arbeitssoftware über umfassende Dokumentation
, solange diese Software umfassend dokumentiert ist

Die Zusammenarbeit der Kunden bei Vertragsverhandlungen
innerhalb der Grenzen strenger Verträge und unterliegt einer strengen Änderungskontrolle

Reagieren auf Änderungen nach einem Plan,
sofern ein detaillierter Plan vorhanden ist, um auf die Änderung zu reagieren, und der genau befolgt wird

Ich musste das einmal tun. Das Team wollte Agile machen, der Kunde wollte (und verstand Agile), einen externen Dritten (nennen sie "Auditoren"), wollte Wasserfallberichte sehen.

Ein wichtiger Grund, warum wir lügen konnten, war, dass es der dritten Partei eigentlich egal war, sie wollte nur Kontrollkästchen aktivieren. Wenn der Kunde zufrieden war und das Team zufrieden war, gingen die "Auditoren" kaum zurück und sahen sich die Berichte an, die wir ihnen gegeben hatten, bevor sie die letzten Kästchen ankreuzten.

Tun Sie dies nicht, wenn der Dritte wichtig ist und sich WIRKLICH darum kümmert, dass Sie einen Wasserfall verwenden . Wenn die Auditoren wissen, dass Sie agil sind und ihre Unterlagen nicht aktualisiert haben, um Sie zu unterstützen, können Sie lügen.

Wie geht's? Lüge , aber Notlüge.

• Formulieren Sie Features neu, als Anforderung "Muss Feature haben".
• Ihre Arbeit ist in Iterationen, Iterationen dauern in der Regel über X Wochen, ein Wasserfallplan sieht die Dinge im Allgemeinen in Wochen, also kein großes Problem. Sie können das Ende jeder Iteration als Meilenstein kennzeichnen. Meilensteine ​​sind Wasserfälle. Iterationen haben in der Regel ein Thema (oder ein zugehöriges Epos), sodass Sie das Thema / den Titel des Epos auf den Meilenstein kleben können (z. B. 21/11 GUI vollständig haben).
• Berechnen Sie Ihre Geschwindigkeit (aus Ihren Burn-Down / Up-Diagrammen) und berechnen Sie, wie viel Zeit ein Story Point im Durchschnitt darstellt (zumindest bei Ihrer aktuellen Geschwindigkeit). Dadurch erhalten Sie eine Aufgabendauer. Oft wild ungenaue, aber sie werden bis zu einem gewissen Grad von Bedeutung sein.
• Ihr Plan hat je nach Zeitrahmen unterschiedliche Detaillierungsgrade - im Grunde das gleiche für Wasserfälle. Mögliche Unterschiede Ein Wasserfallplan weist je nach Zielgruppe unterschiedliche Details auf.

• Ein agiler Plan gehört dem Team. Ein Wasserfallplan gehört dem Projektmanager. Sie haben nachweislich bereits einen Projektmanager, der diese Übersetzung wahrscheinlich ausführt . Sie sollten das übersetzte Dokument in Besitz nehmen und das Team vor dem Schwarz schützen, das aufgrund dessen auf sie herabregnen könnte. Es ist die Aufgabe eines Agile- oder Waterfall-Projektmanagers, das Team vor Ablenkungen zu schützen, die es am Arbeiten hindern.

• Sicher, Sie wissen nicht wirklich, was Sie in der nächsten Iteration tun, aber Sie wissen ungefähr, was Sie tun. Sie haben ein Gefühl dafür und noch härter die Iteration danach. (Ich habe gehört, dass dies das Iterationsradar genannt wird). Lüge und sag, dass du es tust. und wenn Sie durch Ihre Zähne über eine Story-Karte liegen, die nicht auf Ihrem Iterationsradar ist, und sie einfach irgendwo hineinstecken. Ich hoffe, Sie müssen nicht zu viele Aktualisierungen des Projektplans einreichen, sonst werden sie feststellen, dass Sie nicht das getan haben, was Sie versprochen haben.

Grundsätzlich ist das ein Schmerz. Die Übersetzung wird viele Arbeitsstunden dauern. Wenn Sie viel tun müssen, automatisieren Sie es.

Die erste Frage ist, was das Unternehmen eigentlich will. Einige Unternehmen freuen sich sehr, wenn agile Sprints in einem Gantt-Diagramm dargestellt / zerlegt werden. Es mag für niemanden Sinn machen, der die Sprints tatsächlich versteht und sich regelmäßig ändert, aber es ist den Leuten vertraut, die danach fragen. Präsentieren Sie dann zusammen mit dem Gantt-Diagramm den Burndown usw.

Wir haben etwas Ähnliches durchgemacht und irgendwann (wenn Agile funktioniert) wird es sich selbst verkaufen (wenn nicht, warum machst du es dann?). Die Leute beginnen, "Anstrengung" zu verstehen und dass ein bestimmtes Team in der Lage ist, 40 Anstrengungspunkte in einem 2-wöchigen Sprint "niederzubrennen", und sind im Durchschnitt ziemlich gut darin, diese Anstrengungspunkte zu schätzen. Sobald sie die Vorteile für sie sehen, verkaufen sie den Prozess für Sie an den Rest des Unternehmens. Aber der Hauptpunkt ist, dass man es niemals jemandem aufzwingen kann, da er sich nur wehrt.