In unseren Berufsalttag entwickeln wir eine Software. Wir erzeugen kein Gegenstand, sondern verrichten eine Tätigkeit, also ein Prozess, bei dem was hergestellt wird. Dabei ist es sehr wichtig sich auf dem Prozess und auf das Produkt zu konzentrieren. Kein Kunde wird sich freuen wenn sein Produkt nicht genau das leistet was er erwartet hat, oder wenn er das Produkt nicht rechtzeitig ausgeliefert bekommt.Erfreulicherweise haben sich viele kluge Köpfe, schon vor langer Zeit, darüber Gedanke gemacht, wie man Software mit guter Qualität herstellt, und diese Erkenntnisse in sogenannte Methodologien festgehalten.

In der Realität schaut das anders aus, und zwar – die meisten Entwicklungsteams kommen kaum auf diese Erkenntnisse und Informationen. Für die meisten Teams ist ein Prozess ein banaler Gedanke, oder etwas was vom Management oder Vorstand aufgedrückt wird. Unter einer Methodologie stellen sich die meisten lange Konferenzen und viel Papier-Kram vor. Oft werden Methodologien von Managern aufgesetzt und Manager müssen oft einen Prozess verfolgen. Dabei handelt es sich um Prozesse die in den 80er definiert worden sind und in der heutigen Zeit nicht mehr passen. Diese alten Prozesse werden einfach neu aufbereitet, werden mit diversen Mode-Wörtern wie „agil“ aufgepeppt und an das Team aufgedrückt. Das lustige daran ist, dass neu angehende Manager die aus dem Team stammen, oft diese Prozesse einfach übernehmen und das ohne sie zu hinterfragen.

Doch es gibt bessere Wege für Teams gute Software zu entwickeln. Man arbeitet in Team vermutlich als Software-Designer, Programmierer oder Tester und man denkt, dass der Entwicklungsprozess nicht in seiner Verantwortung liegt. Das stimmt auch – für den Prozess ist leider niemand zuständig. Soll aber ein neues Entwicklungsprozess im Unternehmen erfolgreich implementiert werden, dann kann das nur der implementieren der ihn auch anwendet und versteht – also der Programmierer.

Nun, stellt sich die Frage: Wie spürt man die Verantwortung über einen Prozess? Die Antwort ist: Man hilft bei der Implementierung diesen Prozesses in eigenen Unternehmen bzw. Team. Wenn das Unternehmen keinen klaren Prozess anwendet, dann findet man heraus welche Methodologien für das Unternehmen passen würden. Also: KANBAN, SCRUM, V-Modell, Testgetriebenes-Entwickeln oder sonst was. Dafür diskutiert man am besten mit dem Team über die aktuellen Entwicklungsprobleme und Möglichkeiten, sie durch Übernahme eines Standartprozesses zu beseitigen. Danach erstellt man alleine oder besser mit dem Management einen Plan auf, um den gewählten Prozess in Unternehmen einzuführen. Dafür ist wichtig, dass man von jedem Teammitglied die Bereitschaft zugesichert bekommt, bei der Umsetzung des Plans, mitzumachen.

Es steht eine Vielzahl an Methodologien zur Verfügung. Trotzdem wird man nie ein Unternehmen vorfinden, das diese vollständig implementiert hat. Ja, das ist vollkommen in Ordnung! Der beste Prozess ist immer der, der das Team am produktivsten macht und die beste Software ausliefert. Es ist also möglich zwei Prozess-Typen zu finden. Dabei ist es wichtig, einzelne Komponenten auszuwählen, die in Team sinnvoll zu sein erscheinen, und fortlaufend anhand der Erfahrung zu verfeinern.

Letztendlich kann man, wen man den Prozess nicht beherrscht, das Produkt nicht herstellen. Kenntnisse über den Software-Entwicklungsprozess sind in diesem Fall nützlich. Denn, es ist viel einfacher jemanden zu finden der eine Software erstellen und zu laufen bringen kann, als jemanden zu finden, der den Prozess der Erstellung von Software erfolgreich im Unternehmen implementieren kann.

Wie sieht ihr das? Welche Erfahrungen habt ihr gemacht? Schreibt mir. Ich würde mich sehr freuen.