Wie entwickelt man exzellente Software mit agilen Methoden?

Das Kano-Modell der Kundenzufriedenheit definiert verschiedene Klassen von Produktmerkmalen. Darunter sind

1. Muss-Eigenschaften: Wenn diese nicht implementiert sind, wird der Kunde das Produkt nicht akzeptieren.

2. Attraktive Qualitäten (Entzücker): Eigenschaften, die der Kunde oft gar nicht erwartet, die aber für Aufregung und Freude sorgen, wenn sie entdeckt werden.

Attraktive Qualitäten haben offensichtlich einen hohen Geschäftswert. Sie bringen die Leute dazu, einen Ferrari für 500.000 zu kaufen, wenn ein gebrauchter Fiat für weniger als 5.000 alle Anforderungen erfüllen würde.

Alle agilen Prozesse, die ich kenne, bevorzugen jedoch unbedingt die Anforderungen. Diese haben immer die höchste Priorität. Es scheint nicht einmal einen Ort für attraktive Qualitäten in Agile zu geben.

Ich glaube, dass agile Prozesse bei der Softwareentwicklung sehr nützlich sind. Aber wie können sie eingesetzt werden, um qualitativ hochwertige Softwareprodukte zu erstellen, und nicht nur das Nötigste, das die erforderlichen Anforderungen kaum erfüllt?

Nachtrag: Wie die ersten beiden Antworten gezeigt haben, ist es sinnvoll, den Muss-Anforderungen die höchste Priorität einzuräumen. Aber wissen wir (und der Kunde) wirklich immer im Voraus, welche Anforderungen gestellt werden müssen? Ich habe einige Male die Erfahrung gemacht, dass sich Anforderungen, denen anfangs eine hohe Priorität eingeräumt wurde, später als viel weniger wichtig, wenn nicht nutzlos herausstellten. Deshalb glaube ich, dass man sich nicht sklavisch auf die Muss-Anforderungen konzentrieren sollte.

Die formelle Antwort lautet, Sie haben es falsch verstanden. Agil schreibt keine Anforderungen vor, die Stakeholder tun dies. Der Kern von Agile besteht nicht darin, Ihre Anforderungen in Stein zu meißeln, sondern sie entstehen zu lassen, während Sie in engem Kontakt mit Ihrem Kunden von fortschrittlichen Einsichten profitieren.

Aber das ist alles Theorie. Was Sie gesehen haben, ist in der Tat ein gemeinsames Merkmal vieler Software-Produktionslinien, die eine agile Arbeitsweise gewählt haben.

Das Problem besteht darin, dem Kunden zuzuhören und schnell auf die Bedürfnisse des Kunden zu reagieren. Oft führt dies dazu, dass er nicht über das Produkt nachdenkt oder überhaupt etwas entwirft. Was früher ein proaktiver Prozess war, der von Vision und Fachwissen gespeist wird, kann und wird sich oft zu einem passiven, vollständig reaktiven Prozess entwickeln, der von den Wünschen des Kunden gespeist wird. Dies wird dazu führen, dass nur das Nötigste gemacht wird, was "die Arbeit machen wird".

Das Automobil wäre niemals erfunden worden, wenn die damaligen Hersteller "agil" gewesen wären, weil die Kunden nur nach einem schnelleren Pferd fragten.

Das macht Agile allerdings nicht schlecht. Es ist ein bisschen wie im Kommunismus. Eine großartige Idee, die so gut wie nie funktioniert, weil Menschen nur Menschen sind und Menschen Dinge tun. Und die Methode / Ideologie / Religion wiegt sie in die Vorstellung, dass es ihnen gut geht, solange sie die Bewegungen durchlaufen und / oder die Regeln befolgen.

[bearbeiten]

Slebetman:

Es ist ironisch, dass Agile aus der Automobilindustrie hervorgegangen ist (nämlich Toyota).

Erinnern Sie sich an die goldene Regel der Automatisierung? "Erst organisieren, dann automatisieren". Wenn Sie einen unterbrochenen Prozess automatisieren, können Sie am besten alles beschleunigen, was schief geht. Die Leute bei Toyota waren keine Idioten.

Der typische Grund für die Einführung einer neuen Methodik ist, dass die Dinge nicht gut laufen. Das Management erkennt dies an, versteht jedoch möglicherweise nicht die Kernprobleme. Also stellen sie diesen Guru ein, der eine widerstandsfähige Rede über Agile und Scrum hält. Und jeder liebt es. Aus eigenen Gründen.

Die Entwickler könnten denken: "Hey, das könnte funktionieren. Wir wären mehr mit geschäftlichen Problemen befasst und könnten Input liefern, um diesen Rückstand aufzufüllen. Dies könnte eine Chance sein, Vertrieb und Kundenservice zu verstehen, was wir tun, warum es notwendig ist." und wir würden sie aus unseren Haaren haben, während wir transparent niederbrennen, worauf wir uns geeinigt haben. " Kein "Hör auf, was du tust, das muss jetzt erledigt werden" mehr durch irgendeinen Typen, den du nicht davon abhalten willst, an deinem Schreibtisch aufzutauchen.

Vertrieb, Kundendienst oder der Eigentümer können dies als eine Möglichkeit ansehen, die Kontrolle über diese Black Box einer Abteilung (zurück) zu erlangen, die vermutlich das Notwendige tut. Sie sehen nicht, was dort passiert, aber sie sind sich ziemlich sicher, dass der Kern des Problems irgendwo dort drin vergraben ist. Also stellen sie Scrum vor, installieren einen Produktbesitzer ihrer Wahl und plötzlich haben sie alle Kontrolle, alle Fäden sind in ihrer Hand. Was nun? ... Ehrr ...

Das eigentliche Problem ist oft, dass der Shop von Anfang an nicht gut organisiert war und sich dies nicht geändert hat. Den Menschen wurden Verantwortlichkeiten zugewiesen, mit denen sie nicht umgehen können, oder vielleicht können sie es, aber Mr. Boss mischt sich ständig ein und ruiniert das, was sie getan haben, oder (am häufigsten nach meiner Erfahrung) wurden entscheidende Verantwortlichkeiten überhaupt nicht erkannt oder jemandem zugewiesen.

Manchmal entsteht im Laufe der Zeit eine informelle Organisation zwischen den formellen Linien. Dies kann dann das Fehlen einer formalen Struktur teilweise ausgleichen. Manche Leute machen einfach das, was sie können, ob sie eine Visitenkarte haben, um es zu beweisen oder nicht. Die stumpfe Einführung von Agile / Scrum kann dies sofort zunichte machen. Weil nun von den Leuten erwartet wird, dass sie sich an die Regeln halten. Sie haben das Gefühl, dass das, was sie früher getan haben, nicht geschätzt wird. Stattdessen erhalten sie gelbe kleine Papiere mit kleinen Geschichten. Unnötig zu erwähnen, dass dies für diese Personen keine besondere Motivation darstellt. Sie werden bestenfalls auf Befehle warten und keine Initiative mehr ergreifen.

Es wird also schlimmer und die Schlussfolgerung wird sein, dass Agile scheiße ist.

Agile ist nicht schlecht, es eignet sich hervorragend für Wartungsprojekte und kann sogar für Neuentwicklungen gut sein, wenn es sorgfältig angewendet wird. Wenn die falschen Leute es jedoch nicht verstehen oder aus den falschen Gründen übernehmen, kann es äußerst zerstörerisch sein.

Es scheint nicht einmal einen Ort für attraktive Qualitäten in Agile zu geben.

Sie vergleichen Äpfel und Orangen. Wenn Sie im traditionellen Wasserfall nach Ihren Wünschen die Must-Haves benötigen, erhalten Sie einen Fiat. Wenn die Anforderungen besagen, dass es erstklassig sein muss, bekommen Sie einen Ferrari.

Das gleiche passiert in Agile. Wenn Ihre Anforderungen an Must-Haves aufhören, erhalten Sie einen Fiat. Wenn Sie Geschichten für Spitzenleistungen haben, bekommen Sie einen Ferrari. Alles , was agile wirklich erzwingt, dass Sie das Must - Haves tun zuerst . Seit zwei Jahren keinen super coolen Spoiler mehr bauen und dann die Deadline für den Motor verpassen.

So lange Rede und Antwort: Sie bekommen, was Sie brauchen. Wenn Sie einen Sportwagen planen, bekommen Sie einen Sportwagen. Agile ändert daran nichts. Wenn Ihr agiler Prozess Anforderungen an einen Fiat stellt, beschuldigen Sie nicht agil, sondern nur diejenigen, die einen Fiat benötigen.

Alle agilen Prozesse, die ich kenne, bevorzugen jedoch unbedingt die Anforderungen. Diese haben immer die höchste Priorität.

So wie es sein sollte - schauen Sie sich Ihr Kano-Modell noch einmal an: Wenn die Anforderungen nicht erfüllt werden, akzeptiert der Kunde das Produkt nicht. Und dann sind deine Entzücker egal.

Es scheint nicht einmal einen Ort für attraktive Qualitäten in Agile zu geben.

Nichts ist weiter von der Wahrheit entfernt.

In agilen Prozessen werden in der Regel folgende Punkte hervorgehoben:

• Häufige Lieferung eines funktionierenden Produkts, zu dem Sie Feedback erhalten können.
• Teilen Sie Features in kleine Teile auf, die in kurzer Zeit fertiggestellt werden können.
• Implementieren Sie diese Teile in der Reihenfolge ihrer Priorität.

Nichts hindert Sie daran, "entzückenden" Funktionen eine hohe Priorität einzuräumen. Es kommt ganz auf die Personen an, die für die Festlegung der Prioritäten zuständig sind.

Nun ist es wahr, dass viele solche Leute es vorziehen, kein Risiko einzugehen und daher "Entzückern" möglicherweise keine hohen Prioritäten einräumen. Aber in einem nicht agilen Projekt wäre das immer noch der Fall.

Agile sagt nichts darüber aus, was zuerst getan werden soll, nur, dass der Code inkrementell geschrieben und so oft wie möglich in einem freigebbaren Zustand gehalten werden sollte, anstatt für Monate bis zum nächsten freigebbaren Zustand unbrauchbar zu sein.

Ich habe sowohl nach einem agilen als auch nach einem BDUF-Verfahren (Big Design Up Front) gearbeitet, und obwohl beide Verfahren auf jeden Fall innovative und attraktive Funktionen bieten, müssen Sie bei BDUF überraschenderweise im Voraus planen. Das bedeutet, dass die Innovationen in der Regel von Personen vorgeschlagen oder zumindest gesponsert werden müssen, die im Entwurfsprozess eine herausragende Rolle spielen.

Dies liegt daran, dass Sie bis zur nächsten Version sechs Monate (oder was auch immer) Zeit haben, und die Projektmanager sind gestresst darüber, was in dieser Version vor sich geht. Wenn ihre Funktion nicht verfügbar ist, dauert es weitere sechs Monate bis zur nächsten Version . Es gibt also eine vollgepackte Liste von Funktionen in einem vollgepackten Zeitplan, und wenn die wenigsten Leute zwei oder drei Tage lang an etwas Coolem arbeiten, glauben sie nur, dass es dem Kunden gefällt, und es steht nicht auf dem Programm Liste, sie riskieren den gesamten Zeitplan und es wird die Hölle zu bezahlen sein.

In einem agilen Prozess sind wir bestrebt, die Software in einem releablen Zustand zu halten, und die Projektmanager sind weniger gestresst, da sie die Software nach einem Ausfall ihrer Funktion in nur zwei Wochen erhalten können. Wenn ein Entwickler von einer Konferenz mit einer coolen Idee zurückkommt und ein paar Tage für etwas verbringt, gefährdet er nicht einen Terminplan, der für sechs Monate in Blut geschrieben ist.

Grundsätzlich ernten Sie, was Sie säen. Wenn Sie Innovationen fördern und den Teams genügend Autonomie einräumen, werden Sie sie erhalten. Wenn Sie zur Einhaltung der Fristen ständig Abstriche verlangen, erhalten Sie unabhängig von Ihrer Methodik die passende Software.

Exzellente Software kommt aus zwei Dingen:

• Dem Kunden das geben, was er benötigt

• Professionell sein

Bei der Entwicklung von Software sind alle möglichen Prinzipien zu beachten. TROCKEN, lesbar, FEST usw., die nichts mit den Kundenanforderungen zu tun haben. Der Kunde fragte nach einem Sportwagen. Wenn der Kunde verstehen würde, was es braucht, um einen Sportwagen großartig zu machen, würde er Sie nicht brauchen. Es liegt an Ihnen, herauszufinden, was sonst noch wichtig ist.

Ein Teil unserer Aufgabe ist es, Standards beizubehalten, die der Kunde niemals erfährt, es sei denn, die Dinge laufen fürchterlich schief.

Wenn Sie es richtig machen, tendiert Agile nur dann zum Fiat, wenn es der Kunde wirklich will. Nicht, wenn sie sich damit abfinden müssen.

Wasserfall ist anders, denn sobald sich ein Missverständnis über eine anspruchsvolle Sportwagenanforderung festgesetzt hat, bleibt dieses eher bestehen. Agile kann mit neuen Informationen umgehen und sich anpassen, wenn sich herausstellt, dass sie wirklich ein Bullet Bike benötigen.

Wasserfall ist noch heute in vielen Geschäften in Gebrauch. Diese Shops sind erfolgreich, weil sich ihre Anforderungen innerhalb eines Jahres um weniger als 2% ändern.

Ihre Aufgabe ist es nicht, dem Kunden nur das zu geben, was er will. Es geht auch darum, Dinge zu erledigen, von denen Sie wissen, dass Sie überhaupt keine Anerkennung erhalten. Dinge, die der Kunde niemals zur Sprache bringt, es sei denn, Sie lassen die Dinge fürchterlich schief laufen. Diese Dinge sollten besser ausgewählt werden, sonst verschwenden Sie viel Zeit damit.

Jeder Idiot kann mit unbegrenztem Budget eine Brücke bauen. Ein Profi baut eine Brücke, die niemals herunterfällt.

Deshalb glaube ich, dass man sich nicht sklavisch auf die Muss-Anforderungen konzentrieren sollte.

Sicher solltest du. Außer bei der Schätzung Ihrer Zeit. Weil diese Anforderungen nicht die einzige Überlegung sind.

Okay,

In Agile kann der Programmierer die Software erstellen, aber am Ende ist es der Productowner, der das Produkt erstellt. (Mit den Softwareentwicklern.)

Also über "attraktive Qualitäten", das liegt beim Produktbesitzer.

Wenn der Produktbesitzer "sexy design" verlangt, kann dies zur Bedingung gemacht werden. Der Entwickler sollte sich über diese Entscheidungen keine Gedanken machen müssen.

Außerdem unterscheidet sich Software so stark von tatsächlichen physischen Produkten, dass ich denke, dass viele der Kano-Modelle nicht zutreffen. Warum zum Beispiel facebook ich? Einziger Grund: weil es meine Freunde tun. Wie man das im nächsten Sprint umsetzt ........ Und eine der attraktivsten Eigenschaften von Software ist, dass sie tatsächlich das tut, was sie tun soll. (Und hier hilft Agile sehr: P)

Meine Erfahrung stimmt mit der obigen Ausführungen - es gibt nichts inhärent in Agile , die die Entwicklung von ausgezeichneter Software ausschließt - aber es gibt mehrere Aspekte, wie Agile ist oft (Fehl-) praktiziert, der Software führen , die nur „gut genug ist . "

• Agile legt Wert darauf, dass so schnell wie möglich etwas funktioniert. Dies bedeutet jedoch, Annahmen zu vereinfachen und Abstriche zu machen, insbesondere in der nicht für den Benutzer sichtbaren Infrastruktur. Daran ist an sich nichts auszusetzen, wenn die Kosten für die Korrektur der vereinfachenden Annahmen niedrig sind. Allzu oft wird diese "technische Verschuldung" jedoch nicht beseitigt, bevor ein Produkt in Produktion geht.
• Agile predigt, dass Sie am Ende eines Sprints immer etwas haben sollten, das so nah wie möglich am Versand ist, damit Stakeholder und Projektmanager entscheiden können, dass "das, was sie haben" gut genug ist, um es voranzutreiben Produktion. Auch hier ist nichts von Natur aus falsch, wennSie haben alle Ihre "technischen Schulden" beglichen (oder sich damit abgefunden, wie viel Sie haben und wo es ist). Meiner Erfahrung nach gehen jedoch viel zu viele technische Schulden in Produktion, mit dem Versprechen eines Managers, dass "wir" Wenn der Schiffsdruck nachlässt, müssen wir sehr vorsichtig sein, was wir jetzt ändern. Sie haben mir nie gesagt, dass wir dieses Risiko eingehen. Wir müssen das nächste Mal einen besseren Job machen! " Die Lektion von Ben Frankin über "Die Bitterkeit schlechter Qualität bleibt lange nach dem Vergessen der Süße des niedrigen Preises bestehen" scheint nie gelernt zu werden;
• Doch selbst bei vertrauenswürdigen Managern und gut disziplinierten Entwicklern besteht häufig das Problem, dass vor dem Start des Sprints, in dem die Implementierung eingeleitet und abgeschlossen werden soll , einfach zu wenig ordnungsgemäße Analyse, Entwurf und Entwurfsprüfung erfolgt . Das Versäumnis, nachdenklich über Alternativen nachzudenkenUI-Metaphern und -Designs sind groß - es ist normalerweise zu kostspielig, dies nach dem Start eines Projekts erheblich zu überarbeiten. Das Versäumnis von Junior-Teams, die Produkte ihrer Wettbewerber sorgfältig zu untersuchen oder die Definition und Implementierung von Infrastrukturtechnologien wie I18N, Benachrichtigungs-Frameworks, Protokollierungs-, Sicherheits- und API-Versionsstrategien zu priorisieren, bedeutet letztendlich, dass sie höhere Fehler aufweisen. Geringere Produktivität und höhere technische Schulden als bei den ersten 2 bis 5 Sprints im Vorfeld, bei denen die erforderlichen Schulungen, Analysen, Konstruktionen und Prototypen erstellt wurden. Kurz gesagt, agile Teams müssen der Lizenz zum Hacken widerstehen.
• Ich hatte einen Manager der zweiten Ebene (mit über 100 Entwicklern), der seine Entwickler davon abhielt, sich die Zeit zu nehmen, ihre geplanten Entwürfe aufzuschreiben, selbst auf der einfachsten Ebene. Seine Argumentation - "Ich möchte, dass die Leute miteinander reden" - war ironisch, weil sie sich in 5 verschiedenen Zeitzonen und 3 Ländern befanden. Unnötig zu erwähnen, dass viel mit den Fingern darauf hingewiesen wurde, welches Team viele Nächte und Wochenenden zu einem späten Zeitpunkt im Projekt arbeiten musste, als sie herausfanden, dass alle dachten, der andere Typ sei für die Implementierung einiger Funktionen verantwortlich (oder) Neuimplementierung, da die Entwürfe von Lieferanten und Verbrauchern einfach nicht ineinandergreifen.)

Es kommt wirklich darauf an, ob der Projektmanager und die Beteiligten ein qualitativ hochwertiges Produkt liefern möchten . Wenn sie dazu verpflichtet sind, wird Agile es aktivieren. OTOH: Da Agile die Entscheidung über den Zeitplan ausschließlich in die Hände des Beteiligten und des Projektmanagers legt, ist es für ein Entwicklungsteam schwierig, ohne diese Unterstützung ein hervorragendes Projekt zu liefern. Kurz gesagt: Die Verantwortung für die Produktqualität liegt fast ausschließlich bei den Projektmanagern.

TL; DR

Tatsächlich hilft Ihnen die agile Entwicklung, die Softwarequalität zu verbessern, den Kunden zufrieden zu stellen und ein hoch wertvolles Produkt zu liefern.

Die agile Entwicklung wurde von einigen klugen Leuten eingeführt, um die Probleme zu lösen, mit denen viele Softwareprojekte in traditionellen Prozessen konfrontiert sind.

Die Schlüsselwerte der agilen Entwicklung im Sinne des agilen Manifests (1) sind:

• Individuen und Interaktionen über Prozesse und Werkzeuge
• Arbeitssoftware über umfassende Dokumentation
• Customer Collaboration über Vertragsverhandlungen
• Umstellung auf einen Plan

Daher hindert Sie die agile Entwicklung nicht daran, qualitativ hochwertige Software zu erstellen. Agile Development unterstützt Sie bei der Bereitstellung hochwertiger Software.

Aber wissen wir (und der Kunde) wirklich immer im Voraus, welche Anforderungen gestellt werden müssen?

Das ist der springende Punkt. Indem Sie sich auf Einzelpersonen konzentrieren, helfen Ihnen der Kunde, die funktionierende Software und die sich ändernden Anforderungen bei der agilen Entwicklung herauszufinden, was der Kunde möchte, bevor das Endprodukt geliefert wird.

Das ist ein Grund, warum agile Frameworks wie Scrum kurze Iterationszyklen haben und die Ergebnisse funktionieren. Sie können Ihre Arbeit bereits frühzeitig gegen die Erwartungen des Kunden validieren und die Ziele / Anforderungen nach Bedarf anpassen. Mit einer agilen Entwicklung können Sie sicherstellen, dass die unerlässliche Qualität eines Produkts erkannt wird.

Früher - das gilt auch heute noch - waren viele nach traditionellen Ansätzen entwickelte Softwareprojekte gescheitert, hatten keinen Erfolg oder verursachten Unzufriedenheit bei den Kunden, weil die erforderliche Qualität nicht erreicht wurde.

Darüber hinaus hilft Ihnen eine agile Entwicklung, eine attraktive Qualität zu erreichen . Das Reflektieren des Produkts nach jeder Iteration bringt neue Anforderungen mit sich, die der Kunde beim Projektstart nicht berücksichtigt hat (attraktive Eigenschaften). So bleibt der Kunde zufrieden.

Ich möchte auch die Reverse Quality - Attribute, die zu Unzufriedenheit führen - des Kano-Modells erwähnen .

In jedem Projekt gibt es Anforderungen, die zu Beginn des Projekts als gute Ideen erscheinen. Nach einer Weile wechseln sie in das Gegenteil und verursachen Enttäuschungen.

In einem herkömmlichen Softwareentwicklungsprozess werden Sie solche Anforderungen nach einem langen Projektlauf im Endprodukt erkennen. Um Enttäuschungen der Kunden zu vermeiden und diese zu ändern, ist ein Folgeprojekt erforderlich.

Agile Development hilft Ihnen, nicht funktionierende oder unbefriedigende Anforderungen frühzeitig zu erkennen und während des Projekts zu ändern.

Wie ich bereits sagte, hilft Ihnen die agile Entwicklung, die Softwarequalität zu verbessern, den Kunden zufrieden zu stellen und ein sehr wertvolles Produkt zu liefern.

Ich bin zu spät zu dieser Party, aber ich möchte einen anderen Blickwinkel zu diesem Thema teilen:

Aber wie können sie eingesetzt werden, um qualitativ hochwertige Softwareprodukte zu erstellen, und nicht nur das Nötigste, das die erforderlichen Anforderungen kaum erfüllt?

In der agilen Softwareentwicklung gibt es einen zeitlichen Aspekt, der sich aus dem iterativen Ansatz und der Berücksichtigung des Kundenfeedbacks ergibt , die zwei wichtige Elemente der agilen Methodik sind. Beispiel: Merkmale, die in Iteration t als attraktive Qualität identifiziert werden, können in der nächsten Iteration t + 1 zu einer Muss-Qualität werden .

Durch das Anwenden agiler Methoden kann die Qualitätskategorie eines Features dynamisch geändert werden. Wenn Sie die geplanten Merkmale der Iteration t mit den fertigen Merkmalen einer späteren Iteration t + n vergleichen, werden Sie genau das erfahren, was Sie erwähnt haben:

Ich habe einige Male die Erfahrung gemacht, dass sich Anforderungen, denen anfangs eine hohe Priorität eingeräumt wurde, später als viel weniger wichtig, wenn nicht nutzlos herausstellten.

Angesichts dieses zeitlichen Aspekts ist es plausibel, dass agile Methoden unter Konzentration auf das Nötigste erfreuliche, qualitativ hochwertige Softwareprodukte hervorbringen können . Der iterative Ansatz, gepaart mit Kundenfeedback, verändert die Spielregeln im Laufe der Zeit.

Fazit

Wie entwickelt man exzellente Software mit agilen Methoden?

Wenden Sie einen iterativen Ansatz an und hören Sie auf Kundenfeedback . Wenn Sie eines dieser Elemente weglassen, erhalten Sie eine weniger erfolgreiche Form der agilen Softwareentwicklung.

   > How to develop excellent software with agile methods?

• Bei der Erstellung einer kundenspezifischen Individualsoftware :
  • Finden Sie einen Kunden, bei dem es nicht auf die Kosten ankommt, weil die Funktion "Entzücken" zusätzliches Geld kostet und der Kunde sich entscheiden muss, ob er dafür bezahlen möchte.
• Bei der Herstellung von Softwareprodukten :
  • "Entzückende" Funktionen sind gut, um neue Kunden anzuziehen, und die Kosten für die Implementierung einer "entzückenden" Funktion sind nicht so wichtig, wenn das Produkt mehr als 1000 Mal verkauft wird.
• In einer Umgebung, in der "gut genug (billiger) ist am besten", erhalten Sie nicht das Geld, um "entzückende" Funktionen zu implementieren

In einem Scrum-Team ist der Product-Owner für die Auswahl der zu implementierenden Funktionen verantwortlich. Es liegt also an ihm (und seinem Budget), eine "gute genug" oder "ausgezeichnete" Software zu definieren

Sie sprechen einige gute Punkte an. Ich glaube jedoch nicht, dass diese Probleme auf agile Prozesse / Methoden beschränkt sind.

Es gibt unterschiedliche Meinungen darüber, was essentielle und was nicht essentielle Merkmale sind. Um Ihr Beispiel zu verwenden, könnte jemand, der ein Auto kauft, das Auffallen von Aufmerksamkeit als ein wesentliches Merkmal betrachten und daher einen Fiat als nicht konform mit dieser Anforderung betrachten.
Realistischer muss ein Softwareprodukt möglicherweise über bestimmte Funktionen verfügen, um die Anforderungen der tatsächlichen Endbenutzer zu erfüllen. Es muss jedoch auch über bestimmte andere Funktionen verfügen, um verkauft zu werden. Weil die Person, die den Kauf autorisiert, häufig kein Endbenutzer ist.
Eine Funktion, die für den / die Endbenutzer "nicht wesentlich" ist, ist möglicherweise für den Verkauf des Produkts von entscheidender Bedeutung ... und daher auch für das Unternehmen, das das Produkt herstellt.

Das alles läuft darauf hinaus, dass es entscheidend ist, ein gutes Produktentwicklungsteam zu haben, um die Anforderungen und Prioritäten angemessen festzulegen. Das gilt aber nicht nur für agile Shops.

Es ist auch wichtig, Product Owner / Stakeholder zu haben, die befugt sind, Entscheidungen zu treffen. Wenn die Entscheidungen Ihres Produktbesitzers ständig von jemand anderem außer Kraft gesetzt werden, bin ich der Erste, der zustimmt, dass dies ein Problem ist, aber es ist auch kein Problem mit Agilität.

Es gibt noch andere Dinge, die Sie von Ihren Produktbesitzern erwarten ... eine Beschreibung, die ich gehört habe, ist "CRACK" (kollaborativ, repräsentativ, autorisiert, engagiert und sachkundig). Ein Produktbesitzer, der in einem dieser Bereiche fehlt, kann Probleme für ein Projekt bedeuten. Aber ich habe dieses Akronym zum ersten Mal in einer Umgebung mit Wasserfällen gehört, sodass der Schmerz von schlechten Kunden / Produktbesitzern nicht auf agile Geschäfte beschränkt ist.

Agile kann (helfen), einige dieser Probleme an die Oberfläche zu bringen.

Zum Beispiel ist die XP-Literatur IIRC ziemlich explizit, dass der "Kunde" kenntnisreich, für das Team zugänglich und befugt ist, Entscheidungen zu treffen. Der Begriff "Product Owner" impliziert ein gewisses Maß an Wissen, Engagement und Autorität.

Wenn Sie sich in einer Situation befinden, in der der Großteil der bereitgestellten Funktionen aus Entzückern und nicht aus Funktionen besteht, die Sie unbedingt benötigen, ist es viel einfacher, dieses Problem zu lösen (und die Ursache leichter zu ermitteln), wenn Sie funktionierende oder nahezu funktionierende Software bereitstellen 2-3 Wochen als bei Lieferungen im Abstand von Monaten oder Jahren.

Wenn Sie in kleinen Iterationen arbeiten und den Rückstand häufig überprüfen (einschließlich erneuter Überprüfung der Priorisierung), hat das Team die Möglichkeit, aus früheren Fehlern zu lernen. "Das scheint jetzt wirklich wichtig zu sein, aber erinnern Sie sich an die dynamische Navigation, von der wir sicher waren, dass wir sie nicht gebraucht haben?" Wie andere betont haben, sind diese Diskussionen viel unwahrscheinlicher, wenn alles im Voraus geplant wurde.

Im Gegensatz dazu wird bei der Up-Front-Entwurfsmethodik (standardmäßig) davon ausgegangen, dass das Verständnis des Produkts und der Funktionen statisch ist. Das war nicht meine Erfahrung: Etwas Greifbares zu haben, ändert fast immer das Verständnis der Geschäftsleute für das Problem. Daher der Schwerpunkt auf schnelles Feedback. (Das Verständnis der Entwickler ändert sich ebenfalls, aber die Prioritäten bleiben davon unberührt.)

Wenn Sie einen Teil der Planung verschieben, können Sie auch auf Änderungen der Geschäftsanforderungen reagieren. "Sie kennen die Website, die Sie erstellen? Wir brauchen sie wirklich, um eine mobile App zu sein, die den Betrieb ohne Verbindung ermöglicht." Dies wurde nicht speziell gefragt ... aber möchten Sie nicht, dass Ihr Prozess in der Lage ist, auf Änderungen in der Geschäftslandschaft zu reagieren (zumindest theoretisch)?

Agile sagt nicht "Bauen Sie keine nicht wesentlichen Funktionen". Es heißt "Erlaubt dem Unternehmen, zu entscheiden, welche Funktionen (nicht) erstellt werden sollen".
... und (ebenso wichtig) "Lassen Sie sich von den Technikern mitteilen, wie lange die Erstellung eines Features dauern soll".

1. Must-be qualitiessind oft schwer zu bestimmen. Die Leute haben sie im Unterbewusstsein. Agile Iterationen und Kundenbeteiligung helfen dabei, die meisten Must-be's zu finden. Das ist die Kraft des Agilen und es ist töricht, es zu vernachlässigen .
2. One-dimensional qualitiesDas heißt, Versprechen, die erfüllt werden müssen, werden von Wasserfall OK unterstützt, bis sie sich nicht ändern. Hier hilft Agilität nur, aber nicht so stark.
3. Attractive qualitiessind nette Features. Sie könnten zu Must-be's der nächsten Generation werden. Aber in der gegenwärtigen Generation sind sie nicht einmal in der Vereinbarung - sonst wären sie eindimensionale Qualitäten. Diese agilen Methoden, die eine repräsentative Beteiligung des Kunden voraussetzen, unterstützen diese Eigenschaften sehr gut. Denn wir können den Umfang während der Arbeit leicht verändern. Wir können uns auf eine Verbesserung einigen, um eine Entschädigung an einem anderen Ort zu erhalten. Im Wasserfall ist es praktisch unmöglich. Ohne große organisatorische Verzögerung konnten wir nur Funktionen kostenlos HINZUFÜGEN. Es ist möglich, wenn vorher etwas mehr Zeit in das Budget gesteckt wird.

Agile Prozesse können also das Kano-Modell unterstützen, einige von ihnen tun dies sehr gut und definitiv viel besser als die besten Wasserfallprojekte.

Um dies nach Ihrem Verständnis zu erreichen, sollten Sie agile Prozesse mit einem verantwortlichen Teilnehmer des Kundenvertreters festlegen.