Kann ein agiler Shop beim Joel-Test wirklich 12 Punkte erzielen? [geschlossen]

Ich mag den Joel-Test sehr, benutze ihn selbst und ermutige meine Mitarbeiter und Befragten, ihn sorgfältig zu prüfen. Ich glaube jedoch nicht, dass ich jemals mehr als 9 Punkte erzielen kann, da einige Punkte dem Agilen Manifest, XP und TDD zu widersprechen scheinen, die das Fundament meiner Welt sind.

Insbesondere: Die Fragen zu Zeitplan, Spezifikationen, Testern und ruhigen Arbeitsbedingungen stehen im Widerspruch zu dem, was wir zu schaffen versuchen, und den Werten, die wir angenommen haben, um wirklich agil zu sein.

Meine Frage ist also, ob es möglich ist, dass ein echter Agile-Shop 12 Punkte erzielt?

Bearbeiten:

Auf Empfehlung eines Antwortenden füge ich einen Link zu meinem Blog hinzu, in dem ich ursprünglich darüber geschrieben habe und der dazu führte, dass ich die Frage hier posten wollte.

http://simonpalmer.com/2011/03/16/why-i-will-never-score-more-than-9-on-the-joel-test/

Ich trage dies ein, weil ich mit vielem, was unten gesagt wurde, einverstanden bin und meine volle Position erklären wollte.

Mein Standpunkt als Agilist:

Verwenden Sie die Quellcodeverwaltung?

Ja, natürlich, kontinuierliche Integration, ein Teil von XP benötigt ein Quellcodeverwaltungssystem, um in der Lage zu sein, Code dafür zu schreiben.

Können Sie einen Build in einem Schritt erstellen?

Ja, der Continuous Integration Server ist dafür da.

Machst du tägliche Builds?

Wenn wir es in einem Schritt schaffen, können wir es planen.

Hast du eine Bug-Datenbank?

Ja, jedes Management-Tool für "Agile-Projekte" kann Fehler nachverfolgen und im Scrum-Produkt-Backlog hinzufügen

Beheben Sie Fehler, bevor Sie neuen Code schreiben?

Ja, sie werden im Produkt-Backlog priorisiert

Haben Sie einen aktuellen Zeitplan?

Ja, dank des Product Backlogs, des Iterations-Backlogs, des Release-Plans und der genauen Schätzungen, die dank Planning Poker damit einhergehen.

Haben Sie eine Spezifikation?

Ja, jede User Story enthält bei Bedarf weitere Details. Wir fördern auch die Kommunikation zwischen dem Product Owner und dem Team.

Haben Programmierer ruhige Arbeitsbedingungen?

Ja, ein Raum mit 8 Entwicklern ist normalerweise sehr ruhig. Wir versuchen, die Verkäufer nicht im selben Raum unterzubringen.

Verwenden Sie die besten Werkzeuge, die Sie für Geld kaufen können?

Ja, obwohl wir Einzelpersonen gegenüber Werkzeugen schätzen, machen Sie sich keine Sorgen, Joel, wir erwerben eine Lizenz für alle Ihre Produkte;)

Hast du Tester?

Ja und sie sind ein wesentlicher Bestandteil des Teams.

Schreiben neue Kandidaten während ihres Interviews Code?

Ja, und das Team ist in den Prozess involviert.

Führen Sie Flur-Usability-Tests durch?

Ja, unsere Tester helfen uns dabei.

Haben Sie einen aktuellen Zeitplan?

Das ist Agil. Scrum verlangt von uns, dass wir uns zu einer Veröffentlichung verpflichten. Wenn Sie einen aktuellen Zeitplan haben, müssen Sie wissen, was in der Version getan wird (und was nicht) und wie der Rückstand aussieht.

Haben Sie eine Spezifikation?

Das ist Agil. Eine Architektur (und die dazugehörige Beschreibung) ist unerlässlich. Dies gibt das Formular an. Anwendungsfälle (oder User Stories) sind unerlässlich und legen die Funktionalität fest.

Haben Programmierer ruhige Arbeitsbedingungen?

Ich kann nicht sehen, wie Agile eine laute, störende, nervige Umgebung benötigt.

Hast du Tester?

Äh. Wenn wir TDD tun, wir sind Tester. Wenn wir den Code an den Produktbesitzer übergeben, können zusätzliche Tester beteiligt sein, bevor die Kunden involviert sind.

Inwiefern widerspricht dies den agilen Methoden oder dem agilen Manifest?

Ich denke, die Antwort lautet: Ja, ein Agile-Shop sollte dazu in der Lage sein. Speziell zu Ihren Punkten.

• Bei der Planung geht es darum, eine klare Definition der Funktionen zu haben, mit denen Sie sich befassen möchten. Das ist definitiv erreichbar.
• Bei "Leisen Arbeitsbedingungen" geht es nicht um den Klang am Arbeitsplatz, sondern um das Entfernen von Nicht-Projekt- / Programmiergeräuschen. Es geht darum, Ihre Programmierer davon abzuhalten, sich Mühe zu geben, Ablenkungen auszublenden
• Agile Shops sollten früh testen und es ist wirklich das, worum es bei Joel geht, wenn jemand anders als der Entwickler den Code testet.

Warum ist ein Zeitplan (um nur ein Beispiel zu nennen) Ihrer Meinung nach nicht mit der agilen Entwicklung vereinbar?

Es ist sehr unwahrscheinlich, dass Sie von Sprint zu Sprint arbeiten, ohne eine Vorstellung davon zu haben, wohin Sie mit Ihrem Produkt wollen. Ja, Sie müssen den Zeitplan nach jedem Sprint erneut aufrufen und überarbeiten, haben aber immer noch einen.

Eine Aussage wie "In Q1 planen wir die Veröffentlichung der Features A, B, C und in Q2 schauen wir uns derzeit die Features X, Y, Z an" ist immer noch ein Zeitplan. Es gibt jede Chance, dass X zu W wird, aber genau das können Sie tun, wenn Sie agil sind.

Nehmen Sie eine andere Sache von Ihrer Liste - Specs. Was ist eine User Story, wenn nicht eine Spezifikation?

Ich schätze, ich werde das aus einer anderen Perspektive betrachten als die meisten hier. Wenn Sie beim Joel-Test eine 9 erzielen, sind Sie der Kurve voraus. Viele Orte würden Schwierigkeiten haben, eine 5 oder 6 zu treffen, geschweige denn 9 bis 12.

Fällt es Ihnen schwer, gute Leute einzustellen? Wenn nicht, dann ist eine 12 auf dem Joel-Test, während ein nobles Ziel, möglicherweise nicht wirklich ein Problem. Wenn Ihre Mitarbeiter in der Lage sind, in dem Umfeld zu arbeiten, in dem Sie arbeiten, würde ich sagen, gute Arbeit, wenn Sie so gut abschneiden wie Sie.