Wie aktuell ist der Joel-Test? [geschlossen]

16

Ich möchte meine Partner davon überzeugen, dass wir eine Spezifikation haben sollten und dass Fehler behoben werden sollten, bevor neuer Code geschrieben wird. Soll ich mich auf den Joel-Test beziehen ? Denken Sie, dass der Joel-Test auf dem neuesten Stand ist? Ich denke, dass das Fehlen einer Spezifikation ein schlechtes Projektmanagement ist. Stimmen Sie dem Joel-Test zu? Könnten Sie etwas hinzufügen? Es wird zum Beispiel nicht Open Source erwähnt.

issue-tracking specifications joel-test Niklas
quelle
2
Der Joel-Test richtet sich an die Software-Entwicklung und die Einstellungsprozesse von Entwicklern. Wie hängt die Art und Weise, in der Sie Ihre Software lizenzieren oder ob Sie Ihre Quelle veröffentlichen oder nicht, damit zusammen?
Marjan Venema
Danke Marjan für die Frage. Ich dachte, dass Open Source ein Trend ist, seit der Joel-Test konzipiert wurde. Wenn jemand Open Source sehr negativ bewertet, würde ich wahrscheinlich gerne wissen, wie ein Team Open Source ablehnt, wenn dies der Fall ist. Ich bin damit einverstanden, dass Urheberrechtsprobleme den Rahmen sprengen könnten, aber Programmierer können nicht mit einem Team zusammenarbeiten, das Open Source für eine Frage der Quelltextanzeige hält, und Frage 13 könnte lauten: "Haben Sie ein Backup-System?" und 14 "Haben Sie eine stärkere Sicherheit als MD5?" wo Antworten ja sein sollten.
Niklas
1
Ok, das macht Sinn. Open-Source-Bemühungen sollten nicht nur "verbraucht", sondern auch dazu beigetragen werden, wenn auch nicht unbedingt mit Code (denken Sie an monetäre Unterstützung). Backup-Systeme sind wichtig, aber nicht auf die Entwicklung beschränkt. Daher würde ich sie nicht zum Joel-Test hinzufügen. Aber wenn ich mit einem Unternehmen sprechen würde, das nichts gegen Backups unternimmt, würde ich zur Tür rennen. Sicherheit würde ich auch nicht hinzufügen. Bei der von der Software entwickelten Sicherheit handelt es sich möglicherweise nicht um ein Problem (Inhouse-Apps), sodass keine Ja / Nein-Antwort möglich ist. Außerdem muss die Sicherheit nicht entwicklungsspezifisch sein.
Marjan Venema
Vielen Dank für das Teilen des Wissens mit mir. Backup ist zwar wichtig, aber nicht entwicklungsspezifisch.
Niklas
Viele gute Fragen erzeugen einen gewissen Grad an Meinung, der auf Expertenerfahrung basiert. Die Antworten auf diese Frage basieren jedoch in der Regel fast ausschließlich auf Meinungen und nicht auf Fakten, Referenzen oder spezifischem Fachwissen.
gnat

Antworten:

22

Ich denke, der Joel-Test ist auf dem neuesten Stand - er ist genauso aktuell wie die meisten anderen Software-Programme, die "zeitlos" sind.

Produktentwicklung (einschließlich Softwareentwicklung) ohne Spezifikation ist einfach Wahnsinn.

Woher weißt du, wohin du willst?

Es gibt nur einen Punkt, auf den ich beim Schreiben einer Spezifikation eingehen werde (ich denke nicht, dass Joels Spezifikationen sehr gut sind ... besser als nichts, aber nicht so gut wie es sein könnte). Dieser Punkt ist:

Sagen Sie beim Schreiben einer Spezifikation nur, was das Produkt tun muss, nicht, wie es getan werden soll.

Dies bedeutet, dass Sie in einer Spezifikation keine Implementierungsdetails festlegen. Das ist eine Designaktivität, die Sie der Erfahrung und Kreativität der Designer überlassen.

[Es gibt nur eine Ausnahme von dieser Regel: Manchmal ist ein bestimmtes Implementierungsdetail oder eine bestimmte Methode vorgeschrieben oder erforderlich. In diesem Fall ist dies erforderlich. Wenn die Software beispielsweise in PHP geschrieben sein muss und dies nicht verhandelbar ist, erfolgt dies die spezifikation. Es sollte nur sehr wenige Beispiele dafür geben.]

Ich könnte hinzufügen: Fehlendes Bug Tracking ist ein Akt des gleichen Wahnsinns. Es ist einfach die unprofessionellste und dümmste Art zu operieren und wird zu großen Schmerzen und Leiden führen.

schnell_nun
quelle
Vielen Dank für die sehr schnelle und wertvolle Antwort. Ein weiterer Wahnsinn, der mich erreichte, war die Aussage, dass alles die gleiche Priorität haben sollte. Es fühlt sich an, als würde das Gegenteil dieser verrückten Regeln zum Erfolg führen.
Niklas
4
"Alles hat die gleiche Priorität" - auch bekannt als "Alles ist die Nummer 1". Das ist ehrlich gesagt völliger Schwachsinn. Alles sollte in Bezug auf HARM TO THE BUSINESS brutal priorisiert werden. Dann arbeiten Sie an der Nummer 1. Wenn Sie aus irgendeinem Grund auf der Nr. 1 angehalten werden, arbeiten Sie auf der Nr. 2. Und so weiter. Wenn Sie einige Leute haben, die aus irgendeinem Grund nicht an der Nr. 1 arbeiten können und am Ende an der Nr. 9 arbeiten - das ist in Ordnung, vorausgesetzt, es gibt einen guten Grund. ("Ich fühlte mich wie es und sein cooooooool" ist kein guter Grund). Es ist auch in Ordnung, Prioritäten neu zu setzen. Häufiger als wöchentlich zu tun ist auch Wahnsinn.
quick_now
Danke für die Weisheit. Ich stimme voll und ganz zu, dass alles priorisiert werden sollte. Mein Partner erklärte auch, dass wir keine Probleme und keinen Issue Tracker haben sollten. Ich halte es jedoch für richtig, Probleme zu dokumentieren, und selbst der Marktführer hat einen Issue Tracker. Wiederum wird das Gegenteil der Regel funktionieren ...
Niklas
@ 909Niklas Sie sollten wahrscheinlich versuchen, einen anderen Partner zu finden, um Ihr zukünftiges Leben angenehmer zu gestalten ...
Marcel
+1 nur für: Wenn Sie eine Spezifikation schreiben, sagen Sie nur, was das Produkt tun muss, nicht, wie es getan werden soll.
Marcel
4

Ich werde hier den Anwalt des Teufels spielen und vorschlagen, dass der Joel-Test nicht auf dem neuesten Stand ist. Es ist zu allgemein. Da die Technologie ausgereift ist, sollten die Fragen spezifischer sein als zu dem Zeitpunkt, als er den Test schrieb.

Spezifikationsdokumente, zumindest umfangreiche Spezifikationsdokumente, sind nicht mehr erforderlich, da wir Anwenderberichte und agile Entwicklungsprozesse haben. Diese Frage sollte in "Ist der Dokumentationsgrad für die zu entwickelnden Lösungen geeignet?" Geändert werden. Kleinere, engere User Stories, die alle zwei Wochen veröffentlicht werden, sind in den meisten Fällen viel nützlicher als ein großes Vorabdokument, in dem das Produkt ausführlich beschrieben wird. Wenn Sie jedoch den nächsten Mars Rover bauen, benötigen Sie möglicherweise ein detailliertes Vorab-Designdokument. Wenn Sie gefragt werden, ob ein Unternehmen über Designspezifikationen verfügt, würde es mich nicht überraschen, die Antwort "Nicht wirklich, wir verwenden stattdessen agile Prozesse und User Stories" zu hören.

Zweitens sollte sich die Frage nach "Daily Builds" in eine Frage nach kontinuierlicher Integration ändern. Sofern Sie keine Software erstellen, deren Erstellung Stunden in Anspruch nimmt (was 99,99% der Unternehmen nicht tun werden), stellt sich die Frage, ob das Unternehmen die kontinuierliche Integration verwendet.

Die meisten Joel-Tests sind überhaupt nicht datiert. Es ist immer noch eine gute Möglichkeit, sich einen Überblick über das Arbeitsumfeld zu verschaffen.

Stephen
quelle