Angenommen, ein Kunde oder Product Owner erstellt eine Aufgabe, die wie folgt aussieht:
Ändern Sie die Lokalisierung
Old termin allen Orten in der App für die Sprache .New termX
Und das Entwicklungsteam muss dafür eine Schätzung abgeben. Aber es gibt keine Person im Team, die die Codebasis gut genug kennt, um eine Liste aller Vorkommen zu erhalten. Das Projekt ist einfach zu groß und besteht bereits seit mehreren Jahren .
Wir können davon ausgehen, dass wir nur die Lokalisierungsdatei(en) für language ändern X, aber was ist, wenn jemand versehentlich irgendwo die Lokalisierung hartcodiert hat (und dies ist für das konkrete Projekt durchaus möglich) ... Außerdem Old termkann es Teil mehrerer anderer größerer Sätze sein in Lokalisierungsquellen, die über die gesamte App verteilt sind!
Was sollten wir in einer solchen Situation tun:
Es ist wichtig zu erwähnen, dass die Schätzung mehr oder weniger verbindlich sein sollte und die Aufgabe selbst ziemlich klein ist, wenn wir einen konkret definierten Umfang hätten.
PS: Konzentrieren Sie sich nicht auf die konkreten Beispieldetails, hier sind ein paar weitere Beispiele, um die Gesamtsituation besser zu beschreiben:
Ändern Sie die Farbe aller
greenSchaltflächenredauf allen Seiten der Website.
Die Abschlussanimation für jede erweiterbare Komponente (Dropdown, Spoiler, "Mehr anzeigen" usw.) muss eine Dauer von genau
Nms haben.
Verhandeln.
Sprechen Sie mit demjenigen, der die Anforderung gestellt hat. Erklären Sie die Situation und die damit verbundenen Herausforderungen. Das Ergebnis kann eine Änderung in der Definition der Anforderung sein, oder vielleicht werden sie zustimmen, dass zuerst eine Untersuchung durchgeführt werden muss, um eine zuverlässigere Schätzung zu erhalten.
Alle Anforderungen sollten verhandelbar sein. Dies ist wichtig, wenn Sie einen agilen Ansatz verfolgen und zusammenarbeiten möchten.
Aus diesem Grund enthält die INVEST- Mnemonik auch N für verhandelbar.
Interessante Frage.
Für mich würde ich die Arbeit so planen:
Teilen Sie dem Anfragesteller mit, dass Änderungen, die nicht vollständig spezifiziert sind, zu einem Plan führen, der eine größere Bandbreite an Schätzungen enthält. (Nebenbei: Das ist Sophistik; alle Pläne sind Schätzungen, die auf Bandbreiten basieren. Werte in einem Plan, die nicht durch eine Bandbreite modifiziert werden, sind unter dem technischen Projektmanagement-Begriff "Fiktion" bekannt; ehrliche Pläne basieren auf einer Schätzung und einer Bandbreite um diese Schätzung herum. Je vager die Aufgabenstellung, desto breiter die Schätzspanne)
Katalogisieren Sie die Instanzen des „alten Begriffs“ in der vorhandenen Codebasis. Beginnen Sie mit einer einfachen Suche in der Codebasis, aber speichern Sie die Antwort in einem vereinbarten Repository . (Dies sollte eine Aufgabe sein, die relativ einfach einzuschätzen ist, basierend auf der Annahme, dass der erste Entwurf des Katalogs nicht mehr als 80 % genau sein wird.)
Schätzen Sie die Zeit, um alle Instanzen des „alten Begriffs“ in den „neuen Begriff“ basierend auf dem Katalog zu ändern.
Führen Sie die Aktualisierung basierend auf der Schätzung in 2 durch.
Als normaler Teil des „Buffing the Backlog“ (Sie geben Scrum nicht an, daher verwende ich den Begriff locker – unabhängig von Ihrer Methodik gibt es eine Liste von Arbeiten, die sich „im Backlog“ befinden), aktualisieren Sie den Katalog des „alten Begriffs“. Dies sollte auch Teil der Code-Wartung sein – wenn Sie an einem Fehler arbeiten und eine Instanz von „altem Begriff“ finden, aktualisieren Sie den Katalog. Wenn Sie einen untätigen Moment haben und sich der Aussicht auf eine weitere kundenorientierte Aufgabe nicht stellen können, versuchen Sie, den Katalog zu aktualisieren. Wenn Sie einen jüngeren/neuen Mitarbeiter haben, der eine Aufgabe benötigt, die ihm hilft, sich mit der Codebasis vertraut zu machen, aktualisieren Sie den Katalog. Wenn sich die Größe des Katalogs erheblich ändert, aktualisieren Sie die Schätzung in 2.
Warum enthält Ihre Codebasis nicht bereits eine Liste mit Querverweisen von Funktionen/Begriffen/Variablen/Einstiegspunkten? Fügen Sie dem Rückstand den Aufwand hinzu, der erforderlich ist, um den Katalog zu einem vollständigen Index Ihrer Codebasis zu erweitern. Diese Investition wird sich durch die Beschleunigung zukünftiger Änderungen, die Reduzierung von Fehlerdiagnosen, bessere Schätzungen usw. auszahlen.
Bevor das Team dies schätzt, müssen einige Verfeinerungen vorgenommen werden. Jemand, vielleicht mehrere Personen, aus dem Team sollte sich die Zeit nehmen, diese Arbeit zu verstehen und zu untersuchen, um zu sehen, was der Umfang ist. Sie können die spezifischen Abschnitte des Systems identifizieren, die aktualisiert werden müssen, und sie notieren. Die Verfeinerung und Identifizierung der betroffenen Teile des Systems kann dem Team helfen, die Arbeit einzuschätzen. Diese Untersuchung kann auch Wege finden, die Arbeit so aufzuteilen, dass es sinnvoll ist, inkrementell zu liefern.
In einigen Fällen kann die Änderung äußerst dringend sein. In diesem Fall kann es das Risiko wert sein, die Arbeit einfach so lange zu erledigen, bis sie erledigt ist. Es lohnt sich vielleicht nicht, die Arbeit zu schätzen, sondern einfach damit anzufangen. Es besteht jedoch immer das Risiko, dass etwas Unerwartetes passiert und die Arbeit nicht abgeschlossen ist. Wenn dies ein akzeptables Risiko ist, können später nach der Erstlieferung zusätzliche Änderungen als Folgearbeiten durchgeführt werden.
Es gibt zwei Möglichkeiten, es zu tun, richtig;
Schätzen Sie ab, welche weniger Zeit in Anspruch nehmen wird, und teilen Sie dem Kunden Ihre Empfehlung gemäß der Priorität des Kunden mit. Aufwand vs. Qualität des Outputs. Zum Beispiel: „Wenn wir die Entdeckung machen, wird der Aufwand zu hoch. Beginnen wir mit den Änderungen ohne Entdeckung; es kostet weniger. Aber wenn wir einige Teile vermissen, werden wir sie in der Produktion finden und versuchen, sie so schnell wie möglich zu beheben ."
Die Definition von „alle“ ist eigentlich ganz klar und eindeutig. Schlimmere Übeltäter sind: „richtig“, „gute Qualität“, „zu hoch“. Sie sind Mittelweg, ohne numerischen / messbaren Bezug.
Wenn Sie also eine Anfrage mit "all" erhalten, sollten Sie (zusammen mit Ihrem Team) Folgendes tun.
Das ist grundlegendes Projektmanagement und grundlegendes Requirements Engineering.
Wählen Sie eine Teilmenge von "all" aus, die Sie vernünftig einschätzen können, erstellen Sie eine neue Geschichte dafür und priorisieren Sie diese Geschichte vor den anderen. Hoffentlich wird die Arbeit am reduzierten Umfang dem Team einen besseren Einblick in die größere Arbeit geben.
Alternativ, da Sie sagen, dass die Aufgabe "ziemlich klein" ist, wenn der Umfang bekannt ist, ist sie vielleicht klein genug, dass Sie einfach ein kalkuliertes Risiko eingehen können, dass sie in einer Iteration erledigt werden könnte, und sehen, wie weit das Team kommen kann. Wichtig ist nicht die Schätzung, sondern das Vertrauen des Teams, dass es in einer einzigen Iteration abgeschlossen werden kann.