it-swarm.com.de

Ist es im Allgemeinen besser, alle Funktionsteile zu erstellen oder die Benutzeroberfläche zuerst zum Laufen zu bringen - oder eine Mischung aus beiden?

Ist es im Allgemeinen besser, alle Funktionsteile zu erstellen oder die Benutzeroberfläche zuerst zum Laufen zu bringen - oder eine Mischung aus beiden?

Angenommen, Sie arbeiten an etwas Großem. Ist es allgemein anerkannt, dass alle Blobs zur Erfassung funktionaler Daten vor einer Benutzeroberfläche funktionieren, die gesamte Benutzeroberfläche einzeln ausgeführt wird oder etwas in der Mitte?

Wir alle wissen, dass wir die Arbeit in überschaubare Teile zerlegen müssen, aber die Frage ist letztendlich, ob die Benutzeroberfläche in überschaubaren Teilen enthalten ist, nehme ich an.

Betrachten Sie für den Fall des Beispiels eine GUI-Anwendung mit einem Stammfenster, aber über einem Dutzend Registerkarten in verschiedenen Docks, um verschiedene Datenkomponenten zu trennen. Hinter jeder einzelnen Registerkarte befindet sich aus Sicht der Funktionseinheiten ein relativ komplexer Satz beweglicher Teile.

Die Beispielanwendung in dieser speziellen Frage ist hier mit dem zugehörigen Blog und dem rsprüngliches kommerzielles Produkt .

47
RobotHumans

Viele Geschäftsanwender und Kunden haben die allgemeine Auffassung, dass es fast vollständig ist, wenn es vollständig aussieht. Wie Sie wahrscheinlich wissen, ist dies weit von der Wahrheit entfernt. Man kann es schön aussehen lassen, aber ohne Backend, und einige Benutzer denken, dass es 80% der Arbeit ausmacht, es schön aussehen zu lassen, nicht 20% ( oder die anderen 80% ).

Unzählige Entwickler können Horrorgeschichten darüber erzählen - indem sie mithilfe von Screenshots eines anderen Tools ein Modell der in Microsoft Word erstellten Seiten erstellen und der Client sagt: "Sie haben es also fast geschafft?"

Sie müssen es so einstellen, dass alle Teile fertig sind, wenn es fertig ist. Der Versuch, zuerst das gesamte Backend und dann das gesamte Frontend zu erstellen, führt dazu, dass der Endbenutzer denkt, dass Sie nichts tun, und fragt, warum Sie bezahlt werden, wenn nichts dafür angezeigt werden kann. Auf der anderen Seite, Front-End zuerst, und Sie werden feststellen, dass der Endbenutzer kleine Änderungen vornimmt und unsere ganze Zeit in Anspruch nimmt.

Der schlimmste Fall bei einem "einer zuerst und der andere" ist, wenn Sie zum anderen Teil gelangen, stellen Sie fest, dass er überhaupt nicht zum Design passt.

Bauen Sie also beide. Zeigen Sie den Fortschritt im Frontend an und lassen Sie das Backend mit dem arbeiten, was Sie erstellen. In vielen Fällen ist es eine gute Idee, inkrementelle Builds bereitzustellen und sicherzustellen, dass Sie das tun, was der Client will (dies wird zu Agile). Zu lange ohne 'sichtbare Fortschritte' zu bleiben, kann die Kundenbeziehung beeinträchtigen (dies gilt für beide Fälle von 'alles sieht früh erledigt aus' und 'nichts wird getan bis zum Ende “- es ist für den Kunden schwierig, das zu schreibende Framework oder die Komponententests oder die Datenbereinigung als Fortschritt zu sehen.

Joel schrieb darüber in The Iceberg Secret, Revealed :

Wichtige Folgerung Zwei. Wenn Sie einem Nicht-Programmierer einen Bildschirm mit einer 100% schönen Benutzeroberfläche zeigen, denken sie, dass das Programm fast fertig ist.

Leute, die keine Programmierer sind, schauen nur auf den Bildschirm und sehen einige Pixel. Und wenn die Pixel so aussehen, als ob sie ein Programm bilden, das etwas tut, denken sie: "Oh Gott, wie viel schwieriger könnte es sein, es tatsächlich zum Laufen zu bringen?"

Das große Risiko besteht darin, dass, wenn Sie zuerst die Benutzeroberfläche verspotten, vermutlich damit Sie einige Gespräche mit dem Kunden führen können, jeder denkt, dass Sie fast fertig sind. Und wenn Sie dann das nächste Jahr sozusagen "unter der Decke" arbeiten, wird niemand wirklich sehen, was Sie tun, und sie werden denken, dass es nichts ist.

Dies wird im Blog-Beitrag noch einmal wiederholt Lassen Sie die Demo nicht fertig aussehen , der diese hilfreiche Grafik enthält:

How done it is to what it looks like

Beachten Sie hier, dass die beiden Optionen im Allgemeinen das "Erledigen der Benutzeroberfläche" (und dann die Erwartung, dass Sie bald fertig sind) und "Erledigen des Backends" (und dann ist der Kunde besorgt, dass Sie die Frist verpassen) widerspiegeln.

Wie etwas "erledigt" aussieht, sollte mit dem übereinstimmen, was "erledigt" ist.

Jeder Softwareentwickler hat dies in seiner Karriere schon oft erlebt. Desktop-Publishing-Tools bereiten Tech-Autoren jedoch die gleichen Kopfschmerzen. Wenn Sie jemandem einen groben Entwurf zeigen, der perfekt geschrieben und formatiert ist, wird er als mehr erledigt angesehen, als Sie möchten. Wir brauchen eine Übereinstimmung zwischen dem, wo wir sind und dem, wo andere uns wahrnehmen.

In diesem Artikel wird auch ein wichtiger Punkt zum Typ des Feedbacks angesprochen, das Sie mit unterschiedlichen Dönungsstufen der Benutzeroberfläche erhalten. Wenn Sie etwas haben, das vollständig aussieht, erhalten Sie eher Feedback zu "Könnten Sie die Schriftart ändern" als zu "Dieses Layout funktioniert nicht - es gibt zu viele Registerkarten."


Für diejenigen, die in der Java Swing-Welt) damit kämpfen, gibt es ein Look and Feel namens Serviette , das es so macht, dass die Benutzeroberfläche sieht nicht vollständig aus (auch wenn es ist).

(

Der Schlüssel hier ist, es so zu gestalten, dass es nicht fertig aussieht . Das vollständige Erscheinungsbild der Benutzeroberfläche ist für viele Geschäftsbenutzer ein Signal dafür, dass die Anwendung vollständig ist (auch wenn es sich nur um wenige statische Seiten ohne Logik oder etwas handelt, das in einem Interface Builder integriert ist).


Weiterführende Literatur (und Links aus dem Artikel):

86
user40980

Es kommt darauf an: Sie benötigen eine enge Rückkopplungsschleife um Ihre wichtigste Funktionalität

Wenn der Kern Ihrer Arbeit, der riskante und beängstigende Teil, eine interne Engine ist, dann bringen Sie den Kernteil beispielsweise in der Konsole oder durch Unit-Tests zum Laufen. Beispielsweise benötigt ein Protokollparser keine Benutzeroberfläche, um zu wissen, ob er ordnungsgemäß funktioniert.

Wenn Ihre coole Sache Interaktivität beinhaltet - Interaktivität, die Sie ständig beheben, wegwerfen und neu entdecken müssen -, ist ein UI-First-Ansatz von entscheidender Bedeutung. Zum Beispiel möchte ich eine App erstellen, mit der Benutzer mit einer Datenvisualisierung interagieren können. Das Wichtigste, was ich herausfinden muss, ist, ob die Visualisierung sinnvoll ist. Daher werde ich wahrscheinlich ein halbes Dutzend Ansätze wegwerfen, bevor ich mich für einen entscheide. Ich werde das alles tun, bevor ich einen einzelnen Unit-Test schreibe.

Dazwischen gibt es eine unscharfe Grauzone, in der Sie die beste Kombination für die beste Interaktion und Validierung Ihres Codes festlegen können (automatisierte Tests? Benutzeroberfläche zum Experimentieren?). Ich persönlich habe beide Extreme und alles dazwischen getan, und die Entscheidung, wo ich mich in diesem Spektrum befinden soll, ist eines der schwierigsten Dinge, die ich entscheiden muss, und hängt zu 100% von der Art der Dinge ab, die ich baue.

27
Doug T.

In einer agilen Umgebung hören Sie möglicherweise Diskussionen über "wandelnde Skelette" oder "dünne vertikale Scheiben". Die Idee ist, dass Sie, da funktionierende Software für den Benutzer wichtig ist, die Software Stück für Stück auf funktionierende Weise ausbauen.

In der von Ihnen erwähnten Beispielanwendung würden Sie mit dem Fenster und möglicherweise einer Registerkarte beginnen und dafür sorgen, dass alles in gewisser Weise von vorne nach hinten funktioniert. Im Laufe der Zeit fügten Sie dann von Fall zu Fall Funktionen und damit Registerkarten hinzu, sodass jede Funktion beim Erstellen funktioniert. Dies ist Teil dessen, was Ihnen häufige Kundendemonstrationen bieten: die Möglichkeit, etwas Neues zu zeigen und sofort Feedback dazu zu erhalten.

Kurz gesagt, ja, UI-Arbeit ist ein wesentlicher Bestandteil einer funktionalen Arbeitseinheit, wenn Sie eine UI haben.

Beginnen Sie mit etwas Kleinem, das funktioniert, und wiederholen Sie die Funktionalität, um eine vollständige Software bereitzustellen.

8
Kate Bertelsen

Ich würde empfehlen, eine Mischung aus Funktionalität und Benutzeroberfläche zu erstellen (und so schnell wie möglich Feedback oder Testerfahrung zu erhalten).

Übrigens, ist es nicht die Art und Weise, wie die meisten großen GUI-Programme entwickelt werden? Schauen Sie sich zum Beispiel den Browser Firefox an: Von einer Version zur nächsten haben sich sowohl die Funktionalität als auch die Benutzeroberfläche weiterentwickelt.

Was ich dazu neige, ist beginne mit einer beschissenen Benutzeroberfläche: etwas, das nur die variablen Daten auf dem Bildschirm ausgibt. Keine Schriftarten, keine Ausrichtung, lange Zeit nichts Grafisches. Nur "Willkommen Benutzer x" und Schaltflächen namens "Bild laden" usw. Was gut daran ist, ist, dass Sie herausfinden, ob etwas im Backend defekt ist.

Im Verlauf der Entwicklung müssen möglicherweise mehr oder weniger Dinge erledigt werden. Aber irgendwann werden Sie entscheiden, dass das Backend fast fertig ist. Jetzt haben Sie eine Benutzeroberfläche, die alle erforderlichen Anhänge enthält, und Sie können viel Zeit damit verbringen, alle grafischen Aufgaben zu erledigen.

Achtung, es ist nicht kinderleicht. Sie benötigen ein wenig Voraussicht, um bestimmte Probleme zu erkennen. Beispielsweise müssen Sie möglicherweise UI-Komponenten untersuchen, um die Daten auf sinnvolle Weise anzuzeigen.

2
Carlos

In großen (PHP-webbasierten) Anwendungen, an denen ich arbeite, versuche ich, zuerst die Klassen und Methoden einzurichten, die Dummy-Werte zurückgeben. Hiermit wird ein Pseudovertrag erstellt, für den die anderen Entwickler die Benutzeroberfläche implementieren können.

Ein sekundärer Vorteil dieser Methode besteht darin, dass wir den Vertrag/die Schnittstelle verbessern können, wenn Änderungen der Benutzeroberflächenanforderungen (und sie ändern sich immer), noch bevor der gesamte Code geschrieben und geliefert wird.

2
dotancohen

Wenn Sie ein gutes Meilenstein- und Problemverfolgungssystem verwenden, können Sie einige dieser Probleme vermeiden, da das Management auf einen Blick erkennen kann, wie produktiv Sie sind. Sie werden sehen können, dass Sie das Backend zu 80% fertiggestellt haben und dass die Benutzeroberfläche der nächste Meilenstein ist. Sie können sehen, dass Sie über eine Reihe von UI- und Backend-Aufgaben verfügen, die für einen bestimmten Funktionsmeilenstein abgeschlossen werden müssen. Aber alles beginnt mit den Anforderungen des Projekts, und die Antwort von Doug T wirft einige gute Punkte zu diesem Aspekt des Entwurfs eines Systems auf.

0
Derek

Denken Sie aus Sicht Ihrer Benutzer/Kunden. Ein Softwaresystem ist eine Sammlung von Funktionen, die diesen Benutzern/Clients einen gewissen Wert verleihen. Natürlich hat jede dieser Funktionen eine Benutzeroberfläche, ein Backend und einige andere Dinge.

Erstellen Sie Ihr System immer Feature für Feature und versuchen Sie, es in sehr kleine Features zu unterteilen. Auf diese Weise sind Sie immer in der Nähe, um Ihren Kunden etwas mehr zu bieten. Denken Sie daran, dass es bei der Softwareentwicklung nicht darum geht, die Version 1.0 zu erstellen, sondern um die Version 1.0.1 auf 1.0.2 und so weiter.

0
AlfredoCasado

Es hängt davon ab, ob. Wie genau sind Ihre Anforderungen definiert? Wie viel von dem System ist der Benutzeroberfläche ausgesetzt?

Nach meiner Erfahrung wissen die meisten Kunden nicht, was sie wollen, bis sie etwas vor sich sehen. Daher stelle ich normalerweise einige Drahtmodelle mit wichtigen Aspekten der Benutzeroberfläche bereit oder liefere den Großteil der Benutzeroberfläche (funktioniert nicht). Dies ermöglicht es dem Kunden, seine Meinung zu Features/Funktionen ohne allzu große Auswirkungen zu ändern, da sich das Datenbankdesign und die Codestruktur noch in der Entwurfsphase befinden - es ist einfach, das Design zu ändern. Es ist um Größenordnungen einfacher/schneller, das Design früher im Projekt als später zu ändern.

Agile Zustände sollten Sie auch zuerst an den schwierigsten und wichtigsten Gegenständen arbeiten. Schnell ausfallen. Sobald der Kunde die Benutzeroberfläche gesehen hat, konzentriere ich mich darauf, kleine Komponenten zu erstellen, die voll funktionsfähig sind und die wichtigsten und am schwierigsten zu implementierenden Komponenten sind, damit Sie so schnell wie möglich wissen, ob Sie auf Hürden stoßen.

Dann haben Sie Ihre Sprints und haben eine ständige Kommunikation mit dem Kunden, der irgendwann sowohl die Benutzeroberfläche als auch die funktionalen Aspekte entwickelt.

0
Daveo