Wenn Sie meinen, dass ich schreiben werde, dass man, um die Qualität einer Anwendung zu gewährleisten, Tests und Code-Reviews (eigentlich auch eine Art Test, lieber Programmierer) durchführen oder eine gute Serie automatischer Tests schreiben muss, dann irren Sie sich. Natürlich haben die obigen Elemente einen Einfluss auf die Produktqualität, aber sie sind nicht am wichtigsten. Warum?
Steigert das Testen die Produktqualität?
Diese Frage stellte ich seinerzeit gerne bei Qualifikationsgesprächen. Die entschiedene Mehrheit der Kandidaten antwortete, dass das Testen natürlich die Qualität einer Anwendung steigert. Unsinn. Durch das Testen werden Fehler oder Unzulänglichkeiten einer Anwendung entdeckt. Aber durch das Finden der Fehler allein verbessert sich nicht die Produktqualität. Angenommen wir haben ein Auto, dass nicht anspringt und wir wissen nicht warum, verbessert sich dann durch die Kenntnisnahme, dass eine leere Batterie daran schuld ist, die Funktionsfähigkeit des Autos? Nein. Und mit dem Testen ist es genauso. Das Testen ist eine Art Messinstrument, mit dem wir die Produktqualität messen. Ob diese jedoch gesteigert wird – das ist nicht mehr vom Tester abhängig.
Automatische Tests?
Glauben Sie mir, kaum beginnen Ihre Tests, Fehler in einer Anwendung zu finden, schon entsteht vor Ihren Augen das Paradox der Pestizide und es erscheinen Fehler außerhalb der Pfade der automatischen Tests. Wie kann man also die Qualität einer Anwendung gewährleisten? Wo versteckt sie sich, aus welcher Schublade soll man sie ziehen? Die Antwort ist denkbar einfach – die Qualität steckt in Ihnen. Sie verbirgt sich in jedem Teammitglied. Und nur wenn das Team sich dessen „bewusst” ist, über die notwendigen Kenntnisse verfügt und – was das Wichtigste ist – gut zusammenarbeitet, hat es eine Chance, ein Produkt guter Qualität zu schaffen.
Teamverantwortung für das Produkt
Der erste Punkt ist die Verantwortlichkeit des Teams für das Produkt. Ja – des Teams. Nicht der Architekt, der Manager oder der Tester ist verantwortlich. Das ganze Team muss verantwortlich sein. Wenn sich das Team für das Produkt nicht verantwortlich fühlt, das Produkt nicht als ein „geliebtes Kind” betrachtet, dann wird die Arbeit des Teams von Anfang nicht so gut ausfallen wie sie könnte. Darum ist es sehr wichtig, in einem Entwicklerteam das Gefühl der Verantwortlichkeit zu wecken und ihm das Produkt näher zu bringen. In einem der Teams, in dem ich Mitglied war, habe ich das an der eigenen Haut erfahren. Wir haben eine Art Transformation durchgemacht, unsere Arbeitsweise hat sich mit der Zeit geändert. Je näher uns das Produkt war, desto leichter fanden wir Geschäftsvoraussetzungen und Gründe diverser Entscheidungen, desto besser war die Qualität unseres Produkts. Mehr noch – wir waren zusammen mit „dem schlechten Geschäft” dafür mitverantwortlich, diese Entscheidungen zu treffen – sollten ihm beim Treffen der Entscheidungen helfen. Wenn die Verantwortlichkeit für eine Gesamtaufgabe von einer Person allein übernommen wird, führt das zu einer Situation, in der den Entwicklern Aufgaben aufgetragen und auch bestimmt gut ausgeführt werden, aber nur „von Taktstrich zu Taktstrich“ – ohne einen breiteren Überblick über die Anwendung und ihre Architektur und die Konsequenzen einer gewählten Lösung in der Zukunft. Auf diese Weise entstehen häufig technische Schulden.
Wissen und Transparenz – der Schlüssel zum Erfolg
Der zweite Punkt ist die Informiertheit. Wie ich schon weiter oben angedeutet habe, ist es wichtig, dass das gesamte Team und jedes einzelne Teammitglied über die für die Arbeit erforderlichen Informationen verfügt. Es darf nicht passieren, dass z.B. einer der Entwickler eine Analyse einer zusätzlichen Kundenanforderung macht und der Rest des Teams nichts davon weiß. Erstens – selbst wenn die betreffende Person der beste Architekt in der ganzen Firma ist, heißt das, dass er die besten Entscheidungen trifft und die besten Lösungen wählt? Heißt das, dass er das Alpha und das Omega ist? Kann es nicht sein, dass ein neu eingestellter Entwickler, der noch studiert und für den dies der erste Job ist, eine bessere Idee hat? Vielleicht kennt er ja irgendeine neuere Technologie oder Methode, mit der das betreffende Problem deutlich effektiver gelöst werden kann? Und auch, wenn er keine geniale Idee hat, warum soll er nicht an dem Prozess teilnehmen dürfen, um mit vollen Händen aus dem Wissen und der Erfahrung des älteren Kollegen zu schöpfen? Weiter – wenn das Team die Produktvision und –strategie nicht kennt, kann es dann effektiv und gut arbeiten? Werden wohl alle unter solchen Umständen getroffenen Entscheidungen gut sein? Nicht unbedingt. Mehr noch, bestimmte Aufgaben werden für das Team unsinnig sein, werden keinen Sinn machen. Wenn Sie an etwas arbeiten, das Ihnen unsinnig erscheint, geben Sie dann alles, was Sie haben? Genau. Darum ist die Transparenz so wichtig. Transparenz ist der Schlüssel.
Teamwork
Sehr wichtig ist auch die Beziehung zwischen den Teammitgliedern. Ist das Team geteilt, bilden sich „Grüppchen gegenseitiger Verehrung”. Eben – ist das dann noch ein Team? Eine solche Gruppe von Mitarbeitern hat, auch wenn sie aus den besten Profis besteht, keine Chance, ein hochwertiges Produkt zu schaffen. Es werden sehr schnell Konflikte auftreten und dazu führen, dass die Stimmung im Team unterhalb aller Erwartungen fällt. Kann man unter solchen Bedingungen effektiv arbeiten? Vielleicht ja, aber nur mit enormen emotionalen Kosten. Der Schlüsselaspekt ist der gegenseitige Respekt – für die Personen und deren Fähigkeiten. Ich habe in einem Team ohne Respekt gearbeitet – glauben Sie mir – das ist kein Vergnügen. Man kommt zur Arbeit und wartet nur darauf, dass die acht Stunden vorbeigehen. Wirken sich solche Voraussetzungen gut auf Ihre Kreativität aus? Ganz im Gegenteil – sie führen auf direktem Wege zum beruflichen Burn-out. Wenn wir unsere Arbeit in „dicker” Luft machen müssen, bringt sie uns keine Befriedigung mehr. Jeder von uns ist anders, hat andere Meinungen und Erfahrungen, einschließlich der beruflichen Erfahrungen. Durch gegenseitigen Respekt können wir diese Unterschiede als eine Quelle betrachten, aus der wir schöpfen können.
Scrum – Verantwortung, Transparenz, Respekt
Możecie uważać, że nie mam racji – macie do tego pełne prawo. Jednak moje doświadczenia pokazują, że Vielleicht sind Sie anderer Ansicht – das ist Ihr volles Recht. Meine Erfahrungen weisen jedoch darauf hin, dass es so ist – wo Transparenz ist, wo Respekt ist, wo Verantwortlichkeit ist, da entsteht, auch unter ungünstigen Bedingungen, ein wertvolles, qualitativ gutes Produkt. Das bedeutet natürlich nicht, dass da, wo diese Werte fehlen, nicht auch ein gutes Produkt entstehen kann. Es kann auch so entstehen, aber gewiss wird es unter großen Schmerzen geboren werden.
Verantwortlichkeit, Transparenz, Respekt. Als ich diese Worte schrieb, nahm ich auf keinerlei Methode Bezug und dachte an keine bestimmte Methode, aber jetzt, wo es Zeit für die Schlussfolgerung ist und ich die obigen Abschnitte noch einmal durchgelesen habe, habe ich festgestellt, dass ich drei der Werte genannt habe, die der Scrum-Methode zugrunde liegen. Die übrigen Werte haben sich sicher auch zwischen den Worten eingeschlichen. Ein Zufall? Sicher nicht. Heißt das also, ohne Scrum keine Qualität? Natürlich nicht. Dennoch wussten ihre Erschaffer, welche Werte die richtige Grundlage schaffen.
