Sollten uns in Scrum Mängel und ungeplante Aktivitäten in Rechnung gestellt werden?

TL;DR

Ja. Im Rahmen Ihres aktuellen Vertrags und innerhalb Ihres aktuellen Prozesses sollten Sie den Anbieter für alle abgeschlossenen Arbeiten bezahlen. Sofern Sie keinen Festpreisvertrag mit festem Umfang haben, handelt es sich bei allen von Ihnen beschriebenen Problemen um Prozessprobleme, für die Ihr Unternehmen (und nicht der Anbieter) verantwortlich ist.

Sie haben Schwierigkeiten, weil Sie das Offshore-Unternehmen als externen Anbieter behandeln, anstatt bei jeder Iteration aktiv mit ihm zusammenzuarbeiten. Die Werte des Agilen Manifests :

Zusammenarbeit mit dem Kunden bei Vertragsverhandlungen[.]

Beide Probleme sind durch eine bessere agile Zusammenarbeit lösbar. In der Zwischenzeit sollten Sie aus rein pragmatischen Gründen wahrscheinlich die Rechnungen bezahlen, wenn Sie diese Firma weiterhin als Verkäufer nutzen möchten. Behandeln Sie es als versunkene Kosten und verbessern Sie Ihren Prozess, während Sie vorankommen.

Scrum Scoping und Ergebnisse

Basierend auf der folgenden Aussage nutzen Sie das Scrum-Framework nicht in Ihrem aktuellen Prozess. Du fragst:

Sollten wir für ungeplante Dinge bezahlen, die weder Teil unserer Anforderungen noch eine Änderungsanforderung von unserer Seite sind (z. B. die Bereitstellung auf dem Staging-Server funktioniert nicht, die Aktualisierung der Codebasis zur Unterstützung der neuesten iOS-Version usw.)?

Diese Frage hebt mehrere Probleme mit Ihrem aktuellen Prozess hervor, darunter:

1. Ihr Unternehmen sollte entweder den Product Owner für den Prozess bereitstellen oder aktiv als Stakeholder durch einen Product Owner auf der Anbieterseite zusammenarbeiten.
2. Ihre Erwähnung von „ungeplanter Arbeit“ weist darauf hin, dass Product Backlog Items nicht richtig zerlegt und zu Beginn jeder Iteration geplant werden.
3. Das Versäumnis, das Unerwartete zu erwarten, insbesondere in der IT, verstößt gegen das zentrale agile Prinzip, Veränderungen anzunehmen, und weist im Allgemeinen auf einen Mangel an ausreichendem Spielraum und iterativer Planung in Ihrem Prozess hin.
4. Die Erwähnung von „Anforderungen“ und „Änderungswünschen“ weist auf eine organisatorische Denkweise hin, die sich eher auf die Vorabspezifikation als auf eine wirklich iterative oder kollaborative Entwicklung konzentriert.

Um diese Art von Problemen zu beheben, müssen Sie höchstwahrscheinlich grundlegend ändern, wie Sie mit Ihrem Anbieter zusammenarbeiten. Mindestens:

1. Es muss eine klar definierte Product Owner-Rolle geben, und sowohl die Stakeholder als auch das Entwicklungsteam sollten aktiv mit dem Product Owner zusammenarbeiten, um den Umfang zu verwalten und die Ergebnisse zu priorisieren.
2. Die Arbeit für jede Iteration muss einer priorisierten Liste von Arbeitselementen (dem Product Backlog) entnommen und in Aufgaben für das Sprint Backlog zerlegt werden. Diese Just-in-Time-Planung ist unerlässlich, um den Umfang richtig festzulegen und erkennbare (aber möglicherweise ungeplante) Arbeiten zu identifizieren, die sich auf die aktuelle Iteration auswirken werden.
3. Ihr Prozess muss ausreichend Spielraum enthalten, um mit einem angemessenen Maß an Ungewissheit umgehen zu können. IT-Entwicklung ist eine ungenaue Wissenschaft, und die Erwartung einer 100-prozentigen Sicherheit oder 100-prozentigen Auslastung wird Ihnen bei Ihrer Planung sehr wenig nützen. Ein unausgereifter Scrum-Prozess sollte im Allgemeinen nur etwa 60 % der Teamkapazität anvisieren, um die Wechselfälle der Softwareentwicklung zu bewältigen.
4. Der Prozess muss damit beginnen, Product-Backlog-Einträge und das Product-Backlog als fortlaufende Konversation zwischen Stakeholdern und dem Entwicklungsteam zu behandeln. Das Backlog ist keine Liste feststehender Spezifikationen; Jedes Element im Backlog ist ein Ausgangspunkt für iterative Planung und gemeinsame Entwicklung.

Tests, Mängel und die Definition of Done

Sie können nicht erwarten, dass jemand ein sich bewegendes Ziel trifft. Wenn du sagst:

Sollten wir nach dem Benutzerakzeptanztest für das Entwicklungsteam bezahlen, um Fehler zu beheben, die wir in Funktionen finden, die sie als vollständig geliefert haben?

Sie sagen implizit, dass Sie sich das Recht vorbehalten, die Ziellinie zu verschieben, nachdem Sie sich bereits auf die Definition of Done für einen Arbeitsschritt geeinigt haben. Tu das nicht!

Die Frage zeigt, dass es im aktuellen Prozess an Test-First-Entwicklung mangelt und dass Sie und der Anbieter nicht aktiv an der Definition of Done für Product Backlog Items zusammenarbeiten. Um dies zu lösen, muss der Prozess von subjektiven, post-facto-Tests zu objektiven (und idealerweise ausführbaren) Kriterien zur Erfolgsmessung wechseln.

Um die Lücken im aktuellen Prozess zu schließen, sollten Sie Folgendes sorgfältig prüfen:

1. Arbeiten Sie mit Ihrem Entwicklungsteam an den Akzeptanztestkriterien zusammen, bevor sie eine Entwicklung durchführen. Dadurch wird sichergestellt, dass sich alle auf eine objektive Definition von „potentiell lieferbar“ für das Inkrement einigen.
2. Arbeiten, die die vereinbarten Kriterien nicht erfüllen, sind nicht mangelhaft; es ist einfach "nicht fertig".
3. Wenn Sie viel Arbeit haben, die am Ende jedes Sprints „nicht erledigt“ ist, ist dies das ideale Material zur Prozessverbesserung, das Sie in Ihrer Retrospektive besprechen können.
4. Wenn die Arbeit die vereinbarten Kriterien erfüllt, Sie aber Verfeinerungen oder Änderungen benötigen, dann ist dies zukünftige Arbeit , die zur Priorisierung und Planung in das Product Backlog gehört. Unvollkommen zu sein ist kein Mangel ; es ist ein Übergangszustand für emergente Designs innerhalb eines iterativen Entwicklungsprozesses.
5. Selbst wenn Sie im Nachhinein feststellen, dass sich alle auf die falschen Kriterien geeinigt haben, war es immer noch die anfangs vereinbarte Arbeitserhöhung. Das Entwicklungsteam sollte nicht bestraft werden, weil die Stakeholder und der Product Owner sie gebeten haben, das Falsche zu bauen.

Prüfen und iterativ anpassen !

Es gibt sicherlich noch andere Probleme mit dem aktuellen Prozess, die ebenfalls angegangen werden müssen. Stellen Sie sicher, dass Sie und der Anbieter bei einer gemeinsamen Retrospektive zusammenarbeiten, und arbeiten Sie bei jeder Iteration zusammen, um Ihren Prozess kontinuierlich zu überprüfen und anzupassen, bis er für Sie beide reibungsloser läuft.

Bitte denken Sie daran, dass "glatt" nicht perfekt bedeutet! Es bedeutet lediglich, dass der Gesamtprozess innerhalb definierter Toleranzen abläuft und dass die Projektmanagementkontrollen wie erwartet funktionieren.

Die Antwort auf diese Frage hat nichts mit Scrum oder irgendeiner anderen Entwicklungsmethode zu tun. Es ist eine Vertragsfrage. Ein Festpreis pro Person plus Auflistung der Aufgaben ist eine Zeit- und Materialvereinbarung. Das heißt, jede verbrannte Stunde für eine Aufgabe an Ihrem Produkt ist Ihre Haftung. Es bedeutet jedoch auch, dass Sie sich täglich mit diesen Aufgaben beschäftigen sollten, anstatt zum Zeitpunkt der Rechnungsstellung überrascht zu werden. Sie haben einen Platz am Tisch darüber, welche Aufgaben von wem ausgeführt werden sollen, weil Sie dafür bezahlen. Wenn Sie dieses Risiko nicht mögen, schließen Sie beim nächsten Mal einen Festpreisvertrag ab. Bei einem Festpreis können Sie jedoch davon ausgehen, dass Sie auf der höheren Seite der Spanne belastet werden, um die Risiken der Unbekannten abzudecken.

BEARBEITEN, um die Frage in den Kommentaren zu beantworten:

1. UAT ist Teil des SDLC. Es ist Teil der Produktentwicklung als Minderung des Qualitätsrisikos, um das Produkt vor dem Go-Live zu verbessern. Der Versuch, ein Szenario zu schaffen, in dem die Haftung für einen Fehler vom Anbieter bezahlt werden muss, führt zu einem Verhalten, das nicht mit dem Ziel der Qualitätsverbesserung vereinbar ist. Der Anbieter wird sich gegen die Feststellung von Mängeln wehren, und Sie werden viel Zeit – und Geld – aufwenden, um zu versuchen, einen Mangel anzuerkennen und zu bearbeiten. Außerdem können Sie davon ausgehen, dass sich der Anbieter viel mehr Zeit nimmt – und Ihnen viel mehr Geld in Rechnung stellt – um das Produkt vor der UAT zu entwickeln, um das Risiko einer Vertragsstrafe zu verringern.
2. Bekannte Unbekannte und unbekannte Unbekannte sind in Projekten eine Gewissheit. Wer dafür haftet, ist eine Vertragsfrage. Wenn Sie nicht für jede Überraschung bezahlen wollen, dann streben Sie einen festen Vertrag an; Aber täuschen Sie sich nicht, Sie werden diese Überraschungen auf irgendeine Weise im Festpreis bezahlen. Wenn Sie im Rahmen eines T&M versuchen, die Haftung für diese Überraschungen auf den Anbieter zu schieben, können Sie erwarten, dass sich der Anbieter schützt, indem er 1) das Problem nicht meldet, 2) die Schuld auf andere Ursachen konzentriert und 3) seine besten Talente umleitet auf andere profitablere Arbeiten und die Bindung mittelmäßiger Talente an Ihr Projekt, 4) Erhöhung der Stundensätze in der nächsten Verhandlungsperiode oder eine Kombination davon.

Ich denke, Sie möchten eine Partnerschaft mit Ihren Lieferanten für eine Win-Win-Lösung anstreben. Sich auf der einen Seite zu schützen, könnte bedeuten, dass Sie auf der anderen Seite teuer bezahlen werden.

Ja, Sie möchten, dass diese Dinge passieren, also sollten Sie gerne dafür bezahlen.

Indem Sie für Zeit und nicht für Funktionen bezahlen, entlasten Sie sich von der Last, jedes noch so kleine Detail der gewünschten Arbeit spezifizieren zu müssen, und entlasten Sie von der Last, jede Funktion schätzen zu müssen, einschließlich eines Budgets für unerwartete Überschreitungen. Insgesamt soll es billiger werden.