Blogpost

Der Text auf dieser Seite wurde automatisch von DeepL übersetzt. Das Ergebnis ist zum Zweck der Dokumentation unverändert. Hier der Link zum Original (Ich finde es einfacher IT blogs auf englisch zu schreiben): englische Version. Erstaunlich: Kommentare in Codeblöcken wurden auch übersetzt, ohne den Code zu verändern (weitestgehend).

Bauchgefühl schätzt

Wie erhält man eine "grobe" Schätzung des Aufwands für die Erfüllung eines Arbeitspakets? Auf der Grundlage des Bauchgefühls: Die Schätzung muss von demjenigen vorgenommen werden, der die der die Arbeit macht. Das Ergebnis der Schätzung wird einer der folgenden "natürlichen" Bereiche sein

Minuten, Stunden, Tage, Wochen, Monate, Quartale, Jahre

Bedeutung

  • Minuten: 1 bis 60 Minuten
  • Stunden: 1 bis 24 Stunden
  • Tage: 1 bis 5 Tage
  • Wochen: 1 bis 4 Wochen
  • Monate: 1 bis 3 Monate
  • Quartale: 1 bis 4 Quartale
  • Jahre: 1 bis offenes Ende

Verwendung für Empfänger (derjenige, der um einen Kostenvoranschlag bittet)

Wenn Sie z. B. die Schätzung "Tag" erhalten, wissen Sie, dass es ein bis 5 Tage sein können. Das war's. Fragen Sie nicht nach einer genaueren Angabe. Nehmen Sie es einfach mit.
Es ist Sache des Empfängers, das "Risiko" zu managen, welche Anzahl von Tagen er verwenden soll.
Dies wird dazu führen, dass wir sehr schnell (gute!) Schätzungen erhalten.

Besonders bei längeren Zeiträumen (ab "Woche") ist es wichtig, noch einmal zu fragen mindestens einmal nachzufragen, z.B. wenn etwa 50% der ursprünglich geschätzten Zeit vergangen sind. vergangen. Dies ermöglicht es uns, die Erfahrung des Entwicklers zu nutzen, die in der Regel mit der Arbeit am Projekt wächst. Es ist gut, eine solche Überprüfung der Schätzung von Anfang an gemeinsam mit dem Entwickler zu planen.

Verwendung für Arbeiter (derjenige, der die Arbeit verrichten wird)

  1. Wenn Sie wirklich keine Ahnung haben, bitten Sie um eine kurze Zeitspanne ("Minute" oder "Stunde"), um die Arbeit durchzugehen. Es ist wichtig, dies in einem Zeitfenster zu tun.
  2. Gehen Sie die Einheiten im Kopf durch, zum Beispiel: Ist es in Minuten möglich? Nein. In Stunden? Nein. In Tagen? Nein. In Wochen? Vielleicht => Schätzung ist "Woche".

Voraussetzungen

  1. Vertrauen.
  2. Vernetzungswerkzeug zur Aufzeichnung des Shared Understanding. Jeder Teilnehmer hat Lese- und Schreibzugriff darauf. Die Einschätzungen müssen dort sichtbar sein.

Motivation

Auch in einer agilen Entwicklung wird der Eigentümer nach Schätzungen fragen. Das ist etwas, das ein Entwickler akzeptieren muss. Die meisten Entwickler (oder alle!?) mögen keine mögen keine Schätzungen, und das nicht ohne Grund. Es liegt nicht daran, dass sie einfach "nicht mögen". Es liegt daran, dass sie es gut machen wollen, aber sie (besonders die erfahrenen) wissen, dass es nicht möglich oder zumindest sehr zeitaufwendig ist, es gut zu machen.

Da agile Entwicklung nicht bedeutet, dass es keinen Plan oder Fahrplan gibt, sind die Entwickler verpflichtet, Schätzungen abzugeben - was also tun?

Eine Möglichkeit, die Entwicklerteams wählen, ist die Verwendung von Adjektiven wie "hoch", "mittel" und "niedrig" oder die Farben "rot", "gelb" und "grün", um einen Anhaltspunkt für den Umfang des Aufwands zu geben. Dies, um "vage" Schätzungen zu erhalten, um ihre Ungenauigkeit zu reflektieren oder um zu vermeiden, dass andere Personen eindeutige Zeiten "missverstehen" können. Das Problem ist jedoch, dass nicht allen Teilnehmern klar ist, was diese Einheiten bedeuten (denken Sie an neue Teammitglieder). Was bedeutet es, dass eine Aufgabe einen "hohen" Aufwand darstellt? Es ist erforderlich, eine Definition dieser Einheiten beizubehalten. Diese Art von Einheiten unterstützen die Kommunikation nicht, sondern erschweren sie. Andererseits, Wenn ich eine Aussage wie "Das wird Wochen dauern" bekomme, weiß ich, was das bedeutet. Warum nicht damit planen?

Referenzen