Was denkst du über den Joel -Test? [abgeschlossen

softwareengineering.stackexchange https://softwareengineering.stackexchange.com/questions/2776

  •  16-10-2019
  •  | 
  •  

Frage

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

War es hilfreich?

Lösung

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 hat die Wahl zwischen Maus und Tastatur
  4. Jeder Programmierer muss einen komfortablen Stuhl haben
  5. Jeder Programmierer muss eine schnelle Internetverbindung haben
  6. Jeder Programmierer muss ruhige Arbeitsbedingungen haben

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

Das einzige, was nicht erwähnt wird, ist eine bequeme und verstellbare Sache zu haben Schreibtisch.

Dies könnte alles hinzugefügt werden, indem Sie sich ändern:

Current #9: Verwenden Sie die besten Werkzeuge, die Geld kaufen können?

zu

Verbessert #9: Verwenden Sie das Beste Werkzeug und Ausrüstung Geld kann kaufen?

Andere Tipps

Es ist interessant, dass Punkt 8 jetzt lautet:

8. Do programmers have quiet working conditions?

Wenn es früher gelesen (so etwas wie)

8. Do programmers have their own office?

Und der letzte Absatz beginnt immer noch:

Bewegen wir sie nun in getrennte Büros mit Wänden und Türen.

Ich war diesem Test immer misstrauisch wie an allen Orten, an denen ich gearbeitet habe - sowohl als Mitarbeiter als auch als Besucher - sind die einzigen Menschen mit eigenen Büros die Direktoren und Führungskräfte.

Das Schreiben von Software in der realen Welt ist normalerweise eine Teamaktivität. Sie müssen mit Ihren Teamkollegen sprechen, um Ideen zu verbringen. In der Lage zu sein, Dinge auszuziehen und Menschen Code und Diagramme zu zeigen, hilft sehr. Das heißt nicht, dass verteilte Teams nicht funktionieren 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 von 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 Arbeiten weitermachen, ohne vom Verkaufsteam oder vom Verkauf von Besuchern gestört zu werden (an einem Ort, an dem ich gearbeitet habe, kamen Sie direkt in den Entwicklungsbereich durch die Haustür).

Wenn Sie mit anderen Entwicklern zusammenarbeiten, aber jeder an separaten Projekten arbeitet, dann ein gemeinsames Büro kann Seien Sie nützlich - aber nur, wenn Sie sich streng darauf befassen, Treffen in den Besprechungsraum zu nehmen und die Fristen anderer Menschen usw. zu respektieren.

Die meisten anderen sind selbstverständliche Wahrheiten.

Ich mag es, aber wenn ich es verwenden würde, um ein Unternehmen zu bewerten, würde ich nicht alle Gegenstände wiegen. Es ist ein viel größeres Problem, keine Quellenkontrolle zu haben und nicht die besten Werkzeuge zu kaufen, die Geld kaufen können.

Der einzige Deal-Breaker für mich ist:

 8. Do programmers have quiet working conditions?

Interessant ist die Frage, die am wahrscheinlichsten durch Stack Overflow -Stellenausschreibungen gescheitert sein wird.

Einige der Fragen sind schwer zu scheitern, insbesondere wenn es mehr als einen Programmierer im Unternehmen gibt:

 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 gesagt:

12. Do you do hallway usability testing?

Es gibt einen, der Lügner erfasst:

 5. Do you fix bugs before writing new code?

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

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

  1. Unterstützen Sie die Entwicklerausbildung, indem Sie an Konferenzen teilnehmen, Bücher oder so etwas von dieser Art kaufen?
  2. Haben Sie einen einfachen, dokumentierten Prozess, um bei Bedarf neue Tools zu übernehmen, um Jobfunktionen zu erfüllen?
  3. Stellen Sie Entwicklern Geräte und eine Umgebung zur Verfügung, die es ihnen ermöglicht, produktiv zu sein?

Mehr als alles andere, was dies sind, haben mir Artikel von früheren Arbeitgebern "verärgert", und nun, dass sie jetzt schnelle Track -Fragen sind, die ich zu jeder Gelegenheit stelle.

Ich stimme den meisten Punkten von Joel zu. Ich bin mir nicht so sicher über "Usability -Tests der Flur". Sicherheitsprüfung, sicher, aber tatsächlich jemanden aus dem Flur packt und ihn Ihr Programm testen lassen, obwohl es nicht ihre Aufgabe ist? Das scheint eine großartige Möglichkeit zu sein, die Leute abzukreuzen.

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

Es gibt einige Bedingungen, die wirklich nicht viel Sinn machen, wenn Sie sich zum Beispiel entwickeln eingebettete Software für einen Satelliten oder eine Verkaufsautomat, wie die täglichen Builds (3) oder Usability -Tests (12).

Der Joel -Test testet nicht, wie gut ein Team ist. Es wird getestet, wie gut Ihr Team am Joel -Test haftet.

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 gut schreiben?

Es ist für mich irrelevant, ob Sie den Flurstest "für den Flur" oder nicht, welche Quellensteuerung Sie haben oder wie Ihr Build -Prozess ist (wenn es eine gibt - nicht jede Lanugage hat sie). Das wahre Maß für ein Team ist die Qualität der von ihnen erstellten Software.

Grundsätzlich können Sie jeden einzelnen Schritt des Joel -Tests befolgen und immer noch mit Mistcode und Produkten erhalten, die niemals versendet werden. Zum Beispiel macht die Quellvertretung nicht auf magische Weise einen besseren Codierer. Es erleichtert das Verwalten von Code. Und die neueste Version von Visual Studio bedeutet nicht, dass Ihre Anwendung besser funktioniert, als wenn sie mit geschrieben wurde Visual Studio 2005.

Lizenziert unter: CC-BY-SA mit Zuschreibung
scroll top