Auslösekriterien zum Ändern eines Release Candidate

In einem Softwareentwicklungsprojekt, bei dem wir alle drei Wochen eine Veröffentlichung planen, habe ich einen Kunden, der die UAT für einen Veröffentlichungskandidaten um etwa 4 Wochen verzögert hat.

Die Geschäftsleitung sieht keine Notwendigkeit, sie zu drängen, aber das bereitet uns Probleme. Damit das Team nicht ins Stocken gerät, haben wir mit der Arbeit an einigen zukünftigen Funktionen begonnen, aber diese stehen nach einigen geringfügigen Änderungswünschen zur ursprünglichen Arbeit im Widerspruch und werden viel Zeit in Anspruch nehmen, um sie wieder in die nächste Version zu integrieren.

Die Kundenbeziehung ist schwer zu sagen das Beste. Wie würden Sie dem Kunden die Schwierigkeiten mitteilen? Die Beantragung von Fördermitteln ist keine Option.

Antworten (2)

Ich bin anderer Meinung als @CodeGnome. Prozesse und Pläne dürfen nicht einseitig sein – sie müssen von allen Parteien des Projekts oder eines Systems vereinbart werden. In Ihrem Fall ist der Kunde eindeutig nicht mit Ihnen einverstanden – aus Gründen, die Sie nicht angegeben haben oder die Ihnen vielleicht nicht bekannt sind. Auch Ihre Geschäftsleitung ist nicht bereit, mit Ihnen zusammenzuarbeiten, um Ihr Problem zu lösen. Warum ist das so?

Sie können keinen "Plan für die Veröffentlichung alle 3 Wochen" haben, wenn der Kunde die UAT um 4 verzögert. Es scheint, dass der Kunde nicht an der Priorisierung der Arbeit für die nächste Version beteiligt ist, noch am Abgleich von Änderungsanforderungen mit dem ursprünglichen Umfang des Projekts ( obwohl Ihr Satz "aber diese sind nach einigen geringfügigen Änderungswünschen zur ursprünglichen Arbeit widersprüchlich" nicht sehr klar ist.)

Meiner Meinung nach müssen Sie entweder jemanden finden, der den Respekt und/oder die Autorität hat, diese Diskussion zu führen, oder es auf sich nehmen – es könnten sehr gut Sie sein, da Sie das Team leiten –, eine offene und aufrichtige Diskussion darüber zu führen Herausforderungen, denen Sie und Ihr Team gegenüberstehen, und damit auch der Kunde und damit auch das Management. Schließlich entstehen dem Kunden durch die Verzögerung finanzielle Kosten! Seien Sie auf jeden Fall auch bereit, Lösungen anzubieten – wie z. B. Ihr Team dazu zu bringen, UAT-Fälle zu schreiben (es muss einen Grund geben, warum sie UAT verzögern!) oder irgendetwas anderes, das zur Lösung von Problemen beiträgt.

Sie alle müssen an die eigentliche(n) Ursache(n) der Situation herangehen, einen Prozess ausarbeiten, dem alle zustimmen, und die Ziele – sowohl funktional als auch finanziell – des Projekts ausarbeiten. Nur dann können Sie den Erfolg sehen.

In meinen (viel zu vielen) Jahren Erfahrung habe ich viele solcher Erfahrungen gemacht (schwierige Kunden, widerwilliges Management) – und was letztendlich funktioniert hat, ist, dass vernünftige Männer und Frauen zusammenkommen, eine Perspektive bekommen und Dinge lösen. Leider dauert es fast immer viel zu lange – und die Menschen, die am meisten darunter leiden, sind das Team, das an dem Projekt arbeitet.

Ich hoffe, das hilft – und Sie können dieses Gespräch mit dem Kunden führen. Sobald Sie sich auf den Prozess geeinigt haben, halten Sie auf jeden Fall die Linie an, wenn sich diese Situation das nächste Mal entwickelt.

Danke Mahesh, ich führe diese Gespräche. Wir nehmen kleine – nicht widersprüchliche Änderungen vor, die wir den Funktionen hinzufügen, und stellen unsere UAT-Fälle bereit – teilweise, um die tatsächlichen Anforderungen zu bestätigen, wenn sie sich mehrdeutig anfühlen, und teilweise, um dem Kunden zu helfen.

Verwenden Sie Jidoka als Prozesssteuerung

Bei Kanban, das stark auf die Zusammenarbeit aller Parteien angewiesen ist, um die definierten Warteschlangen und Work-in-Progress-Limits einzuhalten, ist das Richtige, wenn ein Fehler im Fluss auftritt, „die Linie zu stoppen“.

Dies bewirkt ein paar nützliche Dinge:

  1. Es stellt sicher, dass sich Fehler nicht stromabwärts ausbreiten.
  2. Es stellt sicher, dass Produktions-/Prozessfehler in der gesamten Organisation sichtbar gemacht werden.
  3. Es verhindert, dass Work-in-Progress (WIP)-Limits verletzt werden, da unvollständige Arbeit in der UAT-Warteschlange auf das vereinbarte globale WIP-Limit angerechnet werden sollte.
  4. Es verhindert kaskadierende Fehler, die durch die Arbeit an zukünftigen Iterationen verursacht werden, wenn die aktuelle Iteration unvollständig ist.
  5. Es macht die Kosten des Prozessfehlers deutlich, da die Linie nicht fortgesetzt werden kann, bis das Prozessproblem behoben ist oder der Prozess neu entwickelt wurde.

Dies ist kein Kommunikationsproblem; Es ist ein Prozessproblem. Sie müssen es als solches behandeln und geeignete Prozesskontrollen anwenden, um sowohl die Informationen auszustrahlen als auch die Abweichung vom Plan zu korrigieren. In diesem Fall ist „Stoppen der Linie“ die richtige Prozessführung.

Mir ist bewusst, dass wir das tun sollten. Aber es bedeutet auch, dass ich ein Team von 3 Entwicklern habe, für die keine geplante Arbeit ansteht. Der Kunde bezahlt uns nach Funktion, nicht nach Zeit und Material (was ich schrittweise ändern möchte). Das Anhalten der Linie ist also keine praktikable Option.