Extreme Programmierpraktiken machen eine Anwendung fehleranfälliger? [geschlossen]

Ich forsche akademisch zum Thema Extreme Programming und ob seine Praktiken dazu führen, dass Platz für mehr Fehler und Bugs in Anwendungen geschaffen wird.

Aus den Erfahrungen, die ich von vielen gesammelt habe, habe ich Kommentare, die auf beide Seiten fallen. Viele unterstützen es und betrachten es als eine tägliche Notwendigkeit mit einer Dynamik, die es ermöglichen kann, sich ändernde Projektanforderungen zu erleichtern. Viele andere argumentieren, dass dies zu vielen Problemen führt, wie zum Beispiel:

• Eine übermäßige Einbeziehung des Kunden in den Prozess führt dazu, dass Kundenwünsche und nicht Bedürfnisse zum Ausdruck gebracht werden

• Viele Produkte haben mehrere Kunden, was zu widersprüchlichen Bedürfnissen und Meinungen führt und unnötige Blockaden verursacht

• Viele Produkte haben keine externen Kunden, bei denen das Produkt für den internen Gebrauch oder für den zukünftigen Verkauf bestimmt ist. In diesen Fällen spielt das Team selbst sowohl den Benutzer als auch den Entwickler, wodurch die Effektivität des Prozesses beeinträchtigt wird.

• In der formalen Dokumentation gibt es nicht viele Dinge. Diese Informalität führt zu einer vagen Vision und kann zu Problemen führen, bei denen der Kunde möglicherweise sagt, dass dies nicht das ist, was wir gefragt haben usw. usw.

Die Frage ist, warum solche widersprüchlichen Meinungen zu XP existieren. Handelt es sich um verschiedene Szenarien? Gibt es noch etwas? Inwieweit ist die Behauptung (wie im Titel geschrieben) wahr?

Ich möchte, dass Leute, die hier arbeiten oder mit XP gearbeitet haben, ihre Lern- und realen Erfahrungen einbringen. Es wäre ideal, wenn Sie Fakten oder Referenzen haben, die Ihre Antwort unterstützen.

Eine übermäßige Einbeziehung des Kunden in den Prozess führt dazu, dass Kundenwünsche und nicht Bedürfnisse zum Ausdruck gebracht werden.

Dies setzt voraus, dass der Kunde ein perfektes Orakel für die Anforderungen des Systems ist. Eines der Grundprinzipien von XP ist, dass der Kunde kein perfektes Orakel ist und dass ständiges Feedback auf der Grundlage realer Versandsoftware erforderlich ist, um die tatsächlichen Bedürfnisse des Marktes, der Kunden und letztendlich der Stakeholder zu ermitteln.

Viele Produkte haben mehrere Kunden, was zu widersprüchlichen Bedürfnissen und Meinungen führt und unnötige Blockaden verursacht.

Ja, und die regelmäßige Einbeziehung dieser Kunden wird dazu beitragen, diese Konflikte deutlich zu machen und sie im Laufe der Zeit zu lösen. Wenn Sie das Problem verbergen, wird es nicht verschwinden.

Viele Produkte haben keine externen Kunden, bei denen das Produkt für den internen Gebrauch oder für den zukünftigen Verkauf bestimmt ist. In diesen Fällen spielt das Team selbst sowohl den Benutzer als auch den Entwickler, wodurch die Effektivität des Prozesses beeinträchtigt wird.

Interne Stakeholder unterscheiden sich nicht grundlegend von externen Stakeholdern. Sie haben nicht erklärt, wie Nicht-XP-Methoden mit diesem Problem umgehen.

In der formalen Dokumentation gibt es nicht viele Dinge. Diese Informalität führt zu einer vagen Vision und kann zu Problemen führen, bei denen der Kunde möglicherweise sagt, dass dies nicht das ist, was wir gefragt haben usw. usw.

XP beinhaltet häufiges, inkrementelles Feedback zwischen den Stakeholdern und den Entwicklern. Wenn diese Kommunikationsfehler vorhanden sind, können sie während früher Iterationen entdeckt und behoben werden, bevor sie spätere Iterationen erheblich beeinflussen. Die Alternative besteht darin, dass diese Kommunikationsfehler erst unmittelbar vor dem Versand des Produkts entdeckt werden.

Ich denke, das grundlegende Missverständnis ist, dass XP diese Probleme nicht verursacht. Es macht sie nur sichtbar . Prozesse, die Probleme frühzeitig und häufig aufdecken und beheben, sind im Allgemeinen weniger fehleranfällig, nicht mehr.

Ein paar Gedanken:

• Zu viele Eingriffe des Kunden in den Prozess veranlassen ihn, seine Wünsche und nicht seine Bedürfnisse gegenüber der Software auszudrücken

Es besteht immer ein Gleichgewicht zwischen einer detaillierten, stabilen Spezifikation und der Reaktion auf den Kunden. Extreme soll die Reaktionsfähigkeit gegenüber dem Kunden erhöhen, und natürlich ist es möglich, zu weit in diese Richtung zu gehen. Dies ist also ein berechtigtes Anliegen (insbesondere abhängig davon, wie das Projekt in Rechnung gestellt wird: Wenn es sich um einen Festpreisvertrag handelt, müssen Sie ihn offensichtlich genau spezifizieren).

Nach meiner Erfahrung müssen Sie jedoch, egal wie gut Ihre Spezifikation ist, diese häufig ändern, um "das zu tun, was der Kunde wünscht". Extreme hilft Ihnen dabei, diese Änderungen so schnell wie möglich vorzunehmen, anstatt nachdem Sie ein riesiges, kompliziertes Programm nach Spezifikation erstellt haben.

• Viele Produkte haben mehrere Kunden, was zu widersprüchlichen Bedürfnissen und Meinungen führt und zu unnötigen Blockaden führt

Natürlich ist die Lösung widersprüchlicher Bedürfnisse in einer solchen Situation immer ein Problem, mit dem Sie einen guten Prozess bewältigen müssen. Wenn der Prozess des Erhaltens von Kundenfeedback zeitaufwändig und komplex ist, würde dies die extreme Programmierung weniger effektiv machen, daher halte ich dies für ein berechtigtes Anliegen.

• Viele Produkte haben keine externen Kunden (Produktorganisation für sie oder für den zukünftigen Verkauf). In diesem Fall spielt das Team selbst sowohl den Benutzer als auch den Entwickler, wodurch die Effektivität des Prozesses beeinträchtigt wird.

Ich halte das überhaupt nicht für legitim. Die Idee hinter Extreme ist, dass Kunden erst erkennen, was sie wollen, wenn Sie tatsächlich damit beginnen. Dies gilt für interne "Kunden" ebenso wie für externe.

Und wenn Sie etwas entwickeln, das noch keine Kunden hat (wie ein Produkt, das noch nicht veröffentlicht wurde), müssen Sie jemanden (oder eine Gruppe) haben, der als hypothetischer Kunde fungiert und entscheidet, was die Leute wollen. Extreme funktioniert genauso gut mit ihnen als Kunden.

Ich habe an einem Produkt wie diesem gearbeitet, das für externe Kunden bestimmt war, aber noch nicht veröffentlicht wurde. Obwohl wir es nicht als "Extreme Programming" bezeichnet haben, haben wir einen ähnlich iterativen Entwicklungsprozess ohne umfangreiche formale Spezifikation und mit häufigen Builds verwendet. Ich fand es ziemlich effektiv.

• In der formalen Dokumentation gibt es nicht viele Dinge. Diese Informalität führt zu einer vagen Vision und kann zu Problemen führen, bei denen der Kunde möglicherweise sagt, dass dies nicht das ist, was wir gefragt haben usw. usw.

Ja, alles, was nicht dokumentiert ist, ist ein Problem. Extrem, da es nicht von einer formalen Spezifikation bestimmt wird, kann es einfacher sein, Dinge nicht zu dokumentieren. Extrem bedeutet jedoch nicht automatisch, dass "Dinge nicht dokumentiert sind". Sie sollten weiterhin Dokumentation erstellen, diese wird jedoch nicht vorher, sondern neben dem Programm erstellt. In einigen Fällen bedeutet dies, dass das Verhalten nach der Implementierung dokumentiert wird. Dies ist an und für sich kein Problem.

Wenn es um die Abrechnung geht, benötigen Sie häufig eine schriftliche Dokumentation darüber, was genau geliefert wird, bevor Sie mit der Arbeit beginnen. Dies kann mit Extreme Programming schwieriger sein.

Fazit : Extreme ist eine Methode, die wie alles Vor- und Nachteile hat. Sie müssen beides berücksichtigen, wenn Sie es verwenden (oder unterrichten).

Ihre Fragen befassen sich nur mit zwei Hauptthemen von XP: "direkte Kundenkommunikation" und "nicht zu viel formale Dokumentation". Aus meiner Sicht ist dies also keine "XP" -Frage, sondern Themen, die Teil eines anderen mir bekannten agilen Entwicklungsprozesses sind.

Hier sind meine Gedanken:

Zu viele Eingriffe des Kunden in den Prozess veranlassen ihn, seine Wünsche und nicht seine Bedürfnisse gegenüber der Software auszudrücken.

Nun, wenn Sie einen wasserfallähnlichen Prozess mit einer zuvor vollständig detaillierten Spezifikation und vielen Anforderungen haben, können Sie in Schwierigkeiten geraten, entweder welche dieser Anforderungen sind nur Wünsche und welche sind echte Bedürfnisse. Der einfachste Weg, dies zu klären, besteht meiner Meinung nach darin, mit dem Kunden zu sprechen und ihm verschiedene Alternativen aufzuzeigen - wann immer Sie zu einem Punkt kommen, an dem eine Klärung erforderlich ist. Das Gegenteil ist der Fall: "Agile Entwicklung" hilft Ihnen, besser mit "Bedürfnissen gegen Wünsche" umzugehen.

Viele Produkte haben mehrere Kunden, was zu widersprüchlichen Bedürfnissen und Meinungen führt und zu unnötigen Blockaden führt

Ja, mit einer zuvor vollständig detaillierten Spezifikation wurden diese Konflikte möglicherweise vor Beginn der Entwicklung gelöst (wenn Sie Glück haben). Die Lösung für dieses Problem in einem agilen Prozess besteht darin, dass nur wenige Kunden direkt mit den Entwicklern sprechen und ein verantwortlicher Vertreter für die Kunden, der im Konfliktfall endgültige Entscheidungen treffen kann.

Viele Produkte haben keine externen Kunden (Produktorganisation für sie oder für den zukünftigen Verkauf). In diesem Fall spielt das Team selbst sowohl den Benutzer als auch den Entwickler, wodurch die Effektivität des Prozesses beeinträchtigt wird.

Nein, das ist nicht richtig. Wenn Sie nur interne Benutzer haben, die demselben Unternehmen wie die Entwickler angehören, ist die Installation von "Kunde vor Ort" viel einfacher als wenn Sie nur externe Kunden haben. Wenn Sie keine direkten Benutzer zur Hand haben, kann dies ein Problem sein, aber es handelt sich nicht um ein agiles spezifisches Problem. Sie müssen dann jemanden finden, der stattdessen die Rolle eines potenziellen Benutzers übernimmt (und diese Person ist normalerweise nicht von der Entwicklerteam).

In der formalen Dokumentation gibt es nicht viele Dinge. Diese Informalität führt zu einer vagen Vision und kann zu Problemen führen, bei denen der Kunde möglicherweise sagt, dass dies nicht das ist, was wir gefragt haben usw. usw.

Wenn Sie sich nach einer formalen Spezifikation ohne ständige Kundenkommunikation entwickeln, ist meiner Erfahrung nach die Chance, etwas zu entwickeln, bei dem der Kunde sagt, dass dies nicht das ist, was ich gefragt habe,> 100-mal höher als bei einem täglichen Gespräch mit dem Kunden. Wenn Sie auch weiterhin auf dieses Problem stoßen, gibt es eine einfache Lösung: Notieren Sie sich nach jeder Kundensitzung kurz schriftlich, was Sie vereinbart haben. Senden Sie diese Notiz gegebenenfalls an den Kunden und geben Sie ihm die Möglichkeit, Korrekturen vorzunehmen. Das funktioniert sowohl in einem agilen Prozess als auch in jeder anderen Art von Projekt.

Too much involvements of the customer in the process make him start expressing his wishes rather than his needs to the software

Entwickeln Sie Software basierend auf den Anforderungen eines Kunden? Was ist, wenn ein Kunde möchte? Verweigern Sie den Kunden, weil "Hey Kunde, ich erstelle Software nur nach Bedarf! ??"

Ich habe in einem extrem programmier- und agilen Geschäft gearbeitet. Ich habe wöchentliche Kundeninteraktionen aus erster Hand gesehen, die manchmal die Qualitätssicherung und die Entwickler verrückt machten. Aber sie lieferten genau das, was der Kunde wollte, wann er es wollte, und es wurde während "Show and Tell" mit dem Kunden klar, was er tat, was er nicht tat und was sein sollte, wie er wollte.

Many products have multiple customers which lead to conflicting needs and opinions leading unnecessary blockades

Keine unnötigen Blockaden, wenn der extreme und agile Shop die Ziele der Implementierung klar macht und was in das Produkt aufgenommen wird und was nicht. Verschiedene Versionen desselben Produkts sind ebenfalls möglich und hängen davon ab, was ausgehandelt wird. Dies muss kein Streitpunkt sein, der die Produktivität beeinträchtigt oder zu unnötigen Blockaden führt.

Many products don’t have any external customers (products organization made for them or to be selling in future). In this case the team itself is playing the user as well as the developer hence killing the effectiveness of the process.

Nicht unbedingt. Sogar eine externe Benutzeroberfläche, bei der zufällig Personen auf der Straße befragt werden, um festzustellen, welche Benutzeroberfläche für ein bestimmtes Gerät für sie interessant erscheint, ist möglich.

Not many things exists in formal documentation, this informality leads to vague vision and can create problems where the customer might say that this is not what we asked etc. etc.

Dann muss eine formale Dokumentation verwendet werden. Die formelle Dokumentation hält die Füße des Kunden am Feuer und eine einzeilige Lochkarte "das haben Sie uns gesagt, dass Sie es wollten" stimmt mit der Dokumentation und der Kundeninteraktion überein, sodass es keine Ausreden gibt. Da ich als Praktikant in einem extremen und agilen Geschäft Gelegenheit hatte, dies in Aktion zu sehen, hat der Kunde wöchentlich die Dokumentation unterschrieben. Der Kunde hatte auch die Möglichkeit, Änderungen vorzunehmen und musste diese ebenfalls abzeichnen. Wenn es an Dokumentation mangelt, besteht eine Einladung zur Katastrophe.

The questions is why such conflicting opinions exists regarding XP, is it the matter of different scenarios or is there something else and till what extent the claim (as written in the title) is true.

Ich würde sagen, das hängt von der Intelligenz des Geschäfts ab. XP und Agile sind Richtlinien und keine Anweisungen. Um mit XP und Agile erfolgreich arbeiten zu können, muss es in die Betriebspraktiken integriert und im gesamten Unternehmen eingesetzt werden. Der Kilometerstand wird immer variieren und einige werden zweifellos behaupten, dass er schlecht ist, andere werden sagen, dass er gut ist. Wo ich interniert habe, war es zweifellos gut und es wurde viel Erfolg gehabt.

Aus meiner Erfahrung heraus scheint die Starrheit gegenüber den Prinzipien von XP und Agile zu bestimmen, ob die Softwareentwicklung erfolgreich ist, wenn sie in den "Alltag" einbezogen wird. Während meines Praktikums hat die Kundeninteraktion alles vorangetrieben und nichts wurde getan, ohne dass ein Kunde zuvor angegeben hatte, dass dies getan werden sollte. Die Art und Weise, wie dieser Shop seinen Betrieb betrieb, lieferte einen guten, messbaren Erfolg unter Verwendung solider Entwicklungsprinzipien als Teil des XP- und Agile-Frameworks, das eng in alles integriert ist, was sie tun.

Wenn wir uns an die ursprüngliche Frage von halten

Ich forsche akademisch zum Thema Extreme Programming und ob seine Praktiken dazu führen, dass Platz für mehr Fehler und Bugs in Anwendungen geschaffen wird.

Ich bin nicht sicher, ob die geäußerten Bedenken für die Frage relevant sind.

Wenn die Befürchtung besteht, dass Kunden über die Beteiligung eher zu Wünschen als zu Bedürfnissen führen, würde ich mich an das Team wenden, um sicherzustellen, dass die Artikel ordnungsgemäß in kleine Releases mit einfachen Designs zerlegt werden. Danach priorisieren Sie diese Elemente so, dass das Team in einem nachhaltigen Tempo arbeiten kann.

Wenn mehrere Kunden sich nicht auf Bedürfnisse und Meinungen einigen können, besteht die Hoffnung, jemals testen zu können, ob die Software den Kundenbedürfnissen entspricht. Es ist besser, diese Dinge früh im SDLC zu klären, als später.

Wenn das Team der Benutzer für XP sein muss, wird der XP-Prozess dadurch nicht beendet. In der Tat wird ausdrücklich angegeben, dass der Kunde ein Mitglied des Teams ist. Manchmal ist dieses Teammitglied eher ein interner Mitarbeiter als ein "echter Kunde". Es ist wichtig, dass der Einzelne befugt ist, die Bedürfnisse des Kunden zu vertreten. Ich sehe nicht, dass dieses Problem für XP relevanter ist als für jeden anderen Ansatz, sei es agil oder traditionell.

In der formalen Dokumentation gibt es nicht viele Dinge? Bei richtiger Ausführung verbringen XP-Teams mehr Zeit mit der Planung als herkömmliche Teams. Da die Spezifikationen zu Beginn jeder Iteration gemeinsam zwischen den geschäftlichen und technisch denkenden Teammitgliedern geschrieben werden, sind die Spezifikationen im Vergleich zu großen Designs im Vorfeld tendenziell genauer.

XP konzentriert sich auf die Entwicklungsaspekte (Engineering) eines Projekts. Dinge, die bei der Betrachtung von XP besprochen werden sollten, sind:

• Beeinträchtigt die Lernkurve für die testgetriebene Entwicklung die Entwicklung eines Qualitätsprodukts?
• Wie schwierig ist es, Qualitätstests zu erstellen, die zu einem Qualitätscode führen.
• Wie wahrscheinlich ist es, dass Entwickler den testgetriebenen Entwicklungszyklus "betrügen" und zuerst den Code und später den Test schreiben. Ist das wichtig?
• Wie effektiv sind Entwickler, die im Vergleich zur herkömmlichen Entwicklung paarweise arbeiten (eine Person schreibt den Code für eine Funktion).
• Führt iteratives / emergentes Design zu stabileren, skalierbaren Systemen als Systeme, die im Voraus entworfen wurden?
• Wie effektiv ist die kontinuierliche Integration, um Softwarefehler proaktiv zu verhindern?

Für mich sind dies die Fragen, die bei XP zu berücksichtigen sind. Die oben angesprochenen Bedenken scheinen eher für eine Diskussion über Scrum (das sehr häufig mit XP gepaart wird) geeignet zu sein.

Für Referenzen würde ich sehen:

http://xprogramming.com/index.php

oder

http://www.objectmentor.com/resources/omi_reports_index.html

Prost und viel Glück bei Ihrer Recherche.