Wie bringe ich unseren Kunden dazu, sich um Komponententests zu kümmern, anstatt nur um Funktionen und Fehlerbehebungen?

Ich arbeite an einem neuen Projekt und der Code wird von mindestens zehn Softwareentwicklern geteilt und geschrieben. Es gibt einige Module, die lesbar sind, und einige Teile, die vollständig aus Spaghetti-Code bestehen.

Ich habe versucht, diesen Punkt zur Sprache zu bringen und erwähnte dies unserem Kunden und Architekten und schlug auch Unit-Tests vor. Unser Kunde unterstützt diese Dinge nicht und ist nur an der Entwicklung von Funktionen interessiert und kümmert sich nicht um Qualität und Regression.

Unser Architekt und ich sind uns einig, dass Komponententests uns helfen werden, die Regression in Schach zu halten, bevor wir neue Funktionen einführen.

Wie bilde ich unseren Kunden auf, damit das Projekt nicht bald implodiert, da viele Leute daran arbeiten und es besser spät als nie ist, einen Prozess einzubauen, der zu besserer Qualität führt?

Beauftragen Sie Ihren Kunden mit Ihren Bemühungen, was bedeutet, dass er Sie stundenweise für die Arbeit bezahlt, die er Ihnen sagt? Oder werden Sie dafür bezahlt, dass Sie eine bestimmte Software liefern?
@JoeStrazzere Wenn Sie nicht im Rahmen eines Wartungsvertrags arbeiten, würde ich normalerweise Fehlerkorrekturen als unter einen Garantieaspekt eines Projekts fallend ansehen und sie nicht in Rechnung stellen (vorausgesetzt, es handelt sich um einen tatsächlichen Fehler und nicht um eine hirntote Anforderung). Auf der anderen Seite sind Scope-Änderungen eine offene Saison für $$$
Alles, was Sie ihnen in einem Kostenvoranschlag zeigen, wird als Einzelposten angesehen, der eliminiert werden kann. Zeigen Sie daher nichts, was nicht eliminiert werden kann.
@PeterM Wenn sich der Kunde wirklich nicht um Qualität und Regression kümmert, warum sollte er dann für eine Garantie bezahlen wollen?
@alephzero Auf die gleiche Weise wird Ihr neues Auto mit einer Garantie geliefert, die Sie nicht separat erworben haben.
Ich habe noch nie einen Kunden getroffen, der sich wirklich nicht um Qualität gekümmert hat, egal was er gesagt hat. Wenn Sie versucht haben, sie dazu zu bringen, für Müll zu bezahlen, mit dem Haftungsausschluss "aber Sie sagten, Ihnen sei die Qualität egal", wird das nicht funktionieren. Was dann passieren wird, ist, dass es eine Debatte darüber geben wird, was gesagt oder (miss)verstanden wurde.
Wenn dies ein externer Kunde ist, sagen Sie im Grunde: "Was Sie bisher bei uns gekauft haben, ist Mist, aber ich, der neue Typ, werde es reparieren"? Ich wäre schneller aus der Tür, als du diesen Satz beenden kannst.
In manchen Geschäften sind Zeitplan und Fristen wichtiger. Ein Geschäft, für das ich gearbeitet habe, könnte über 1 Mio. USD verlieren, wenn die Frist versäumt wird. Sie sagten, dass einige Softwarefehler in Updates behoben werden könnten. Updates hatten einen anderen Zeitplan und andere Fristen.
@ThomasMatthews wahrere Worte wurden nie gesprochen. Es sollte eine Antwort sein.
Die Antwort auf jede Frage des Formulars "Wie bringe ich X dazu, Y zu tun?" ist "Erkläre ihnen den Wert, damit sie es tun wollen."
Wenn Sie es jemals herausfinden, haben Sie den goldenen Gral des Software-Engineerings herausgefunden. Kunden neigen dazu, sich nicht um technische Schulden und Tests zu kümmern, solange alles funktioniert, und stellen daher auf Anfrage keine Mittel für diese Dinge bereit. Am besten: nicht fragen.
Nennen Sie es nicht "Einheitentest". Nennen Sie es „Verfügbarkeitsoptimierung“.

Antworten (6)

Sie gehen mit Ihrem Kunden zu sehr ins Detail.

Vermutlich sind sie zu Ihnen gekommen (also zu Ihrem Team oder Ihrer Firma), weil Sie mehr über Softwareentwicklung wissen als sie. Es hört sich so an, als ob Sie jetzt versuchen, sie über Softwareentwicklung aufzuklären, um ihnen zu helfen, die Vorteile von Komponententests zu verstehen. Sie sollten stattdessen einfach die Zeit zum Erstellen geeigneter Komponententests in Ihre Schätzungen für neue Funktionen einbeziehen.

Wenn Sie gefragt werden, warum die Schätzungen höher erscheinen als zuvor (oder wenn Sie es vorziehen, im Voraus transparenter zu sein), erklären Sie, dass die höhere Investition im Voraus zu niedrigeren Wartungskosten und damit zu einem schnelleren Zugriff auf mehr Funktionen in der Zukunft führt.

Dies eröffnet Ihrem Kunden die Möglichkeit, jetzt eine Präferenz für kostengünstigere Funktionen zu äußern, mit dem Risiko hoher Wartungskosten in der Zukunft. Wenn es sich um einen internen Kunden handelt, eskalieren Sie das Problem, um sicherzustellen, dass das Unternehmen von diesem Ansatz überzeugt ist. Wenn der Kunde ein externer Kunde ist, hat er durchaus das Recht, sein Geld auf diese Weise auszugeben. Solange es Ihnen nichts ausmacht, Fehler zu beheben, ist Ihre zukünftige Anstellung sicher.

Machen Sie sich vorerst keine Gedanken über Vorschläge zum Refactoring von vorhandenem Spaghetti-Code. Wenn Ihr Kunde die Vorteile des Testens neuer Funktionen sieht, wird er später eher eine Investition in die vorhandene Codebasis unterstützen. Wenn Sie am Ende keine neuen Funktionen testen, gibt es keine Möglichkeit, Tests nachzurüsten (siehe vorheriger Kommentar zu zukünftigen Wartungszahlungen in diesem Fall).

Hätte ich selbst nicht besser sagen können. - Als Software Engineer müssen Sie lernen, mit Kunden zu sprechen, ohne auf die technischen Details einzugehen. Ich würde die Worte „Unit-Tests“ niemals gegenüber einem Kunden erwähnen, es sei denn, er fragt ausdrücklich danach.
"Sie gehen mit Ihrem Kunden zu sehr ins Detail." genau richtig. Mach es einfach richtig und sag nichts.
Mein letztes Unternehmen hatte ein Problem, bei dem wir eine detaillierte Aufschlüsselung einer Funktion einschließlich Dokumentation und Testzeit gegeben haben. Kunden kamen immer wieder und verlangten, dass wir sie auslassen, um Kosten zu sparen ... Dies führte zu vielen Problemen. - Als wir anfingen, einen einzigen Preis pro Funktion zu geben, sagten die Kunden nichts und akzeptierten einfach die Arbeit.
Oftmals funktioniert es nicht, den Kunden über das hinauszubilden, was er zu lernen bereit ist. Dinge müssen in eine Sprache gebracht werden, die sie verstehen, was oft bedeutet, dass viele Details übersprungen werden. Sprechen Sie stattdessen einfach über die Qualität Ihrer Arbeit. Refactoring von bestehendem Code muss oft in der Gesamtkostenschätzung versteckt und nicht herausgebrochen werden. Nur wenige Kunden schätzen es, Code zu überarbeiten, der „bereits funktioniert“.
Diese Antwort ist absolut richtig. (Der Kunde zahlt auch nicht für Fehler, also hören Sie auf, ihm Fehler zu liefern!) Außerdem würde ich auch sagen, dass es auch den Umfang potenzieller Prozessänderungen einschränkt, wenn Sie ihm einen detaillierten Überblick über das Wesentliche geben. Vielleicht erweist sich Unit Testing als nicht nützlich, aber einige Methoden wie End-to-End-Tests wären vorteilhafter. Aber dazu müssen Sie zum Kunden zurückgehen und neu verhandeln. Es ist viel besser, das vor ihnen zu verbergen.
Exakt! Bei einer Operation bittet der Chirurg seinen Patienten nicht um Erlaubnis, sich 5 Minuten lang die Hände waschen und schrubben zu dürfen. Und in einem Restaurant fragt der Küchenchef seine Kunden nicht, ob sie ihm erlauben, seine Messer zu schärfen, seine Küche zu reinigen, seine Speisekammer/Kühlschrank zu organisieren oder den Grill vorzuwärmen, bevor er eine Mahlzeit zubereitet. Er tut diese Dinge einfach, weil ihn die Erfahrung gelehrt hat, dass diese Art von Vorbereitungsarbeit wichtig ist. Wenn der Kunde der Meinung ist, dass dies zu viel Zeit in Anspruch nimmt, steht es ihm frei, woanders hinzugehen oder stattdessen seinen Neffen einzustellen, der die Aufgabe erledigt. Wenn Ihr Kunde unvernünftig ist, müssen Sie ihn feuern.
"Solange es Ihnen nichts ausmacht, Fehler zu beheben" - wichtiger Punkt, was, wenn ich es tue. Ich glaube, dass es einen grundlegenden Unterschied gibt, wie ich meinen Tag verbringe, zwischen dem konstruktiven Erfinden von Features und dem Erkunden der Tiefen und dem Bewahren von abgründigem Code. Wenn ich diese Funktionen so baue, wie sie sein sollen, habe ich außerdem die Möglichkeit, meine Karriere voranzutreiben, indem ich mich in weitere Disziplinen und Technologien einbringe. Im Gegensatz dazu, wenn ich mich wochenlang tief in ein Durcheinander stürzen muss, kann das sehr wohl die Zeit verschwenden und damit das Leben derer, die gezwungen sind, sich darauf einzulassen.
Meine Lektüre der ursprünglichen Frage war, dass der "Code von mindestens zehn Entwicklern geteilt und geschrieben wird", und diese Entwickler nicht alle für das Unternehmen des Fragestellers arbeiten. Wenn sie also ein Komponententest-Framework auferlegen wollen, die anderen Entwickler des Kunden müsste es auch verwenden.
Ich werde noch weiter gehen und sagen, dass, wenn es möglich ist, Arbeitszeittabellen in „Geschäftscode schreiben“ und „Testen“ zu unterteilen, der Prozess des Schreibens von Tests verbessert werden muss. Ich bin kein eingefleischter TDD-Unterstützer, aber Tests und der zu testende Code sollten Hand in Hand entwickelt werden.
@GregoryCurrie: Schön. Also grundsätzlich: Entwicklungsprozess kapseln.
Ja, das funktioniert
Obwohl ich diesen Ansatz wählen würde, sehe ich einen großen Nachteil: Sie können von Konkurrenten unterboten werden, die lukrative kurzfristige Fortschritte und Geschwindigkeit zu geringeren Kosten versprechen. Sicher, wir wissen, dass alles zusammenbrechen wird, sobald sie die „Schlammballen“-Phase des Projektlebenszyklus erreicht haben, aber viele Kunden haben möglicherweise nicht die gleiche Voraussicht.

Wenn ein Profi jemandem eine erste Schätzung gibt, sollte es für die „richtige“ Arbeit sein. Für Software, die nicht einmalig ist, umfasst dies normalerweise Untersuchungs-/Designzeit, Komponententests, Integrationstests, QA-Zeit und alle anderen notwendigen Teile der Entwicklung von qualitativ hochwertigem Code. Wenn die anfängliche Schätzung zu teuer ist oder zu lange dauert, dann verhandeln Sie, welche Funktionen im Umfang reduziert oder weggelassen werden, oder einen verkürzten QA-Zyklus mit erhöhtem Risiko.

Unit-Tests fallen zu lassen, wäre nichts, was ich auf den Tisch legen würde, da ich sie als Teil der normalen Entwicklung betrachte. Ich könnte anbieten, einen „schnellen und schmutzigen“ Prototyp eines Features zu erstellen, wenn wir uns einigen, dass wir den Prototyp wegwerfen und es richtig machen, wenn der Kunde dieses Feature möchte.

Ich stelle keinen Klempnermeister ein und schätze dann die Notwendigkeit jedes der Schritte, die er tut, um die Arbeit zu erledigen. Warum ist Ihr Kunde so stark in Ihre Entwicklung involviert? Wenn Sie ein neues Feature erstellen, schätzen Sie die Zeit, um es richtig zu machen, einschließlich Unit-Tests für das neue Feature und machen jeden Legacy-Code, den Sie berühren, robuster.

Es ist unrealistisch zu erwarten, dass ein Kunde dafür bezahlen möchte, dass Ihr Team Ihren Code bereinigt, um dem Team die Arbeit zu erleichtern, weil sich das Team nicht die Zeit genommen hat, beim ersten Mal gute Arbeit zu leisten.

Das Team muss damit beginnen, Unit-Tests zu berücksichtigen und stinkenden Code in seine Schätzungen für alles weitere einzubeziehen, anstatt zu versuchen, den Kunden dazu zu bringen, dafür zu zahlen, dass alter Code auf die Qualität gebracht wird, die er hätte erhalten sollen, als er für das Schreiben bezahlt wurde.

Die andere Sache ist, dass, wenn Sie etwas falsch bauen und es finanzielle Auswirkungen auf den Kunden hat (z Der Kunde wird mit dem Finger auf Sie zeigen und Sie sind dafür verantwortlich, etwas falsch zu machen. Sie müssen sich schützen.

Wie motiviere ich unseren Kunden, der Unit-Tests abgeneigt ist und nur Features und Bugfixes will?

Ich denke, Sie sagen: "Es kostet nicht mehr Geld oder dauert länger." Aber ist das wahr? Manchmal ist es. Manchmal ist es nicht.

Der Kunde wird Ihnen nicht zuhören, weil Sie nicht ganz oben in der Hierarchie stehen. Der Architekt hat bereits vergeblich versucht, sie zu überzeugen, also haben sie keinen Grund, Ihnen zuzuhören. Soweit Sie wissen, sagte der Architekt dem Kunden sogar, dass keine Tests erforderlich seien.

Manchmal muss ein Kunde so schnell wie möglich auf den Markt kommen, um mehr Geld zu sammeln. Sie kümmern sich nicht um die langfristigen Wartungskosten. Natürlich, wenn Sie wissen, dass es absolut kritisch ist zu testen (Finanz-Apps, medizinische Scanner, Fahrzeugkontrollen und dergleichen), dann machen Sie es entweder richtig oder suchen sich woanders einen neuen Job und/oder melden es den Behörden. Wenn Sie eine Website für Muffinläden oder ähnliches erstellen, schwitzen Sie nicht. Es ist die Entscheidung des Kunden, wie er sein Geld ausgibt, auch wenn es aus technischer Sicht töricht ist.

Du nicht. Sie tun, was der Kunde verlangt. Sie weisen den Kunden darauf hin, dass die Software nicht vollständig getestet wird und möglicherweise Fehler und andere Probleme aufweist, wenn Sie keinen Zeitplan erhalten, der genügend Spielraum zum Hinzufügen dieser Robustheitsfunktionen bietet, und wenn sie eine robuste Software wünschen, dann sie müssen Ihnen einen Zeitplan geben, der es Ihnen ermöglicht, eine robuste Software zu erstellen. Wenn es dem Kunden egal ist, ob sein Server abstürzt, dann bauen Sie, was Sie können, und lassen den Server abstürzen.

VORBEHALT : Ich gehe davon aus, dass Sie ein direkter Auftragnehmer des "Kunden" sind. Wenn Sie ein Mitarbeiter des Kunden sind, sollten Sie mit Ihrem Vorgesetzten über die Softwareentwicklungspraktiken sprechen und sicherstellen, dass Sie auf derselben Seite sind, denn was auch immer Sie erstellen, wird bei Ihrem Vorgesetzten schlecht aussehen, wenn es schlecht ist. Wenn Sie ein Mitarbeiter eines Beratungsunternehmens sind, das diesen Kunden hat, sollten Sie Ihren Vorgesetzten des Beratungsunternehmens darauf aufmerksam machen, dass der Kunde ausdrücklich darum gebeten hat, dass keine Tests durchgeführt werden (möglichst schriftlich), damit, wenn die Scheiße aufgeht ( was unweigerlich der Fall sein wird), wird Ihr Unternehmen damit übers Ohr gehauen, dass der Kunde nicht sagen kann, er sei nicht gewarnt worden oder habe es nicht gewusst.

Nun, es ist nicht nur so, dass die Software fehlerhaft ist, wenn es keine Komponententests gibt. Das spätere Beheben dieser Fehler wird (möglicherweise viel) teurer sein, als jetzt für die Tests zu bezahlen – selbst wenn die Kosten für die Fehler selbst ignoriert werden, wenn sie in der Produktion auftauchen.
WAHR. Aber das ist nicht das Problem von OP. Das ist das Problem des Kunden. Wenn der Kunde später lieber mehr bezahlen möchte, um den fehlerhaften Code von OP zu debuggen, weil er OP nicht die Tools gegeben hat, die er benötigt, um überhaupt einen richtigen Code zu schreiben, ist das das Problem des Kunden. OP gibt ihnen eine faire Warnung, dass das Produkt möglicherweise nicht perfekt ist, wenn es geliefert wird, und hier endet die Verantwortung von OP; Wenn der Kunde dieses Risiko akzeptiert, liegt es in der Verantwortung des Kunden, das Chaos zu beseitigen oder OP die Werkzeuge zu geben, die er benötigt, um diese Situation zu verhindern.
Einverstanden, obwohl die faire Warnung stärker sein sollte als nur „das Produkt ist möglicherweise nicht perfekt, wenn es geliefert wird“. (Auch bei Unit-Tests ist das Produkt sicher nicht perfekt ...)

In vielen Shops sind Deadlines wichtiger als alle Probleme zu lösen. Ich war in einem Geschäft, wo das Unternehmen bei Versäumung einer Frist 1 Million USD verlieren könnte. Das Unternehmen sagte, dass sie später Updates herausgeben könnten und die Updates die Korrekturen enthalten könnten.

Im Projektmanagement müssen Sie Ihre Prioritäten abwägen. Beispielsweise geriet ein Projekt, an dem ich arbeitete, in Verzug, sodass viele der Anforderungen reduziert wurden. Auf ähnliche Weise sollten Probleme in eine Rangfolge gebracht werden, sodass die Probleme mit der niedrigsten Priorität nach Bedarf entfernt werden, um die Frist einzuhalten.

Eine der Anforderungen des Entwicklers ist es, dem Projektmanager eine gute Einschätzung der Arbeit zu geben. Der Entwickler muss auch alle Abweichungen melden, die er sieht (kommende oder unmittelbare). Dies ermöglicht es den Beteiligten, den Zeitplan zu überprüfen und entsprechende Änderungen vorzunehmen. Je früher die Berichterstattung, desto bessere Umplanungsmöglichkeiten.

Je später ein Fehler, ein Problem, eine Schwierigkeit oder eine Fehlfunktion entdeckt wird, desto kostspieliger ist natürlich die Behebung. Unit-Tests sind entscheidend, damit die Units aufgebaut und zusammengesetzt werden können und funktionieren. Dies ist nur gesunder Menschenverstand, bei mechanischen Geräten oder Geschäftsplänen, ebenso wie bei Programmen und Systemdesigns, aber es ist oft sehr schwierig, Menschen außerhalb des Handwerks dazu zu bringen, es zu verstehen. Vielleicht hilft etwas Aufklärung mit wirklich einfachen physikalischen Analogien.

Wie bringe ich unseren Kunden dazu, sich um Komponententests zu kümmern, anstatt nur um Funktionen und Fehlerbehebungen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v