it-swarm-eu.dev

Was denkst du über den Joel Test?

Der Joel Test ist ein bekannter Test, um festzustellen, wie gut Ihr Team ist. Was denkst du über die Punkte? Stimmen Sie mit keinem von ihnen überein? Gibt es etwas, das Sie hinzufügen würden?

52
Casebash

Jeff Atwood hat Die Bill of Rights des Programmierers .

Aus der Post:

  1. Jeder Programmierer muss zwei Monitore haben
  2. Jeder Programmierer muss einen schnellen PC haben
  3. Jeder Programmierer muss die Wahl zwischen Maus und Tastatur haben
  4. Jeder Programmierer muss einen bequemen Stuhl haben
  5. Jeder Programmierer muss über eine schnelle Internetverbindung verfügen
  6. Jeder Programmierer muss ruhige Arbeitsbedingungen haben

Dies scheint einige Elemente zu haben, die ich gerne auf Joels Liste sehen würde. Speziell im Bereich Hardware (Dual-Monitor, schneller PC, Maus/Tastatur, bequemer Stuhl, schnelle Verbindung).

Das einzige, was nicht erwähnt wird, ist ein bequemer und verstellbarer Schreibtisch .

Dies alles könnte durch Ändern hinzugefügt werden:

Aktuelle Nummer 9: Verwenden Sie die besten Tools, die Sie für Geld kaufen können?

zu

Verbessert # 9: Verwenden Sie die besten Werkzeuge und Ausrüstung Geld, das Sie kaufen können?

41
spong

Es ist interessant, dass Punkt 8 jetzt lautet:

8. Do programmers have quiet working conditions?

wenn es früher gelesen hat (so etwas wie)

8. Do programmers have their own office?

und der letzte Absatz beginnt noch:

Lassen Sie uns sie jetzt in separate Büros mit Wänden und Türen verlegen.

Ich war diesem Test immer misstrauisch, da an allen Orten, an denen ich gearbeitet habe - sowohl als Angestellter als auch als Besucher - die einzigen Personen mit eigenen Büros die Direktoren und leitenden Angestellten sind.

Das Schreiben von Software in der realen Welt ist normalerweise eine Teamaktivität. Sie müssen mit Ihren Teamkollegen sprechen, um Ideen auszutauschen usw. Dies ist selbst mit Instant Messaging-Systemen bei Personen in separaten Büros schwieriger. Es hilft sehr, Dinge zeichnen und Menschen Code und Diagramme zeigen zu können. Das soll nicht heißen, dass verteilte Teams nicht arbeiten können - sie können und tun es offensichtlich, das ist nur eine andere Reihe von Problemen.

Was ich sagen würde ist, dass jedes Team in seinem eigenen Büro mit 6-8 Personen sein muss (vorausgesetzt, das ist die Größe des Teams). Auf diese Weise können sie interagieren, ohne die anderen Teams zu stören (falls vorhanden), und ihre Arbeit fortsetzen, ohne vom Verkaufsteam oder den Besuchern gestört zu werden (an einem Ort, an dem ich gearbeitet habe, sind Sie durch die Eingangstür direkt in den Entwicklungsbereich gekommen).

Wenn Sie mit anderen Entwicklern zusammenarbeiten, aber jeder an separaten Projekten arbeitet, ist ein gemeinsames Büro kann nützlich sein - aber nur, wenn Sie strikt darauf achten, Besprechungen in den Besprechungsraum zu bringen und die Fristen anderer Personen usw. Zu beachten .

Die meisten anderen sind selbstverständliche Wahrheiten.

13
ChrisF

Ich mag es, aber wenn ich es zur Bewertung eines Unternehmens verwenden würde, würde ich nicht alle Artikel gleich wiegen. Keine Quellcodeverwaltung zu haben, ist ein viel größeres Problem, als nicht die besten Werkzeuge zu kaufen, die man für Geld kaufen kann.

10
JeffO

Der einzige Deal-Breaker für mich ist:

 8. Do programmers have quiet working conditions?

Interessant ist die Frage, die bei Stellenausschreibungen mit Stapelüberlauf am wahrscheinlichsten fehlschlägt.

Einige der Fragen sind schwer zu beantworten, insbesondere wenn mehr als ein Programmierer im Unternehmen ist:

 1. Do you use source control?
 2. Can you make a build in one step?
 4. Do you have a bug database?

Die meisten anderen interessieren mich nicht wirklich. Ich meine ehrlich:

12. Do you do hallway usability testing?

Es gibt einen, der Lügner entdeckt:

 5. Do you fix bugs before writing new code?

Ich muss sagen, dass es eine gute "Basislinie" ist, aber bei jedem Messwerkzeug gibt es andere Faktoren. Zum Beispiel hat keine einzige Firma, für die ich gearbeitet habe, Daily Builds durchgeführt (ich weiß, ich weiß), aber einige von ihnen waren sehr gut.

Ich persönlich habe ein paar andere Elemente, die ich einer Liste hinzufügen würde.

  1. Unterstützen Sie die Entwicklerausbildung, indem Sie an Konferenzen teilnehmen, Bücher kaufen oder ähnliches?
  2. Haben Sie einen einfachen, dokumentierten Prozess, um bei Bedarf neue Tools einzuführen, um Jobfunktionen auszuführen?
  3. Stellen Sie Entwicklern Geräte und eine Umgebung zur Verfügung, in der sie produktiv arbeiten können?.

Mehr als alles andere haben mich diese Dinge von früheren Arbeitgebern "angepisst", und nun sind es schnelle Fragen, die ich zu jeder Gelegenheit stelle.

6
Mitchel Sellers

Der Joel-Test testet nicht, wie gut ein Team ist. Es wird getestet, wie gut Ihr Team den Joel-Test einhält.

Hier ist ein besserer Test, wie gut Ihr Team ist. Ich nenne es den GrandmasterB-Test. Es hat eine Frage.

1) Ist die Software, die Sie schreiben, gut?

Für mich ist es unerheblich, ob Sie einen Flurtest durchführen oder nicht, welche Quellcodeverwaltung Sie haben oder wie Ihr Erstellungsprozess abläuft (falls vorhanden - nicht jede Sprache hat sie). Das wahre Maß eines Teams ist die Qualität der von ihm erstellten Software.

Grundsätzlich könnten Sie jeden einzelnen Schritt des Joel-Tests befolgen und trotzdem Mistcode und Produkte erhalten, die niemals ausgeliefert werden. Zum Beispiel macht die Quellcodeverwaltung einen nicht auf magische Weise zu einem besseren Codierer. Es erleichtert die Verwaltung von Code. Und die neueste Version von Visual Studio bedeutet nicht, dass Ihre Anwendung besser funktioniert, als wenn sie mit Visual Studio 2005 geschrieben wurde.

5
GrandmasterB

Obwohl ich denke, dass es im allgemeinen Sinne sinnvoll ist, fand ich die Liste ziemlich zentriert auf die spezifische Art von Software, die Fog Creek Software macht ( Shrinkwrap ). Das ist nicht wirklich überraschend, da er auch in einem anderen Beitrag darüber spricht, Fünf Welten. Und es gibt viele Entwicklungen außerhalb dieser Welt.

Es gibt einige Bedingungen, die wirklich wenig Sinn machen, wenn Sie zum Beispiel eingebettete Software für einen Satelliten oder einen Verkaufsautomaten entwickeln, wie tägliche Builds (3) oder Usability-Tests (12).

5
Khelben

Ich stimme den meisten Punkten von Joel zu. Ich bin mir bei "Flur-Usability-Tests" nicht so sicher. Usability-Tests, klar, aber tatsächlich jemanden vom Flur holen und ihn dazu bringen, Ihr Programm zu testen, obwohl es nicht ihre Aufgabe ist? Das scheint eine großartige Möglichkeit zu sein, Leute abzuhaken.

5
Tim Goodman