Entwickler schätzen nicht gerne. Was kann ich tun, um den Prozess zu verbessern?

Manchmal gibt es sogar Wutanfälle bei der Schätzung oder sie nehmen am Planungstag Krankschreibungen.

Das sind Erwachsene, von denen wir sprechen? Vielleicht sollten Sie sie direkt fragen, was das Problem mit Schätzungen ist. Ich denke, sie wollen vielleicht nicht dafür verantwortlich sein, wenn sie die Erwartungen nicht erfüllen, ist das wahr? Menschen können nicht härter arbeiten als sie können. Dies ist auch ein guter Grund, relative Größen zu verwenden.

Fragen Sie sich, warum und wie Sie die Schätzungen verwenden werden, und kommunizieren Sie dies ehrlich mit den Entwicklern. Ich denke, das Ziel sollte es sein, eine Prognose zu erhalten, aber wichtiger ist es, die Diskussion in Gang zu bringen, um Aufgaben kleiner und einfacher zu machen und eine gemeinsame Grundlage dafür zu schaffen, woraus die Aufgaben bestehen.

Um die Schätzungen zu erleichtern, verwenden Sie vielleicht eine feste relative Skala, auf die sich jeder beziehen kann. Ich bin auf „Das abstrakte Gewicht intelligenter Anwendungsfälle“ gestoßen, wie es von Smart verwendet wird (beschrieben in dem Buch „ This is Agile “ ) und in diesem Slide-Share verwendet wird .

Abstraktes Gewicht intelligenter Anwendungsfälle

1: Stück Kuchen

2: Moderat

3: Durchschnitt

4: Schwer

5: Sehr schwierig

8: Extrem, aber bekannt

10: Extrem und unbekannt

Ich denke, Schätzungen auf einer Skala wie dieser sind leichter zu verstehen als relative Story Points. Lassen Sie trotzdem alle blind abstimmen und gleichzeitig die Komplexität aufdrehen, um zu verhindern, dass sie sich gegenseitig beeinflussen. Diskutieren Sie dann, ob die Schätzungen nicht nahe beieinander liegen, sonst nur im Durchschnitt.

Dieses Thema ist nicht nur auf Entwickler oder Agile oder sogar in der IT-Branche beschränkt. Dies erstreckt sich über alle Branchen und alle Arten von Rollen.

Bei der Bereitstellung von Schätzungen geht es darum, die Zukunft so genau und genau wie möglich vorherzusagen, und die unbequeme Wahrheit ist, dass wir nicht in der Lage sind, die Zukunft mit einem wirklichen Maß an Genauigkeit oder Präzision vorherzusagen.

Der menschliche Zustand erwartet jedoch 100% Genauigkeit und Präzision, und alles andere ist kaputt und unbrauchbar. Wir erwarten endgültige Ergebnisse und glauben, dass wir tatsächlich die Kontrolle über die Zukunft haben. Tatsächlich ist unsere Welt in hohem Maße probabilistisch, unzuverlässig, unvorhersehbar und sehr zufällig. Aber das verkauft sich nicht, das kaufen die Kunden nicht, und wenn man Statistiken anspricht, werden alle glasig.

Das Problem beim Erhalten von Schätzungen ist die Kultur, in der diese Schätzungen vorgenommen werden. Es ist die Erwartung von 100 % Genauigkeit und Präzision und die schwerwiegenden Konsequenzen, die wir haben, wenn wir das nicht erreichen, vorausgesetzt, das Team hat gegen nur ein zufälliges Ergebnis innerhalb der normalen Verteilung möglicher Ergebnisse versagt. Gemeinsam haben wir Schätzverhalten erfolgreich aus unserem Verhaltensrepertoire herausgesucht, indem wir die falschen Dinge belohnt und die richtigen Dinge bestraft haben.

Wenn Sie dieses Verhalten ändern wollen, müssen Sie die kulturelle Dynamik ändern. Viel Glück damit.

Haben Sie versucht, ihnen beizubringen , wie man Schätzungen macht? Ich habe das in Ihrer Liste nicht gesehen, und nicht jeder "versteht" automatisch, wie es geht.

Ich bin auf zwei Hauptgründe für die mangelnde Bereitschaft gestoßen, Schätzungen vorzunehmen: Einer war die Angst, daran festgehalten zu werden, aber der andere war, dass sie es noch nie zuvor getan hatten, also fragte ich sie: „Wie lange, glauben Sie, wird das dauern ?" Sie antworteten ehrlich: "Ich habe keine Ahnung." Als ich sie drückte, sagten sie: "Nun, ich würde nur raten!" (Was beim Planen von Poker bedeuten könnte, dass man zufällig eine Karte zieht.)

Also haben wir darüber gesprochen, dass eine Schätzung eine Vermutung ist , aber es ist eine fundierte Vermutung, und jeder versteht das; und dann führte ich sie grob durch den mentalen Prozess, den ich verwende, um Schätzungen vorzunehmen, und sagte, dass sie natürlich zunächst nicht sehr gut darin wären, wenn sie es noch nie zuvor getan hätten, aber wir würden üben und sie würden besser darin werden es. Ich habe auch kontextualisiert, warum Schätzungen wichtig für uns als Team sind (Vertrauen in uns selbst aufbauen und unseren Stakeholdern vertrauen, dass wir in der Lage sein werden, das zu tun, was wir sagen, dass wir in der Lage sein werden), und wies auf dieses Lernen hin Schätzungen vorzunehmen ist auch ein guter Schachzug für die Karriereentwicklung. (Wenn die Leute, die Widerstand leisten, sich an „senior devs“ wenden, kann dies ein gutes Argument für sie sein.)

Ich denke, der einfachste Weg für Leute, mit Schätzungen zu beginnen, sind ideale Arbeitstage, dh angenommen, ich könnte 100 % meiner Zeit ohne Unterbrechung für diese Aufgabe aufwenden, wie lange würde ich dafür brauchen? Story Points können für Leute, die diese Fähigkeit gerade erlernen, zu abstrakt sein.

Zu Ihren QA-Leuten: Ich habe auch festgestellt, dass Leute zögern, sich an der Schätzung von Aufgaben zu beteiligen, an denen sie nicht direkt arbeiten werden, z. B. wollen Leute, die an einem Subsystem arbeiten, keine Arbeit schätzen, die vollständig in einem anderen Subsystem enthalten ist. Meine Lösung bestand darin, zu sagen: "Nun, Sie haben gesehen, wie lange die anderen Subsystem-Leute brauchen, um solche Aufgaben zu erledigen, also schätzen Sie es so gut ein." Sie zögern immer noch, aber zumindest habe ich ihnen eine Rubrik gegeben, der sie folgen können.

An diesem Punkt glaube ich nicht, dass Sie im Teamprozess noch etwas tun müssen. Ich würde eine oder mehrere der folgenden Methoden ausprobieren (in keiner bestimmten Reihenfolge):

• Wenden Sie sich an jeden widerstrebenden Entwickler einzeln unter vier Augen und fragen Sie aus Neugierde, was das Problem ist, wenn sie Schätzungen vornehmen?

• Wenden Sie sich an die Vorgesetzten der widerstrebenden Entwickler (vorausgesetzt, Sie sind das nicht?) und geben Sie Feedback, dass sie anscheinend geschult werden müssen, wie man Schätzungen macht. (IE, gerät nicht in "wird nicht" und Wutanfälle; konzentriere dich auf "scheine nicht in der Lage zu sein, diese Aufgabe zu erledigen", daher muss trainiert werden)

• Wenden Sie sich an die Linienmanager und stellen Sie sicher, dass Ihre Erwartungen an die Verantwortlichkeiten der Entwickler mit ihren übereinstimmen, insbesondere. um Schätzung.

Ich habe festgestellt, dass Entwickler nervös sind, wenn es darum geht, Schätzungen abzugeben (wir haben sie in Schätzungen umbenannt), weil sie befürchten, dass sie zur Rechenschaft gezogen werden, wenn sie unterschätzen / überschätzen. Das schafft Unsicherheit, Angst und Befürchtungen.

Ich habe kürzlich festgestellt, dass Planungspoker dem Team bei der Entscheidung hilft, und ich habe daraus gute Schätzungen erhalten. Hast du das versucht? https://www.mountaingoatsoftware.com/agile/planning-poker

Es ist wie ein Kartenspiel und es kann Spaß machen. Ich habe dem Team auch erklärt, warum wir Schätzungen brauchen (und das ist alles, was sie sind – Schätzungen) und warum es besser ist, sie zu überschätzen als zu unterschätzen. Sie müssen in der Lage sein, eine Schätzung abzugeben, mit der sie zufrieden sind. Ich stimme hier David Espina zu. Schätzen macht Spaß. Ändern Sie es zum Besseren.

Interessant, dass sich die Antworten darauf beziehen, dass das Team den Prozess nicht verfolgt oder geschult werden muss. Es gibt eine Bewegung in Agile um #noestimates, da das Gefühl besteht, dass sogar die Verwendung von Story Points in der PM-Schätzung der alten Schule verwurzelt ist.

Wenn Sie INVEST in Ihren Storys verwenden (Independent, Negotiable, Valuable, Estimable, Small und Testable), denken Sie darüber nach, was Sie in die Story einbauen. Jetzt geht es darum, Storys ähnlicher Größe zu erstellen. Sie können dann Ihre Metriken verwenden, um die durchschnittliche Zeit bis zum Abschluss zu berechnen, und diese anstelle der Geschwindigkeit (oder Arbeitsstunden) bei der Planung verwenden.

Schauen Sie sich die Arbeit an, die Alan Holub macht. Am Ende des Tages funktioniert es so genau wie der Versuch, es zu schätzen, wir würden und brauchen kein 10% Engagement des Teams.

Alles, was Sie bereits tun, was Sie oben aufgelistet haben, ist ausgezeichnet, und obwohl Sie noch ein paar Dinge tun können, gibt es nicht zu viel, bevor Sie es in die Kette aufnehmen. Dinge, die es wert sind, getan zu werden:

1. Agile-Trainings haben. Studien zeigen, dass je besser ein Team sich mit Agilität auskennt, desto mehr werden sie es annehmen und desto besser werden sie zu einem Team.

2. Arbeiten Sie mit Ihrem leitenden Entwickler zusammen, um dieses Problem zu lösen. Manchmal, wenn ein Scrum Master anscheinend nicht zum Junior-Entwickler durchdringen kann, kann der leitende Entwickler dies tun. Arbeiten Sie mit Ihrem leitenden Entwickler an der Entwicklung einer Teamkultur, die offen für Wertschätzung ist.

Wenn keines dieser Dinge funktioniert, müssen Sie leider ihr Verhalten mit ihren Vorgesetzten oder der Personalabteilung besprechen. Wenn ich persönlich ein Teammitglied hätte, das einen Wutanfall bekommt, würde ich es nicht loslassen. Das ist nicht nur unprofessionell, sondern auch ein schlechtes Beispiel für das Team, und wenn Sie ihn damit durchkommen lassen, wird er lernen, dass es ein akzeptabler und effektiver Weg ist, um aus der Schätzung herauszukommen.

Das ist jedoch ein letzter Ausweg!

Zuerst; wenn das Team die Geschäftsziele erreicht; Mach dir keine Sorgen.

SONDERN

Wenn ich die Kommentare über die jahrelange Arbeit mit agiler Methodik lese, vermute ich, dass Sie diese nur teilweise umsetzen. Ohne Sprint-Planung verwenden Sie Agile nicht.

Dies wäre eine gute Frage, die man in den Retrospektiven angehen könnte; da der Prozess eindeutig davon profitieren würde. Wenn die Planung dauerhaft zu niedrig ist: Auch damit sollten Sie im Nachhinein umgehen.

Aus der Perspektive eines Entwicklers führt die Ausgabe einer Schätzung zu der folgenden Wahrscheinlichkeitsverteilung über die Ergebnisse:

• 50% Chance zu überschießen, wodurch nicht nur mehr Aufgaben übernommen werden müssen, sondern auch die Leute dich als faul ansehen
• 50% Chance zu unterschreiten, also zu spät gemacht und vom Manager angeschrien zu werden
• 0% Chance, richtig geschätzt zu haben
• 100 % Chance, Zeit mit einer Aufgabe zu verbringen, die dem Entwicklungsaufwand nicht direkt zugute kommt

Um also das Codieren abzuschaffen und mit dem Schätzen fortzufahren, ist Zuckerbrot oder Peitsche erforderlich.

_{Aus der Perspektive von 4 agilen Arbeitsplätzen gesprochen, von denen meiner Meinung nach keiner gut funktioniert hat. Einer war ein führender deutscher Automobilhersteller. Ein anderer war ein Silicon Valley ... Unternehmen.}