In der Softwareentwicklung beinhaltet die übliche „Schätzung“ eine quantitative Bewertung des Arbeitsaufwands zur Erfüllung einer gegebenen Entwicklungsaufgabe; dies wird normalerweise in Form von Dauer (Stunde / Tag) oder geschätzter Einheit (Story Point) ausgedrückt. Der Zweck besteht darin, eine Reihe solcher Einzelschätzungen zu konsolidieren, um einen Hinweis auf die Gesamtdauer, den Arbeitsaufwand oder die Kosten des Softwareprojekts zu erhalten.
Häufige Fallstricke der agilen Schätzung
Auch in einer agilen Community finden sich viele unterschiedliche Denkrichtungen zur Bewertung von Theorie und Praxis. Einige der typischen Fehler, denen agile Teams oft begegnen, wenn sie agile Assessments durchführen, und diese häufigen Fallstricke haben jedoch einen breiten Konsens gefunden:
- Schätzungen müssen „Unsicherheiten“ enthalten; „ (Story) Point “-Schätzungen werden üblicherweise als unzureichend angesehen, da sie diese Unsicherheit nicht widerspiegeln.
- Die Schätzung unterscheidet sich vom Versprechen; Wenn er beispielsweise den Entwickler beschuldigt, 3 Tage zu verbringen, schätzt er / sie ein, dass die Fertigstellung der Arbeit in 2 eine kontraproduktive Einstellung sein könnte, die normalerweise zu einer zukünftigen Überschätzung führt.
- Die Schätzung ist nicht die endgültige Antwort, sie spiegelt nur die Informationen wider, die in der Kommunikation enthalten sind; sollte es immer ermöglichen, den geschätzten Wert aufgrund neuer Informationen nach oben oder unten zu aktualisieren.
Agile Schätzung Referenzen
- Schätzung – Agile Alliance
- Was ist agile Schätzung?
- Was ist Planning Poker in Agile?