Wie gehe ich mit 'externen' Abhängigkeiten in Scrum um?

Wenn Sie mehrere User Stories für einen Sprint geplant haben und eine Kandidaten-Story davon abhängt, dass ein externer Anbieter Ihrem Team etwas liefert. Zum Beispiel ein Onlinedienstanbieter, der seinem System einen neuen API-Aufruf hinzufügt oder Ihr Testkonto auf seinem System aktiviert.

Sie wissen, dass es "bald" kommt.

Fügen Sie die Geschichte dem Sprint hinzu, in der Hoffnung, dass sie die für die Fertigstellung Ihrer Geschichte erforderliche Zeit liefert, oder warten Sie bis zum nächsten Sprint, wenn Sie wissen, dass er fertig ist und Sie sofort loslegen können, auch wenn Es bedeutet, die Geschichte nicht so früh wie möglich zu beginnen.

Wenn erstere, wie gehen Sie mit "unverdienten" Story-Punkten um, die aufgrund der Abhängigkeit verloren gehen? Teilgutschrift (eek!) oder am Kinn nehmen.

Letztendlich hängt es davon ab, ob Sie zu 100% davon überzeugt sind, dass der externe Anbieter etwas liefert, das Sie zum gewünschten Zeitpunkt nutzen können.

Wenn Sie nicht sicher sind, ob sie rechtzeitig geliefert werden, fügen Sie die Story nicht zum Sprint hinzu. Nur weil sie in der Vergangenheit immer geliefert haben, gibt es keine Garantie, dass sie diesmal liefern werden.

Sie sollten dem Kunden mitteilen, dass diese Abhängigkeit besteht und dass Sie warten müssen, bis die API (oder was auch immer) verfügbar ist, bevor Sie die Arbeit planen können.

Auf der positiven Seite gibt es möglicherweise Aspekte der Story, die Sie liefern können - dh, Sie müssen sie weiter aufteilen, bis Sie die Abhängigkeiten so weit wie möglich isoliert haben. Dies könnte es Ihnen ermöglichen, einen Teil der Geschichte zu erzählen, bevor der Lieferant seine Arbeit liefert.

Eine Möglichkeit besteht darin, eine Schnittstelle zwischen Ihrem Code und der Drittanbieter-API zu erstellen. Sie codieren in Ihre Benutzeroberfläche, damit der Rest des Projekts fortgesetzt werden kann, und bis Sie die echte API haben, verwenden Sie einen Schein, um Beispieldaten zurückzugeben. Wenn dann die echte API eintrifft, müssen Sie nur den Code hinter der Schnittstelle ändern, der den Rest der Anwendung nicht beeinträchtigt. Tun Sie dies nur, wenn Sie mit dem Lieferanten der API übereinstimmen können, dass sich deren Schnittstelle nicht ändert (zumindest nicht drastisch).

Das Team ist dasjenige, das die Verpflichtung eingeht. Wenn wir in unserem Team das Gefühl haben, auf (zum Beispiel) einen externen Entwickler zu warten, haben wir gelernt zu sagen, dass wir nicht bereit sind, die Geschichte aufzugreifen. Die Geschichte ist nicht in einem Zustand, in dem sie aufgegriffen werden kann.

Es besteht eine sehr gute Chance, dass sich Ihre Schätzungen und Prioritäten aufgrund der verspäteten, unerwarteten oder von der externen Ressource abweichenden Zustellung ändern.

Bis Sie alle Informationen haben, sollte das Team nicht so naiv sein, um zu glauben, dass es die Geschichte vervollständigen kann. Wenn sie sagen, dass sie es können, dann kommt es zu spät, in einem erwarteten Format oder überhaupt nicht, sie haben alle im Stich gelassen.

Klingt hart, aber ich möchte meinen Standpunkt klarstellen.

In Scrum gibt es eine Definition von "Fertig" und eine Definition von "Bereit für User Stories". In einer Situation wie Ihrer ist es wichtig, eine Definition von bereit zu haben, mit der alle Beteiligten einverstanden sind. Zum Beispiel scheint es sehr vernünftig, eine Zeile in Ihrer Definition von fertig zu haben:

• Alle für die Story erforderlichen externen APIs müssen bereitgestellt und getestet werden.

Wenn Sie diese API benötigen, um Ihrem Produkt einen Mehrwert zu verleihen, müssen Sie logischerweise warten, bis wir wirklich über diese API verfügen, um mit der Arbeit zu beginnen. In der Zwischenzeit können wir auch andere US-Produkte herstellen, die dem Produkt einen Mehrwert verleihen. Ich mag diese US-Produkte mit nachgemachten Implementierungen und dergleichen nicht wirklich. Wenn der Kunde keinen echten Wert hat, gibt es keine US-Produkte, die Zeit und Ressourcen verschwenden .

Wenn Sie auf etwas warten, das Sie noch nicht wissen, können Sie es nicht planen, auch wenn Sie zu 100% sicher sind, dass es morgen geliefert wird. Warum? Denn wenn Sie es nicht kennen, können Sie seine Komplexität nicht einmal einschätzen, und wenn Sie es nicht einschätzen können, können Sie es nicht planen.

Wenn Sie im Voraus ein "Interface" / "Vertrag" definiert haben, das von einer externen Firma befolgt werden muss, können Sie es planen und auf Ihrer Seite ein Service-Mock erstellen. In Ihrer Entwicklung wird der gespielte Service verwendet, sodass diese nicht von einer externen Lieferung abhängig sind. Die Entwicklung mit Mock sollte für den Sprint geplant werden, bei dem der echte Service erbracht wird, da die für Mock entwickelte und getestete Funktion nicht abgeschlossen ist. Sie muss mit dem echten Service getestet werden, der am Ende des Sprints als abgeschlossen gilt.

Kommunikation und Vereinbarungen

Zwei Systeme werden von Programmierern und nicht von der Methodik selbst integriert. Wenn sich ein Unternehmen für die Integration eines externen Systems entschieden hat, besteht ein Vertrag zwischen (mindestens) 2 Unternehmen. Der Vertrag muss die Integration sicherstellen . Wenn die Vereinbarung zwischen den Unternehmen keine technische Zusammenarbeit zwischen beiden Abteilungen erfordert, liegt das Problem folglich nicht in der Entwicklungsmethodik. Das Problem ist die Geschäftsmethodik (im Grunde genommen der Vertrag) .

Allerdings muss dies bei der Planung dieser Fälle als Risiko eingestuft werden. Wenn Sie die Geschwindigkeit des Teams nicht kennen , müssen Sie mit diesen Spielräumen großzügig umgehen.

Wie kann ein Projektmanager eine Abhängigkeit von einem externen Team verwalten?

/pm/1400/how-can-a-project-manager-manage-a-dependency-on-an-external-team

Wenn es nicht von Ihrem Team abhängt und Sie andere Aufgaben erledigen können, empfehle ich Ihnen, es nur zu übernehmen, wenn es fertig ist. Selbst wenn Sie einen Mockup-Webservice, ein Schema, eine Schnittstelle und / oder einen Vertrag haben, kann es dennoch zu einer Unterbrechung kommen (erinnern Sie sich an Murphys Gesetz?).