Vor 12 Jahren erfand Joel Spolsky, Gründer von Fokgreek Software den Joel Test. 12 Fragen an denen man erkennen soll, ob man in einem vernünftigen Softwareentwicklungsteam arbeitet. Kann man nur 10 der 12 Fragen mit Ja beantworten, sollte man sich überlegen, etwas am Prozess zu verändern. Wie gesagt: Das ganze ist jetzt schon 12 Jahre her. Um es vorwegzunehmen es hat sich doch einiges geändert. Hier mein Vorschlag für einen aktualisierten Joel Test (Sven Test):
- Kannst du deine Software in einem Schritt bauen und deployen?*
- Erstellst du bei jedem Checkin einen automatischen Build?*
- Erstellst du regelmäßig Metriken über deinen Code und wertest diese aus?*
- Spricht dein Issue-Tracker mit dem Build- und Versionskontrollsystem?*
- Werden bei dir Bugs gefixt bevor neue Features programmiert werden?
- Wird Funktionalität der Software vor der Implementierung in irgendeiner Form aufgeschrieben und mit Stakeholdern abgeglichen?*
- Haben deine Programmierer ruhige Arbeitsbedingungen?
- Benutzt du die besten Tools, die man kaufen kann?
- Hast du Mitarbeiter, die sich Vollzeit mit Tests beschäftigen?*
- Müssen Bewerber Quellcode während des Vorstellungsgespräches schreiben?
- Führst du Usability Tests mit Endbenutzern durch?
- Wird jede geänderte und neu programmierte Zeile deines Codes reviewt?*
* neu hinzugefügt
Aber schauen wir uns den Joel Test aus dem Jahr 2000 einmal genauer an, um zu verstehen, wie es zu meinem neuen Joel Test kam:
- Benutzt du eine Versionskontrolle?
Das braucht man im Jahr 2012 wohl nicht mehr zu fragen. Teams ohne Source Control dürfen sich nicht Softwareentwicklungsteam nennen sondern Adrenalin Junkies. Im Jahr 2012 heißt die Frage eher: Benutzt du eine verteilte Versionskontrolle? So essinziell finde ich die Frage allerdings nicht, dass sie in den Joel Test kommen müsste: Fazit: Die Frage fliegt raus! - Kannst du den gesamten Build in einem Schritt ausführen?
Dies ist leider in vielen Projekten immer noch ein Problem, ist aber durch Continuous Integration Tools wie Jenkins, Cruise Control und Bamboo viel besser geworden.
Heutzutage müsste es aber heißen: Kannst du deine Software in einem Schritt deployen? Dies rückt spätestens seit der Verbreitung des Begriffes DevOps mit Konfigurationsmanagement immer mehr ins Zentrum. - Erstellst du tägliche Builds?
Wie die Zeiten sich doch geändert haben: Das gehört definitiv ins Museum. Heute ist es eigentlich selbstverständlich einen Build pro Checkin aufzurufen: Erstellst du bei jedem Checkin einen automatischen Build? Ich würde das gerne noch ergänzen durch: Erstellst du regelmäßig Metriken über deinen Code und wertest diese aus? - Hast du eine Datenbank für deine Bugs?
Ich hoffe, das können wir streichen. Vielmehr sollten es heutzutage heißen: Spricht dein Issue-Tracker mit dem Build- und Versionskontrollsystem? Die Verknüpfung von textuell beschriebenen Funktionen mit dem tatsächlichen Code, den Builds und den Code Reviews ist super brauchbar! - Werden bei dir Bugs gefixt bevor neue Features programmiert werden?
Das ist immer noch aktuell und wird es wohl auch immer bleiben. Allerdings sind wir dank Scrum , also durch kurze Entwicklungsiterationen und Releasecyclen, dem Problem dichter auf den Fersen… oder etwa nicht?
Fällt ein Fehler in der laufenden Software auf, kann er in der nächsten Iteration gefixt werden… Dies kann manchmal auch kritisch werden. Mit Kanban nähern wir uns dem Problem schon besser an. Mein Fazit: Behalten wir bis auf weiteres mal im Test. - Hast du einen aktuellen Entwicklungsplan?
Klar, heute hat man ein Scrum- oder Kanban Board! Diese Frage können wir also streichen. Und da Product Owner für die Features verantwortlich sind, die programmiert werden sollen, ist das nicht mehr das Problem der Entwicklung: Aufgabe abgewälzt. - Hast du eine Spezifikation?
Durch Epics und User Stories existiert eine bessere Spezifikation. Funtionaltäten müssen noch nicht bis ins kleinste Detail im voraus festgelegt werden. Diese Art ist übersichtlicher und nicht so zeitaufwendig. Der Punkt ist aus meiner Sicht auch nicht mehr aktuell und sollte durch die Frage: Wird Funktionalität der Software vor der Implementierung in irgendeiner Form aufgeschrieben und mit den Stakeholdern abgeglichen? - Haben deine Programmierer ruhige Arbeitsbedingungen?
Das ist natürlich auch heute noch interessant. Aber Joels Vorschlag, alle Mitarbeiter in separate Büros zu sperren, ist meiner Meinung nach auch nicht die Lösung. Man verliert dadurch die Zusammenarbeit, den Informationsfluss und Erfahrungsaustausch. Ich habe sehr gute Erfahrung mit Regeln gemacht, indem man ein bestimmte Zeit zur ruhigen Arbeit vereinbart und jemanden als Ansprechpartner für das gesamte Team ernennt. Diese Frage ist also immer noch aktuell und sollte im Joel Test bleiben. - Benutzt du die besten Tools, die man kaufen kann?
Glücklicherweise sind heutzutage die besten Tools entweder umsonst oder kosten nicht viel. Dank Cloud-Angeboten werden diese wohl auch in nächster Zeit noch günstiger, auch weil man nicht den Betrieb übernehmen muss.
Anderseits höre ich heutzutage auch oft: Warum ein etwas besseres Tool einsetzen wenn etwas schlechteres umsonst ist? Aber an den Tools für die Entwickler sollte man auch heutzutage nicht sparen! - Hast du Tester?
Wir Entwickler schreiben Unit-Tests. Diese werden bei jedem Check-In automatisch ausgeführt. Zusätzlich haben wir automatische Integrationstests, die auch automatisch ausgeführt werden. Es fehlt noch der Abgleich der programmierten Funktionalität mit der User Story. Das könnten doch auch die Programmierkollegen übernehmen? Wozu also heutzutage noch Tester? Weil diese viel mehr Erfahrung mitbringen. Die Aufgabe des Testers, bzw. der QA sollte darin bestehen, sich um die Infrastruktur zu kümmern, die Regeln zu überprüfen, Usability Tests durchzuführen und die Programmierer befähigen, dass diese die QA unterstützen können. Tester gehören ins Team und sollten kein eigenständiges Team sein. Also kurz gesagt: Immer noch ein berechtigte Frage für den Joel-Test, die heute aber so heißen muss: Hast du Mitarbeiter, die sich Vollzeit mit Tests beschäftigen? - Müssen Bewerber Quellcode während des Vorstellungsgespräches schreiben?
Ich glaube nicht, dass sich hier viel verbessert hat. Es ist immer noch die Ausnahme, dass Arbeitsproben gefordert werden. Da viele Programmierer sich aber an Open Source Projekten beteiligen, kann man sich heutzutage oft schon vorab über die Programmierqualität informieren. Aber ein paar programmierte Zeilen, während eines Vorstellungsgespräches, sollte man trotzdem einfordern. Auch wenn das mehr Vorbereitungs- und Nachbereitungsarbeit erfordert. - Führst du Usability Tests mit Endbenutzern durch?
Dieser Punkt wurden in vielen agilen Unternehmen aus 2 Gründen verbessert: Die Stakeholder nehmen am Ende der Iteration die Funktionalität ab. Man bekommt also alle 2-4 Wochen direktes Feedback. Leider sind Stakeholder nicht unbedingt auch Endbenutzer. Wir kommen aber dichter dran. Durch häufigere Releases kann bekommt man schneller Feedback darüber, ob die neue Funktion auch Benutzerfreundlich ist.
Auch dank Apple legen die Unternehmen immer mehr Aufmerksamkeit auf Usability.
Ist dieser Punkt wirklich immer noch so wichtig? Klar! Stakeholders wissen manchmal auch nicht was benutzbar ist und was nicht.
Sven Peters 