Wie kann verhindert werden, dass sich die Entwicklungsspezifikation während der Entwicklung ändert?

Problem : Es scheint, als ob bei fast jedem Entwicklungsaufwand, mit dem ich zu tun habe, unabhängig davon, wie viel Zeit für die Planung vor dem Beginn der Entwicklung aufgewendet wird, immer eine große Menge an Änderungen erforderlich ist, entweder auf halbem Weg oder gegen Ende des Projekts. Dies sind manchmal große Veränderungen, die eine Menge Neuentwicklung erfordern.

Ich arbeite nicht für Kunden, die Geld bezahlen. Dies ist ein internes Entwicklungsteam auf internen Entwicklungswebsites. Es ist also nicht so, als könnte ich dafür eine Gebühr erheben. Und am Ende des Tages müssen wir versuchen, die Fristen einzuhalten.

Fragen : Was sind die besten Möglichkeiten, um zu verhindern, dass Spezifikationsänderungen auf halbem Weg oder nach der Entwicklung auftreten?

Es gibt ein berühmtes militärisches Sprichwort, das Helmut von Moltke zugeschrieben wird: "Kein Schlachtplan überlebt den Kontakt mit dem Feind". Aus dem gleichen Grund denke ich nicht, dass es möglich ist, eine Spezifikation zu erstellen, die nicht geändert werden muss - es sei denn, Sie können die Zukunft vorhersagen und die Meinungen der Stakeholder lesen (selbst dann haben sie sich möglicherweise noch nicht entschieden, auch wenn sie behaupten, sie hätten es getan). Ich würde stattdessen vorschlagen, es auf verschiedene Arten anzugehen:

1. Machen Sie eine klare Unterscheidung, was geändert werden kann und was nicht. Kommunizieren Sie es klar mit den Stakeholdern, lassen Sie sie unveränderliche Dinge so schnell wie möglich explizit abzeichnen.
2. Bereiten Sie sich auf die Änderung im Voraus vor. Verwenden Sie Codemethoden, mit denen die austauschbaren Teile einfacher ausgetauscht werden können, und investieren Sie in Konfigurierbarkeit, Kapselung und klare Protokolle, mit denen Teile unabhängig voneinander ausgetauscht und ersetzt werden können.
3. Sprechen Sie häufig mit den Stakeholdern, holen Sie Feedback und Zustimmung ein. Dies würde Sie beide auf dem Laufenden halten und vermeiden, dass sie behaupten "Oh, das ist nicht das, was wir wollten", wenn es zu spät ist. Wie in anderen Antworten erwähnt, helfen Ihnen dabei agile Methoden und häufige Mini-Releases.
4. Tragen Sie die Zeit in den Zeitplan ein, um den unvermeidlichen Änderungen Rechnung zu tragen. Haben Sie keine Angst davor, zu Beginn zu sagen, dass wir mehr Zeit brauchen, wenn Sie glauben, dass dies der Fall ist. Wenn der Zeitplan, den Sie erhalten, unrealistisch ist, ist es besser, ihn zu Beginn zu kennen (und Sie haben das in der Akte) als um das Ende.
5. Wenn die Änderungen zu umfangreich sind und die Frist bedrohen, drücken Sie zurück und sagen Sie etwas wie "Diese Änderung ist möglich, wird aber die Frist um das X-fache verschieben, treffen Sie Ihre Wahl".
6. Führen Sie einen formellen Prozess durch, in dem Sie Änderungen anfordern, Prioritäten setzen und Änderungen an Versionen oder Releases zuweisen. Wenn Sie den Leuten sagen könnten, "Ich kann es in dieser Version nicht tun, aber ich würde es gerne für die nächste Version terminieren", ist es viel besser, ihnen zu sagen, "Sie sind zu spät, Ihr Wechselgeld kann nicht eingehen "Auf Wiedersehen" und würde sie zu deinem Freund machen - sie würden sich freuen, wenn du sie rechtzeitig freigibst, damit du früher frei bist, um zur nächsten Veröffentlichung zu gelangen, die ihr Wechselgeld haben wird - und nicht zu deinem Feind.

Liefern Sie etwas (ich zögere, das Wort irgendetwas zu verwenden) früh und liefern Sie häufig. Das heißt - verwenden Sie eine Art iterative Entwicklungsmethode.

Dies ist die Basis der Agilen Entwicklung, kann aber mit (fast) jeder Methodik verwendet werden.

Indem Sie das Projekt in eine Reihe von Miniprojekten aufteilen, erhalten Sie mehr Kontrolle, da Sie dem Kunden frühzeitig etwas vorlegen können. Sie sind nicht an einen langen Entwicklungsplan gebunden, der veraltet ist, wenn der Kunde seine Meinung ändert Sie werden).

Wenn sich das System weiterentwickelt, ändern sich einige Anforderungen, andere werden überflüssig, und andere erhalten höhere Priorität. Durch einen kurzen Projektlebenszyklus werden Sie jedoch in der Lage sein, diese Änderungen zu bewältigen.

Die Theorie, dass es möglich ist, ein Softwareprojekt jeder bedeutenden Größe vollständig zu spezifizieren, ist eine völlige Fantasie. Es hat sich herausgestellt, dass diese Theorie in der gesamten Geschichte der Softwareentwicklung in großen und kleinen Organisationen nicht funktioniert.

Sie MÜSSEN einen Weg finden, um Änderungen zu berücksichtigen, während Sie gehen! Sie werden passieren, weil die meisten Stakeholder, auch wenn sie sagen "Ja, das ist was ich will", keine Ahnung haben, was sie wollen, bis es vor ihnen liegt. Deshalb haben wir so viele Leute, die iterative Methoden anwenden.

Unabhängig davon, ob Sie das Produkt iterieren oder was auch immer, MÜSSEN Sie einen Weg finden, um diese Änderungen zu berücksichtigen, da die Schwerkraft nur darum bittet, sich für ein paar Minuten selbst auszuschalten, damit Sie fliegen können.

Versuche nicht, Veränderungen zu verhindern, sondern nimm sie an. Je mehr Sie im Voraus planen, desto wahrscheinlicher wird sich Ihr Plan ändern. Planen Sie also weniger , nicht mehr. Verwenden Sie eine agile Entwicklungsmethode, bei der Sie häufig kleine Teile des Arbeitscodes bereitstellen und dem Kunden die Möglichkeit geben, die Spezifikationen alle paar Wochen zu ändern.

Sie stellen die falsche Frage. Spezifikationsänderungen werden immer in Softwareentwicklungsprojekten jeder Größe vorgenommen.

Oft liegt es daran, dass sich die Geschäftsanforderungen ändern, aber ich habe auch gesehen, dass Kunden (intern oder extern) Schwierigkeiten haben, sich vorzustellen, was möglich ist, ohne etwas zu sehen, von dem sie abweichen können Entwicklungslösung.

Die Frage, die Sie stellen sollten, lautet nicht "Wie kann ich die Spezifikation sperren", sondern "Wie kann ich meinen Code und meine Prozesse strukturieren, um auf eine sich ändernde Umgebung zu reagieren, ohne alles wegzuwerfen, was ich bereits geschrieben habe?"

Dies führt Sie dann in die Modewort-Bingo-Arena: Agile Methoden, iterative Entwicklung und technische Lösungen wie komponentenbasiertes / modulares Codieren, kontinuierliche Integration ... die Liste geht weiter.

Ich sage nicht, dass dies eine Silberkugel für all Ihre Probleme ist, aber sie sind alle entstanden, weil Sie die Situation, die Sie beschreiben, so gut managen wollten, dass sie zumindest eine Untersuchung wert sind.

Es tut mir leid, wenn dies keine konkreten Lösungen bietet, aber ich bin der Meinung, dass sich ein Umdenken in Bezug auf das Akzeptieren und Verwalten von Veränderungen mehr auszahlt als der Versuch, dies zu vermeiden.

Eine Veränderung ist nur eine Überraschung ... wenn es eine Überraschung ist!

Ich würde vorschlagen, darüber nachzudenken:

• Woher kommen diese Veränderungen überhaupt?
• warum bist du dir ihrer nicht früher bewusst?
• Warum tragen Sie nicht zu diesen Änderungen bei (und machen möglicherweise noch mehr daraus)?

Veränderung ist die Natur dessen, was wir tun. Seit wann haben Sie einen Algorithmus genau so programmiert , wie er am ersten Tag geplant war?

Wenn Sie jedoch vermeiden möchten, dass der frustrierte Entwickler ständig von Änderungen "überrascht" wird, sollten Sie sich näher an die Entscheidungsprozesse heranwagen. Immerhin bin ich mir sicher, dass Sie jede Menge Ideen haben, wie Sie das Produkt verbessern können. Nehmen Sie einen Platz am Tisch ein oder akzeptieren Sie für immer, dass Sie sich nur um diese "Überraschungsänderungen" kümmern müssen.

Nun, das ist eine obwohl Anruf, Kunden wollen immer mehr, aber hier sind ein paar Punkte, die Sie berücksichtigen sollten:

HTML-Mock-ups: Erstellen Sie immer HTML-Mock-ups, um den UI-Teil einer Anwendung zu definieren, zeigen Sie ihnen, wie er aussehen wird, und fragen Sie sie nach ihrer Meinung. Wenn Sie etwas zumutbares finden, um es zu ändern, lassen Sie es im HTML-Prototypen geschehen. Auf diese Weise können Sie viele Dinge wie Probleme mit der Benutzeroberfläche, den grundlegenden Ablauf und einige Add-Ons (wie Sortieren, Paginieren, Anzahl der anzuzeigenden Datensätze usw.) aussortieren.

Aktive Teilnahme vom anderen Ende: Dies ist sehr wichtig, wenn Sie sich für eine Unternehmensorganisation entwickeln, sie bitten, Ihre Zweifel zu klären und sie unbedingt zu fragen, welche Änderungen sie in ihrem Ablauf wünschen (falls erforderlich).

Modulare Freigabe: Geben Sie Ihren Code modular frei, geben Sie ihn frei, testen Sie ihn, nehmen Sie Feedback entgegen und geben Sie ihn erneut frei.

Deshalb ist es fast unmöglich, zu weit im Voraus zu planen, aber keine Entschuldigung, überhaupt nicht zu planen. Verlieben Sie sich nicht zu sehr in Ihre Pläne und Sie müssen sich keine Sorgen machen, dass sie Ihnen das Herz brechen.

In Ihrem Unternehmen fallen Kosten für die Nutzung der IT-Ressourcen an, unabhängig davon, ob diese von jemandem bekannt sind, nachverfolgt werden oder ob ein Budget dafür erforderlich ist oder nicht. Die Realität ist, dass Ihr Team in einer bestimmten Zeit nur so viel Code erstellen kann. Alle Abteilungen und Projekte teilen sich dieses Budget.

Sie können niemanden daran hindern, die Anforderungen zu ändern, aber sie können den Konsequenzen nicht entgehen. Änderungen können die Entwicklungszeiten erheblich verlängern. Das ist eine Tatsache, mit der sie sich auseinandersetzen müssen oder die Entscheidung treffen, die Änderung nicht vorzunehmen. Betrifft eine Anfrage von einer Abteilung eine andere? Möglicherweise müssen Sie das Projekt vollständig hinter eine andere Abteilung verschieben, da sich die Änderungsanforderung auf den Zeitplan einer anderen Gruppe auswirkt.

Die aktive Beteiligung der Benutzer während des gesamten Entwicklungszyklus und die Verwendung einer möglichst agilen Methodik helfen uns bei unseren Produkten.

Spezifikationsänderungen sind unvermeidlich, aber da sie für die Benutzer transparent sind und vor allem häufig eingesehen werden, werden die meisten Änderungen so früh wie möglich erfasst.

Für mich ist das ganz einfach.
Sagen Sie dem "Product Owner" , der die Funktionen bestellt hat, dass dies in Ordnung ist, aber er muss ein paar geplante Funktionen auswählen, auf die er für diese Frist verzichten könnte.
Stellen Sie sich das als ein halbes Sprint-Meeting mit dem PO vor, bei dem Sie ihm sagen, dass der Sprint nicht auf 0 abbrennt.

Ps. Wenn es nicht die "PO" ist, würde ich sagen, rede nicht mit mir, gehe durch die "PO"

Was sind einige der besten Möglichkeiten, um zu verhindern, dass Spezifikationsänderungen auf halbem Weg oder nach der Entwicklung auftreten?

Es gibt keine besten Wege. Es liegt in der Verantwortung des Managements, die Änderungen der Spezifikation in einer bestimmten Phase der Entwicklung zu begrenzen.

Sie sollten Ihre Software jedoch so gestalten, dass Sie die Änderungen erwarten. Dann wären die Auswirkungen von Änderungen viel geringer. Iterative und inkrementelle Entwicklung ist ein guter Anfang.

Ich habe festgestellt, dass Kunden direkt oder indirekt die Ursache für die meisten Änderungen sind (und auch für die kritischsten Fehler, BTW). Die naheliegende Lösung besteht also darin, Kunden auszuschalten. (Was nützen sie überhaupt?)

Da Sie Veränderungen nicht verhindern können, müssen Sie sie annehmen. Ich denke, das Wichtigste, was Sie tun können, ist, dass Sie versuchen müssen , die Änderungsanforderungen so früh wie möglich vom Kunden zu erhalten , da es weniger kostspielig ist, Änderungen vorzunehmen, wenn nur wenig Code vorhanden ist. Daher müssen Sie dem Kunden Ihr Design so früh wie möglich präsentieren, indem Sie Prototypen (möglicherweise sogar einen Papierprototyp) verwenden, agile Methoden anwenden und so weiter.

Sie könnten erwägen, mit einer Methode wie SCRUM eine gewisse Disziplin in den Entwicklungsprozess einzuführen. In SCRUM erstellt ein Team einen ersten Plan, indem es die Implementierung von Features in Storys aufteilt und jeder Story eine Aufwandsschätzung zuweist (Anzahl der Arbeitsstunden oder Tage, die für die Implementierung dieser Story erforderlich sind).

Wenn eine späte Änderung angefordert wird (für eine Story, die bereits implementiert wurde), müssen Sie eine neue Story erstellen und den Implementierungsaufwand dafür schätzen. Dann können Sie zu Ihrem Manager (dem Product Owner ) gehen und einfach erklären, dass die neue Funktion diese zusätzliche Zeit kosten wird. Der Projektmanager ist dann dafür verantwortlich, den zusätzlichen Aufwand zu akzeptieren und den Zeitplan anzupassen (möglicherweise andere, noch nicht implementierte Storys zu stornieren).

Selbst wenn Ihr Team SCRUM oder einen anderen Entwicklungsprozess nicht vollständig implementieren wird, können Sie zumindest die Planung basierend auf Storys einführen, den Entwicklungsaufwand für jede Story schätzen und den Zeitplan anpassen, wenn neue Storys angefordert werden.

http://teddziuba.com/2010/05/why-engineers-hop-jobs.html

Ich habe zu viele Abende nach der Arbeit gestresst und unglücklich verbracht, weil noch ein anderer Junge nicht versteht oder sich darum kümmert, wie das Software-Geschäft funktioniert. Ich habe kein Problem damit, jemanden zu konfrontieren, aber ich habe nicht die Unterstützung meiner Nerd-Kollegen. Kinder zu haben ist eine Schlampe, was? Ich werde wahrscheinlich bald aufhören.

Ehrlich gesagt, ich wünschte, Programmierer hätten im Allgemeinen mehr Bälle. Schauen wir uns das an:

"" Ich arbeite nicht für Kunden, die Geld bezahlen. Dies ist ein internes Entwicklungsteam auf internen Entwicklungswebsites. Es ist also nicht so, als könnte ich etwas dafür verlangen. Und am Ende des Tages Wir müssen versuchen, die Fristen einzuhalten. "" "

Wenn Sie es mit einem Kunden zu tun haben, der $ zahlt, und wenn Sie Ihren Arsch durch einen Vertrag abgedeckt haben (http://vimeo.com/22053820?utm_source=swissmiss), dann würden Änderungen der Spezifikation diesen Kunden mehr Zeit UND mehr Geld kosten ( oder möglicherweise die gleiche oder weniger Zeit, aber exponentiell mehr Geld). Ihr Unternehmen versucht, die technischen Daten nicht zu ändern, ohne mehr Zeit und Geld zu kosten.

In der Zwischenzeit verursacht der Versuch, Termine einzuhalten, Ihnen und Ihren Mitarbeitern unnötigen Stress. Sie können nicht ein Qualitätswochenende mit Freunden / Familie verbringen. Es ist wirklich unnötig, denn wer Arbeit auf dich wirft, weiß es wahrscheinlich nicht einmal, was traurig ist.

Meine vorgeschlagene Lösung: Lassen Sie die Bälle gemeinsam mit ihnen konfrontieren und erklären Sie, dass es kein kostenloses Mittagessen gibt und alles Kosten verursacht, dass ein Automechaniker länger dauert und mehr berechnet, wenn die Spezifikationen während der Arbeit geändert werden, dass eine Vertragsagentur länger dauert und mehr verlangen, wenn die technischen Daten während der Arbeit geändert wurden, und es gibt einen guten Grund dafür. Wenn sie nicht bereit sind, in angemessener Weise mit Ihnen zusammenzuarbeiten, stehen Sie als Gruppe auf und müssen Entwickler einstellen, die das Projekt dort abholen können, wo es aufgehört hat, und es pünktlich liefern.

Dann gibt es auch ein Versprechen der agilen Entwicklung, das keine harten Fristen impliziert.

Ich muss noch Programmierer streiken sehen, aber das wäre etwas gewesen. Inkompetente Manager sind in Softwareunternehmen zu häufig. Viel zu viele Leute wollen etwas für nichts, auf Craigslist oder in einem tatsächlichen Unternehmen. http://teddziuba.com/2011/07/the-craigslist-reverse-programmer-troll.html

Programmierer müssen mehr Bälle haben.

Ein Ansatz, den ich für in Ordnung befunden habe (nicht bei allen Managern offensichtlich), ist: "Ich denke, ich kann das, ja. Es hängt davon ab, wie viel zusätzliche Zeit Sie für dieses Projekt aufwenden. Es ist eine ziemlich große Änderung, die Sie sind anfordern. "