Wie gehen Sie mit sich ändernden Anforderungen um? [geschlossen]

In meinem jetzigen Job haben wir das Gefühl, dass sich viele Anforderungen ändern. Wir sind ein "agiler" Laden, also verstehe ich, dass wir uns anpassen sollen und was nicht, aber manchmal ist die Veränderung groß und nichts Triviales.

Meine Frage ist, wie Sie die Kosten der Änderung effektiv kommunizieren? Wenn eine Änderung groß genug ist, wird aus Gründen der Beweglichkeit etwas aus dem aktuellen Sprint entfernt, aber normalerweise wird es beim nächsten Mal hinzugefügt. Da es sich bei unserem Modell um SaaS handelt, ist der Endkunde im Grunde genommen das Unternehmen selbst, und er weiß, dass er die Schnittfunktion n Wochen später erhält .

Ich vermute, ich versuche zu erreichen, dass das Entfernen eines Features für die Kommunikation nicht wirklich von Nutzen ist, da es nur um n Wochen verzögert wurde . Welche anderen Möglichkeiten gibt es, damit das Unternehmen versteht, was eine Änderung kostet?

@Joe "Wir sind ein" Agiler "Laden, also verstehe ich, dass wir uns anpassen sollen und was nicht, aber irgendwann ist die Veränderung groß und nichts Triviales."

Wenn Sie mit Ihrem Prozess die Änderungsrate der Anforderungen nicht steuern können, ist Ihr Prozess nicht agil, sondern willkürlich. Agil bedeutet nicht, "etwas zu nehmen, das mir in den Weg kommt".

Um Anforderungsänderung / -schleichen zu steuern, können Sie in Ihrem Prozess die Vorstellung übernehmen, dass sich eine Anforderung nicht ändert (eine Vorstellung, dass sie das Herzstück von Scrum ist). Behandeln Sie eine Anforderungsänderung so, als ob Sie eine alte Anforderung durch eine neue ersetzen. Sie müssen einen Rückstand an Anforderungen haben und Sie müssen den Benutzer auswählen lassen, welche er / sie implementiert haben möchte.

Du wolltest X und Y in zwei Wochen, aber plötzlich willst du Z. Nun, dann kann ich dir alle drei in 4 Wochen liefern. Oder ich kann ein Paar (X und Z) oder (X und Y) oder (Y und Z) in zwei Wochen geben und das restliche später liefern. Wählen.

So verhandeln Sie mit Kunden. Auf diese Weise teilen Sie die Kosten für Anforderungsänderungen mit. Wenn Ihre Gruppe nicht über diese Macht verfügt, befinden Sie sich nicht in einem agilen Geschäft, und Sie können nichts dagegen tun. Es ist scheiße, aber es ist wahr.

Wenn Sie verhandeln können, müssen Sie die Zeit, die für die Implementierung von Anforderungen und Anforderungsänderungen erforderlich ist, genau nachverfolgen. Das heißt, Sie müssen diese Daten aus früheren und aktuellen Projekten sammeln.

Sie erfassen die ursprüngliche Zeitschätzung und die tatsächliche Fertigstellungszeit (zusätzlich zu Ressourcen wie der Anzahl der Entwickler) pro Anforderung (oder Modul, das von N Anforderungen betroffen ist). Besser noch, schätzen Sie die Größe der Anforderung / Anforderungsänderung (in Bezug auf Codezeilen oder Funktionspunkte in früheren Projekten und Anforderungen).

Angenommen, Sie haben eine Metrik, mit der Sie mit dem Benutzer sprechen können. Sie wissen, dass eine neue Anforderung beispielsweise 1 KB Codezeilen oder 10 Webseiten mit durchschnittlich jeweils 5 Eingabefeldern (50 Funktionspunkte) benötigt.

Schauen Sie sich dann die historischen Daten an, die für Ihre vergangenen Projekte spezifisch sind (einige nach Codezeilen, andere nach Webseiten, andere nach tatsächlichen Funktionspunkten), und schätzen Sie, wie sich diese Kosten jeweils auf die absolute Ausführungszeit auswirken. Für Benutzer mit ausreichenden Daten können Sie auch die Anforderungen identifizieren, die die tatsächliche Anzahl der Entwickler überwachen.

Dann verwenden Sie das und teilen Ihrem Kunden dies auf der Grundlage historischer Daten mit. Sie argumentieren, dass Projektfehler tendenziell einer exponentiellen Verteilung folgen. und dann sind Sie mit dem folgenden Argument für Ihren Kunden bewaffnet:

Basierend auf Daten aus früheren und gegenwärtigen Projekten und verfügbaren Ressourcen wird die von Ihnen gewünschte Anforderung erfüllt

1. X Zeitspanne bis zum Abschluss mit einer Wahrscheinlichkeit von 25% des Scheiterns (oder 75% des Erfolgs)

2. 1,5 * X Zeit bis zum Abschluss mit 5% des Scheiterns (oder 95% des Erfolgs)

3. 0,5 * x Zeit bis zum Abschluss mit 95% des Scheiterns (oder 5% des Erfolgs)

Die Ausfallwahrscheinlichkeit in Abhängigkeit von der Menge der Zeitressourcen beträgt in der Regel 95%, 25% und 5% (ähnlich einer exponentiellen Verteilung). Sie vermitteln die Nachricht, dass ein bestimmter Basisbetrag eine recht gute Erfolgschance bietet (jedoch mit echten Risiken verbunden ist ). 1,5 davon könnten bei minimalem Risiko fast eine gewisse Erfolgschance bieten, aber viel weniger (0,5 des Originals garantiert fast einen sicheren Misserfolg).

Du lässt sie das verdauen. Wenn sie sich immer noch für den riskanten Vorschlag entscheiden ( getan gestern! ), Haben Sie zumindest schriftlich, dass Sie es ihnen gesagt haben. Wenn es Hoffnung gibt, dass Ihre Gruppe nicht nur agil, sondern auch technisch ist, könnte der Kunde ernsthafte Überlegungen zu Ihren Zahlen anstellen und diese und zukünftige Anfragen entsprechend planen.

Es ist Ihre Aufgabe als Ingenieur, in ingenieurmäßigen, überprüfbaren und klaren Begriffen zu erklären, dass Änderungswünsche keine kostenlose Mahlzeit sind.

Nach dem, was Sie beschrieben haben, haben Sie kein Problem. Sie bitten um eine Änderung und sind entweder bereit zu warten, bis Sie sagen, dass dies möglich ist, oder sie sind bereit, eine andere Funktion zu verschieben. Scheint ein Gleichgewicht zwischen: Zeit, Ressourcen und Anforderungen.

Sie können versuchen, ein Mindestalter für eine neue Hinzufügung / Änderung festzulegen (gilt nicht für Fehlerkorrekturen). Zum Beispiel können keine neuen Änderungen bearbeitet werden, bis es 3 Wochen alt ist.

Ein Mindestalter für eine Aufgabe zu haben, ist schön, weil zu Beginn jede Aufgabe extrem wichtig erscheint, aber wenn Sie eine Weile warten, wird ihre Bedeutung oft erheblich sinken. Abhängig von Ihrem Zeitintervall erhalten Sie mindestens so viel Zeit für die Stabilisierung der Aufgaben, an denen Sie arbeiten.

Um das Alter zu verfolgen, würden Sie zulassen, dass die Aufgaben zu einer Liste hinzugefügt werden, sie würden jedoch nicht als Aufgaben angesehen, an denen Sie arbeiten müssen, bis dieser Zeitraum abgelaufen ist.

Dies ist ein weit verbreitetes Problem, unabhängig davon, wie schnell ein Projekt technisch voranschreitet. Der Kunde empfindet es als viel langsamer und kann seine Anforderungen gerne ändern, da er denkt, dass die Entwickler sowieso nicht viel tun müssen.

Diese fehlerhafte Wahrnehmung rührt von drei wichtigen Entwicklungsaufgaben her, die viel Zeit in Anspruch nehmen und von den Kunden nie richtig berücksichtigt werden:

1. Codeüberprüfungen / Bereinigung: Alter Code wird aufgebläht und durcheinander gebracht und benötigt regelmäßige Überprüfungen und Bereinigungen. Dies nimmt viel Zeit in Anspruch und der Kunde wird es nie glauben.
2. Sicherheitsüberprüfung und -korrekturen: Insbesondere wenn Sie Junior-Teammitglieder haben, treten viele Code-bezogene Sicherheitsprobleme auf, und Sie möchten regelmäßig den gesamten neuen Code durchgehen, der geschrieben wurde, und Dinge neu schreiben, die aus Sicherheitsgründen nicht gut aussehen Perspektive wird der Kunde nie wissen oder für diese Zeit verantwortlich.
3. Architekturbedingte Änderungen: Eine wachsende Codebasis kann (und wird höchstwahrscheinlich) an mehreren Stellen ein strukturelles Umdenken und Umgestalten erforderlich machen. Dies kann Folgendes umfassen: A - Leistungsbezogene Änderungen / Optimierungen (Algorithmusänderungen, Bibliotheksersetzungen, Cache-Engines usw.) oder: B - Produktivitätsbedingte Änderungen / Optimierungen (Lesbarkeit, Wiederverwendbarkeit des Codes, einfache Verständlichkeit, neue Kodierungskonventionen, ein neues Framework usw.).

Keiner der oben genannten Punkte wird jemals von Endkunden verstanden und ordnungsgemäß berücksichtigt.

Grundsätzlich wurde nichts getan, was keine "Ansichten" (GUI-Elemente) hat.

Nennen wir das den Satz von Projenix, haha, kein Scherz: D