Ist das Schreiben von Software bei fehlenden Anforderungen eine Fähigkeit oder eine Situation, die ich vermeiden sollte?

44

Ich finde, dass einige Softwareentwickler darin sehr geschickt sind und oftmals für ihre Fähigkeit gelobt werden, ein Arbeitskonzept mit abstrakten Anforderungen zu liefern. Ehrlich gesagt, macht mich das verrückt, und ich mag es nicht, es mir zu überlegen, wenn ich gehe. Früher dachte ich, das sei problematisch, aber ich habe angefangen, eine Veränderung zu spüren, und ich frage mich, ob ich meinen Gedanken- (und Programmier-) Prozess anpassen muss, wenn mir sehr wenig Anweisungen gegeben werden. Sollte ich anfangen, diese Fähigkeit als Fertigkeit zu erwerben, oder mich an die Idee halten, dass das Sammeln von Anforderungen und die Geschäftsregeln die erste Priorität haben?


quelle
2
Eine Situation zu vermeiden. Das einzige ist, dass du es nicht kannst. Und ich habe schimpfen über sie vor wenigen Wochen ...
Yannis
64
Es ist beides, als würde man einen Feuerlöscher bedienen.
Ben Brocka
3
Wenn Sie nicht planen, planen Sie auch nicht. Diese Projekte, die ohne Anforderungen erstellt wurden, entsprechen möglicherweise nicht den Erwartungen des Kunden, wenn sie das Geschäft verlassen, aber sie verbergen mit ziemlicher Sicherheit eine Vielzahl von Sünden. Wenn sich die Anforderungen ändern (und dies auch immer tun), erwartet die Person, die dies tun muss, eine Welt voller Verletzungen Nehmen Sie die erforderlichen Änderungen vor. Programmierer, die ohne formale Anforderungen schreiben, sollten nicht gelobt werden. Sie sollten gerügt werden, weil sie nicht auf die langfristige zukünftige Wartung des Projekts
vorbereitet sind
10
Obligatorischer Dilbert: dilbert.com/strips/comic/2006-01-29
Dan Neely
5
Manchmal weiß der Kunde nicht, was er will. Sie möchten, dass Sie "Experimente" durchführen, um festzustellen, was sie wollen. Ich habe einmal ein Provisionssystem geschrieben, bei dem es nur darum ging, Provisionen zu zahlen. Der Prozentsatz und die Provisionspositionen sollten durch Erfahrung mit dem experimentellen Provisionssystem bestimmt werden.
Gilbert Le Blanc

Antworten:

80

Es ist nicht die Fähigkeit, Software ohne Anforderungen zu schreiben. Stattdessen sollen Anforderungen vom Projektverantwortlichen unabhängig davon ermittelt werden, ob eine formale Anforderungsdokumentation vorliegt oder nicht.

Das Sammeln von Anforderungen ist definitiv Ihre oberste Priorität, aber Sie müssen nicht unbedingt alle Kundenbedürfnisse im Voraus festhalten. Das Risiko besteht natürlich darin, dass Sie wichtige Informationen verpassen, die Ihre Systemarchitektur unbrauchbar machen, wenn Sie nicht die richtige Art von Gesprächen mit Ihrem Kunden führen. Es ist jedoch nicht ungewöhnlich, ein Produkt zu definieren und überhaupt zu erhalten einen Großteil der Entwicklung aus dem Weg räumen und gleichzeitig die wichtigsten Entscheidungen zur Systemarchitektur bis zum letztmöglichen Moment verschieben. Dies ist ein schlanker Entwicklungsansatz, der sicherstellen soll, dass Sie sich nicht zu früh in Ihrer Produktentwicklung zu einer potenziell inkompatiblen Architektur bekennen, bis Sie über fundiertere Informationen verfügen. In den Situationen, die das OP in seiner Frage beschrieben hat,

Ja, manchmal muss man ein wenig in die Kristallkugel schauen, um zu verstehen, wonach der Kunde wirklich fragt, wo Prototyping-Spitzen und langsames - und manchmal auch schmerzhaftes - inkrementelles Herausziehen von Anforderungen erforderlich sind dass Sie wirklich gute Kundenbeziehungsfähigkeiten entwickeln und auch die Geduld, bei jeder komplexen Software-Idee zu erkennen, dass der Kunde am Anfang oft nicht viel mehr weiß als Sie, was die Software tatsächlich tun muss. In den meisten Fällen ruft der Kunde Sie frühzeitig an, um sich auf Ihre Fachkenntnisse zu verlassen und die Anforderungen zu definieren, da der Kunde nicht immer über die erforderlichen Fachkenntnisse oder Kenntnisse des Softwareentwicklungsprozesses verfügt.

S.Robins
quelle
22
"Die Fähigkeit, Software ohne Anforderungen zu schreiben, besteht nicht darin, dem Projektbesitzer Anforderungen zu entlocken, unabhängig davon, ob eine formale Anforderungsdokumentation vorliegt oder nicht." Darüber habe ich auch viel nachgedacht. Es ist fast so, als ob man ein guter Detektiv wäre oder weiß, wie man jemanden interviewt und die richtigen Fragen stellt. In dieser Situation stelle ich die Frage: "Können Sie mir sagen, was Sie tun möchten?" funktioniert viel besser als "Kannst du mir sagen, wie es funktionieren soll?"
5
@BrianReindel Ich beginne manchmal mit einer Kombination von Mind-Map / Binary-Tree der Gedanken des Kunden. Ich frage "Was ist die Idee?" Und verwende dann die Wortassoziation, um zu sehen, was jede Idee dem Kunden einfällt. Von dort aus erstelle ich ein Bild von dem, was der Kunde denkt, und beginne von dort aus, Anforderungen zu definieren. Jede Anforderung wirft Fragen auf, die gestellt werden müssen. In der Regel werden "Warum" -Fragen besser beantwortet als "Was / Wie" -Fragen, da sie dem Kunden die Möglichkeit geben, über das Wesentliche hinauszudenken. Es ist im Grunde eine Kunst, Psychologie einzusetzen, um die Bedürfnisse des Kunden zu offenbaren.
S.Robins
3
Ein Teil der Fertigkeit besteht darin, die Reihenfolge zu kennen, in der Dinge zu tun sind, und zu vermeiden, Dinge zu "perfektionieren", die sowieso zerrissen werden. Auf diese Weise können Sie sich mit dem Kunden / Manager / was auch immer treffen, ihm zeigen, was Sie bisher haben, und sich währenddessen anpassen. Sie müssen zuerst wissen, wie man die großen Schritte in die richtige Richtung macht.
David Schwartz
4
Eine Möglichkeit, Anforderungen zu ermitteln, besteht darin, ihnen etwas Grundlegendes zu geben und festzustellen, über welche Teile sie sich beschweren. Erstellen Sie beispielsweise einen Papierprototyp ( amazon.co.uk/… ) und führen Sie die Interaktionen mit ihnen durch.
Deworde
35

Das ist sehr vieldeutig ...

Zwei Dinge, die ich sagen kann:

  1. Es gibt viele sehr begabte Techniker, deren Karrieren gestoppt werden, weil sie auf perfekte Anforderungen warten. Oder sie spielen das "Sorry, kann es nicht, war nicht in den Anforderungen." Die Realität ist, dass das Schreiben von Anforderungen sehr schwierig ist. Die Präzision, die für gute Anforderungen erforderlich ist, ist anders als alles, was die meisten Geschäftsleute jemals geschaffen haben. Es gibt eine Brücke zwischen Technologie und Geschäft, und Menschen, die die anderen zu 100% dazu bringen, sich mit ihnen zu treffen, verlieren normalerweise.

  2. Es gibt Software-Leute, die die Domains so gut oder besser lernen als ihre Kunden. Diese Leute sind Gold wert, auch wenn sie nicht zu 100% die besten Entwickler sind. Ich habe gesehen, dass Software-Leute die quantitativen Marketingbedürfnisse der besten Markenmanager des Landes antizipieren. Sie waren nicht die Besten bei der Kodierung aller Lösungen, aber sie waren Helden, weil sie die Brücke überqueren konnten.

Das Leben dreht sich aber nicht um Schwarz und Weiß. Wenn Sie ein schmales Kästchen um sich ziehen, beschränken Sie sich. Auf der anderen Seite ist eine Organisation, die das ablehnt, was zur Schaffung von Technologie erforderlich ist, ebenfalls begrenzt. Du musst sehen, wo du lieber grau bist.

MathAttack
quelle
12

Anforderungen sind die Schritte auf dem Weg, eine Vision ist die Richtung

Für viele Anwendungen steht eine sehr detaillierte technische Spezifikation im Vordergrund, da eine schnelle Diskussion das sorgfältig gesetzte Dokument unbrauchbar machen kann. Beginnen Sie stattdessen mit einer Vision. Wenn jeder das Gesamtbild versteht, können die Anforderungen auf dem Weg durch Diskussionen ergänzt werden.

Als Entwickler müssen Sie lernen, diese Diskussionen zu nutzen, um Anforderungen zu ermitteln . Dies bedeutet, den Kunden wichtige Fragen zu stellen, die sie dazu bringen, darüber nachzudenken, wie ihre heutige Entscheidung in die Gesamtvision passt. Je früher diese detaillierteren Diskussionen stattfinden, desto schneller wird sich die Gesamtvision zu einem kohärenten Design verfestigen.

Sie sollten das Ergebnis dieser Diskussionen in einer Art Issue-Tracker nachverfolgen, damit andere sie kommentieren können, wenn sie die ursprüngliche Diskussion verpasst haben. Und damit Sie eine Aufzeichnung haben, auf die Sie oder andere Mitglieder Ihres Teams zurückgreifen können, sollten Sie eine Klärung benötigen.

Lerne also, gegen die Vision zu programmieren, aber sei bereit, diese Anforderungen zu erfüllen, wenn es soweit ist.

Gary Rowe
quelle
+1 für "Anforderungen sind die Schritte auf dem Weg, eine Vision ist die Richtung"
Benutzer
10

Steve Jobs glaubte, dass Kunden nicht genau beschreiben können, wie die zukünftigen Produkte aussehen sollen, und es ist Ihre Aufgabe, sie zu liefern. Wenn Sie also nicht ständig kundenspezifische Software liefern, vergessen Sie formale Spezifikationen und beginnen Sie mit der Erstellung von Prototypen. Lassen Sie die Kunden damit spielen und sagen Sie, was sie denken. Sie müssen die richtige Person für das Prototyping einsetzen, und sie müssen Hilfe haben. Ich sage dies aus Erfahrung - ich bin der Prototyp-Affe, der es liebt, intuitive Benutzeroberflächen zu erstellen, und ich habe mich mit jemandem zusammengetan, der versteht, was die Kunden wollen, und kann Dinge auf Papier oder mit Excel erklären.

Keiner von uns ist ein Genie, aber wir denken dasselbe - man kann fast sagen, dass wir Chemie haben und einen großen Einfluss darauf hatten, welche Dinge wie gebaut werden. Jetzt kann es sich nur ein mittelgroßes bis großes Team leisten, einen Prototypen und einen Nicht-Codierer zu haben, der ausschließlich Produkte entwickelt, aber es lohnt sich. Prototyping ist die günstigste Phase in der Softwareentwicklung, daher ist es nur sinnvoll, die Benutzeroberfläche und das scheinbare Verhalten richtig einzustellen. Ich habe Code Complete noch nicht gelesen, aber ich denke, dass in diesem Buch so etwas geschrieben steht.

Technische Daten sind nett zu haben, aber sie sind nie perfekt. Dazu gibt es einen Satz. Sie können nicht beweisen, dass die Spezifikation vollständig ist, und Sie können nicht beweisen, dass das Tool keine Fehler enthält oder dass es anhält :)

Trotz dieser Unzulänglichkeiten versenden Softwareunternehmen die ganze Zeit Software. Die Spezifikation wird niemals perfekt sein. Die Spezifikation ist auch UNNATURAL und veraltet. Eine Spezifikation für einen Prototyp ist wie eine Logarithmentabelle für ein einzelnes Diagramm - eine Spezifikation ist im Wesentlichen eine langweilige Broschüre, die gedruckt werden soll, während Sie stattdessen mit einem Werkzeug / Diagramm interagieren können. Inspiration finden Sie unter http://www.i-programmer.info/news/112-theory/3900-a-better-way-to-program.html .

Nun, spec ist gut, wenn Sie einen Vertrag haben müssen, um Ihren Arsch zu decken. Aber eine Spezifikation sollte immer noch nach einem Prototyp kommen, nicht vorher. Es ist Ihre Aufgabe, herauszufinden, wie Sie Prototypen billig machen können.

Job
quelle
+1 für die Spezifikation, die niemals perfekt ist, aber -1 für die Spezifikation, die unnatürlich und veraltet ist. Stellen Sie sich Anforderungen als eine Liste von Funktionen vor, die ein Kunde benötigt, und eine Spezifikation als eine Liste von Verhaltensweisen, die definieren, was der Kunde benötigt. Im Wesentlichen eine Art Vertrag, der definiert, wie das System funktioniert und nicht, was das System ist. Big-Up-Front-Design und -Spezifikationen sind problematisch, aber wie alle großen Probleme ist es einfacher, sie zu lösen, wenn sie nacheinander aufgeschlüsselt werden. Prototyping ist auch selten kostengünstig, wenn Sie keine Ahnung haben, WAS prototypiert werden soll. Hier bieten Spezifikationen einen Ausgangspunkt ...
S.Robins
... Spezifikationen sollten jedoch nicht unbedingt in Stein gemeißelt sein. Prototyping (im Wesentlichen Spitzenprobleme) sind am wertvollsten, wenn sie neue Informationen in die Spezifikation einspeisen und wenn die Spezifikation geändert werden darf, um den vom Prototypen gelernten Dingen Rechnung zu tragen. Ohne die Spezifikation riskieren Sie, die Dinge einfach nachzubilden, was nicht immer im besten Interesse des Kunden ist. Kunden erwarten von Ihnen, dass Sie ihre Bedürfnisse erfüllen, und Sie riskieren weniger Reibungspunkte, wenn Sie nachweisen können, dass Sie etwas vereinbart haben, auch wenn dies nur vorläufig geschieht.
S.Robins
@S. Robins, ein Arzt (Klient), sagt vielleicht etwas so Einfaches wie "Ich möchte einen Stammbaum mit dem entsprechenden geschätzten Krebsrisiko für jedes Familienmitglied sehen." Da es viele verschiedene Möglichkeiten gibt, diese Informationen zu präsentieren und sich Sorgen um große Familien zu machen, die mehrere Seiten umfassen, halte ich es für absurd, dies sofort als Spezifikation zu dokumentieren. Wir haben verstanden, was der Arzt gesagt hat, aber wir wollen präziser werden. Ein interaktiver Prototyp, der zufällige Zahlen und Namen anzeigt, die ein Dokument als Ja oder Nein bezeichnen kann, ist natürlicher als eine unvollständige 30-Seiten-Spezifikation, die versucht, diese zu beschreiben.
Job
1
Ich verstehe, woher Sie kommen, aber was Sie vorschlagen, ist normalerweise ein teurer Ansatz. Natürlich schlage ich nicht vor, dass der Prototyp ein vollständiges Produkt ist, aber alles, was Sie dort bauen, wo es Interaktivität gibt, benötigt Zeit, um sich zu entwickeln. Eine kostengünstigere Option ist es, an einem Whiteboard zu stehen, ein paar Ideen zu skizzieren und gezielte Fragen zu stellen, um Ihre Kriterien einzugrenzen. Ich befürworte auch nicht die Erstellung einer großen Spezifikation. Gliederungsdokumente oder sogar Testcodevorlagen, die iterativ und nach Bedarf erstellt werden, sind in der Regel einfacher und kostengünstiger als das erstmalige Erstellen von Prototypen.
Robins
3

Ich habe oft festgestellt , dass in einigen Situationen , die ich als Business Analyst handeln muß, genau zu entdecken , wie das Geschäft funktioniert derzeit, wie die Menschen denken , es funktioniert (oft sehr verschiedene Dinge), und wie sie sich gerne es an der Arbeit.

Ich habe Erfolg, indem ich mir immer klar war, welche Entscheidungen ich treffen muss, um die Software zu erstellen. Ich erkläre meine Überlegungen, schreibe Unterlagen über das, was ich entdeckt habe, erstelle Diagramme und verteile sie an alle.

Sie werden wahrscheinlich keinen guten Eindruck hinterlassen, wenn Sie sich weigern, etwas zu tun, bis die vollständigen Anforderungen übergeben wurden. Indem Sie jedoch selbst gute Qualitätsanforderungen erheben (ohne unbedingt darauf aufmerksam zu machen), erreichen Sie das gleiche Ziel wie bei Qualitätssoftware.

Und ja, wie andere Kommentatoren gesagt haben, erstellen Sie die Software immer unter der Annahme, dass sie sich ändern wird. Veränderung ist die einzige Konstante, auf die Sie sich verlassen können. Erstellen Sie Ihre Software immer so flexibel und modular, dass es nicht mühsam wird, sie zu aktualisieren, wenn plötzlich neue Anforderungen auftreten.

Will Sheppard
quelle
3

Wenn Sie als Softwareentwickler bei einem Startup arbeiten möchten, ist dies eine Fähigkeit, die Sie besitzen müssen.

Wenn Sie bei einem Beratungsunternehmen arbeiten möchten, sollten Sie dies unbedingt vermeiden. Dies liegt daran, dass Ihre Firma danach bezahlt wird, wie gut Sie die Spezifikation / Anforderungen umgesetzt haben und nicht danach, wie gut Sie das Problem des Kunden gelöst haben.

Wenn Sie in Ihrer Freizeit zum Spaß programmieren, ist dies Ihr Anruf. Wenn Sie sich nicht qualifiziert fühlen, den Anruf für Ihre Freizeitprojekte zu tätigen, probieren Sie ein Paar aus und sehen Sie, was funktioniert. Es ist auch nicht unbedingt eine Einheitsgröße erforderlich, einige Projekte erfordern den einen oder anderen Ansatz. Wenn Sie bei einem dieser Projekte das falsche auswählen, werden Sie es normalerweise ziemlich schnell herausfinden.

John
quelle
2

Ein bisschen von beidem. Sie müssen Ihre Kunden zufriedenstellen, was bedeutet, dass Sie wissen müssen, was sie wollen. Andererseits kommunizieren Kunden notorisch schlecht, was sie wirklich wollen.

Sie möchten also Szenarien vermeiden, in denen Sie nicht wissen, was Kunden wollen, aber Sie werden unvermeidlich in ein Szenario geraten, in dem die Anforderungen bestenfalls "matschig" und im schlimmsten Fall täuschend sind. Ein guter Programmierer in der realen Welt erfordert Anpassungsfähigkeit.

Telastyn
quelle
2

Es ist nicht möglich, ein Programm ohne Anforderungen zu schreiben. Sogar die "Hallo Welt" hat die Anforderung: Ausgabe zu produzieren. Also, ich denke, Sie fragen nach formalen Anforderungen, in Form eines großen Stapels von etwas UML-ähnlichem. Und in Bezug auf diese habe ich zwei Arten von Menschen getroffen:

1) Menschen, die formale Anforderungen benötigen. Sie müssen genau wissen, was zu tun ist und bestenfalls, wie es zu tun ist. Sie lieben die Sätze wie Die Prozedur A, die das Argument B verwendet, gibt C aus , und sie hassen diese: Das Programm sollte die Arbeit unserer Abteilung effektiver machen . Sie sind in der Regel Unternehmenstiere.

2) Menschen, die der Gegensatz zu 1 sind. Sie hassen es, zu erfahren, was zu tun ist und wie zu tun ist, und sie lieben es, zu erfahren, was erreicht werden sollte. Sie sprechen gerne mit dem Kunden, analysieren, was sie sagen, und entwickeln dann ihre eigene Lösung. Sie sind in der Regel Freiberufler und passen nicht gut zu Unternehmen.

Ich werde nicht sagen, welche davon besser ist. Beide haben ihre Vor- und Nachteile. Sie sind einfach ausreichend für die anderen Bedingungen.

Donau Seemann
quelle
0

Sie können nicht entwickeln operative Software , ohne die Voraussetzungen zu wissen; Aber Sie können sich ziemlich gut darin auskennen, zu entwickeln, was Ihre Erfahrung Ihnen sagt, dass die Anforderungen wahrscheinlich sindsein. Agile Entwicklung verwendet eine Kombination von 'intuitiven' Techniken, einschließlich der 80:20-Regel und der 'Entdeckung' von Anforderungen durch Prototyping. Mit anderen Worten, ein erfahrenes Entwicklungsteam errät am besten, was benötigt wird, und erstellt einen Prototyp der Software. Die 80:20 Regel besagt, dass sie zu 80% korrekt sind. Die Projektbeteiligten überprüfen dann den konkreten Prototyp. Ihr Feedback fängt an, die 20% -Lücke in unserem Verständnis der Anforderungen zu füllen. Tatsächlich geht es bei Agile also nicht darum, Software ohne jegliche Anforderungen zu schreiben, sondern darum, anhand Ihrer bisherigen Erfahrungen zu sagen: "Wollen Sie so etwas?" Damit können Sie in 80% der Fälle schneller als mit herkömmlichen Anforderungsprozessen feststellen, was wirklich benötigt wird.

Richard Seddon
quelle
Bei Agile geht es nicht um Intuition, sondern um Kommunikation. Das häufige Bereitstellen von funktionierender Software, um häufig Feedback zu erhalten, fördert die Kommunikation und bewertet die Bereitstellung der vom Kunden benötigten Dinge. Ja, Erfahrung kommt ins Spiel, aber Sie entwickeln mit größerer Wahrscheinlichkeit, was der Kunde benötigt, wenn Sie zuerst fragen, was der Kunde benötigt. Die so genannte 80:20-Regel gilt nur dann wirklich, wenn Sie mit der Geschäftsdomäne des Kunden vertraut sind, und selbst dann würde ich diese "Statistik" mit einem großen Löffel Salz nehmen.
S.Robins
-2

Wer hat gesagt, dass Agile Code schreibt, wenn keine Anforderungen vorliegen? Ich weiß, dass das Manifest von einigen so interpretiert wurde ... aber das macht es nicht richtig.

Trent
quelle
1
Hallo Trent, obwohl ich im Prinzip Ihrer Bemerkung zustimme (und ich bin es leid zu sehen, wie die Leute Agile als Ausrede benutzen, um den Entwicklungsprozess zu vermasseln und es als "agil" zu bezeichnen), spricht diese Antwort die OPs nicht wirklich an Frage, die sich nicht mit Agile befasst, sondern sich stattdessen mit der Frage befasst, ob das Schreiben von Software ohne Anforderungen eine Fähigkeit ist, die man entwickeln kann. Vielleicht wollten Sie dies als Kommentar zu der Antwort eines anderen hinzufügen?
S.Robins