Wie viel Zeit widmen Sie die design Dokument(en) für Ihre software?

Question

Offensichtlich ist die Größe des Projekts, an dem Sie arbeiten werden ein sehr großer Faktor, wie lange Sie verbringen schreiben das design-Dokument/Spezifikation.Aber gehen Sie alles durch, suchte er sich jedes kleine detail?Oder nehmen Sie ein agiler Ansatz, und starten Sie das schreiben der software ziemlich früh auf und lösen die Probleme, wie Sie zu Ihnen kommen?

Ich habe immer gefunden, dass es gibt nur so weit können Sie gehen Sie mit der Gestaltung.Es wird unweigerlich einige Dinge, die fehlen, und an diesem Punkt, wie gut können Sie sich an die Gegebenheiten anzupassen, bedeutet, dass mehr als die Spezifikation selbst.

Bin ich die richtige Sicht auf das?Ist es tatsächlich eine Meinung, oder ist ein perfektes design spec stets die beste route zu gehen?

Answer 1

Es hängt ein wenig von Ihrer Zielgruppe ab, aber meine Erfahrung (mehr in der Entwicklung kleiner/mittlerer Maßstab als sehr groß) ist, dass detaillierte Entwurfsdokumente mühsam und langweilig sind, um zu schreiben, selten zu lesen und zu tendenziell veraltet nach dem enden Mal wird ein Projekt geliefert.

Dies bedeutet nicht, dass sie wertlos sind - wenn Sie etwas für jemanden liefern, muss es eine maßgebliche und vereinbarte Aussage darüber geben, was ausreichend detailliert geliefert wird, dass jeder darauf hinweisen kann, falls jemand mit dem Deal unzufrieden ist und sagt. " Das haben wir versprochen "und bewerten es gegen das, was geliefert wurde.

Wenn ich jedoch ein Unternehmen für den Bau eines Produkts einrichten würde, würde ich mich nicht so sehr um eine detaillierte Spezifikation kümmern. Ich würde dokumentieren wollen was Wir würden tun, aber ich würde nicht zu viel Tiefe in Bezug auf die Tiefe in Bezug auf wie - Dies ist der Teil, der sich am wahrscheinlichsten ändert und die Dokumente veraltet und nutzlos oder sogar ungenau genug ist, um tatsächlich obstruktiv zu sein. Ich würde es vorziehen, das "Wie" -Material im Code mit dem Dokumentationsformat der Sprache oder der IDE am besten zu dokumentieren, sodass der Code bei der Änderung des Codes die Dokumentation gleichzeitig einfacher aktualisiert wird. Es wird es nicht verhindern, dass es veraltet ist, aber es wird es etwas verringern.

Idealerweise möchten Sie ein Entwurfsdokument, das sich als Handbuch verdoppeln könnte, wenn Ihr Code abgeschlossen ist, aber ich kenne niemanden, der dies erfolgreich geschafft hat.

Answer 2

Es hängt definitiv auf die Größe und Struktur des Projekts.

Für Kundenprojekte, detaillierte Spezifikationen sind ein muss.Ich mag stark einbeziehen der Kunden während der design-Spezifikation.Dies hilft Spülen extra überlegungen, und Es gibt der Kunde ein besseres Verständnis von dem, was zu erwarten ist.Es ist in der Regel eine positive Veränderung in der Haltung (gegenüber der Zeit-und Preisgestaltung) nach der Entdeckung und die Spezifikationen sind komplette.Dies erlaubt uns auch, Meilensteine zu setzen - und Treffer - die ist günstig für den Kunden, und unsere Entwicklung team.

Für interne Projekte und Spaß Seite Projekte, die ich in der Regel erstellen Sie ein Flussdiagramm und feature-Liste, starten Sie dann hacken Sie es zusammen.In diesen Fällen, was ich viel wichtiger finde, als eine Funktion, Datenblatt, ist die eigentliche Benutzeroberfläche.Ich werde Drahtgitter die Seite auf dem Papier und nicht eine einfache Benutzeroberfläche erstellen (html/css).Das hilft mir denke, durch die Benutzer Erfahrung, die ich mehr Wert als spezifische Merkmale auf meine eigenen Projekte.Ich kann immer zurück gehen und Stück zusammen features später.

Answer 3

Hängt davon ab, was Sie mit Designdokumenten meinen.

Ich verbringe 1/3 bis 1/2 meiner Zeit damit, Designs für die Software aufzuschreiben, die ich schreibe, in einem Notizbuch, das die Dinge herausschreibt, Algorithmen, Beziehungen, Geschichten usw. herausfindet.

Ich mache das nicht alles im Voraus.

Ich habe kein wichtiges, signiertes und versiegeltes Dokument, aus dem ich arbeite. Ich habe in der Vergangenheit und ich habe nie Arbeit erledigt, weil ich immer darauf gewartet habe, dass jemand etwas abschreibt. Das war eher ein Problem mit der Bürokratie des Unternehmens, mit dem ich zusammen war, als mit dem Konzept, alles im Voraus zu entwerfen, aber ich bevorzuge immer noch den flüssigeren/agileren Ansatz, den ich jetzt habe.