it-swarm.com.de

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

Ich finde, dass einige Softwareentwickler dies sehr gut können 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 zu erfinden, wenn ich gehe. Früher dachte ich, dies sei problematisch, aber ich habe angefangen, eine Verschiebung zu spüren, und ich frage mich, ob ich meinen Denk- (und Programmier-) Prozess anpassen muss, wenn mir nur sehr wenig Anweisungen gegeben werden. Sollte ich anfangen, diese Fähigkeit als Fertigkeit zu erwerben, oder mich an die Idee halten, dass das Sammeln und die Geschäftsregeln der Anforderungen oberste Priorität haben?

44
user9483

Die Fähigkeit ist nicht, Software ohne Anforderungen zu schreiben. Es geht stattdessen darum, Anforderungen vom Projektbesitzer zu ermitteln, unabhängig davon, 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 notieren. Das Risiko besteht natürlich darin, dass Sie wichtige Informationen verpassen, die Ihre Systemarchitektur unbrauchbar machen, wenn Sie nicht die richtigen Gespräche mit Ihrem Kunden geführt haben. Es ist jedoch nicht ungewöhnlich, ein Produkt zu definieren und sogar zu erhalten Ein Großteil der Entwicklung wurde aus dem Weg geräumt, während die wichtigsten Entscheidungen zur Systemarchitektur bis zum letztmöglichen Moment verschoben wurden. Dies ist ein schlanker Entwicklungsansatz, mit dem sichergestellt werden soll, dass Sie sich nicht zu früh in Ihrer Produktentwicklung auf eine möglicherweise inkompatible Architektur festlegen, bis Sie fundiertere Informationen haben. In den Situationen, die das OP in seiner Frage beschrieben hat, wäre dieser schlanke Ansatz meiner Meinung nach sehr wichtig, um später größere Nacharbeiten und Kosteneinsparungen zu vermeiden. Dann haben Sie endlich gelernt, was Ihr Kunde wirklich brauchte.

Ja, manchmal müssen Sie ein wenig auf die Kristallkugel blicken, um auf den Punkt zu kommen, was der Kunde wirklich verlangt. Hier müssen Prototyping-Spikes und das langsame - und manchmal schmerzhafte - inkrementelle Herausziehen von Anforderungen erforderlich sein dass Sie wirklich gute Fähigkeiten in Bezug auf Kundenbeziehungen entwickeln und auch die Geduld, zu erkennen, dass der Kunde bei jeder komplexen Softwareidee am Anfang oft nicht viel mehr als Sie darüber weiß, was die Software tatsächlich tun muss. In den meisten Fällen ruft der Kunde Sie frühzeitig an, um sich auf Ihr Fachwissen zu verlassen, um seine Anforderungen zu definieren, da der Kunde nicht immer über das erforderliche Fachwissen oder Wissen über den Softwareentwicklungsprozess verfügt.

79
S.Robins

Das ist sehr vieldeutig ...

Zwei Dinge kann ich sagen:

  1. Es gibt viele sehr begabte Techniker, deren Karriere unterbrochen wird, weil sie auf perfekte Anforderungen warten. Oder sie spielen das "Entschuldigung, 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, sie 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, wie Software-Leute die quantitativen Marketinganforderungen der besten Markenmanager des Landes vorwegnahmen. Sie waren nicht die besten, wenn es darum ging, alle Lösungen zu programmieren, aber sie waren Helden, weil sie die Brücke überqueren konnten.

Im Leben geht es jedoch nicht um Schwarz und Weiß. Wenn Sie eine schmale Box um sich ziehen, beschränken Sie sich. Auf der anderen Seite ist eine Organisation, die das ablehnt, was für die Erstellung von Technologie erforderlich ist, ebenfalls begrenzt. Sie müssen sehen, wo in dem Grau Sie bevorzugen.

36
MathAttack

Anforderungen sind die Schritte auf der Reise, eine Vision ist die Richtung

Für viele Anwendungen ist eine sehr detaillierte technische Spezifikation einfach zu viel im Voraus, da eine kurze Diskussion das sorgfältig gesetzte Dokument unbrauchbar machen könnte. Beginnen Sie stattdessen mit einer Vision. Wenn jeder das Gesamtbild versteht, können die Anforderungen auf dem Weg durch Diskussionen erfüllt werden.

Als Entwickler müssen Sie lernen, diese Diskussionen zu verwenden, um nach Anforderungen zu suchen . Dies bedeutet, den Kunden Leitfragen 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 verfolgen, 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, falls Sie eine Klärung benötigen.

Lernen Sie also, gegen die Vision zu programmieren, aber seien Sie bereit, diese Anforderungen zu erfüllen, wenn es soweit ist.

12
Gary Rowe

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

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

Spezifikationen sind schön zu haben, aber sie sind nie perfekt. Es gibt einen Satz darüber. Sie können nicht beweisen, dass die Spezifikation vollständig ist und Sie können nicht beweisen, dass das Tool keine Fehler aufweist oder dass es anhält :)

Trotz dieser Mängel liefern Softwareunternehmen immer wieder Software. Die Spezifikation wird niemals perfekt sein. Die Spezifikation ist auch UNNATURAL und veraltet. Eine Spezifikation für einen Prototyp entspricht einer 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. Schauen Sie sich http://www.i-programmer.info/news/112-theory/3900-a-better-way-to-program.html an, um sich inspirieren zu lassen.

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

10
Job

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

Wenn Sie in einem Beratungsunternehmen arbeiten möchten, sollten Sie dies unbedingt vermeiden. Dies liegt daran, dass Ihr Unternehmen danach bezahlt wird, wie gut Sie die Spezifikationen/Anforderungen implementieren und nicht danach, wie gut Sie das Problem des Kunden gelöst haben.

Wenn Sie in Ihrer Freizeit zum Spaß programmieren, dann ist es Ihr Anruf. Wenn Sie sich nicht qualifiziert fühlen, um Ihre Freizeitprojekte anzurufen, versuchen Sie es mit jedem Paar und sehen Sie, was funktioniert. Es ist auch keine 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.

3
John

Ich habe oft festgestellt, dass ich in einigen Situationen als Business Analyst agieren muss, um genau herauszufinden, wie das Geschäft derzeit funktioniert, wie Menschen denken es funktioniert (oft sehr unterschiedliche Dinge) und wie sie - wie es funktioniert.

Ich habe Erfolg gefunden, indem ich mir immer klar darüber war, welche Entscheidungen ich treffen muss, um die Software zu erstellen. Ich erkläre meine Argumentation, schreibe Dokumentation über das, was ich entdeckt habe, mache Grafiken und verteile sie an alle usw.

Sie werden wahrscheinlich keinen sehr guten Eindruck hinterlassen, wenn Sie sich weigern, Arbeiten auszuführen, bis die vollständigen Anforderungen vorliegen. Indem Sie jedoch selbst gute Qualitätsanforderungen erfassen (ohne unbedingt darauf aufmerksam zu machen), erreichen Sie das gleiche Ziel von 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 flexibel und modular genug, damit es nicht schmerzhaft ist, sie zu aktualisieren, wenn plötzlich neue Anforderungen auftreten.

3
Will Sheppard

Ein bisschen von beidem. Sie müssen Ihre Kunden zufrieden stellen, was bedeutet, dass Sie wissen müssen, was sie wollen. Auf der anderen Seite können Kunden notorisch schlecht kommunizieren, was sie wirklich wollen.

Sie möchten also Szenarien vermeiden, in denen Sie nicht wissen, was Kunden wollen, aber Sie werden unweigerlich auf ein Szenario stoßen, in dem die Anforderungen bestenfalls "matschig" und im schlimmsten Fall irreführend sind. Ein guter Programmierer in der realen Welt erfordert Anpassungsfähigkeit.

2
Telastyn

Es ist nicht möglich, ein Programm ohne Anforderungen zu schreiben. Sogar die 'Hallo Welt' hat die Anforderung: Ausgabe zu produzieren. 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) Personen, die formale Anforderungen benötigen. Ihnen muss genau gesagt werden, 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 das Gegenteil von 1 sind. Sie hassen es, wenn ihnen gesagt wird, was sie tun sollen und wie sie es tun sollen. Sie lieben es, wenn ihnen gesagt wird, was erreicht werden soll. Sie sprechen gerne mit dem Kunden, analysieren, was sie sagen, und entwickeln dann ihre eigene Lösung. Sie sind in der Regel freiberuflich tätig 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.

2
Danubian Sailor

Sie können NICHT betriebsbereite Software entwickeln, ohne die Anforderungen zu kennen; Aber Sie können sehr gut entwickeln, was Ihre Erfahrung Ihnen sagt, dass die Anforderungen wahrscheinlich sind. Die 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 schätzt 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 beginnt die 20% ige Lücke in unserem Verständnis der Anforderungen zu schließen. In der Tat geht es bei Agile also nicht darum, Software ohne Anforderungen zu schreiben, sondern darum, anhand Ihrer bisherigen Erfahrungen zu sagen: "Wollen Sie so etwas?" In 80% der Fälle können Sie schneller einen Sprung nach vorne machen und bestätigen, was wirklich benötigt wird, als durch herkömmliche Anforderungsprozesse zu stapfen.

0
Richard Seddon