Der beste Weg, um mit "Also, wann wird dies geschehen?"

8

Während des täglichen Standup-Meetings mitten im Sprint fragt der De-facto-Projektmanager / Scrum-Master die Entwickler normalerweise nach einer Version von:

"Also wann wird das erledigt sein?"

"Können Sie sich also verpflichten, diese Aufgabe heute bis 16 Uhr zu erledigen?"

"Wie viele Stunden haben Sie noch für diese Unteraufgabe übrig?"

Das ist ehrlich gesagt sehr ärgerlich und lässt die Dinge nicht schneller erledigen. Das Ergebnis ist, dass Entwickler oft unter großem Druck stehen und Stand-ups oft eher ein Schlachtfeld als eine Zusammenarbeit sind.

Was ist als Entwickler ein solider Weg, um damit umzugehen?

Derek
quelle
Haben Sie Projektmanager, die versuchen, "agil zu werden"? Das klingt nach einer typischen Dummheit aus dem Mund eines Projektmanagers. Sie müssen dicke Haut wachsen lassen und alle Schätzungen auffüllen, so wie wir es bei allen anderen Entwicklungsstilen immer getan haben.
Frank Hileman
6
Sie haben einen Projektmanager / Scrum Master? Sie sollten einen Projektmanager und einen Scrum Master haben, und diese sollten nicht dieselbe Person sein.
Gnasher729
"Ich weiß nicht" ist eine durchaus akzeptable Antwort, wenn Sie dies nicht tun.
Robert Harvey

Antworten:

5

Der beste Weg, um mit "Also, wann wird dies geschehen?"

"Am Ende des Sprints".

Mir ist klar, dass das eine bissige Antwort ist, aber da ist etwas Wahres verborgen. Es hängt davon ab, wer fragt und warum sie diese Frage stellen.

Der Projektmanager hat wirklich nichts damit zu tun, solche Fragen zu stellen - er sollte den Scrum Master fragen, ob er detaillierte Informationen zu laufenden Aufgaben benötigt, und dies außerhalb des täglichen Stand-up.

Wenn es der Scrum Master ist, der fragt, fragen sie vielleicht, damit sie auf bevorstehende Straßensperren vorbereitet sind. Wenn das der Fall ist, sei einfach ehrlich.

In Scrum ist das Team nicht verpflichtet, eine bestimmte Aufgabe oder Story bis zum Ende des Sprints zu beenden, vorausgesetzt, es fragt nach einer Story, die sich auf den aktuellen Sprint bezieht (im Vergleich zu einem Out-of-Band-Hotfix). Die Fristen für Aufgaben innerhalb einer Story gehören dem Team und sollten nicht von einem Projektmanager unter Druck gesetzt werden.

Die Softwareentwicklung ist jedoch ein kollaborativer Prozess, daher ist es sinnvoll, solche Fragen im Rahmen des Zumutbaren zu berücksichtigen.

Die Lösung? Aus Ihrer Sicht: Antworten Sie so ehrlich wie möglich, so kurz wie möglich, wenn es im Stand-up ist. Wenn Sie aktiv an der Aufgabe arbeiten, nach der gefragt wird, können Sie immer etwas in der Art sagen: "Es wird voraussichtlich ein paar Stunden dauern, damit ich sie möglicherweise heute erledigen kann." Wenn Sie nicht daran arbeiten, ein einfaches "Ich weiß nicht, ich habe noch nicht damit begonnen. Ich denke, die Schätzung scheint immer noch ziemlich genau zu sein".

Aus ihrer Sicht: Sie müssen Ihre Antwort akzeptieren.

"Können Sie sich also verpflichten, diese Aufgabe heute bis 16 Uhr zu erledigen?"

Die Antwort darauf sollte fast immer "nein" sein. Es ist einfach nicht erforderlich, sich für eine Aufgabe mitten im Sprint auf ein Tagesende festzulegen. Ob die Aufgabe heute um 16 Uhr oder morgen um 9 Uhr beendet ist, spielt keine Rolle, solange die gesamte Geschichte bis zum Ende des Sprints fertig ist.

"Wie viele Stunden haben Sie noch für diese Unteraufgabe übrig?"

Das ist eine vernünftige Frage. Antworte einfach ehrlich. Mir ist klar, dass das sehr schwer zu tun ist. Ich war dort. Ich denke, Entwickler sind von Natur aus optimistisch. Wir werden uns eine Aufgabe ansehen und denken, "das dauert nur ein paar Stunden" und bevor Sie es wissen, ist der ganze Tag vergangen. Deshalb funktioniert Agilität - wir geben unsere Grenzen bei der Schätzung zu und tun unser Bestes, um die Dinge in möglichst kleine Teile zu zerlegen.

Bryan Oakley
quelle
2

Bitten Sie den Scrum Master, den Zweck eines Sprint- und Stand-Up-Meetings zu klären. Fast jeder, der mit Scrum arbeitet, würde sagen, dass der Zweck eines Sprints darin besteht, zu entscheiden, was während der Länge des Sprints getan wird, und ich habe noch nie gehört, dass während eines Sprints etwas fällig ist.

Vielleicht müssen Sie sich um Notfälle kümmern, die wirklich nichts mit einem Sprint zu tun haben. Teams / Entwickler, die diese Aufgaben außerhalb des Sprints haben, müssen sicherstellen, dass sie nicht die Zeit dafür in die Sprintplanung einbeziehen. Vielleicht haben Sie einen 8-Stunden-Arbeitstag, aber wenn Sie 1-2 Stunden damit verbringen, Feuer zu löschen, können Sie nicht erwarten, dass dies als Teil der Schätzung berücksichtigt wird.

In Bezug auf Standup-Meetings möchten Sie möglicherweise ein anderes System vorschlagen, um zu verfolgen, wann bestimmte unmittelbare Aufgaben wie eine Art Support-Ticket-System erledigt werden. Diese sollten nicht einmal während des Aufstehens besprochen werden.

Es scheint, als müsste Ihr Scrum-Master entweder umgeschult werden oder überdenken, warum Sie Scrum überhaupt machen. Es ist nicht für alle Gruppen und Situationen geeignet. Jemand an der Spitze hat sich nicht eingekauft.

JeffO
quelle
"Der Zweck eines Sprints besteht darin, zu entscheiden, was während der Dauer des Sprints getan wird": Und selbst dieses Ziel kann möglicherweise aufgrund falscher Schätzungen nicht erreicht werden, z. B. wenn zusätzliche Implementierungsdetails während der Implementierung selbst klar werden.
Giorgio
@Giorgio - Ich würde sagen, der Zweck eines Sprints ist es, zu entscheiden, was Sie "versuchen", um fertig zu werden. Wenn Sie zu kurz kommen, planen Sie damit den nächsten Sprint. Das ist der Vorteil eines iterativen Prozesses. Wenn es ein totaler Fehler ist, verschrotte einfach den Sprint und starte einen neuen. Es gibt nichts zu gewinnen für die zukünftige Planung, wenn Sie eine drastische Fehleinschätzung vorgenommen haben, außer nicht den gleichen Fehler zu machen.
JeffO
2

Ich habe Mikromanagement wie dieses erlebt und bin erfolgreich damit umgegangen, sehr transparent und kommunikativ zu sein. Es dauert nicht lange, um das Vertrauen des Managers zu gewinnen. Sie bauen Vertrauen auf und sie ziehen sich zurück. Manchmal gibt es sogar mehr Platz und Spielraum. Ihr Manager fühlt sich möglicherweise unsicher oder außer Kontrolle, was dies für ihn erleichtert. Natürlich ist es nicht ideal, aber Sie sind ein Team und sollten alle das gleiche Ergebnis wollen. Viel Glück.

Nicole N.
quelle
Empathie. Das ist eine mächtige Fähigkeit, die nicht jeder beherrscht :-). Es ist jedoch gut zu verstehen, warum der Manager so viel Wert auf die Planung legt, wenn in Agile der Schwerpunkt auf den Menschen liegt. Das Verständnis der Schmerzen des Managers kann helfen, das Warum des Drucks zu kontextualisieren. Der Manager und das Unternehmen sollten sich jedoch bewusst sein, dass Schätzungen genau das sind. Annahmen. Nicht Mathe, deshalb sollten sie auch Empathie gegenüber den Entwicklern üben und ihnen Anerkennung zollen.
Laiv
1

"Es wird getan, wenn es fertig ist."

Es ist sinnlos zu versuchen, Schätzungen der Fertigstellung von Entwicklern zu erhalten. Schätzungen sind ungenau, insbesondere wenn sie zeitbasiert sind. Darüber hinaus neigen Personen in Führungspositionen dazu, diese Schätzungen als Verpflichtungen zu interpretieren, was zu den schädlichen Auswirkungen führt, die Ihre Entwickler spüren.

Eine Möglichkeit wäre, die Beantwortung der Frage in Bezug auf zeitliche Verpflichtungen zu vermeiden.

"Diese Aufgabe wird erledigt, nachdem ich die Dinge A, B und C erledigt habe."

"Okay. Und wie lange wird das dauern?"

"Wir werden am Ende des Tages sehen."

Das Ändern der Konversation von zeitlichen Verpflichtungen zu dem, was getan werden muss, kann helfen, den Vorteil zu nutzen und zu zeigen, dass "wie lange es dauern wird, bis es erledigt ist" weniger wichtig ist als "was es braucht, um erledigt zu werden".

Binskits
quelle
2
Ich bin damit einverstanden, dass es im Allgemeinen sinnlos ist, stundenweise Schätzungen vorzunehmen, insbesondere für etwas Kreatives wie das Programmieren, das große Mengen ununterbrochener Arbeit erfordert. Aber andere Menschen müssen zu Recht wissen, wann wir bereit sind, daher sind Schätzungen auf einer Skala von Tagen oder Wochen erforderlich. Wenn „Scrum“ dem im Weg steht, ist Scrum und nicht die Schätzung das Problem. Die gute Nachricht: Schätzungen werden besser, wenn Sie sie üben, und können abgesichert werden: „Es besteht eine Chance von 50 bis 50, dass ich heute bereit bin, sonst morgen früh“. Ich habe auch gute Erfahrungen mit Techniken wie der Planung von Poker gemacht.
Amon
Ich bin damit einverstanden, dass Schätzungen für Personen außerhalb des Teams von Nutzen sein können, aber meine Antwort war spezifisch für die Frage des OP, wie mit Mikromanagement während Stand-ups umgegangen werden soll.
Binskits
1

Lassen Sie sich vom Scrum Master nicht einschüchtern. Sprechen Sie offen und offen über die bevorstehende Arbeit. Stellen Sie Fragen an sie / ihn wie die Dringlichkeit. Warum muss es bis 4 gemacht werden? Wenn es wirklich erledigt werden muss, müssen andere Aufgaben möglicherweise bis später verschoben werden. Es ist Ihre Gelegenheit, Fachwerk zu bauen. Frank Antworten sind besser früh als Ausreden später.

Randy Moulton
quelle
1

Je "mikro" das Management ist, desto schwieriger ist es, genaue Vorhersagen zu treffen. Wenn ich 20 achtstündige Aufgaben habe, dh Aufgaben, die nach vernünftigem Ermessen jeweils acht Stunden dauern, sollten sie in vier Wochen oder vielleicht ein paar Tagen mehr oder weniger erledigt werden. Wenn ich eine solche Aufgabe habe, gibt es viel mehr Variabilität.

Eine solche Aufgabe kann 10 Minuten dauern, wenn sich herausstellt, dass das zu lösende Problem viel einfacher ist als ich dachte. (Ist mir passiert, ich schätzte, dass ich ziemlich viel Code schreiben musste, und es stellte sich heraus, dass jemand anderes bereits genau das geschrieben hatte, was ich brauchte). Oder es kann eine Woche dauern (mein Code funktioniert nicht, weil ein Fehler in einer Bibliothek behoben werden muss, der dann alle möglichen bösen Konsequenzen hat). Für zwanzig Aufgaben gleichen sich diese Dinge aus. Nicht für eine Aufgabe.

Jemand bittet Sie, die Zukunft vorherzusagen. Das kannst du nicht machen. Und wenn Sie nach der Vorhersage eines einzelnen Ereignisses gefragt werden, hilft Ihnen die Statistik nicht weiter. Die Art von Person, die diese Fragen stellt, versteht die Bedeutung von "Schätzung" nicht. Wenn Sie also gefragt werden, ob dies in vier Stunden erledigt sein wird, sind die möglichen Antworten "sehr wahrscheinlich", "vielleicht, vielleicht nicht" und "sehr" unwahrscheinlich".

gnasher729
quelle
1

Das ist eine gute Frage. Ich antworte aus der Perspektive von jemandem mit 30 Jahren Erfahrung mit einem Jahrzehnt als engagierter Projektmanager in allen Bereichen außer der Softwareentwicklung, bin aber kürzlich unbeabsichtigt in den Bereich Softwareentwicklung gestolpert. Unabhängig von der Methodik, die in Ihrem Team angewendet wird, und der so genannten Methode sind Entwicklungsprojekte am Ende des Tages dieselben wie alle anderen in geschäftlicher Hinsicht, da die Ziele innerhalb konkurrierender Zeit-, Budget- und Qualitätsbeschränkungen erreicht werden müssen. - und während Projekte ausgeführt werden, bewegt sich das Geschäft weiter und hat gute Chancen, Änderungen in Ihr Projekt einzufügen. Daher ist es notwendig, Ziele und Zeitrahmen festzulegen und festzulegen und in der Lage zu sein, regelmäßig und auf Anfrage Aktualisierungen bereitzustellen. Ich nicht

Nach meiner Erfahrung ist es jedoch besonders schwierig, Zeitschätzungen in der Softwareentwicklung vorzunehmen, wenn Entwicklungsprojekte viele Neulandgebiete umfassen. Die technische Definition eines "Projekts" gemäß dem Project Management Institute of Knowledge des Project Management Institute lautet, dass ein Projekt eindeutig sein muss. Die überwiegende Mehrheit der "Projekte" in der IT sind jedoch bloße Neuausführungen zuvor entwickelter Blaupausen und Entwürfe sowie Implementierungslaufbücher. In der Softwareentwicklung verfügen wir über Frameworks und verschiedene generische Entwurfsmuster, die einen Großteil der Entwicklung wiederverwendbar machen. Dennoch ist der Kern jedes Projekts völlig einzigartig.

Darüber hinaus erfordern die meisten Entwicklungsprojekte die Integration in andere Systeme, und wie schnell dies durchgeführt werden kann, ist eine große Vermutung. Ich arbeite gerade an einem Projekt, bei dem meine ursprünglichen Zeitschätzungen auf der Annahme beruhten, dass die 4 Systeme, mit denen ich programmgesteuert interagieren muss, APIs haben würden, und es stellt sich heraus, dass dies keine tun. Darüber hinaus ist eines der Systeme in der Cloud gehostet, und meine Organisation verfügt über Richtlinien, die die Ausführung der Arbeit verbieten. Wer hätte das vorhersagen können?

Da Entdeckungen gemacht werden, die den Zeitrahmen gefährden, ist es wichtig, gut zu kommunizieren, warum die Verzögerung aufgetreten ist, warum sie nicht vorhersehbar war usw.

Mir wurde auch gesagt, dass der angegebene Zeitrahmen nicht funktionieren und es viel "schneller" machen würde. Eine andere Variante besteht darin, eine Bootsladung mit Änderungen zu erhalten, die in die Entwicklung eingebracht werden können, ohne dass zusätzliche Zeit zur Verfügung steht. In der Physik gibt es ein Gesetz, das besagt, dass Materie nicht geschaffen oder zerstört werden kann, und dies kommt mir in den Sinn, weil es mir so scheint, als könne Zeit auch nicht aus dem Nichts geschaffen werden. Eine Beschleunigung der Entwicklung wird sich wahrscheinlich negativ auf die Release-Qualität, die Unterstützbarkeit des Produkts und / oder die zukünftige Entwicklung des Produkts auswirken.

Anfragen zum Zeitplan sollten allgemein beantwortet werden. "Ja, wir sind auf dem richtigen Weg, um die zuvor festgelegten Fristen einzuhalten, und es gibt keine Probleme beim Brauen, die dies gefährden." Anfragen, ohne mehr Zeit einen erheblichen Umfang hinzuzufügen oder einfach die Bereitstellung zu beschleunigen, sollten eine Form von "Wir können das tun, aber nur damit alle wissen, dass das Risiko von Fehlern von Natur aus besteht, da ein Großteil der Entwicklungszeit proaktiv ist." um keine Fehler einzuführen und auch umfassend zu testen. " Wenn sie mit "Also einfach schneller testen" antworten, erhalten sie eine Antwort, die erklärt, dass Entwicklungstests keine Leerlaufzeit mit sich bringen und beschleunigt werden können, ohne dass das Risiko fehlender Fehler besteht.

Zusammenfassend schlage ich lediglich vor, dass alle Entwickler - nicht nur die Leads, Scrum Master oder Projektmanager - bereit sind, ihre Aufgaben in einem Geschäftskontext zu diskutieren und Diskussionen über die Änderung von Projektparametern zu führen, indem sie die Kompromisse berücksichtigen, die sich daraus ergeben würde ergeben.

Thomas Carlisle
quelle
Dies ist eine einschüchternde Antwort. Erst im sechsten Absatz sehe ich etwas, das einer umsetzbaren Antwort ähnelt, und ich höre fast auf zu lesen, bevor ich dort ankomme. Möglicherweise möchten Sie es neu schreiben, um die endgültige Antwort zu erhalten ("Anfragen zum Zeitplan sollten allgemein geschäftlich beantwortet werden"), und anschließend die Erklärung abgeben.
Bryan Oakley
0

Sobald die Arbeit ausgeführt oder abgeschlossen ist, wird die geschätzte verbleibende Arbeit aktualisiert.

- Scrum-Anleitung , Seite 15

Jeder Entwickler sollte seinen Aufgabenstatus und die geschätzten verbleibenden Stunden jeden Tag in dem von Ihrem Team verwendeten Produktivitätswerkzeug (z. B. TFS) aktualisieren.

Die einfache Antwort an Ihren Manager besteht darin, ihn in die Spalte "Verbleibende Stunden" in der Aufgabenliste zu leiten. Hoffentlich wird er erfahren, dass er selbst auf diese Nummern zugreifen und keine dummen Fragen mehr stellen kann.

John Wu
quelle
1
Der Scrum-Leitfaden sagt nichts darüber aus, wie die Arbeit geschätzt wird. Es kann durchaus sein, dass die Arbeit in Aufgaben unterteilt ist und dass das Update auf dem Abschluss der Aufgabe und den verbleibenden Aufgaben basiert.
RibaldEddie
Wenn eine Aufgabe in mehrere Unteraufgaben unterteilt ist, sollte der Scrum Master weiterhin sehen können, wie die aktuellen Schätzungen sind.
mhr
0

Indem Sie eine der oben genannten Fragen stellen. Der Scrum Master versucht zu entscheiden, ob wir auf dem richtigen Weg für diesen Sprint sind und ob es Blockierungsprobleme gibt, damit Sie diese Aufgabe erfüllen können.

Story-Punkte korrelieren nicht mit Arbeitsstunden, sie sind nicht dazu gedacht, aber wenn er fragt, ob Sie bis zu einem bestimmten Datum etwas tun können, fragt er wirklich, was Sie davon abhält, an dieser Aufgabe teilzunehmen? Wenn Sie etwas fragen müssen, ist es meiner Ansicht nach seine Aufgabe, sicherzustellen, dass Sie in der Lage sind, am Sprint teilzunehmen, das ist es, was er wirklich fragt ...

JamesD
quelle