Gibt es eine Alternative zur agilen Entwicklungsmethodik?

47

Die beiden vorherrschenden Methoden für die Softwareentwicklung sind Waterfall und Agile. Bei der Erörterung dieser beiden Aspekte liegt der Schwerpunkt häufig auf den besonderen Praktiken, die sie auszeichnen (Paarprogrammierung, TDD usw. im Vergleich zu Funktionsspezifikationen, umfassendes Design usw.).

Die wirklichen Unterschiede sind jedoch weitaus tiefer, da diese Praktiken aus einer Philosophie stammen.

Wasserfall sagt: Änderung ist kostspielig, also sollte sie herabgesetzt werden.
Agile sagt: Veränderung ist unvermeidlich, also macht Veränderung billig.

Meine Frage ist, unabhängig davon, was Sie von TDD oder funktionalen Spezifikationen halten, ob die Entwicklungsmethode für Wasserfälle wirklich praktikabel ist.

Ist jemand der Meinung, dass die Minimierung von Softwareänderungen eine praktikable Option für diejenigen ist, die wertvolle Software bereitstellen möchten? Oder ist die Frage wirklich, welche Praktiken in unseren Situationen am besten funktionieren, um den unvermeidlichen Wandel zu bewältigen?

Eric Wilson
quelle
1
interessante Frage. freue mich auf die antworten.
DevSolo
3
@ FarmBoy - Gute Frage. Ich sehe die agile Philosophie etwas anders. Ich würde es so schreiben: "Agile sagt: Veränderung ist unvermeidlich, also mach es billig, um die Kosten der Veränderung zu bestimmen." Änderungen können immer noch sehr teuer sein, aber bei Agile können Sie dies schnell und kostengünstig herausfinden, sodass wir immer die Kosten für Änderungen kennen. Wenn man es anders formuliert, denkt man, dass Veränderungen, da sie agil sind, billig sind. Einige Änderungen kosten viel, egal was der Prozess ist.
Mike Two
1
@Yannis Rizos: Warum schließen Sie diese interessante Frage alleine, ohne eine einzige Gemeinschaftsabstimmung?
1
@ Pierre303 wegen dieser Frage, die die Diskussion hier diese Frage aufgeworfen hat.
Ryathal

Antworten:

59

Wasserfall ist natürlich lebensfähig. Es brachte uns zum Mond!

Und es ist ein agiler Coach, der hier spricht!

Wenn Sie Probleme im Zusammenhang mit der Verwaltung Ihrer Projekte nicht eindeutig identifizieren können, gibt es keinen gültigen Grund für eine Änderung.

Als Alternative zu den Agile- und Waterfall- Methoden schlage ich IHRE Methodik vor . Angepasst an Ihr spezifisches Unternehmen, Ihr spezifisches Team, Ihre Produkte, Ihre Arbeitsweise, Ihre Unternehmenskultur ... Deshalb wird Scrum als einfaches Framework anstatt als Methodik bezeichnet.

Eine Methodik implementieren zu wollen, weil jemand in einem Blog, über das Sie gerne gesprochen haben, so dumm ist, als wenn man Probleme laufen lässt, ohne etwas zu tun.


quelle
10
+1 auf die IHRE Methodik, der nächste Agile Coach, der mir sagt, dass SCRUM der einzige Weg ist, wird einen Stiefel auf der Rückseite bekommen;)
Martijn Verburg
1
@karianna: Ich mache speziell SCRUM, aber manchmal ist es einfach nicht angebracht. Auf der anderen Seite habe ich auch gesehen, wie ein Team versucht, SCRUM an seine Chefs zu verkaufen, weil es meint, das Problem zu lösen. Sie haben versagt, weil das Problem nicht ihre Chefs oder ihre PM waren. Es gibt keine einzige Regel. Jeder Fall seine Lösung. Und ja, die meisten organisatorischen Probleme können mit agilen Techniken gelöst werden, aber agil ist keine Wunderwaffe.
5
Nicht nur der Mond. Das Space Shuttle hatte in seinen eingebetteten Systemen etwa 1 Million Zeilen C-Code. Über ~ 30 Jahre hatten sie nur 2 Bugs, die es in die Produktion schafften.
Dan Neely
2
Wasserfall tötete auch die ersten drei Astronauten. Dieses Bestehen darauf, dieses Apollo-Programm als Aushängeschild für Waterfall zu verwenden, ist bestenfalls unwissend. Waterfall wird auch als verantwortlich dafür angeführt, dass beide Programme komplette Finanz-Boondoggles sind, und dass das Shuttle ein überentwickelter, zerbrechlicher, teurer "Space Ferrari" ist, als die ursprüngliche Spezifikation für einen "Space Truck" war. Ich bin mir ziemlich sicher, dass SpaceX dem nicht zustimmen würde.
4
@DanNeely das hohe Qualitätsniveau der Space-Shuttle-Software war nicht billig. Offenbar war der Preis in der Größe von $ 1000 pro Zeile Code.
21

Zunächst werde ich mit Ihren Aussagen nicht einverstanden sein:

Wasserfall sagt: Änderung ist kostspielig, also sollte sie herabgesetzt werden.
Agile sagt: Veränderung ist unvermeidlich, also macht Veränderung billig.

Meine Interpretation ist:

Wasserfall sagt: Der Kunde weiß, was er will.
Agile sagt: Der Kunde weiß nicht, was er will, deshalb müssen wir ein paar verschiedene Versionen erstellen.

Die beste Implementierung von "waterfall", die ich je gesehen habe, war ein riesiges Integrationsprojekt mit einem sehr großen Finanzkunden, an dem über 40 Teilprojekte beteiligt waren. Das von uns gelieferte Desktop- und Website-Paket war nur eines dieser über 40 Unterprojekte. Während ich dachte, dass sie das Geld anderer Leute ziemlich übermäßig verschwendet haben, hatten sie ihre Sachen zusammen und hielten mehr als 40 verschiedene Schiffe in Formation zusammen. Das Projekt wurde zum Zieldatum in Betrieb genommen (das Ziel wurde während des Projekts einmal verschoben ), und obwohl ich dachte, dass sie es sparsamer und agiler hätten machen können, wurde es pünktlich und nach Vorgabe durchgeführt. Der Zeitplan für die Go-Live-Nacht war ungefähr 100 Seiten lang und ungefähr 40 dieser Seiten enthielten Notfall-Panik-Kontaktdaten aller beteiligten Personen. Dieser Kunde hat mich sehr beeindruckt.

Oder könnten Sie tun , was wir tun, die herumlaufen und das tun , was die jüngste Beschwerde / Fehlerbericht ist, und rufen Sie diesen agil.

Tangurena
quelle
8
Gemäß
Peter K.
11
Es ist eher so, als ob "Waterfall sagt: Der Kunde weiß nicht, was er will, also setzen wir uns,
besprechen
+1: Sehr gute Antwort. Ich denke, die agile Community hat ein grundlegendes Problem: Agile ist in bestimmten Kontexten für bestimmte Projekt- und Kundenklassen gut, aber sie sehen nicht, dass es Projekte gibt, bei denen sich die Anforderungen nicht ändern, dass schnellere und strukturiertere Ansätze die bessere Wahl sind . Ich denke, dass die agile Community versuchen sollte, die Bereiche, in denen ihr Ansatz die bessere Wahl ist, realistisch zu identifizieren (ich denke, dass es solche Bereiche gibt), und es nicht als allgemeine Lösung versuchen sollte, da dies nicht der Fall ist.
Giorgio
6
@scrwtp - und Agile ist eher wie "Mein Kunde weiß nicht, was er will, und kann / will nicht sprechen und überlegen, und sie ändern ihre Meinung alle 5 Minuten. Ich muss ihm etwas ins Gesicht schieben." um sinnvolle Antworten zu bekommen ". Beeindruckend. Das klingt wirklich bedauerlich, wenn ich es aufschreibe.
Michael Kohne
1
@scrwtp: Ich denke, die Millionen-Dollar-Frage lautet: Ist dieser "Glaube", dass man sich "hinsetzen und darüber reden und zustimmen" kann, realisierbar? Die Antwort lautet: Es kommt darauf an, oder? Es hängt von einer Reihe von Variablen ab: Wie groß ist das Projekt? Wissen wir überhaupt, wie groß es ist? Wie viel Zeit haben Kunden, um sich mit uns "zu setzen"? Wir haben jahrzehntelang versucht, Softwareentwicklung mit Konstruktion in Beziehung zu setzen, die fast zu 100% vorgeschrieben ist. Die Softwareentwicklung bewegt sich irgendwo zwischen "vollständig reaktionär" und "100% vorschreibend". In den meisten Läden ist es eher "reaktionär", was die Einführung von agile bedeutet.
Calphool
21

Sie beginnen mit den Worten:

Die beiden vorherrschenden Philosophie der Softwareentwicklung sind Wasserfall und Agilität.

Das ist falsch. Diese Dichotomie wurde von der agilen Community konstruiert, um einen Gegner zu schaffen, gegen den man sich positionieren kann. Bevor Agile in Mode kam, sprachen die Leute über eine Vielzahl unterschiedlicher Ansätze beim Erstellen von Software. Sie existieren noch heute, aber irgendwie werden sie oft von agilen Befürwortern zu einem großen Chaos namens "Wasserfall" zusammengefasst.

Ich benutze OPEN / Metis und seine Varianten seit über 10 Jahren mit großem Erfolg. Es ist definitiv nicht wendig und definitiv kein Wasserfall. Tausende von Entwicklern erstellen täglich äußerst komplexe Software für Flugzeuge, lebenswichtige Systeme, Bankgeschäfte usw. mit nicht agilen Methoden.

Ja, natürlich gibt es eine Alternative zu Agilität.

CesarGon
quelle
6
Ich bin nicht in der Lage, schnell zu verstehen, was OPEN / Metis von diesem Link ist. (Normalerweise müssen Sie keine Methodik herunterladen.) Meine Frage lautet: Was ist die Philosophie, insbesondere im Umgang mit Veränderungen? Versucht es, Änderungen zu minimieren oder die Änderungskosten zu senken? Denken Sie daran, dass meine Frage sich auf agile Philosophie und nicht auf agile Praktiken bezog.
Eric Wilson
OPEN / Metis hat einen iterativen Lebenszyklus, der Systeme schrittweise erstellt. Veränderung wird als etwas anerkannt, das nicht nur geschieht, sondern auch großartig ist , da der eigentliche Zweck der Entwicklung eines Informationssystems darin besteht, eine Veränderung herbeizuführen. Die Änderungskosten werden jedoch durch einen geeigneten Lebenszyklus und die damit verbundenen Verfahren gesteuert und verwaltet.
CesarGon
1
In Bezug auf Ihre Bemerkung zum "Herunterladen von Methoden", also ... Sie laden keine Methoden herunter, stimme ich zu. Sie laden Dokumente herunter, die Methoden beschreiben. Wie erfährst du sonst davon? Schauen Sie sich die unzähligen Bücher an, die XP, Scrum usw. beschreiben
CesarGon
1
@CesarGon Zu umschreiben Cheece und Chong: "Sieht aus wie
10

Ja, abhängig von Ihrer Problemdomäne sind verschiedene Softwareentwicklungstechniken möglich. Es ist "Pferde für Kurse".

Sie schreiben beispielsweise Software zur Steuerung eines Kernkraftwerks oder zum Fahren des NASA-Space Shuttles. Diese Art von Problemdomäne eignet sich wahrscheinlich besser für einen Wasserfallansatz (oder einen noch strengeren Ansatz). Sie möchten möglichst alle Probleme im Vorfeld lösen (oder BOOM!).

Erstellen Sie die neueste Web 2.0 / 3.0 / Buzzy-Marketing-Term-Benutzeroberfläche? Agile ist ein viel besserer Weg (Sie brauchen das schnelle Feedback und die schnelle Änderung).

Es gibt, was ich Software-Handwerksprinzipien nennen würde, die immer noch angewendet werden können, unabhängig davon, wie die Methodik lautet:

  • Quellcodeverwaltung
  • bauen und CI
  • Paar-Programmierung
  • TDD
  • Ich gebe ein ^% $$ &

und mehr.

Was auch immer Sie tun, hören Sie nicht auf die Eiferer auf beiden Seiten der Gleichung, tun Sie, was für Sie, Ihr Team und Ihre Problemdomäne richtig ist.

Martijn Verburg
quelle
Wasserfall funktioniert, wenn Sie es sich leisten können. Jemand oben behauptete, dass die Softwarekosten für das NASA-Mondprojekt etwa 1000 USD pro Codezeile betrugen. Die meisten Geschäfte benötigen ungefähr 1 bis 10 US-Dollar pro Codezeile, und Agile ist für solche Situationen besser geeignet. Ich behaupte jedoch nicht, dass Agilität insgesamt eine bessere Qualität bietet. Im Grunde läuft es darauf hinaus, dass Sie es sich leisten können, eine Menge Geld zu paginieren, um sicherzugehen, dass die Software korrekt ist, oder die Lösung billiger zu finden, wenn Sie feststellen, dass die Software nicht korrekt ist.
Mikko Rantalainen
2

Das Problem ergibt sich aus der Komplexität der Software. Wasserfall eignet sich hervorragend für Dinge wie Brückenbau und Straßenbau, da sich die Physik einfach nie ändert. Sicher, irgendwann werden wir einen neuen Asphalt entwickeln, aber er wird die Art und Weise, wie Straßen gebaut werden, nicht revolutionieren. Der Stahl in der Aufhängung einer Brücke hat entweder die richtige Größe oder nicht. Sie können ein echtes Bauprojekt nicht so kludgen oder stumpfen wie Sie es mit Software können.

Software Änderungen. Software ändert sich schnell. Moores Gesetz besagt, dass sich die Anzahl der Transistoren auf einem Chip alle 18 bis 24 Monate verdoppelt. Folglich verdoppelt sich auch die Anzahl der Codezeilen in einem Programm. Die Komplexität zwischen diesen Codezeilen steigt daher mit einem bigO von etwa 2 ^ (2t).

Software ändert sich schnell, und die Komplexität nimmt mit ihr exponentiell zu.

Wenn Sie die Kosten der Software steuern, möchten Sie nicht nur multiplikative oder additive, sondern auch exponentielle Faktoren steuern . Das Ändern von Code erhöht die Komplexität (und wird selbst im Verlauf des Projekts exponentiell komplexer) auf exponentielle Weise.

Veränderung ist unvermeidlich. Die Art der Programmierung erweitert die Sprache mit Klassen und benutzerdefinierten Methoden, wodurch die Sprache selbst geändert wird. Das kann man in keiner anderen technischen Disziplin tun (wie dem Bau von Straßen. Man erfindet keine neuen Pflastersteine, nur um eine Straße in Kansas über Kalifornien zu ebnen).

Die agile Methode bietet Ihnen auch eine Plattform für den Umgang mit zukünftigen Releases und Fehlerkorrekturen. Sie verfügen bereits über die Verwaltungstools, Prozesse und geschulten Mitarbeiter für die Entwicklung versionierter Software. Bei einer Wasserfallmethode müssten Sie Ihr Team umschulen, um auch kleinere Fehler zu beheben.

jedenfalls meine 2 cent.

Stephen Furlani
quelle
2
Es gibt viele Aspekte des Software-Designs, die so absolut sind wie die Gesetze der Physik. Agile ist ein Tool wie Waterfall oder andere Methoden, und wie bereits erwähnt, gibt es viele Geschäftsfälle, in denen dies keinen Sinn ergibt. Es würde mich wundern, wenn ich Sie in der Schlange sehen würde, um in ein Flugzeug zu steigen, in dem Boeing sagte, sie befänden sich mitten in einem agilen Prozess der Flugsteuerungssoftware, und sie brauchten Kunden, um zu überprüfen, ob das Flugzeug nicht ohne Weiteres in der Luft fliegt Grund.
Hounshell
Und mehr Löcher in Ihrem Argumente Schrotflinte, gibt es Straßen engineered - Designs werden jetzt die für eine Straße zwischen Kansas und Kalifornien angemessen wäre, aber nicht zwischen New York und Boston. Und ständig kommen neue Techniken für den Umgang mit Asphalt heraus.
Hounshell
2
Und zum Schluss sagen Sie: "Mit einer Wasserfallmethode müssten Sie Ihr Team neu trainieren, um auch kleinere Fehler zu beheben." Das ist so unwissend, wie der Wasserfallprozess funktioniert. Probieren Sie einen guten Wasserfallladen aus, bevor Sie feststellen, dass er für jedes Softwareentwicklungsszenario ungeeignet ist.
Hounshell
1
Hallo Stephan, nicht alle Softwareanforderungen ändern sich ständig.
Paul Nathan
1
Das Geschäft ändert sich immer ; Ein Unternehmen, das sich nicht verändert und anpasst, ist ein Unternehmen, das im Sterben liegt. Zeit ist eine Konstante , die nicht gut mit Veränderungen interagiert. Ein System , das die Philosophie hat , die Veränderung anerkennen wird erwartet , kann die Änderung empfängt, sonst hat Zeit ändern zu empfangen, und es ist eine unyeilding konstant!
2

Zur Beantwortung der Frage gibt es eine sinnvolle Alternative, für Software vielleicht nicht - oder zumindest im allgemeinen Fall noch nicht. Ich denke, es hängt von der Natur der Software ab. Software als Information kann kostenlos vervielfältigt werden. Im Gegensatz zu einer Brücke oder einem Haus. Dies bedeutet, dass ich mit etwas Übung gut darin werde, ein Haus zu bauen und in einem relativ einfachen Bereich zu arbeiten. An welchem ​​Punkt warum nicht einen One-Shot-Ansatz verwenden?

Aber weil Software keine Vervielfältigungskosten verursacht, warum sollten Sie das Gleiche jemals zweimal tun? Software tendiert weg von der Fertigung. Wenn also die gesamte Software aus der Entwicklung neuer Produkte besteht, sind wir immer in einem komplexen Bereich tätig, in dem wir teilweise nicht wissen, was wir tun. Oder es ist teuer, es von vornherein zu wissen, und es ist billiger, es herauszufinden, indem man es tut. In einem komplexen, riskanten Bereich möchte ich Experimente durchführen und diese inkrementieren und iterieren.

Kernkraftwerke und Fly-by-Wire-Systeme werden häufig als Beispiele für Software angegeben, die Sie für Wasserfälle verwenden möchten. Aber wurde die Shuttle-Avionik nicht iterativ entwickelt? Wie war das kanadische und das US-amerikanische Flugsicherungssystem?

Und wenn OPEN / Metis iterativ und inkrementell ist, dann klingt es für mich so, als hätte es die agile Philosophie, auch wenn es sich nicht mit anderen gängigen agilen Praktiken verbindet.

AlanMJackson
quelle
2
Jetzt versucht Agile, iterativ und inkrementell zu würdigen? Egal, dass iterativ und inkrementell seit Beginn der Entwicklung im Jahr '92 Kernbestandteile der Wasserfallentwicklung sind.
Dunk
1

Die Waterfall-Methode ist mit Sicherheit praktikabel und philosophisch genauso fundiert wie jeder andere Ansatz. Denken Sie daran, dass es Waterfall schon viel länger als Agile gibt, aber beachten Sie, dass dies kein Argument dafür ist, ob eine Methode besser ist als eine andere.

Sie verwenden die Waterfall-Methode, wenn Sie ein klares Verständnis für die gesamte Problemdomäne haben und wissen, was der Kunde mit einem Softwarepaket erreichen möchte. Wahrscheinlich haben Sie bei Vertragsabschluss einen Festpreis angegeben, und Ihr Kunde ist sich dessen bewusst, dass er nicht von den vereinbarten Anforderungen abweichen kann. Ihr Prozess durchläuft streng genommen eine Reihe von Abmeldungen zwischen den verschiedenen Entwicklungsphasen, und es kommt häufig vor, dass jede Phase von einem anderen Team - manchmal sogar von einem anderen Unternehmen - abgeschlossen wird, was möglicherweise nicht unbedingt der Fall ist Kontakt mit den anderen. Sie sehen Waterfall häufig in Militär- und Regierungsprojekten, wenn sie an externe Auftragnehmer vergeben werden. Wenn Waterfall und andere ähnliche Ansätze einen schlechten Ruf haben, ist dies der Fall, wenn Entwickler auf Probleme stoßen. B. eine schlechte Schätzung, Zeitpläne ohne Ausfallzeiten oder ein schlechtes oder unvollständiges Verständnis der Problemdomäne. Das Problem ist nie wirklich ein Fehler der Methodik, sondern in der Anwendung.

Der Vergleich zwischen Agile und einer beliebigen Methode ist falsch. Agile ist keine Methodik, es ist eine Philosophie, oder es ist besser zu sagen, dass es ein Überbegriff ist, der eine andere Sichtweise auf die Entwicklung von Software darstellt. Eine Methodik ist nur ein Werkzeug, und als solches ist ihr Wert immer geringer als der der Individuen und Interaktionen, die den Kern dessen ausmachen, was es heißt, agil zu sein .

Ist jemand der Meinung, dass die Minimierung von Softwareänderungen eine praktikable Option für diejenigen ist, die wertvolle Software bereitstellen möchten?

Jede Möglichkeit, Änderungen zu minimieren, ist sowohl für den Entwickler als auch für den Kunden von Nutzen. Änderungen können dazu führen, dass ein Zeitplan verrutscht oder Funktionen ausgelassen werden, um einen Zeitplan einzuhalten. So steuern Sie die Auswirkungen von Änderungen, die sich auf den Wert Ihrer Projekte auswirken.

Oder ist die Frage wirklich, welche Praktiken in unseren Situationen am besten funktionieren, um den unvermeidlichen Wandel zu bewältigen?

Ihre Praktiken können bei der Verwaltung von Änderungen hilfreich sein oder sie können Änderungen vollständig ignorieren. Was zählt, ist die Kombination Ihrer Entwicklungspraktiken und das Management Ihrer Beziehung zu Ihren Kunden und ob diese Dinge für alle Beteiligten effektiv zusammenarbeiten.

Diejenigen von uns, die in jeder Hinsicht agil sind, verstehen, dass Sie eine Methode wählen, die für Sie funktioniert. Wenn Sie einen bestimmten Ansatz mögen, folgen Sie ihm. Wenn es nicht ganz Ihren Bedürfnissen entspricht, ändern Sie es. Bei der Erstellung von Software kommt es darauf an, die vorhandenen Ressourcen optimal zu nutzen und die Praktiken zu minimieren, die zu einem Scheitern Ihres Projekts führen können. Oft müssen Sie die Methode an die Anforderungen anpassen bestimmtes Projekt zur Hand.

Es ist wirklich eine Sache, "Ok, jetzt sind wir agil" zu sagen und eine ganz andere, nach der Philosophie zu leben und zu arbeiten, die Agile ist. Ob Sie Wasserfall, Inkremental, Spirale, SCRUM, XP, FDD, oder jede andere Methode, sind Sie im Grunde Agile , wo Sie Wert:

  • Individuen und Interaktionen über Prozesse und Werkzeuge
  • Arbeitssoftware über umfangreiche Dokumentation
  • Zusammenarbeit der Kunden bei Vertragsverhandlungen
  • Reagieren, um nach einem Plan umzuschalten

und wo Sie Ihre Werkzeuge, Methoden und Ihre Erfahrungen zusammenbringen, um diese Werte erfolgreich anzuwenden.

S.Robins
quelle
2
Beeindruckend. Es gibt hier einfach so viel seltsames Zeug. Wasserfall ist lebensfähig, wenn man länger in der Nähe ist? Wasserfall ist aufgrund der Verwendung in Verteidigungsverträgen gerechtfertigt? Ist jede Gelegenheit, Änderungen so gering wie möglich zu halten, wirklich im Interesse des Kunden, oder führt dies dazu, dass das geliefert wird, was er für wünschenswert hielt, und nicht das, was er eigentlich wollte? Da es Ihnen anscheinend wichtig ist, habe ich versucht zu verstehen, woher Sie kommen, aber mir fehlt etwas.
Eric Wilson
1
@EricWilson Waterfall gibt es schon länger und wurde erfolgreich eingesetzt, lange bevor die Agile-Philosophie diskutiert wurde. Es ist lebensfähig, weil es existiert und wenn es richtig angewendet wird, funktioniert es für diejenigen, die es verwenden möchten. Ich habe seine Verwendung nicht gerechtfertigt, sondern nur auf ein Beispiel hingewiesen, bei dem ich persönliche Erfahrungen gemacht habe, bei denen ich gesehen habe, wie es funktioniert, und ja, ich habe auch ein paar spektakuläre Fehler gesehen. Sie suchen nicht nach Möglichkeiten zur Minimierung von Änderungen, Sie möchten Möglichkeiten zur Einführung von Änderungen, müssen dies jedoch mit Bedacht tun, da Ihr Kunde sonst entweder weniger als gewünscht erhält oder eine Frist einhält.
S.Robins
0

Ja, Wasserfall-, Spiral-, iterative und andere hybride Prozessmodelle sind alle realisierbar, aber Veränderungen sind unvermeidlich. Bei einem Prozess geht es nicht nur darum, wie mit Veränderungen umzugehen ist, und (ich behaupte, dass) die wichtigste Determinante ist, wie gut Sie das Problem kennen / verstehen und wie genau Sie planen und vorhersagen können.

Die Aussage, dass "die beiden vorherrschenden Methoden für die Softwareentwicklung Wasserfall und Agilität sind", ist nicht sinnvoll, da es ein Spektrum von Softwareentwicklungsprozessen gibt und viele Unternehmen ihre eigene Version des Prozessmodells synthetisieren, die sich häufig für ein bestimmtes Projekt ändert. Es gibt mehr als zwei praktikable Ansätze für die Softwareentwicklung. Obwohl Waterfall und Agile dazu neigen, auf entgegengesetzte Enden des "Änderungs" -Spektrums zu fallen, ist es vernünftig, diese konkurrierenden Methoden wie folgt zu bezeichnen:

Wasserfall sagt: Änderung ist kostspielig, also sollte sie herabgesetzt werden.

Agile sagt: Veränderung ist unvermeidlich, also macht Veränderung billig.

Aber das ist nicht die ganze Geschichte. Unternehmen müssen planen und vorhersagen können, aber Software ist ein kreativer Prozess, und Schätzungen sind oft falsch. Erinnern Sie sich an das gut - schnell - billige Dreieck? Fügen Sie eine vierte Dimension hinzu, Process, und Sie stellen fest, dass die Reduzierung des Prozessaufwands auch den Zeitplan komprimieren kann, wenn sich die Schätzungen als falsch herausstellen und ein Projekt in Gefahr ist, sich zu verzögern. Software ist ein fungibler (veränderlicher) Prozess, und Agile, Iterative, Spiral bieten alle die Möglichkeit, in kürzeren Intervallen inkrementelle Funktionen bereitzustellen.

Wasserfall- und andere anforderungsgesteuerte Prozessmodelle verfügen über Steuerelemente für den Umgang mit Änderungen. Es ist daher ungenau zu sagen, dass Wasserfall Änderungen minimiert, genauer gesagt, erkennt und verwaltet und die Auswirkungen dieser Änderungen kommuniziert (da Änderungen Auswirkungen auf den Zeitplan haben, wenn Sie dies tun) Anforderungen und Design haben). Wenn Sie ein Produkt erstellen oder Anforderungen (Funktionen) vollständig definieren müssen, werden Sie zu einem der Hybridmodelle geleitet.

Und wenn Schätzungen falsch sind, wird häufig der Prozess (der vierte Abschnitt des Eisendreiecks) geopfert, um den Zeitplan einzuhalten.

ChuckCottrill
quelle
Ich war nicht unaufrichtig. Nach fünfjähriger Entwicklungsarbeit in einer Vielzahl von Unternehmen bin ich nur auf zwei gestoßen, und einer wird nur als Perjorativ bezeichnet. Spiral? Habe nie davon gehört.
Eric Wilson
Ich meinte, dass ich sie nicht in der realen Welt getroffen hatte. Alle möglichen Dinge sind in den Zwischenwebs zu finden, aber ich werde jetzt nicht damit beginnen, sie zu jagen, nur weil ich 2010 zufällig eine Frage gestellt habe.
Eric Wilson
-1

Ausgereifte agile und Wasserfall-Ansätze sind nicht voneinander zu unterscheiden. Ihre Annahme über das Ziel des Wasserfallansatzes ist falsch. Beide haben das Ziel, hochwertige Software zu produzieren. Wenn Sie nicht über eine solide Entwicklungsansatz für die haben Unternehmen als Ganzes, müssen Sie sehen , welchen Ansatz die geringste Menge an Reibung Annahme liefern wird. Letztendlich sind kurze Entwicklungszyklen, ein solides QA-Team und ein Unternehmen, das die Entwicklung vorantreibt, das Wichtigste, um erstklassige Software zu produzieren.

Charles Lambert
quelle
1
Ich würde einen Vorbehalt zu Ihrem Kommentar setzen. Wasserfall erfordert talentierte Leute oder es fällt flach auf sein Gesicht. Es ist schwer zu lernen, gut zu entwerfen. Das Erlernen von Code ist vergleichsweise einfach. IMO, das ist der Hauptgrund, warum die meisten Entwickler agil zu sein scheinen.
Dunk
4
Ich kann das gleiche von agil sagen. Jüngere Entwickler ohne Anleitung können mit einer Schnelligkeit ein Durcheinander von Agilen machen.
Charles Lambert