Kaizen 2 go 254 : Qualitätsmanagement in der Software-Entwicklung

Inhalt der Episode:

Was sind typische Qualitätskriterien, die an Software angelegt werden?
Wie wird typischerweise die Einhaltung dieser Kriterien geprüft?
Was unterscheidet Qualitätsmanagement bei der Software-Entwicklung von Konzepte von klassischer Qualitätssicherung?
Welche Vorteile ergeben sich daraus?
Pair Programming
Welche Vorteile Qualitätsverantwortung und -pflege statt Fehlerverantwortlichkeit hat.
Welche Voraussetzungen sind für Pair Programming erforderlich?
Welche Vorteile ergeben sich noch?
Wo Pull auch in der Software-Entwicklung vorkommt.

Notizen zur Episode:

Mitmachen?

Wenn Sie selbst ein interessantes Thema für eine Episode im Umfeld von Geschäftsprozessen haben, können Sie mir das auf dieser Seite mit Vorbereitungsfragen vorschlagen.

Ich freue mich darauf!

Ihnen hat der Inhalt gefallen? Dann bewerten Sie die Episode bitte bei iTunes.

Jetzt eintragen und Artikel/Denkanstöße zukünftig per eMail erhalten.

Artikel teilen auf ...

(Teil)automatisiertes Transkript

Episode 254 : Qualitätsmanagement in der Software-Entwicklung

Herzlich willkommen zu dem Podcast für Lean Interessierte, die in ihren Organisationen die kontinuierliche Verbesserung der Geschäftsprozesse und Abläufe anstreben, um Nutzen zu steigern, Ressourcen-Verbrauch zu reduzieren und damit Freiräume für echte Wertschöpfung zu schaffen. Für mehr Erfolg durch Kunden- und Mitarbeiterzufriedenheit, höhere Produktivität durch mehr Effektivität und Effizienz. An den Maschinen, im Außendienst, in den Büros bis zur Chefetage.

Götz Müller: Heute habe ich Nils Kasseckert bei mir im Podcast-Gespräch, er ist technischer Architekt im SAP-Umfeld bei einer großen Drogeriemarktkette. Hallo Herr Kasseckert.

Nils Kasseckert: Hallo Herr Müller.

Götz Müller: Klasse, dass Sie heute dabei sind. Jetzt habe ich schon ein Stichwort zu Ihnen gesagt, Software-Architekt, SAP-Architekt, aber stellen Sie sich gern noch mal in 2-3 Sätzen ein bisschen intensiver vor.

Nils Kasseckert: Na klar, gerne. Also ich bin bei einer großen Drogeriemarktkette angestellt hauptberuflich, verantworte dort als technischer Architekt die Fiori Apps im SAP-Umfeld, dass alle Apps im Konzern so laufen wie sie halt laufen sollen. Seit 2013 habe ich zusätzlich nebenher noch ein Gewerbe App Supporter, womit ich für verschiedene Kunden Web-Apps, native Apps, Webseiten, Hosting und andere Sachen anbiete.

Götz Müller: Ja, ich glaube, da treffen sich die Dinge ja auch und auch zu unserem Thema heute: Qualitätsmanagement in der Softwareentwicklung. Und vielleicht so zum Einstieg erstmal die Frage, für die, die halt jetzt nicht aus dem Software-Umfeld kommen, was sind so typische Qualitätskriterien, die man an eine Software anlegt?

Nils Kasseckert: Ja, das ist eigentlich relativ einfach zu sagen. Also natürlich Fehlerfreiheit, also wenn, also kein Kunde möchte gerne Software haben, die ständig abstürzt oder ständig Probleme macht, womit wir gleich zum nächsten kommen, Stabilität, also die Software sollte stabil laufen und vor allem, was ganz wichtig ist, auch die Kundenerwartung erfüllen. Also da gibt's verschiedenste Grafiken, auch im Software-Entwicklungsumfeld, der Kunde wünscht sich eine Schaukel und im Endeffekt bekommt er dann nur einen Reifen.

Götz Müller: Ja, dieses Bild habe ich auch vor meinem geistigen Auge. Ich glaube, das passt aber für viele Situationen und natürlich ist, glaube ich, die Kundenerwartung, das ist nicht nur, aber auch speziell im Software-Umfeld sicher ein der schwierigsten Sachen und natürlich schließt sich da im Grunde auch schon die nächste Frage an: Wie prüfe ich denn das? Fehlerfreiheit und Stabilität, glaube ich, ist noch relativ einfach.

Nils Kasseckert: Richtig, genau. Aber diese Kundenerwartung, wie Sie halt jetzt schon meinten, das ist immer so das Kritischste, weil der Kunde selbst meistens gar nicht am Anfang weiß, was will er denn haben oder werden die Änderungen häufig mehrfach umgeändert oder es kommen neue Sachen hinzu. Deswegen es ist gibt prinzipiell jetzt mehrere Möglichkeiten. Ganz klassisch wäre jetzt der manuelle Test durch den Kunden am Ende der Entwicklung und dann hat man aber genau diesen Fall, den ich da gerade meinte, dann könnte sich das Ganze, die ganzen Anforderung ändern. Wesentlich besser wären jetzt natürlich test-driven oder behavior-driven Development-Konzepte, sprich man definiert direkt am Anfang, was soll die Software können, bevor man überhaupt angefangen hat und dann entwickelt man daran die Software.

Götz Müller: Wie unterscheidet sich das jetzt grundsätzlich von, nennen wir es mal klassische Qualitätssicherung?

Nils Kasseckert: Also bei der klassischen Qualitätssicherung wird jetzt, wie ich ja schon so angedeutet habe, bei irgendwelchen Meilensteinen oder am Ende der Entwicklung drüber geschaut: Ist das Ganze jetzt das, was ich haben will oder hat sich das auseinanderentwickelt? Da muss dann der Entwickler wieder anfangen, muss wiederum andere, also muss Änderungen einbauen und so weiter und sofort. Während bei diesem bitte behaviour-driven development zuerst die Tests entwickelt werden. Ganz wichtig ist, dass dann währenddessen diese Tests alle noch failen müssen. Also läuft dieser Test dann schon grün, dann ist da irgendetwas was faul und das hat dann aber diesen Vorteil, dass wir dann die Überprüfung direkt während der Entwicklung bekommen. Also ein konkretes Beispiel ist jetzt, der Kunde will einen roten Button, das ist dann mein Test, wenn der Button jetzt statt rot grün ist, dann schlägt der Test fehl. Es wird erst am Ende der Entwicklung grün.

Götz Müller: Ja, da höre ich auch aus und ich denke, da kommen wir dann auch noch mal drauf, dass man auf Grund dieses Umgangs mit Fehlern man schon mal ganz anders an das Thema rangeht, während in anderen Situationen ist ja vermeintlich so der Fehlern das absolute Tabu.

Nils Kasseckert: Richtig. Also das ist auch noch so, dass man dann eine andere Fehlerkultur hat, mit Fehlern, ja, lernt umzugehen und halt auch dass es jetzt nicht schlimm ist, wenn man einen Fehler macht und das ist halt auch noch eine Sache, die man erstmal lernen muss unter Umständen.

Götz Müller: Und ich höre auch eben raus, weil man ja den Test zuerst definiert und im Grunde sogar die Testumgebung wahrscheinlich zuerst entwickelt, wenn ich mich so an meine persönlich graue Vorzeit erinnere, dann vermeide ich ja auch, dass ich eigentlich die Qualität hinterher reinprüfe, sondern ich entwickle sie vorher rein.

Nils Kasseckert: Richtig, genau. Und das hat dann auch gleich noch andere Vorteile, wenn wir jetzt mal weggehen von der reinen Qualität. Man kann dann auch noch die Software-Sicherheit, also das ja auch ein ganz großes Thema heutzutage, direkt mit reinentwickeln, was halt eine Riesensache ist, statt das man es erst ganz zum Schluss einfügt, und was man halt auch so sagen muss, wenn man diese Tests erst ganz zum Schluss schreibt, wir Entwickler sind meistens ein bisschen faul, das heißt, wir schreiben dann einfach Tests, weil wir sie schreiben müssen, aber es sind dann unter Umständen nicht so sinnvolle Tests. Somit hat man auch dann gleich diesen Zwang, einen sinnvollen Test zu schreiben, was einen auch anderweitig weiterbringt, wie eben, ich habe es jetzt gerade im Arbeitsumfeld, wir müssen auf eine neue Betriebssystemversion upgraden. Durch diese Tests ist es nur noch eine Sache von Tagen, vorher waren es Sachen von Monaten.

Götz Müller: Ja und da kommt mir natürlich jetzt gerade auch in den Sinn, Sie haben es jetzt faul genannt, aber ich finde das jetzt mal gar nicht grundsätzlich verwerflich, denn auch wenn jetzt das vielleicht die Qualitätsmenschen nicht unbedingt hören wollen, aber im Grunde ist Qualitätssicherung definitiv mal keine Wertschöpfung.

Nils Kasseckert: Richtig.

Götz Müller: Sie ist natürlich notwendig, aber sie schöpft für den Kunden direkt noch keinen Wert.

Nils Kasseckert: Richtig und das ist dann auch wiederum das nächste Problem, dass viele Kunden gar nicht das Geld ausgeben wollen oder das bezahlen wollen, weil die meinen, sie wollen nur diese Software haben und das ganze Drumherum interessiert sie gar nicht.

Götz Müller: Ja, gut. Da glaube ich unterscheidet sich jetzt die
Software-Entwicklung von im Grunde allen anderen Themen gar nicht, wo Kunden manchmal ich nenne es mal ein bisschen erstaunt sind, was manche Sachen halt einfach kosten, weil sie halt nur, sagen wir mal, die Spitze des Eisbergs sehen. Und ich glaube, gerade in der Softwareentwicklung ist ja der sogenannte Gutpfad nur ein minimaler Teil.

Nils Kasseckert: Richtig, genau.

Götz Müller: Gut, jetzt waren wir bei dem Punkt eben, was möchte ich als Kunde bezahlen, nicht bezahlen, und da ist mir in dem Kontext, ich bin ja da auf einen Artikel von Ihnen gestoßen, noch ein weiterer Punkt aufgefallen, der da ganz zentral drin vorkam, nämlich das sogenannte Pair Programming, wo auf den ersten Blick auch unheimlich viel Aufwand dahinter steckt und dann auch die Frage entsteht „Ja, warum soll ich das bezahlen?“, aber ich glaube, das ist auch ein ganz wichtiger Teil dessen, was eine gute Software-Entwicklung und gute Qualitätssicherung ausmacht.

Nils Kasseckert: Genau. Also, klar, man kann sagen, also mein Artikel ging ja auch darum „Fluch oder Segen?“, also dieses Pair Programming an sich ist eine gute Sache, also zu sagen, nicht nur einer schreibt die Software, entspricht mindestens dem Konsens von zwei Programmierern. Also wenn halt vier Augen drauf schauen, statt nur zwei, sollte in der Theorie bessere Software rauskommen mit weniger Fehlern, mit weniger Sicherheitslücken. Das zum einen, zum anderen haben wir dann auch noch den sogenannten Bus-Faktor erhöht. Das heißt Bus-Faktor in der Softwareentwicklung besagt, wie viele Leute können vom Bus überfahren werden, ohne dass die Lieferung der Software gefährdet ist. Wenn natürlich jetzt mehr Leute dran arbeiten ist das natürlich eine ganz andere Sache. Und natürlich ein ganz großer Faktor ist natürlich Wissens- und Kompetenztransfer, das ist dasselbe wie der Bus-Faktor, also es reicht schon, wenn der Kollege für drei, vier Wochen mal in Urlaub ist oder anderweitig verhindert ist. Deswegen ist es an sich gut, hat aber auch einige Probleme.

Götz Müller: Ich glaube, das ist halt immer grundsätzlich, wenn ich da wie gesagt, und ich nenne es mal ein bisschen flapsig früheres Leben zurückdenke, das ist, glaube ich, in der Softwareentwicklung die eine ganz große Herausforderung, dass ich diese normierende Instanzen, nenne ich es mal, der Produktion, und etwas produktionsfertig entwickele, das habe ich ja da gar nicht, weil im Grunde meine Entwicklung gleich Produktion ist.

Nils Kasseckert: Richtig.

Götz Müller: Und diese vermeintlich zusätzliche Hürde, die ich jetzt in der klassischen Produktion, wenn ich also etwas Greifbares entwickle, das entfällt halt bei der Software. Und ich nehme es nur so aus dem Augenwinkel wahr, Sie hatten ja auch das Stichwort genannt, App-Entwicklung, wo sich dann Leute manchmal darüber aufregen, wenn eine App mal so in den zweistelligen Eurobetrag reingeht, wo ich mich dann frage: „Leute, habt ihr eine Ahnung wie viel Arbeit dahintersteckt?“

Nils Kasseckert: Richtig. Das ist halt dieser Punkt, was halt, es ist halt auch diese Schwierigkeit, dass man bei der Software-Entwicklung nicht direkt das einschätzen kann erst, wenn man ein Haus baut, sieht man, was das gerade kostet, bei der Software-Entwicklung wird mir oft gesagt: „Ja, Sie googeln doch nur. Das kann ich doch auch selber.“

Götz Müller: Da würde ich dann immer gern sagen „Macht halt mal.“.

Nils Kasseckert: Richtig.

Götz Müller: Beziehungsweise, im Augenblick, das war ja eingangs Ihnen so ein Stichwort, erleben wir es ja ganz oft, gerade, was jetzt so mit Impfterminvereinbarung, was da teilweise für technische, ich nenne es mal Stilblüten, was so Sicherheitsaspekte angeht, das ist schon abenteuerlich, was man da so sieht.

Nils Kasseckert: Richtig. Also da so etwas wie Pair Programming oder behaviour-driven Development eine Sache, die man sich da überlegen sollte.

Götz Müller: Gut. Jetzt könnte ich mir vorstellen, dass durchaus halt auch ein paar Hürden vielleicht, mal von dem Aufwand abgesehen, dahinterstecken, damit Pair Programming so funktioniert, wie es nach den Regeln der Kunst sein sollte. Was sind denn so Voraussetzungen, die das Team, die Menschen, die Organisation mitbringen muss?

Nils Kasseckert: Also, da gibt's einige. Also ich habe das selber anderthalb Jahre erleben dürfen und das sind einige Punkte, die man auf jeden Fall beachten müsste. Das fängt an bei einem ähnlichen Wissensniveau. Also bei mir im damaligen Team war es so, es gab Leute, die hatten in Java noch nie programmiert und andere Leute, die haben schon seit 15 Jahren da gearbeitet. Das heißt, es gab ein riesengroßen Gap zwischen denen. Wenn diese Leute zusammenarbeiten war es halt so, dass halt beide Seiten unzufrieden waren. Der eine kam nicht voran, der andere fühlte sich dumm, jetzt mal ganz platt gesagt. Also was man ja auch bei diesem Pair Programming wissen muss, ist, dass das Pair mindestens wöchentlich wechselt. Das heißt, man hat jede Woche einen anderen Partner, mit dem man jetzt zusammenarbeitet und auch an einem anderen Thema. Da kommen wir gleich zum nächsten, also auch die Person an sich muss halt offen sein, jede Woche etwas anderes zu machen. Man kann jetzt nicht sagen, das ist mein Aufgabengebiet, das mache ich jetzt die nächsten Jahre, sondern jede Woche etwas neues und was halt dann wiederum ist, wenn man jede Woche auch einen anderen Partner hat, muss man sich auch mit dem ganzen Team verstehen. Das heißt, man braucht ein positives Arbeitsklima. Mag man diesen Kollegen nicht, dann wird es eher schwierig. Also wir hatten bei uns dann solche Fälle, es kam dann auch so durch unterschiedliche Kulturen, wir hatten chinesischstämmige Leute da, wir hatten französischstämmige Leute und da ist natürlich eine ganz andere Arbeitskultur, also besonders Chinesen, die würden ja niemals mit einem diskutieren oder so, das ist halt einfach deren Kultur, aber Pair Programming lebt halt von der Diskussion. Also man hat einen Code geschrieben und darüber diskutiert man, ob der jetzt gut oder schlecht ist. Es bringt aber nichts, wenn Partner immer nur ja sagt. Das ist halt so eine Sache und halt, wenn dann das Management nicht aktiv eingreift und guckt, wie sehr verstehen sich die Leute, dann entsteht ganz schnell Abneigung und Abneigung im Pair Programming ist eher ungünstig. Also das führt dann dazu, also bei mir und meinem ehemaligen Team führte das dazu, dass man zwar zum Pair Programming eingeteilt wurde, aber man hat sich die Aufgaben untereinander aufgeteilt und hat nichts voneinander gehört. Das ist auch ungünstig.

Götz Müller: Sie sagten eingangs, dass auch ein gewisses ähnliches Niveau existieren muss. Trotzdem, glaube ich, sehe ich persönlich es auch als eine Entwicklungschance, weil natürlich, so ist zumindest meine Erfahrung vor über 20 Jahren mittlerweile schon, dass ich im Grunde keine andere, nennen wir es mal Profession, kenne, wo selbst bei ähnlichem Ausbildungsniveau doch so ein großer Produktivitätsunterschied besteht.

Nils Kasseckert: Das ist auf jeden Fall. Also da muss ich Ihnen … aber was ich auch mit Wissensniveau meinte, es ist halt auch so, vielleicht nicht nur Wissensniveau, sondern auch dieser Willen und diese Fähigkeit zu lernen. Das ist, also die muss halt auf jeden Fall da sein. Ich das jetzt bei Kollegen, ich bin ja relativ jung mit meinen Anfang 20, ich hatte Kollegen, die gingen kurz auf die Rente zu, die waren schon Anfang 60, und für die war natürlich, wenn man noch nie mit Java entwickelt hat und jetzt auf einmal mit Anfang 60 noch eine neue Sprache lernen, war zum einen die Motivation eher gering, zum anderen auch die, also auch diese Schnelligkeit, da etwas Neues zu lernen und dann ist man natürlich als junge Person, die das schon seit Jahren macht das Ganze, ziemlich frustriert auf Dauer. Das ist halt so ein Spagat. Also es ist unmöglich, dass zwei Leute dasselbe wissen, aber es fängt halt so an, wenn man jemandem erklären muss, wie man da eine Variable deklariert und selber macht man schon zig Sachen damit, ist das halt frustrierend.

Götz Müller: Ja, wo Sie so erzählt haben, auch mit den wechselnden Teams, also nicht bloß, dass man selber die Rollen tauscht, sondern dass man wirklich mit jemand anderem zusammenarbeitet, da ist mir dann eingefallen, eine ganz andere Branche, wo es aber im Grunde genau das Gleiche gibt. Und zwar Luftverkehr. Das, was die zwei Jungs, mittlerweile sind es ja bloß noch zwei, die da vorne im Cockpit sitzen, das nennt sich, da gibt's einen Fachbegriff, nennt sich Crew Resource Management, unter anderem, aber ein zentraler Aspekt ist, dass diese Rolle Flugkapitän und Copilot beziehungsweise flying pilot und monitoring pilot, wie das mittlerweile heißt, dass das sich auch konstant abwechseln. Also nicht mehr, dass ich als der Flugkapitän mit meinen, was weiß ich was, Jahrzehnten Berufserfahrung und tausenden von Flugkilometern, dass ich immer der bin, der fliegt, sondern dass eben auch halbe-halbe, fifty-fifty, mein Co-Pilot fliegt als der, der wirklich aktiv liegt und ich als Kapitän, als der Erfahrenere, bin ich dann der monitoring pilot und im Grunde habe ich in den Kontext dann mal die Aussage gehört, wenn der Co-Pilot fliegt, dann ist der Flug sicherer. Warum? Weil der erfahrenere Pilot der monitoring pilot ist und immer noch im Zweifelsfall eher eingreift speziell, und ich könnte mir vorstellen, so ein bisschen klang es bei Ihnen auch an, wenn es kulturelle Unterschiede gibt, und da gibt's wirklich auch Fälle, da gibt interessante Bücher darüber, wo eben ein starkes Hierarchiegefälle da ist, Sie nannten Frankreich, das ist ein Aspekt oder zum Teil auch asiatische Kulturen, wo ein Co-Pilot sich richtig schwer tun würde, den Piloten, dem Flugkapitän zu widersprechen, wenn der flying pilot ist und da gibt's wirklich einen Fall, wo das halt dann traurig ausgeht. Und ich könnte mir vorstellen, dass das hier ähnlich ist, also ich habe da spontan unheimlich viel Ähnlichkeiten rausgehört zu einer Unterhaltung, die ich halt mal mit einem Flugkapitän hatte zu so einem Thema Fehlervermeidung im Cockpit.

Nils Kasseckert: Klar. Aber das, was Sie jetzt gerade sagten, passt genau, also wusste ich jetzt auch nicht, aber das ist genau das, was Sie meinten, also beim Pair Programming ist es so, dass jetzt nicht einer den ganzen Tag programmiert, sondern man wechselt sich auch ab. Die Hälfte der Zeit programmiert der eine auf seinem Rechner und der andere guckt zu und überwacht und dann es andersrum, ist im Endeffekt dasselbe.

Götz Müller: Ja, vielleicht wäre es mal interessant, wenn sich zwei, in Anführungszeichen, nicht so vertragen, denen dieses Thema Crew Resource Management mal vorzustellen und zu sagen: „Hey, da gibt's Leute, die können im Schlaf fliegen und die machen das trotzdem, guckt mal, ob es nicht vielleicht doch eine gute Idee wäre.“

Nils Kasseckert: Da haben Sie recht, ja. Also guter Punkt.

Götz Müller: Ja, okay. Gut, und was ich aber eben auch rausgehört habe oder vielleicht auch nur reininterpretiert habe, dieser Aspekt eben auch, ja, Probleme offenzulegen, mal bereit zu sein, zu sagen „Hm, verstehe ich nicht, erklär's mir auch.“, voneinander auch zu lernen eben.

Nils Kasseckert: Richtig. Also das ist halt so ein Kultur-Aspekt wieder. Also Ziel des Pair Programm ist ja, dass man gegenseitig lernt, wie man es jetzt bei diesem Flugzeugkapitän sieht, ist ja auch das Ziel, dass der Co-Pilot auf Dauer genauso viel kann wie der Pilot oder der Kapitän, was ist ja bei diesem Pair Programming auch so ist. Also der Kunde macht das ja, damit im Endeffekt zwei Entwickler mindestens genauso gut funktionieren und sind und aber wenn jetzt diese Kultur nicht da ist und derjenige nicht fragt, wenn etwas unklar ist, das war bei mir im Team so, man hatte richtig das Gefühl, der andere versteht gerade nicht, was man gerade macht und was man von ihm will, dann ist das schwierig. Und aber was man auch sagen muss, es muss einem selbst auch liegen, also man muss auch selber so ein, ja, fast schon ein Helfersyndrom, kann man sagen, haben. Man muss den anderen halt auch was lernen wollen, also es gibt durchaus Leute, die wollen, das ist besonders bei uns in der Entwicklung sind da solche Leute, die sich am liebsten so im Keller einsperren, nur ganzen Tag programmieren, also so etwas, was man als klassischen Informatiker kennt und wenn man auf einmal denjenigen hinsetzt und der wie ein Lehrer agieren muss, das liegt halt echt nicht jedem, das muss man auch sagen.

Götz Müller: Ja, das kann ich absolut nachvollziehen und da kommt mir dann noch ein zweiter Aspekt in den Sinn, wo Mike Rother, das ist jetzt jemand, der im Lean-Kontext eine gewisse Stimme da hat, er hat gesagt, lernen ist unbequem, weil ich ja etwas noch nicht kann und das jetzt lernen muss. Und ich bin persönlich noch einen Schritt weiter gegangen und ich glaube, das bestätigt das beziehungsweise das, was sie gerade gesagt haben, bestätigt es total, auch Lehrer sein in so einer Situation, ist oder kann unbequem sein, weil ich nämlich jemand anderem jetzt etwas beibringen muss und ich merke, das ist für den unbequem und ich muss ja im Grunde das verändern, was ich ihm sage, weil das, was ich ihm vorher gesagt habe, aus welchen Gründen auch immer so bei ihm nicht ankam. Das heißt, ich muss mich selber ändern als Lehrer.

Nils Kasseckert: Richtig, genau richtig und dann kommt dann bei einem selber auch noch Frustration auf, warum er das denn jetzt immer noch nicht versteht und halt auf der anderen Seite, also ich war halt in einem Unternehmen, wo es ein sehr starkes Hierarchie-Gefälle gab, ich war da als Junior-Entwickler und wenn da der Junior-Entwickler dem Expert-Developer erzählt, wie er jetzt zu programmieren hat, ist das halt auch so eine Sache durchaus.

Götz Müller: Ja. Das ist dann so wie der Erstflug des Co-Piloten neben jemandem, der schon 20 Jahre Erfahrung auf der Maschine hat.

Nils Kasseckert: Richtig, genau. Obwohl man durchaus in diesem Gebiet mehr Erfahrung hat, aber das ist halt, ja.

Götz Müller: Ja, das kann ich absolut nachvollziehen, ich entsinne mich da gut an eine persönliche Situation, irgendwann mal vor, das ist bei mir jetzt auch schon im Grunde mehr als ein Jahrzehnt, weit mehr als ein Jahrzehnt her, wo ich halt auch festgestellt habe damals, dass ein Hochschulabsolvent in dem Kontext halt, Software, Technik, Technologie Sachen an der Hochschule gelernt, die ich halt damals 20 Jahre vorher oder so, und ich habe gar kein klassisches Informatik-Studium, sondern ich war halt Elektroingenieur oder bin Elektroingenieur, das habe ich nie gelernt. Und dann ist mir aber bewusst geworden, hey, es gibt aber andere Dinge, und für die, die mich jetzt vor dem geistigen Auge haben und meine nicht mehr vorhanden Haare sehen, die wissen, ein paar Sachen halt mit zunehmender Lebenserfahrung typischerweise eher zu nehmen und dann baut man halt darauf.

Nils Kasseckert: Richtig.

Götz Müller: Und akzeptiert, dass man von dem Jüngeren etwas lernen kann.

Nils Kasseckert: Genau, genau richtig. Aber dieses akzeptieren, was Sie da meinten, das muss halt da sein.

Götz Müller: Das muss da sein. Ich glaube aber ein Stück weit, dass man, wenn man darüber redet, nicht, dass man es verordnen kann, aber ich glaube, man kann auf eine gewisse Art und Weise ein Bewusstsein auch dafür schaffen. Es ist dann immer noch eine persönliche Entscheidung von jedem einzelnen, ob er es nachvollziehen kann oder will, aber ich denke, einen gewissen Einfluss, glaube ich, kann man schon ausüben.

Nils Kasseckert: Ja, richtig. Also wir hatten das bei uns dann auch, darüber offen da gesprochen, aber für uns war dann das Problem, dass die Einzelnen halt sich dann entschieden haben, einzelne Probleme halt nicht offen anzusprechen oder halt nur untereinander und das ist dann halt wiederum schwierig, aber ich habe das dann in jedem Kontext, so nur halt im Pair Programming fällt es halt noch mal mehr auf.

Götz Müller: Ja. Und da entsinne ich mich jetzt aber an eine Situation, an einen Artikel, den ich gerade gestern gelesen habe, auch in einem asiatischen Umfeld, da haben sich die Mitarbeiter unheimlich schwer getan, wenn deren, ich nenne es mal ein bisschen flapsig, Oberhäuptling dabei war, und der Berater in den Kontext hat es glücklicherweise wahrgenommen und dieser Häuptling war im Grunde nur da, weil er zweisprachig war und weil er gleichzeitig als Übersetzer fungiert hat, ist sich aber selber gar nicht bewusst gewesen, dass das seine Mitarbeiter aufgrund der kulturellen Randbedingungen halt praktisch verhindert hat, dass die ihm widersprechen beziehungsweise fast schon überhaupt irgendwelche Äußerungen machen und der Beraterkollege, der das wahrgenommen hat, hat halt dann einen Trick angewendet und sich einen anderen Übersetzer gesucht und plötzlich war das eine offene Diskussion.

Nils Kasseckert: Genau, sowas kann ich von mir auch berichten, genau.

Götz Müller: Ja, das ist dann halt wieder, sagten Sie ja auch schon aufs Management kommt es halt ein Stück weit auch an.

Nils Kasseckert: Aber es ist dann auch immer so eine Frage, was kann das Management machen, also Menschen ändert man nicht so schnell, das ist halt dann schwierig. Also da bleibt dann nur eigentlich nur dieses Pair Programming mit anderen Leuten dann durchzuführen, aber viele andere Möglichkeiten gibt's dann meistens nicht.

Götz Müller: Gut, jetzt könnt ich mir vorstellen, der ein oder andere fragt sich vielleicht noch, jetzt haben wir ein bisschen einen Ausflug gemacht, ja, was habe ich jetzt denn davon, und vielleicht da noch mal eine Abrundung, einerseits ist es aufwendiger, klar, es hocken ja zwei drin, aber es entsteht nicht doppelt so viel Code.

Nils Kasseckert: Ja, richtig. Ganz greifbar ist auf jeden Fall die Verringerung von technischen Schulden. Also man kann sagen, während der Entwicklung, egal welcher, treten immer Schulden auf. Das heißt, man entwickelt etwas, dann kommt dann noch jemand, will dann doch noch diese Änderung haben oder man war jetzt nach dem Mittagessen ein bisschen abgelenkt und hat da auf einmal etwas nicht so schön eingebaut, das sind dann alles technische Schulden. Das heißt, das ist Code, der schlecht wartbar ist und der halt auch instabil ist, vielleicht sogar Fehler enthält. Wenn da zwei Leute draufgucken, ist halt die Wahrscheinlichkeit für Fehler und schlechten Code niedriger und dadurch hat man wesentlich weniger Aufwand im Betrieb, Wartung, Fehlerkorrektur und Support. Erst recht, wenn man dieses Pair Programming mit dem automatischen Testen, also behaviour-driven Development kombiniert, dann hat man zum einen zwei Leute, die den Code kennen und zum anderen die Qualität des Codes durch automatische Tests abgesichert, weil die automatischen Tests kann man ja immer wieder ausführen, die haben immer wieder dasselbe Ergebnis. Dadurch spart man sich das, was man am Anfang reinsteckt auf Dauer dann wieder für die Ganzen anderen Sachen wieder ein und natürlich kommt dann daraus stabilere Software, und wenn man wenig Probleme mit der Software hat, wenig Fehler, wenig Support braucht, dann ist natürlich auch der Kunde wesentlich zufriedener.

Götz Müller: Ja, genau. Und halt der Aufwand als sich, zum Beispiel auch in einem Support wird halt einfach kleiner.

Nils Kasseckert: Richtig, genau. Das ist ja, was ich meinte, und halt keine Fehlerkorrektur mehr, also bei mir in dem Team oder für das Produkt, was wir gemacht haben, konnten wir unsere Support-Aufwände um 80% reduzieren.

Götz Müller: Das ist ja, glaube ich, nicht zu unterschätzen.

Nils Kasseckert: Richtig, diese Kosten werden nach vorne verlagert und können dadurch auch noch reduziert werden. Also prinzipiell ist das nicht schlecht.

Götz Müller: Gut. Zum Abschluss noch ein Punkt, den ich mir, bei dem ich auch hängengeblieben bin bei ihrem Artikel und da halt ein Begriff verwendet wurde, der jetzt im Lean-Kontext sehr häufig verwendet wird, nämlich das sogenannte, bei Ihnen hieß es Pull Request und da sind natürlich bei mir sofort alle Lampen Richtung Pull-Prinzip angegangen. Vielleicht erzählen Sie da an der Stelle noch ein bisschen drüber, weil ich glaube, dass schon, oder zumindest habe ich das so rausgelesen, absolut nicht nur der Begriff an sich, sondern sehr ähnliche Gedanken auch dahinterstecken.

Nils Kasseckert: Ja. Also beim Pull Request ist es so, man entwickelt Coding, entweder alleine oder zu zweit, und dieses Coding entwickelt man ja natürlich nicht auf dem, also direkt in der Anwendung, sondern in einem separaten Kontext. Das macht man meistens mit Git. Das heißt, man hat einen Masterbranch, der auch dann in Produktion geht und man hat dann verschiedenste Subbranches. Ein Branch ist dann sozusagen für einen Feature zuständig. Also man kann sich vorstellen, ein Branch ist im Endeffekt eine Snapshot von dem Projektstand, an denen kann man dann arbeiten und dann, wenn man dann fertig ist, kann man den dann in das richtige Projekt integrieren und diese Integration finde durch ein Pull Request statt. Sprich, man tut in diesen System, was man auch immer dann nutzt ein Request aufmachen und sagt, das habe ich jetzt entwickelt, jetzt kommen andere Leute, also jetzt im Kontext von Pair Programming sind das die anderen Pairs und gucken sich diesen Code an, damit hat man das Ganze, dass niemand auch Code in das Produkt integrieren kann, ohne dass andere davon wissen und man hat auch wiederum seine Qualität erhöht, weil dann hat man nicht nur vier Augen, die auf diesen Code schauen, sondern im Team vielleicht insgesamt zehn Augen und dann kann jeder dazu Feedback geben. Über das Feedback wird dann offen gesprochen diskutiert, ob das sinnvoll wäre, diese Änderung, und nur, wenn der Code auch den Qualitätsanforderungen entspricht, erst dann wird er in das Hauptprodukt integriert. Und während dieses Pull Requests kann man natürlich auch noch andere Sachen, wie automatische Sicherheitsprüfungen, oder anderes integrieren.

Götz Müller: Ja, und ich habe da eben auch rausgehört, und in meinem früheren Leben, wie gesagt, war das oft eben nicht so, da ist nicht inkrementell vorgegangen worden, sondern da hat man ein halbes Jahr lang, dreiviertel Jahr lang, in Anführungszeichen, vor sich hinentwickelt und dann ist über Nacht auf einen Knopf gedrückt worden und dann integriert und so weiter, und dann ging erstmal hinterher gar nichts mehr. Und das habe ich rausgehört, rausgelesen, dass mit diesem gezielten „Ich hol mir da was und bau das dann gezielt ein“, eben vermieden wird, dass man von einer Code-Welle überrollt wird und im Grunde genau die gleichen Effekte auftreten, wie in der klassischen Produktion, dass dann alles schlagartig überlastet sind und dann auch wieder Fehler auftreten.

Nils Kasseckert: Richtig genau. Das Ziel von so einem Pull-Request ist eigentlich nur auf eine einzige Funktionalität zu schneiden, also das soll eigentlich nur eine einzige Funktionalität integrieren und wenn man jetzt eine neue Funktion baut, dann macht man wieder einen neuen Branch und man geht eigentlich schon fast soweit, dass man sagt, ein Branch sollte man vielleicht nur 24 Stunden lang lassen und dadurch, dass, was Sie jetzt gerade meinen, man halt nicht diesen großen Berg vor sich herschiebt oder so, halt man halt relativ kleine inkrementelle Änderungen. Das tut man ja meistens in der Software-Entwicklung mit Scrum oder ähnlichem kombinieren, was ja da diese aktuellen Prozesse sind und dadurch hat man kleine Änderungen, kann auch dann direkt sehen, was sind meine Auswirkungen, und natürlich noch wesentlich mehr, also was Sie jetzt meinten, ein halbes Jahr dann auch etwas entwickelt und dann mal schauen, was jetzt passiert, wir hatten es dann so, dass wir eigentlich täglich geliefert haben, also wir haben täglich eine neue Version an den Kunden geliefert, was halt sonst undenkbar wäre.

Götz Müller: Ja, und ich schlage eben mehrere Fliegen mit einer Klappe, einerseits kriege ich ein sofortiges Kundenfeedback, andererseits, wenn der Kunde dann sagt „Jetzt brauche ich hier noch ein kleines Feature“, dann muss ich halt nicht das nächste halbe Jahr abwarten, wenn ich gerade vorgestern das Release gemacht habe, sondern ich kann sie ihm im Grunde am nächsten Tag, in der nächsten Woche schon liefern und sagen: „Guck mal, ist das das, was du dir vorgestellt hast?“
Nils Kasseckert: Richtig, genau. Richtig. Und wenn man das jetzt noch mit behaviour-driven Development integriert, wo man dann direkt das mit dem Kunden durchspricht, dann Pair Programming hat, dann ergibt es ein ganz rundes Bild und dann hat man eine saubere Software.

Götz Müller: Ja, prima. Also ich fand das jetzt eine echt coole Unterhaltung, einerseits weil es mich an mein früheres Leben erinnert hat, und andererseits, weil ich aber definitiv nicht davon enttäuscht worden bin, was ich so an Ähnlichkeiten rausgelesen habe, und im Grunde waren es sogar noch mehr Dinge, deshalb Herr Kasseckert, ich danke Ihnen für Ihre Zeit, für die interessanten Einblicke und, ja, ich möchte sogar noch weitergehen, für gewisse, bei mir zumindest, gewisse Erleuchtung.

Nils Kasseckert: Ich danke Ihnen auch und ich hatte auch ein sehr angenehmes Gespräch.

Götz Müller: Das war die heutige Episode im Gespräch mit Nils Kasseckert zum Thema Qualitätsmanagement in der Software-Entwicklung. Notizen und Links zur Episode finden Sie auf meiner Website unter dem Stichwort 254.

Wenn Ihnen die Folge gefallen hat, freue ich mich über Ihre Bewertung bei iTunes. Sie geben damit auch anderen Lean-Interessierten die Chance, den Podcast zu entdecken.

Ich bin Götz Müller und das war Kaizen to go. Vielen Dank fürs Zuhören und Ihr Interesse. Ich wünsche Ihnen eine gute Zeit bis zur nächsten Episode. Und denken Sie immer daran, bei allem was Sie tun oder lassen, das Leben ist viel zu kurz, um es mit Verschwendung zu verbringen.