Refactoring in der agilen Entwicklung
In einem App-Entwicklungsprojekt wurde der gesamte Umfang des Projekts im App-Design nicht berücksichtigt. Das häufige Refactoring von Codes zur Anpassung an Änderungen wirkt sich daher negativ auf den Zeitplan für die Projektabwicklung aus, der während eines Sprints erforderlich geworden ist. Wie kann dies am besten kontrolliert werden, um das Risiko einer Überschreitung des vereinbarten Termins für die Projektabwicklung zu minimieren, da die Stakeholder nicht bereit sind, Kompromisse einzugehen?
Antworten
TL; DR
Teil eines jeden Projektmanagement-Frameworks, insbesondere eines agilen Frameworks wie Scrum, ist die Notwendigkeit, die Erwartungen der Stakeholder kontinuierlich zu verwalten. Die Leute wollen, was sie wollen, wann sie es wollen, aber ein großer Teil des Projektmanagements erklärt den Leuten, was sie tatsächlich innerhalb der verschiedenen Einschränkungen haben können, die sich auf das Projekt auswirken. Wenn sich das Projekt weiterentwickelt, sollte auch das Verständnis dessen, was derzeit innerhalb der aktuellen Grenzen machbar ist, insbesondere dann, wenn das, was machbar ist, von dem abweicht, was ursprünglich geplant war.
Nacharbeit wird erwartet
Das Refactoring ändert die Implementierung, ohne das externe Verhalten zu ändern. Höchstwahrscheinlich werden Sie nicht wirklich umgestaltet. Sie zahlen technische Schulden ab oder führen Nacharbeiten und Integrationen durch, die an sich nicht dasselbe sind.
Frameworks wie Scrum behandeln verschiedene Arten von Arbeiten (einschließlich Refactoring und Nacharbeit) als akzeptablen Kompromiss für empirische Kontrolle und Design. Dies wird im Schätzprozess behandelt und zeigt sich (korrekt) als Geschwindigkeitsverlust, wenn die technische Verschuldung, die Komplexität oder das Tempo des Wandels zunimmt. Dies ist in einem iterativen Rahmen sowohl zu erwarten als auch wünschenswert , da jede Inspektions- und Anpassungsschleife die Möglichkeit bietet, den Umfang, die Priorisierung oder den Ansatz zu ändern.
Nacharbeit sind die Kosten der empirischen Kontrolle. In komplexen Projekten wie der Softwareentwicklung kann man das nicht wirklich vermeiden. Scrum macht die Überarbeitung nur für das Team und die Stakeholder sichtbar , da die Kosten für notwendige oder wünschenswerte Änderungen anfallen.
Fixed-Alles ist nicht möglich
Das "Eisendreieck" setzt voraus, dass Sie ein Projekt anpassen können, indem Sie Budget, Umfang oder Zeitplan steuern. Die Qualität ist eine implizite vierte Dimension, die von den anderen drei Schiebereglern beeinflusst wird. Die folgende Grafik zeigt dies.
Agile Frameworks wie Scrum behandeln im Allgemeinen den Umfang und insbesondere den Projektumfang als Hauptschieberegler, indem sie fragen:
Wie viel Spielraum können wir in die Zeitbox eines einzelnen Sprints oder in unseren agilen Release-Plan einpassen ?
Derzeit versucht Ihr Projekt, sowohl den Umfang als auch den Zeitplan festzulegen. Damit bleibt nur das Budget als verfügbarer Schieberegler. Wenn Sie versuchen, dies ebenfalls zu sperren, schlägt entweder Ihr Projekt fehl oder die Qualität leidet oder beides. Sie können in keinem Projektrahmen zuverlässig einen festen Preis, einen festen Umfang und einen festen Zeitplan festlegen, während die Qualität erhalten bleibt. Scrum macht es einfach offensichtlicher und macht die Kompromisse sichtbarer.
Der Sinn von Scrum ist nicht, das Eisendreieck auf magische Weise verschwinden zu lassen. Stattdessen wird das Projekt (sowie die Stakeholder und Sponsoren) gezwungen, sich mit den inhärenten Kompromissen auseinanderzusetzen. Mit Scrum können Stakeholder feststellen, ob etwas "gut genug" ist, um am Ende jedes Sprints versendet zu werden, und der Product Owner erhält die Möglichkeit, den Umfang und die Priorisierung während der Backlog-Verfeinerung und der Sprint-Planung anzupassen. Die Stakeholder müssen diese Ereignisse nutzen, um sicherzustellen, dass sie den größtmöglichen Nutzen aus dem Release-Plan ziehen. Es ist niemals eine Geld-zurück-Garantie, dass das Projekt am Ende einer festgelegten Reihe von Sprints entweder zu 100% abgeschlossen oder zweckmäßig ist.
Sinkkosten senken
Ein weiterer Aspekt der agilen Entwicklung ist die Möglichkeit, "früh zu scheitern". Wenn ein Projekt aus irgendeinem Grund wahrscheinlich fehlschlägt, bieten agile Frameworks wie Scrum dem Product Owner die Möglichkeit, Geld zu sparen, indem Sie einen Sprint stornieren und einen neuen planen, der auf geänderten Erwartungen basiert, oder den Stakeholdern ermöglichen, den Rest des Projekts abzubrechen, wenn dies der Fall ist wird ihren Zwecken nicht dienen. Letzteres führt nicht zum Erfolg des Projekts, reduziert jedoch die mit dem Projekt verbundenen versunkenen Kosten.
Nichts, was jemand tut, kann garantieren, dass ein Projekt erfolgreich sein wird. Das Beste, was Sie tun können, ist, die Kontrolle darüber zu behalten und ein zum Scheitern verurteiltes Projekt so früh wie möglich zu beenden, wenn Erfolg keine Option mehr ist.
Was Sie jetzt tun können
Bestätige zunächst, dass du auf dem Weg zu einem Todesmarsch bist. Wenn Sie sich dieser Wahrheit nicht stellen, ist nichts anderes von Bedeutung, was Sie tun.
Stellen Sie als Nächstes fest, ob das Problem Design, technische Schulden, unangemessene Erwartungen oder etwas anderes ist. Es spielt keine Rolle, was die Grundursache oder die Ursachen sind; Sie müssen sie nur sichtbar machen, damit das Team und die Stakeholder sie gemeinsam ansprechen können.
Schließlich kommunizieren eindeutig den aktuellen Status. Wenn Sie einige Zyklen nach dem ursprünglich geplanten Liefertermin auf dem Weg zu einer Veröffentlichung mit vollem Funktionsumfang sind, besprechen Sie, ob das Projekt den Scheitelpunkt "Zeit" anpassen kann. Wenn Sie den Zeitplan nicht anpassen können oder wollen, können Sie die festgelegte Frist trotzdem einhalten, indem Sie die Kosten erhöhen oder den Umfang verringern. Würden die Stakeholder pünktliche Lieferungen eintauschen, um zeitaufwändige Funktionen einzuschränken? Sie werden es nicht wissen, wenn Sie nicht fragen.
Wenn das Projekt eines der oben genannten Dinge nicht ausführen kann oder will, bereiten Sie sich auf einen Fehler vor. Aktualisieren Sie Ihren Lebenslauf und hoffen Sie, dass Sie wertvolle Lektionen gelernt haben, die Sie für Ihr nächstes Projekt oder Ihren nächsten Job verwenden können. Hoffen Sie vor allem, dass Sie gelernt haben, früh und häufig über Annahmen, Herausforderungen, Rahmenanforderungen und Kompromisse zu kommunizieren, und die Bedeutung der kontinuierlichen Verwaltung der Erwartungen der Stakeholder verinnerlicht haben.
Produzieren Sie bei jedem Sprint ein implementierbares Produktinkrement? Wenn ja, werden die vereinbarten Liefertermine bereits eingehalten. Dies ist der beste Weg, um das Risiko zu minimieren und dem Kunden Vertrauen in Ihre Aktivitäten zu geben. Die Stakeholder (über den Product Owner) sollten entscheiden können, welche Dinge sie wann wollen. Das Wichtigste ist also, dass sie weiterhin sehen, dass Sie Wert liefern, und dass Sie ihr Feedback zu Verbesserungen, Änderungen und Korrekturen erhalten, die für das Produkt erforderlich sind. Hier ist es wichtig, ihr Feedback zu erhalten. Kunden sind verständlicherweise besorgt, wenn sich der Zeitplan ohne neuen Funktionsumfang erstreckt. Sobald Sie jedoch die neuesten Verbesserungen einbeziehen, die sie als Priorität betrachten, werden sie die Notwendigkeit von Flexibilität eher zu schätzen wissen.