Es gibt einige einfache Richtlinien zum Schätzen der anfänglichen Geschwindigkeit Ihres Scrum-Teams vor Abschluss der ersten Iteration (siehe FAQs unten). Ab diesem Zeitpunkt sollten Sie jedoch bewährte, historische Messgrößen für die Planung von Funktionen verwenden. Innerhalb kurzer Zeit stabilisiert sich die Geschwindigkeit typischerweise und bietet eine hervorragende Grundlage für die Verbesserung der Genauigkeit und Zuverlässigkeit sowohl der kurzfristigen als auch der längerfristigen Planung Ihrer agilen Projekte. Agile Lieferzyklen sind sehr kurz, sodass die Geschwindigkeit schnell einsetzt und sehr früh in einem Projekt validiert und dann zur Verbesserung der Projektvorhersehbarkeit herangezogen werden kann.
Ist Geschwindigkeit wirklich so einfach?
Ja, so ist es. Versuchen Sie nicht, Velocity zu verkomplizieren – es ist wirklich ein einfaches Konzept und ein großer Teil seines Wertes liegt in seiner inhärenten Einfachheit. Viele Manager und Teams, die neu in agile Methoden neigen dazu, das Konzept der Geschwindigkeit zu sehr zu analysieren und es mit zu viel Komplexität zu überhäufen. Nach ein paar Monaten Erfahrung mit agilen Projekten erleben die meisten Menschen ein „Aha“-Erlebnis mit der Geschwindigkeit, lassen jeglichen Ballast fallen, den sie damit assoziiert haben, und schätzen ihre Einfachheit und ihren inneren Wert.
Geschwindigkeitsdiagramme
Zusammen mit release und Iterations-Burndown-Charts bietet die Messung der Geschwindigkeit agiler Teams nachweislich enorme Einblicke/Sichtbarkeit in den Projektfortschritt und -status. Ein Geschwindigkeitsdiagramm zeigt die Summe der Schätzungen der über alle Iterationen geleisteten Arbeit. Typischerweise stabilisiert sich die Geschwindigkeit im Verlauf eines Projekts, es sei denn, die Zusammensetzung des Projektteams variiert stark oder die Dauer der Iteration ändert sich. Somit kann die Geschwindigkeit für zukünftige Planungszwecke genutzt werden. Obwohl die Geschwindigkeit in der Regel für ein paar Iterationen zuverlässig ist, kann sie zur Planung genutzt werden, wenn man akzeptiert, dass sich Prioritäten, Ziele und Teams im Laufe der Zeit ändern können und sich daher auch das Konfidenzniveau einer Iteration weit in der Zukunft ändert releaseEs liegt viel weiter in der Zukunft.
Zunächst sollten Teams, die neu in der agilen Softwareentwicklung sind, einfach loslegen und anhand der verfügbaren Richtlinien und Informationen eine Anfangsgeschwindigkeit auswählen. Die Geschwindigkeit kann sehr schnell (so schnell wie bei der nächsten Iteration) gemessen und angepasst werden. Geschwindigkeit vereinfacht und beschleunigt zusammen mit granularen Funktionen (z. B. User Stories, Backlog, Anforderungen usw.) und übergeordneten und/oder relativen Schätzungen (in Bezug auf Punkte, ideale Tage oder sogar Stunden) die gesamte Projektplanung enorm , Schätzung, Statusverfolgung und Berichtsprozess.
Häufig gestellte Fragen zu Agile Scrum
Wie ist die Geschwindigkeit eines agile Entwicklung Team berechnet?
Geschwindigkeit ist die Summe der Schätzungen der gelieferten (d. h. akzeptierten) Features pro Iteration.
In welcher Einheit wird die Geschwindigkeit gemessen?
Die Geschwindigkeit wird in denselben Einheiten wie Feature-Schätzungen gemessen, unabhängig davon, ob es sich um Story Points, Tage, ideale Tage oder Stunden handelt, die das Scrum-Team liefert – die alle als akzeptabel gelten.
Wie wird die Geschwindigkeit der ersten Iteration geschätzt?
Für die erste Iteration eines agilen Teams besteht eine allgemeine Richtlinie darin, die Anfangsgeschwindigkeit bei einem Drittel der verfügbaren Zeit einzuplanen. Wenn Sie die ideale Programmiererzeit schätzen, dann berücksichtigt dies Besprechungen, E-Mail, Design, Dokumentation, Überarbeitung, Zusammenarbeit, Recherche usw. Bei sechs Programmierern und zweiwöchigen Iterationen ergeben sich beispielsweise insgesamt 60 Programmierertage (6). Programmierer x10 Tage) stehen zur Verfügung. In dieser Situation wäre es ein guter Anfang, idealerweise 20 Arbeitstage für die Iteration einzuplanen. Wenn Sie die tatsächliche Zeit verwenden, berücksichtigen Sie ausreichend Puffer, um 1) den Overhead des Standardprojekts und 2) die Ungenauigkeit der Schätzung zu berücksichtigen. Denken Sie auch daran, dass die Geschwindigkeit während der ersten Iteration schnell zunimmt. Bei Unterschätzung steigt die Geschwindigkeit in der ersten Iteration, wenn neue Funktionen hinzugefügt werden. und wenn sie überschätzt wird, nimmt die Geschwindigkeit ab, wenn Merkmale entfernt werden. Für die zweite Iteration sollte sich das Scrum-Team dann an der ersten Iteration orientieren.
Werden Besprechungen, Telefonanrufe und E-Mails in die Geschwindigkeit einbezogen?
Dies hängt davon ab, ob diese Posten geschätzt und in die Iterationspläne. Sie sind normalerweise nicht enthalten – ein Ziel der Geschwindigkeit ist die relative Konsistenz und Vorhersagbarkeit über Iterationen hinweg im Hinblick auf die Leistungsfähigkeit eines agilen Teams.
Sollte die Geschwindigkeit über alle agilen Entwicklungsteams oder Projekte hinweg akkumuliert werden?
Geschwindigkeit ist in hohem Maße ein lokalisiertes Maß. Zusätzlich zu den verschiedenen Teammitgliedern mit unterschiedlichen Team-„Persönlichkeiten“ weisen Projekte in der Regel einzigartige Merkmale in Bezug auf Schätztechniken, Detailprozesse, Technologie, Kundeneinbindung usw. auf. Dies kann dazu führen, dass unternehmensweite Analysen sehr ungenau werden. Wenn andererseits alle Ihre Teams genau das Gleiche schätzen, genau das Gleiche entwickeln, genau das Gleiche testen und genau das Gleiche verfolgen, dann sind Sie vielleicht auf jeden Fall die Ausnahme.
Was passiert, wenn die Geschwindigkeit schwankt?
Die Geschwindigkeit schwankt normalerweise innerhalb eines angemessenen Bereichs, was vollkommen in Ordnung ist. Wenn die Geschwindigkeit über mehr als eine oder zwei Iterationen stark schwankt, muss das Scrum-Team die Geschwindigkeit möglicherweise neu schätzen und/oder neu verhandeln release Plan.
Wie lange dauert es, bis sich die Geschwindigkeit stabilisiert?
Bei den meisten agilen Entwicklungsteams stabilisiert sich die Geschwindigkeit typischerweise zwischen 3 und 6 Iterationen.
Wie schätze ich zukünftige Iterationen?
Zukünftige Iterationen nutzen die bewährte Geschichte des Teams, um zu bestimmen, wie viel das Team leisten kann. Daher ist die Geschwindigkeit das richtige Maß für die Planung zukünftiger Iterationen.
Wie schätze ich die Geschwindigkeit ein, wenn sich die Größe von Projektteams ändert?
Um den größtmöglichen Nutzen zu erzielen, ist Geschwindigkeit auf Teamkonsistenz angewiesen. Wenn sich Ihr agiles Team ändert, nutzen Sie Ihren gesunden Menschenverstand bei der Planung zukünftiger Iterationen. Wenn 20 % Ihres Teams für ein paar Iterationen nicht verfügbar sind, reduzieren Sie die geplante Geschwindigkeit um etwa 20 %. Wenn dies einige wichtige Akteure umfasst, insbesondere einen Kunden, der möglicherweise weniger verfügbar ist, reduzieren Sie die Schätzung noch etwas. Es wird nur die Dauer der nächsten Iteration dauern, um besser zu verstehen, was das Team liefern kann und damit auch seine neue Geschwindigkeit.
Bedeutet maximale Geschwindigkeit maximale Produktivität?
Absolut nicht. Beim Versuch, die Geschwindigkeit zu maximieren, kann ein Team tatsächlich das Gegenteil erreichen. Wenn ein Team aufgefordert wird, die Geschwindigkeit zu maximieren, kann es bei Unit- oder Abnahmetests sparen, die Zusammenarbeit mit Kunden reduzieren, die Behebung von Fehlern überspringen, Refactoring minimieren oder viele andere wichtige Vorteile der verschiedenen agilen Entwicklungspraktiken nutzen. Während es möglicherweise kurzfristige Verbesserungen bietet (wenn man es so nennen kann), wird es auf lange Sicht negative Auswirkungen haben. Das Ziel ist nicht eine maximale Geschwindigkeit, sondern eine optimale Geschwindigkeit über die Zeit, die viele Faktoren einschließlich der Qualität des Endprodukts berücksichtigt.
Wie messen wir die Geschwindigkeit, wenn sich unsere Iterationslängen ändern?
Das tun Sie nicht, zumindest nicht annähernd so leicht. Der Wert von Velocity ergibt sich aus seiner inhärenten Konsistenz. Eine feste Iterationslänge trägt dazu bei, den zuverlässigen Rhythmus eines Projekts voranzutreiben. Ohne diesen Rhythmus müssen Sie ständig überarbeiten, neu schätzen und abgleichen, und die Fähigkeit, Vorhersagen für die Zukunft zu treffen, wird aufgrund inkonsistenter Ergebnisse minimiert. Wenn andererseits fast jeder eine Woche lang über die Feiertage oder ein paar Tage für unternehmensweite Besprechungen unterwegs ist, dann sollten Sie auf jeden Fall einfach Ihren gesunden Menschenverstand nutzen und die Iterationstermine oder -geschwindigkeit entsprechend anpassen. Wie bei den meisten agilen Praktiken handelt es sich hierbei um Richtlinien, nicht um Regeln.
