Wir werden gerade unsere Story-Karten für das nächste Projekt definieren.
Unser Prozess der Definition von Storys ist wie folgt
Leider möchte der Kunde eine Schätzung, wie lange es für das gesamte Projekt dauern wird, also müssen wir alle Geschichten im Voraus definieren.
Das dauert eine Weile und kann ziemlich entwässernd sein
Welche anderen Methoden können verwendet werden, um die Storykarten zu definieren? Dies kann andere Wege bringen, um Anforderungen auf Storykarten zu sammeln?
BEARBEITEN:
Ich würde vorschlagen, dass wir ein "Release-Planspiel" nennen. Es ist sehr ähnlich zu dem, was Sie für eine Iteration tun, aber wir haben es auf einer höheren Ebene gemacht. Das heißt, wir würden die Menge der Merkmale oder Funktionspunkte nehmen, die der Benutzer für eine bestimmte Version wollte, und schätzen, dass wir Weg entfernt sind. Sie können dann alle diese Schätzungen zusammenfügen, um eine ungefähre Vorstellung davon zu bekommen, wann Sie denken, dass Sie Ihr Produkt basierend auf Ihren aktuellen Informationen liefern können.
Das sollte Ihren Kunden eine Vorstellung davon geben, wann Sie es veröffentlichen werden, aber Sie müssen immer noch darauf bestehen, dass Sie ein wenig Spielraum brauchen, denn wie Ihre Kunden können Sie die Zukunft nicht vorhersagen (oder zumindest kann ich ' t).
Sie können nicht wissen, wann alles gemacht wird und trotzdem einem agilen Prozess folgen. Selbst wenn Sie sehr hart arbeiten, um alles zu schätzen, ist die Fehlerquote umso größer, je größer die Arbeit ist. Die meisten Schätzungen für mittelgroße Projekte enden mit 2x aus und größere mit bis zu 10x.
Stattdessen würde ich den Kunden nach einem funktionalen Zieltermin fragen. Die Unterhaltung läuft so:
Sie: Wann benötigen Sie diese Funktionen?
(C) ustomer: Wann können Sie sie liefern?
Sie: Lassen Sie uns zuerst die Grenzen aufreißen. Wenn ich alle diese Funktionen in 10 Jahren liefern würde, wäre das zu spät?
C: Natürlich.
Sie: Wenn ich all diese Features morgen liefern würde, wäre das bald genug?
C: Natürlich.
Sie: Wie sieht es in einem Jahr aus?
C: Das ist noch zu spät.
Sie: 3 Monate?
C: Das ist nur ein bisschen zu spät, mehr wie 2 Monate. Wir müssen bereit sein, dies im Januar mit unserem Management-Team zu nutzen.
Sie (denken): Ah ha!
Sie: Wir können nicht alle diese Funktionen in zwei Monaten liefern. Ich denke, wir könnten diese 4 Geschichten in 1 Monat und diese 3 Läden im nächsten Monat liefern.
C: Wir brauchen wirklich Feature X für Januar.
Sie: OK, wenn wir Feature X hinzufügen, müssen wir ein Feature entfernen. Was brauchst du nicht?
C: Wir können nur mit einem Teil von Feature Y arbeiten.
Sie: OK. Wir nehmen diese Liste und arbeiten eine detailliertere Schätzung.
C (denke): Ha! Ich habe bekommen, was ich wollte!
Ich habe immer wieder gefunden, dass der Grund für Schätzungen und die Planung von "alles" ist, dass sie ein Versprechen haben, etwas nach einem Datum zu liefern. Das Durcharbeiten des Zieldatums funktioniert viel besser, weil es:
Zwingt den Kunden dazu, die Kompromisse zu machen
Macht den wahren Grund für Schätzungen sichtbar
Reduziert die Anzahl der zu schätzenden Dinge.
Identifiziert, welche Funktionen für welchen Sprint wichtig sind.
Ich würde keine Geschichten in diesem kleinen für die Veröffentlichung planen (was scheint, was Sie tun wollen). Die Veröffentlichungsplanung ist sowieso weniger genau (da sich die Dinge im Laufe der Zeit ändern werden), daher ist es sinnvoll, eine weniger genaue Einheit für die Schätzung zu verwenden.
Wir verwenden normalerweise Planning Poker, wobei 13 oder 21 der größte zulässige Wert ist, bevor eine Story geteilt werden muss. Für die Release-Planung schätzen wir in " ideale Tage " für die Iterationsplanung in "idealen Stunden" . Funktioniert gut für uns.
Wie planen Sie die Freigabe der Anwendung an den Client? Machst du inkrementelle Lieferungen? Oder ist diese Planung für eine erste Lieferung?
Ich schlage vor, die Entwicklung in zwei oder drei Wochen lange Sprints aufzuschlüsseln und dann eine zusätzliche Woche für jeden Sprint in das Lieferbudget einzufügen, um etwas zusätzliche Zeit zu gewinnen ... nur für den Fall, dass der Kunde seine Meinung zu einem Feature ändert ( Sie werden). Dies wird hoffentlich die Schätzung des endgültigen Liefertermins erleichtern ...
Wenn Sie Ihren Kunden davon überzeugen können, dass Sie inkrementell liefern sollten, werden Sie feststellen, dass Sie weniger redundante Storys erstellen, wenn sich die Spezifikationen ändern. Außerdem müssen Sie nicht so viel im Voraus arbeiten, und im Laufe der Entwicklung können Sie während der Entwicklung die nächsten Geschichten schreiben.
Ich hoffe, das hilft.
Ich frage normalerweise nur nach Titeltiteln im Voraus. Ich versuche zu sehen, ob ich sie auf eine Größenordnung beschränken kann. Ich gebe eine sehr grobe Schätzung basierend auf der Anzahl der Titel und meiner geschätzten Geschwindigkeit / Titel. Ich werde normalerweise den Kunden die Titel brechen lassen in (1) müssen jetzt haben, (2) benötigt aber kann warten, und (3) das wäre nett.
Ich beginne damit, Gruppe (1) anzugehen und genügend Informationen zu sammeln, um sie in eine Reihe von Veröffentlichungen aufzuteilen. An dieser Stelle kann ich normalerweise eine bessere Schätzung geben, indem ich die detaillierteren Informationen verwende, um pro Titel Schätzungen zu liefern. Ich plane nur die Geschichten der Gruppe (1). Wenn es zu viele Gruppen (1) Storys gibt, die in eine Version passen, teilen wir sie in mehrere zusammenhängende Releases / Iterationen auf.
Wenn wir innerhalb von einem Monat anfangen, mit den Geschichten der Gruppe (2) anzufangen, setze ich mich wieder mit dem Kunden zusammen (in einer konzentrierteren Planungssitzung, usu. Sprechen Sie mit ihnen die ganze Zeit), um den Prozess mit zu beginnen die Gruppe (2) Geschichten.
Geschichten, die hinzugefügt werden, wenn das Projekt weitergeht, werden in die richtige Gruppe eingefügt und entsprechend für diese Gruppe behandelt - wenn es aktuelle Version ist, genug Details, um zu arbeiten, wenn später, nur der Titel als Platzhalter.
Die andere Sache, die ich tue, ist sicherzustellen, dass der Kunde versteht, dass es ein kooperativer Prozess ist, und wir werden mit dem enden, was sie wollen. Sie können wählen, wann sie aufhören sollen - selbst wenn noch Geschichten auf dem Brett sind. Solange ich Wert schenke, der ihnen wichtig ist, entwickeln wir uns weiter. Sie müssen darauf vertrauen, dass ich das Richtige für sie tue und fleißig arbeite. Ich muss darauf vertrauen, dass sie mir so schnell wie möglich die bestmöglichen Informationen über das geben können, was sie wollen.
Wenn du versuchst, XP treu zu sein, dann würde ich vorschlagen, dass du hier gehst und dich über den Unterschied informierst zwischen Release-Planung und Iterationsplanung. Sie sollten keine individuelle Aufgabenschätzung durchführen, bis Sie tatsächlich mit dem Codieren beginnen können.
Geschichten! = Aufgaben. Geschichten werden in Aufgaben unterteilt, die Sie dann tun die & lt; 3 Tage Schätzung für. Geschichtsschätzungen sind offener und Sie sollten in der Lage sein, die Schwellenwerte für Geschichtsschätzungen zu bestimmen, die nach einer Weile für Sie und Ihr Team am besten funktionieren. (IE & lt; 1 Woche, 2 Wochen, & gt; 2 Wochen, etc.)
Der wichtigste Teil der Schätzung besteht darin, die tatsächlich aufgewendete Zeit zu verfolgen und Ihren Schätzprozess anzupassen. XP dreht sich alles um Feedback.
Tags und Links agile requirements extreme-programming