Wenn der Kunde mich um einen geschätzten Zeitrahmen für die Fertigstellung des gesamten Projekts bittet, kann dieser dann mit Scrum angegeben werden?
Wenn ich zum Beispiel die (gefürchtete) Wasserfall-Methode verwende, habe ich eine technische Spezifikation, die ich verwenden kann, um eine halbwegs vernünftige Schätzung abzugeben.
Für ein bestimmtes Budget wissen Sie, wie viele Iterationen durchgeführt werden können. Der Product Owner sollte dann die Arbeit priorisieren, um den größten Nutzen aus dem Product Backlog zu ziehen. So funktioniert Agile: feste Zeit und Teamgröße mit variablem Umfang (bei Agile geht es um Umfangsmanagement). Sobald die Geschwindigkeit des Teams bekannt ist, kann man vorhersagen, wie viel Arbeit (in Punkten) erledigt werden kann (Anzahl der Sprints x Geschwindigkeit = Umfang der Arbeit, die erreicht werden kann).
Oft versteht der Kunde das nicht und will "alles, was er zu einem bestimmten Zeitpunkt zu brauchen glaubt" (d. h. einen festen Umfang). In diesem Fall müssen Sie im Vorfeld eine Art Analyse durchführen, um alles in ausreichend kleine Teile zu zerlegen, damit Sie es abschätzen können. Sobald diese Arbeit erledigt ist, können Sie vorhersagen, wie viele Sprints Sie benötigen werden, indem Sie die Geschwindigkeit schätzen (Anzahl der Sprints = Gesamtumfang / Geschwindigkeit). Dies ist eine sehr häufige Situation für Leute mit einem Wasserfall-Hintergrund und führt oft zu einem ungenauen Enddatum (fester Umfang und Teamgröße mit variabler Zeit), weil man die Geschwindigkeit nicht wirklich abschätzen kann und der Beginn eines Projekts der schlechteste Zeitpunkt ist, um Schätzungen vorzunehmen.
In beiden Fällen benötigen Sie die Geschwindigkeit. Das Problem ist, dass die Geschwindigkeit eigentlich 1) unbekannt bevor das Team seine Arbeit aufnimmt und 2) wird im Laufe der Zeit variieren.
Um 1) zu lösen, könnten Sie Schätzung die Geschwindigkeit wie in der zweiten Situation zu schätzen, aber das ist nicht sehr "agil". Idealerweise sollten Sie das Team stattdessen dazu bringen, die tatsächliche Geschwindigkeit zu messen (die in den ersten Iterationen wahrscheinlich ungenau sein wird). Ein Zwischenszenario besteht darin, eine erste sehr grobe Schätzung abzugeben und nach einigen Iterationen mit einer präziseren Schätzung zum Kunden zurückzukommen, sobald Sie mehr Wissen über das Projekt gesammelt und die Unsicherheit verringert haben.
Um 2) zu lösen, verfolge ich die gemessene Geschwindigkeit über die Zeit und verwende die höchste y niedrigste Geschwindigkeit und die Durchschnitt Geschwindigkeit der letzten 3 Sprints als Arbeitshypothese. So kann ich optimistische, pessimistische bzw. realistische Prognosen erstellen.
Ja, Sie können (und tun) Scrum-Projekte schätzen. [Beachten Sie, dass "Scrum" ein englisches Wort ist, kein Akronym oder eine Abkürzung. Es sollte nicht in Großbuchstaben geschrieben werden].
Auf diese Weise schätzen Sie ein Scrum-Projekt ein.
Schreiben Sie den Rückstand auf.
Teilen Sie das Backlog in Sprints auf.
Priorisieren Sie die Sprints in der Reihenfolge vom höchsten zum niedrigsten Wert.
Stellen Sie dem Kunden diese nach Prioritäten geordnete Liste von Sprints zur Verfügung.
Es steht ihnen frei, die Arbeit jederzeit einzustellen, da jeder Sprint nützlich ist und der erste Sprint der nützlichste und wichtigste Teil des Systems ist.
Das ist die Schätzung. Sie müssen es selbst verwalten.
Absolut, in Scrum legt man Kosten und Zeit fest. Dann lässt man die Funktionen variieren. Sie können dem Kunden also sagen, dass es am XX/XX/XXXX zu einem Preis von $YYY.YY erledigt wird. Es liegt dann an ihnen, die gewünschten Funktionen zu priorisieren, um sicherzustellen, dass die wichtigsten unter diesen Einschränkungen fertiggestellt werden.
Ja und Nein. Ich glaube, dass Scrum ein großartiger Ansatz ist, um den Eigentümer in die Planung der Sprints einzubeziehen.
Im Falle einer Schätzung wäre es also schwierig zu sagen: "Wir werden das Projekt in 30 Tagen fertigstellen". Stattdessen wird der Eigentümer eine Erwartung haben, was etwa in der ersten und zweiten Woche erledigt werden soll, und eine Vorstellung davon, was getan werden wird in 30 Tagen.
Meiner Meinung nach ist dies wertvoller, als eine Schätzung von 30 Tagen abzugeben und dann Glück zu haben, oder weit daneben zu liegen.
Außerdem können Sie viel besser einschätzen, was in naher Zukunft zu tun sein wird. Eine weitere großartige Sache an Scrum ist, dass Sie Ihre Entwicklung so anpassen können, dass Sie möglicherweise Elemente ändern oder entfernen können, um nach 30 Tagen ein brauchbareres Produkt zu haben, als etwas, das bei der Wasserfallmethode möglicherweise völlig unbrauchbar ist.
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
