Wie kann ich meinen Stakeholdern und Managern beweisen, dass meine Software funktioniert?[geschlossen]

Question

Was erwartet Softwareentwickler nach einer weiteren stressigen Veröffentlichung?Nun, das erste, was uns in unserer Gruppe begegnet, sind die Bugs, die wir offengelegt haben.Das größte Problem, auf das wir als Softwareentwickler nach einer stressigen Veröffentlichung stoßen, ist Spaghetti-Code, auch „Spaghetti-Code“ genannt großer Schlammball.

Die Zeit und das Geld, um nach Perfektion zu streben, stehen selten zur Verfügung und sollten es auch nicht sein.Um zu überleben, müssen wir alles Notwendige tun, um unsere Software rechtzeitig zum Laufen zu bringen und auf den Markt zu bringen.Wenn ein Team ein Projekt mit Zeitreserven abschließt, nehmen die Manager von heute dies wahrscheinlich als Zeichen dafür, dass sie beim nächsten Mal weniger Zeit und Geld oder weniger Leute bereitstellen.

Sie müssen qualitativ hochwertige Software pünktlich und im Rahmen des Budgets liefern

Kosten:Architektur ist eine langfristige Investition.Für die Leute, die die Rechnungen bezahlen, ist es leicht, die Sache abzulehnen, es sei denn, es ergibt sich ein greifbarer unmittelbarer Vorteil, etwa eine Steuerabschreibung, oder es steht zufällig überschüssiges Geld und Zeit zur Verfügung.Das ist selten der Fall.Häufiger benötigt der Kunde etwas, das bis morgen funktioniert.Oftmals betrachten die Menschen, die den Entwicklungsprozess steuern und verwalten, die Architektur einfach nicht als dringendes Anliegen. Wenn Programmierer wissen, dass handwerkliche Arbeit unsichtbar ist und Manager sowieso nicht dafür bezahlen wollen, entsteht ein Teufelskreis.

Aber wenn dies wirklich der Fall wäre, würde jedes langfristige Softwareprojekt irgendwann zu einem großen Schlammballen führen.

Wir wissen, dass das nicht immer passiert.Wie kommts?Denn die Aussage, dass Architektur für Manager kein drängendes Anliegen sei, ist falsch.Zumindest heutzutage.Manager im IT-Bereich wissen sehr gut, dass Wartbarkeit für das Unternehmen von entscheidender Bedeutung ist.

Unternehmen werden von den Daten abhängig, die sie steuern.Unternehmen sind zunehmend von ihrer Software und ihrer Computerinfrastruktur abhängig.Es gibt zahlreiche geschäftskritische Systeme, die rund um die Uhr und sieben Tage die Woche auf Sendung sein müssen.Wenn diese Systeme ausfallen, können Lagerbestände nicht überprüft werden, Mitarbeiter können nicht bezahlt werden, Flugzeuge können nicht geroutet werden und so weiter.[..]

Deshalb ist es das Herzstück des Unternehmens, nach Möglichkeiten zu suchen, die Systeme vom großen Schlammball fernzuhalten.Dass das System noch wartbar ist.Dass das System tatsächlich funktioniert und dass Sie als Programmierer beweisen können, dass es funktioniert.Fragt Ihr Vorgesetzter Sie, ob Sie heute mit der Codierung fertig sind, fragt er Sie, ob die Veröffentlichung mit den Fixes A, B und C heute fertig gestellt werden kann, oder fragt er Sie, ob die Software, die veröffentlicht wird, tatsächlich funktioniert?Und haben Sie bewiesen, dass es funktioniert?Mit was?

Nun zu meiner Frage:

Welche Möglichkeiten haben wir, unseren Managern und/oder Stakeholdern zu beweisen, dass unsere Software funktioniert?Sind die grünen Lichter unserer Software-Unit-Tests gut genug?Wenn ja, beweist das nicht nur, dass unser großer Schlammball immer noch das tut, was wir von ihm erwarten?Dass die Software wartbar ist?Wie können Sie beweisen, dass Ihr Design richtig ist?

[Später hinzugefügt]

Chris Pebbles Antwort unten bringt mein Team auf den richtigen Weg.Die Qualitätssicherung ist definitiv das, wonach wir suchen.Danke Chris.Eine mit den Stakeholdern vereinbarte QS-Richtlinie ist dann das logische Ergebnis dessen, was mein Team sucht.

Die Folgefrage lautet: Was sollte alles in dieser Qualitätssicherungsrichtlinie enthalten sein?

• Der Buildserver läuft für meine Stakeholder sichtbar
• Der Buildserver muss nicht nur „nur erstellen“, sondern auch Tests hinzufügen, die Teil der QS-Richtlinie waren
• Eine Vereinbarung meiner Stakeholder zu unserem Entwicklungsprozess zu haben (zu der die gegenseitige Überprüfung des Codes durch Entwickler gehört)
• mehr..

Noch ein paar Infos:Das Team, das ich leite, erstellt Webservices, die von anderen Softwareteams genutzt werden.Deshalb kostet ein kaputter Webservice sofort Geld.Wenn die Entwickler des Presentationlayer-Teams oder die eigentlichen Tester nicht weiterkommen, geraten wir sofort in Stress und müssen Fehler so schnell wie möglich beheben, was wiederum zu schnellen Hacks führt.

[später hinzugefügt]

Vielen Dank für alle Antworten.Es geht in der Tat um „Vertrauen“.Wir können keine Veröffentlichung durchführen, wenn die Software nicht von den Stakeholdern vertrauenswürdig ist, die unsere Software selbst aktiv über die Website testen, die unseren Webservice nutzt.Wenn Probleme auftreten, lautet die erste Frage unserer Tester:Handelt es sich um ein Servicelayer-Problem oder ein Präsentationslayer-Problem?Was mich dazu anweist, eine QS-Richtlinie zu haben, die sicherstellt, dass unsere Software für die von ihnen durchgeführten Tests geeignet ist.

Daher kann ich mir (jetzt) ​​nur vorstellen, Vertrauen bei Testern zu schaffen, indem ich:- Sprechen Sie mit dem aktuellen Testteam, gehen Sie die Tests durch, die sie manuell ausführen können (aus ihrem Testskript und Szenario) und stellen Sie sicher, dass unser Team diese Tests als Unit-Tests bereits mit unserem Webservice überprüft hat.Das wäre ein guter Ausgangspunkt für eine „Abnahme“, bevor wir eine Veröffentlichung veröffentlichen, die das Präsentationsschichtteam integrieren muss.Es wird einige Mühe erfordern, klarzustellen, dass die Erstellung automatischer Tests für alle diese Szenarios einige Zeit in Anspruch nehmen wird.Aber es wird auf jeden Fall nützlich sein, um sicherzustellen, dass das, was wir bauen, tatsächlich funktioniert.

Answer 1

Sie können es nicht über den Rahmen der Tests hinaus beweisen, und solange es keine kugelsichere Spezifikation gibt (die es nie gibt), beweisen die Tests nie etwas, das über das Offensichtliche hinausgeht.

Was Sie als Team tun können, ist, verantwortungsbewusst an Ihr Software-Design heranzugehen und nicht der Versuchung nachzugeben, schlechten Code zu schreiben, um Manager zufrieden zu stellen, die notwendigen Ressourcen und Zeitbeschränkungen zu fordern und den gesamten Prozess als Handwerk zu betrachten ein Beruf.Die besten Renaissance-Bildhauer wussten, dass niemand die Rückenstatuen sehen würde, die in den Ecken der Kathedralen aufgestellt werden sollten, aber sie bemühten sich dennoch, sicherzustellen, dass sie sich nicht unter Wert verkauften.

Als Team können Sie die Zuverlässigkeit Ihrer Software nur beweisen, indem Sie eine Erfolgsbilanz aufbauen:Machen Sie die Dinge von Anfang an richtig, beheben Sie Fehler, bevor Sie neue Funktionen implementieren, geben Sie niemals der schnellen Hack-Lösung nach und stellen Sie sicher, dass alle die gleiche Begeisterung und den gleichen Respekt für den Code haben.

Answer 2

Ich bin Teil eines Teams, das an einem großen Projekt für einen Regierungskunden arbeitet.Das erste Modul von Phase 1 war eine große Katastrophe, das Team wurde nicht verwaltet, es gab kein QA-Team und die Entwickler waren nicht motiviert, besser zu arbeiten.Stattdessen schrie der Manager ständig und kürzte den Lohn für Leute, die keine Überstunden machten!!

Der Kunde, hm, fragen Sie nicht danach, er war wirklich sauer, aber er ist bei unserem Unternehmen geblieben, weil er weiß, dass niemand das Geschäft so gut versteht wie wir.

Was war also die Lösung:

• Als Erstes trennte man das Management von den Programmierern und setzte einen freundlichen Teamleiter ein.
• Zweitens: Holen Sie sich ein qualifiziertes QS-Team.In den ersten Wochen gab es Hunderte von Fehlern.
• Drittens: Setzen Sie 2-3 Entwickler als Support-Team ein. Die Verantwortung liegt nicht darin, neue Aufgaben zu erledigen, sondern nur Fehler zu beheben und direkt mit der Qualitätssicherung zusammenzuarbeiten.
• Viertens: Motivieren Sie die Jungs. Manchmal geht es nicht um Geld oder zusätzliche Urlaubstage, manchmal ist ein gutes Wort perfekt.Kleines Beispiel: Nachdem der Teamleiter drei Tage hintereinander fast 15 Stunden am Tag gearbeitet hatte, machte er dem Manager eine Notiz.Zwei Tage später erhielt ich einen Brief vom CEO, in dem er sich für meine Bemühungen bedankte und mir zwei Urlaubstage gewährte.

Wir werden bald das 4. Modul des Systems ausliefern und als Mitglied des Support-Teams kann ich sagen, dass es zu mindestens 95 % fehlerfrei ist.Das ist ein großer Sprung gegenüber unseren ersten Modulen.

Heute verfügen wir über ein leistungsstarkes Entwicklungsteam, qualifizierte Qualitätssicherung und erfahrene Fehlerbehebungen.

Entschuldigung für die lange Geschichte, aber so hat unser Team (während 4 Monaten) dem Manager und dem Kunden bewiesen, dass wir zuverlässig sind und einfach die richtige Umgebung brauchen.

Answer 3

In allen außer trivialen Fällen können Sie nicht „beweisen“, dass Ihre Software korrekt ist.

Das ist die Rolle von User AAkzeptanz Test:um zu zeigen, dass ein akzeptables Maß an Nützlichkeit erreicht wurde.

Answer 4

Ich glaube, das ist, als würde man das Pferd von hinten aufzäumen.Es ist so, als würde ein Fußsoldat dem General erklären, was Kampfmanöver sind und warum es wichtig ist, die eigenen Flanken zu schützen.Wenn das Management den Unterschied zwischen Qualitätscode und einem großen Schlammball nicht erkennen kann, wird es am Ende immer einen großen Schlammball liefern.

Leider ist es völlig unmöglich zu „beweisen“, dass Ihre Software fehlerfrei funktioniert (die Windows XP-Werbespots haben mich immer geärgert, indem sie „die sicherste Windows-Version aller Zeiten“ ankündigten, das lässt sich bei der Veröffentlichung nicht beweisen).Es ist Aufgabe des Managements, einen Qualitätssicherungsprozess einzurichten und durchzusetzen sowie Maßstäbe dafür festzulegen, wie ein lieferbares Produkt tatsächlich aussieht und welcher Grad an Fehlern oder unerwartetem Verhalten in der endgültigen Version akzeptabel ist.

Wenn Sie jedoch ein kleines Team sind und Ihre eigenen QA-Richtlinien mit wenig Input vom Management festlegen, wäre es meiner Meinung nach von Vorteil, einen grundlegenden QA-Prozess zu schreiben und ihn vom Management genehmigen zu lassen.Für unsere Web-Apps unterstützen wir derzeit 4 Browser – und das Management weiß das – wenn also die Anwendung in einem obskuren Handheld-Browser kaputt geht, versteht jeder klar, dass dies nicht etwas ist, für dessen Unterstützung wir die Anwendung entwickelt haben.Es bietet auch einen guten Hebel für die Einstellung zusätzlicher Entwicklungs- oder Testressourcen, wenn das Management beschließt, mit dem Testen für x zu beginnen.

Answer 5

Wie Billy Joel einmal sagte: „Es war schon immer eine Frage des Vertrauens.“

Sie müssen verstehen, dass Softwareentwicklung für alle „schwarze Magie“ ist, außer für diejenigen, die Software schreiben.Für den Rest Ihres Unternehmens ist es nicht offensichtlich (eigentlich eher kontraintuitiv), dass viele Ihrer Initiativen zu einer Steigerung der Qualität und einer Verringerung des Risikos einer Zeit- und/oder Budgetüberschreitung führen.

Der Schlüssel liegt darin, eine vertrauensvolle, respektvolle Beziehung zwischen der Entwicklung und anderen Teilen des Unternehmens aufzubauen.Wie baut man dieses Vertrauen auf?Nun, das ist eines dieser Probleme mit gefühlsbetonten Menschen ...Sie müssen ein wenig experimentieren.Die folgenden Tools verwende ich häufig:

1. Prozesstransparenz - Stellen Sie sicher, dass jeder weiß, was Sie tun und wie die Dinge voranschreiten.Stellen Sie außerdem sicher, dass jeder die Auswirkungen und Änderungen während der Entwicklung sehen kann.
2. Weisen Sie auf die kleinen Siege hin - Um Vertrauen aufzubauen, weisen Sie darauf hin, wann alles genau so gelaufen ist, wie Sie es geplant haben.Versuchen Sie, Situationen zu finden, in denen Sie ein Urteil fällen mussten, und verwenden Sie gegenüber Ihrem Management den Begriff „Risikominderung“.
3. Sagen Sie nicht: „Ich habe es Ihnen gesagt.“ - Nehmen wir an, Sie haben das Management mitgeteilt, dass Sie 2 Monate benötigt, um eine Aufgabe zu erledigen, und sie sagen: "Nun, Sie haben nur drei Wochen." Das Ergebnis ist wahrscheinlich nicht gut (vorausgesetzt, Ihre Schätzung ist korrekt).Machen Sie das Management auf das Problem aufmerksam und dokumentieren Sie alles, was Sie tun mussten, um die Frist einzuhalten.Wenn sich herausstellt, dass die Qualität schlecht ist, können Sie die Probleme, mit denen Sie konfrontiert waren (und die Sie aufgezeichnet haben), professionell bearbeiten, anstatt mit dem Finger zu zeigen und zu sagen: „Das habe ich Ihnen gesagt.“

Wenn Sie eine gute Beziehung zu Ihrem Vorgesetzten haben, können Sie ihm vorschlagen, einige Bücher speziell zur Softwareentwicklung zu lesen, damit er die Best Practices der Branche verstehen kann.

Außerdem möchte ich Ihren Chef darauf hinweisen, dass es Ihrer Karriere schadet, wenn Sie nicht als professioneller Softwareentwickler agieren dürfen.Sie möchten wirklich an einem Ort arbeiten, an dem Sie sich beruflich weiterentwickeln können, und nicht an einem Ort, an dem Sie zum Hacker werden.