Kontakt
Eines der Kernprinzipien des Lean Management ist, Qualität in den Prozess einzubauen. Konkret heißt das, dass Maßnahmen zur Qualitätssicherung bereits während der Produktion durchgeführt werden und nicht erst nachgelagert als separater Prozessschritt stattfinden.
Jedem, der sich mit Scrum beschäftigt, klingeln die Ohren. Schließlich sind viele Elemente von Scrum schon out-of-the-box genau darauf ausgelegt, stabile Qualität in einem immer besser werdenden Prozess zu liefern. Im Zweifel Funktionsumfang geopfert werden, aber Deadlines müssen eingehalten werden.
Was Scrum nicht vorgibt, ist, wie das Maß an Qualität erreicht werden soll. In den meisten Scrum Teams haben sich allerdings bestimmte Vorgehensweisen etabliert und auch unser Team hat seine eigenen entwickelt.
Jede Zeile Code, die ein Entwickler in unserem Team schreibt, muss mindestens ein weiterer Entwickler reviewen. Erst dann darf der zugehörige Task als „done“ gewertet werden, sodass mindestens zwei Personen genau wissen, wie dieser Teil der Software funktioniert.
Auch diese Methode entspringt den Gedanken der Lean Production. Dort trägt das gesamte Team die Verantwortung für die Qualität des Produkts. Jedes Teammitglied muss also über die Arbeitsschritte, die eine andere Person übernimmt, genau Bescheid wissen und sie im Zweifel sogar selbst übernehmen können.
Genau hierfür eignen sich Codereviews hervorragend. Information darüber, wie die Applikation funktioniert, wird über diesen einfachen Prozessschritt im Team verteilt – ohne zusätzliche Meetings oder Präsentationsrunden. Das ist gerade in großen Scrum-Teams essenziell.
Einen ähnlichen Prozessschritt haben wir ebenfalls für User Stories etabliert – allerdings nicht aus technologischer, sondern aus Nutzersicht.
Unser Team arbeitet an einer Applikation, die sich durch exzellente User Experience auszeichnet. Diese lässt sich aber nicht durch reinen Blick auf den Code sicherstellen. Aus diesem Grund muss jede User Story, die mit in das Sprint Review aufgenommen werden soll, den Segen unserer UX-Architektin und unseres Designers erhalten.
Das hilft schon früh in der Entwicklung, den Blick des Users für die Applikation zu bekommen – und notwendige Anpassungen noch im laufenden Sprint zu unternehmen. Gerade dem Product Owner, der oft tief in den Anforderungen steckt, hilft es, wenn mindestens eine Person im Team durchgängig die Nutzerbrille aufbehalten darf.
Daneben haben wir es durch diesen Prozess auch geschafft, ein Design Thinking Mindset im ganzen Team zu säen, sodass das Team beispielsweise im Refinement Meeting User Stories oft auch konzeptionell hinterfragt statt nur technologisch.
Stichwort: Test Driven Development (TDD). Das heißt: Erst den Test entwickeln und dann die zugehörige Funktionalität.
Der Vorteil hier liegt darin, dass der Entwickler sich über die Lösung schon Gedanken machen muss, bevor er nur eine Zeile Code geschrieben hat. Da die Tests im besten Fall auf bestimmten Akzeptanzkriterien basieren, wird durch das „fixen“ des Tests sichergestellt, dass genau das richtige gebaut wird.
Hier tritt aber auch die Schwierigkeit zu Tage:
Es ist häufig schwierig für besonders komplexe Anforderungen Tests zu schreiben, ohne vorher verschiedene Lösungen auszuprobieren. Hat man dann die Lösung gefunden, die funktioniert, ist sie auch schnell umgesetzt. Den Umsetzungsfluss durch das Schreiben eines Tests zu unterbrechen ist in solchen Situationen ungünstig.
Aus diesem Grund sind wir noch lange nicht so gut, wie wir gerne wären. Die Testabdeckung unseres Codes ist zwar durchaus zufriedenstellend. Allerdings kommt es genau deswegen gelegentlich vor, dass erst nach dem Codereview die Tests geschrieben werden.
Das ist auch aus einem anderen Grund verständlich. Schließlich bringen Tests dem User zunächst keinen Mehrwert, wenn doch die Software gerade funktioniert. Erst wenn Regressionen entdeckt werden, entfaltet sich ihr Nutzen.
Ich bin mir aber sicher, dass wir noch eine Methode finden, dieses Element noch konsequenter umzusetzen. Leider lässt sich das Entwickeln von Tests nicht automatisieren.
Aufgaben, die sich automatisieren lassen, haben einen gewaltigen Vorteil: Sie werden gerne erledigt. Nichts macht mehr Spaß als einen Task auf „Done“ schieben zu dürfen, indem man z. B. in Jenkins einen Knopf drückt. Und das Schönste: Sie werden garantiert immer gleich ausgeführt, was so viel heißt wie fehlerfrei.
Aus diesem Grund versuchen wir so viel zu automatisieren, wie möglich.
Dass unsere Akzeptanztests und unsere Buildpipeline automatisiert sind, ist heute fast schon selbstverständlich. Wir versuchen aber noch weiter zu gehen. So haben wir beispielsweise auch die Screenshots, die wir für das Benutzerhandbuch unserer Applikation (in mehreren Sprachen) erstellen müssen, komplett durchautomatisiert.
Das ging relativ problemfrei. Schließlich haben wir die Seiten, die wir als Bild festhalten möchten, sowieso schon mit Selenium-Tests abgedeckt. Wir mussten also nur noch einen Schritt „Screenshot“ einbauen.
Als nächste Aufgabe steht bei uns die Automatisierung der Installation auf Fremdsystemen auf der Liste.
Das klingt für den ein oder anderen vielleicht nach ziemlich viel Aufwand und einer Menge Prozess. In Wahrheit ist es aber so, dass diese Maßnahmen – wenn sie zur Selbstverständlichkeit werden – überhaupt nicht viel Zeit kosten.
Besonders nicht in der Nettobetrachtung. Am allerwenigsten Spaß macht es nämlich Bugfixes ausliefern zu müssen statt an Features zu arbeiten. Im aktuellen Projekt unseres Teams kommt unsere Software bislang nach Auslieferung auf genau einen Bug.
Und einer muss immer sein. Wir wollen ja nicht als Streber dastehen.
