Wie kannst du verhindern, dass das Entwicklerteam ihre Zahlen auffüllt, wenn es darum geht, Aufgaben zu erstellen? Wie motiviert es sie, ihre Arbeit zu tun, wenn es keine echten Fristen gibt und sie nur an ihrer Geschwindigkeit gemessen werden?
Erledigen Sie den Auftrag bis zu diesem Termin
vs
Machen Sie den Job fertig, wenn wir den Umfang, die Qualität oder die Ressourcen erhöhen
Die Grundlage der meisten agilen Methoden ist trust . Wenn Sie Ihrem Team nicht vertrauen, warum haben Sie sie überhaupt eingestellt? Wenn Sie denken, dass sie der Aufgabe nicht gewachsen sind, ist es besser, das Projekt nicht zu starten, weil es fast zum Scheitern verurteilt ist - entweder weil Sie Recht haben und das Team ein Haufen unfähiger Entwickler ist, oder weil Sie sich irren Ihr Mangel an Vertrauen und zu viel Kontrolle erstickt das Team und schwächt tatsächlich ihren Einsatz und ihre Begeisterung.
OTOH Wenn du sicher bist, dass du die besten verfügbaren Jungs eingestellt hast, und dass sie talentiert und motiviert sind, ist es das Beste, ihnen eine gute Herausforderung zu geben, sie arbeiten zu lassen und alle Hindernisse aus dem Weg zu räumen.
Nach meiner Erfahrung beginnen die meisten Entwickler begeistert und motiviert, Produkte zu entwickeln, auf die sie stolz sein können. Unmögliche Deadlines, irreale Erwartungen, zu viel Bürokratie, zu viel Kontrolle und nicht zuletzt die Qualität reduzieren die Motivation.
Der Sinn von agilen Methoden liegt darin, dass Entwickler die richtigen Leute sind, um die Kosten einer bestimmten Funktion zu kennen / schätzen. Wenn das Management darauf besteht, beide die Ressourcen, den Umfang und die Zeit zu schätzen, die dem Projekt zugewiesen sind, führt dies fast immer zu einem Desaster. Wenn OTOH den Entwicklern Vertrauen und Verantwortung anvertraut, werden sie normalerweise der Aufgabe gerecht. In Scrum berechnet das Team gemeinsam die Schätzungen und bekämpft Probleme / Probleme, die während des Sprints auftreten. In guten Projekten treffen die Teammitglieder schnell auf das Team und fühlen sich persönlich für das Projekt verantwortlich. Das kann so weit gehen, nachzügige Mitglieder zu stossen, um Ergebnisse zu erzielen, anstatt das Team zurückzuziehen.
Nach meiner Erfahrung puffern die Entwickler die Zahlen wegen der Unsicherheit. Sind Ihre Produktbesitzer in ihren geschäftlichen Anforderungen klar? Sind die Geschichten ausreichend klein, um sie zu schätzen?
Ihre zwei Möglichkeiten deuten darauf hin, dass Sie ein grundlegendes Missverständnis von Scrum haben. Das Versprechen von Scrum erreicht nicht das gleiche Ergebnis, nur schneller. Es ist die Fähigkeit, schnell zu iterieren, auf Feedback zu reagieren und den Kurs zu ändern. Die Grundlage von Scrum ist das selbstlaufende Team. Wenn Sie keine Teams haben, denen Sie vertrauen, ist Scrum wahrscheinlich nicht für Ihre Organisation.
Wie Péter in seiner Antwort sagte, ist Teammotivation der Schlüssel und der schnellste Weg zu töten ist, sie zu untergraben. Wenn das Team der Meinung ist, dass das Management sie nicht unterstützt oder an sie glaubt, haben sie keinen Grund, aggressive Schätzungen vorzunehmen und werden einfach ihre eigenen Ärger abdecken. Es ist Ihre Aufgabe als Manager, ihnen zum Erfolg zu verhelfen.
Darüber hinaus fördern die agilen Methoden die Verantwortlichkeiten gegenüber dem Peer. Sie sollten nicht nur eine Person haben, die Artikel schätzt. Machen Sie es zu einer Gruppensache, und stellen Sie sicher, dass (meistens) alle mit der Schätzung einverstanden sind. Wenn Sie Ihr gesamtes Team haben, um gegen Sie abzuschlagen, um Schätzungen zu puffern, haben Sie viel mehr Probleme, als Sie denken.
Außerdem gibt es eine Menge Möglichkeiten, um Schätzungen vorzubereiten und Ausreden in traditionellen Wasserfall / BDUF (Big Design vorne) Anstrengung zu machen. Ich würde sagen, dass Scrum, mit den täglichen Scrum-Meetings, dazu beiträgt, das mehr einzudämmen, als es hilft, es zu fördern.
Ich schrieb vor einiger Zeit einen Blog-Beitrag über die Schätzung von Anti-Patterns. Es ist eine lustige Lektüre, aber leider sind alle Muster Dinge, die ich entweder von Kollegen gesehen oder gehört habe. Wir haben ungefähr drei von ihnen in unserem aktuellen Projekt durchlaufen; Ich glaube nicht, dass es ein Team gibt, das es schafft, alle komplett zu vermeiden!
Schauen Sie sich auch Systemdenken, Spieltheorie und perverse Anreize an. Wenn die Entwickler die Schätzungen auffüllen, liegt das daran, dass die Umgebung, in der sie arbeiten, sie dazu ermutigt. Ändern dieser Umgebung wird ihnen helfen.
Gute Antworten hier schon. Im Grunde genommen, wenn Sie annehmen, dass Entwickler Sie betrügen, indem sie Stunden berichten, haben sie nicht wirklich gearbeitet (aber das Spiel, welches MMORPG gerade in Mode ist), warum arbeiten Sie sogar überhaupt mit ihnen? Und wenn Sie ihnen vertrauen, warum denken Sie, dass sie "pad"?
Übrigens - es ist völlig normal für Teams, die neu sind, Scrum zuerst zu überschätzen (und Gegenstände aus Sprint fallen zu lassen), dann - also verbrannt - zu unterschätzen, um zu vermeiden, dass ihnen das wieder passiert, dann wie andere darauf hingewiesen haben Die Teamgeschwindigkeit wird ausgeglichen und die Leute werden besser verstehen, wie viel sie in einem Sprint machen können.
Noch ein Hinweis darauf, was Sie tun können: Stellen Sie ihre Stunden nicht in Frage, versuchen Sie nicht, sie "zu managen", indem Sie ihnen sagen, wie viel Zeit das oder das dauern sollte. Fragen Sie vielmehr, wie sie das oder jenes erreichen wollen, welche Lösungen sie verwenden möchten und warum? Bei guten Geeks ist es durchaus üblich, dass sie dazu neigen, überzubauen - wenn die Dinge viel größer aussehen, als Sie erwartet haben, gibt es wahrscheinlich ein Missverständnis darüber, was gebaut werden soll, was geklärt werden muss.
Es ist tatsächlich ziemlich unmöglich, Schätzungen im Gedränge zu "puffern". Nach ein paar Sprints wird sich die Geschwindigkeit normalisieren und das Team wird "wissen", wie viele Punkte es machen kann. Es gibt nichts zu padeln.
Ich denke, du hast deine Aussagen zurück, weil
Machen Sie den Job fertig, wenn wir den Umfang, die Qualität oder die Ressourcen erhöhen
ist eine genaue Beschreibung von Waterfall; nicht Gedränge. In Scrum haben wir Termine, es heißt das Ende des Sprints. Im Gedränge opfern wir NIE Qualität, weil wir wissen, dass uns das auf lange Sicht mehr kostet. In Scrum fügen wir keine Ressourcen hinzu, weil wir wissen, dass Menschen gelern und ein "Team" bilden, und dass dieses Gleichgewicht für die Produktivität schädlich ist.
Warum kümmern Sie sich überhaupt um Aufgabenzeiten? Das einzige Mal, dass ich gute Entwickler-Pad-Schätzungen gesehen habe, ist, wenn sie gezwungen werden, eine Schätzung für ein unbekanntes Feature zu geben. Wir machen das nicht im Gedränge. Wir wissen, was die Bedingungen für die Akzeptanz eines Features sind, bevor wir uns dazu verpflichten.
Tags und Links scrum