Agile - Spikes und die Gesamtzeitleiste

Das Team beginnt mit seinem ersten Capital-A Agile-Projekt, und das Projekt scheint gut mit der Methodik übereinzustimmen (dh wir können uns wahrscheinlich einfach ein agiles Buch schnappen und es wie ein Rezept befolgen), mit ein wenig Verwirrung:

Das Projekt beinhaltet drei Dinge, mit denen niemand im Team Erfahrung hat: Integration in das Foo Payroll System, Verarbeitung des Dateityps XYZ89 (wobei "XYZ89" = ein Dateityp, von dem Sie noch nie gehört haben) und Konvertierung einiger andere Dateien, damit sie vom Frobnobdicator verarbeitet werden können.

So wie ich es verstehe, besteht die übliche agile Praxis darin, für jede dieser Spitzen Spitzen zu planen. Danach können wir bestimmen, wie lange sie dauern werden (ich bin mir nicht sicher, ob die Wahrscheinlichkeit groß ist, dass der Kunde sich dagegen entscheidet sie, da sie ziemlich solide Anforderungen des Projekts sind)

Meine Fragen sind also:

1. Machen wir alle Spikes in der ersten Iteration im Voraus, um eine bessere Schätzung der Zeit zu erhalten, die dafür benötigt wird, und / oder um ein "Laufskelett" zum Laufen zu bringen?

2. Wenn nicht, wäre der gesamte Projektplan nicht einer dieser Spitzen ausgeliefert, die Daten zurückgeben, dass diese bestimmte Geschichte viel länger dauern wird, als wir geplant haben?

Was ist die beste Methode, um mit mehreren Spitzen umzugehen, wenn diese im Grunde nicht verhandelbare Anforderungen eines Projekts sind?

Die Art und Weise, wie ich mit diesen zwielichtigen Unbekannten in meinem Projektplan umgegangen bin, besteht darin, zu versuchen, Zeit für das Entwicklungsteam einzurichten, um Prototypen der unbekannten Funktionalität vorab zu erstellen. Dies bietet den Vorteil, dass klar bekannt gegeben wird, was für die Ausführung der speziellen Aufgaben erforderlich ist, dass diese technisch machbar sind, und dass der Rest des Teams über mögliche Fallstricke informiert wird, die zu Beginn der aktiven Entwicklung zu vermeiden sind.

Aus diesem Grund beginnen viele agile Projekte normalerweise mit einem Sprint 0 , wie ich es gerne nenne .

Stellen Sie sich vor, Sie schnüren Ihre Laufschuhe, dehnen sich und legen Bandaids an Ihre Brustwarzen, bevor Sie einen Marathon starten. Diese Zeit kann verwendet werden, um die anfängliche Projektplanung und Erstellung von User Storys, das Rollout von Design und Architektur sowie die Erstellung von Software-Frameworks durchzuführen. Die Entwickler können an Prototypen und Proof-of-Concepts für neue Technologien oder unbekannte technische Herausforderungen arbeiten, die User Story zum Ausdruck bringen Schätzung viel einfacher.

Sie sollten die Dinge in der Reihenfolge der Priorität ausführen, die vom Product Owner (oder Kunden) festgelegt wurde. Es macht keinen Sinn, sich wegen etwas umzubringen, das wirklich schön zu haben war. Die Idee ist, dass wenn Sie keine Zeit mehr haben und etwas nicht erledigt wird, es die Elemente mit der niedrigsten Priorität sein sollten.

Wenn sie nicht priorisieren, was sie wollen, werden Sie kämpfen.

Wenn die Dinge relativ gleich sind, beginnen Sie nicht mit dem schwierigsten Punkt - beginnen Sie mit einem einfachen Gewinn, der dem Team die Möglichkeit gibt, sich an die Zusammenarbeit mit der neuen Methodik zu gewöhnen, und dem Kunden ein gewisses Vertrauen, dass er auf diese Weise Dinge liefern kann. Sobald dies feststeht, packen Sie etwas Schwieriges an. Messen Sie die Komplexität des schwierigen Gegenstands an der Komplexität der einfacheren Dinge, die Sie gerade getan haben, und Sie erhalten eine Vorstellung davon, wie lange es dauern kann, bis Sie ihn durchlaufen.

Komplexe Gegenstände sind nicht wirklich "Spikes". Es sind einfach Dinge, die mehr Mühe erfordern, um herauszufinden. Teilen Sie sie so weit wie möglich in einfachere Aufgaben auf.

Eine mögliche Lösung besteht darin, eine Aufgabe für die Erstellung eines Proof-of-Concept zu erstellen, um herauszufinden, wie das Problem gelöst werden kann, und eine Zeitbox zu erstellen. Anschließend wird diese Geschichte einem Sprint mit anderen Geschichten hinzugefügt.

Sie liefern am Ende des Sprints immer noch Wert und ein Produkt, auch wenn es sich um eine Hack-Konsolen-App handelt. Die Idee ist, dass Sie nicht die Produktivität des gesamten Teams beeinträchtigen. Wenn Ihnen die Zeit ausgeht, fügen Sie dem nächsten Sprint eine weitere ähnliche Aufgabe hinzu.