Die Zeit steht
niemals still!

Teil 2

Die Geschichte von GMS. GMS beschleunigt die Softwareentwicklung und fordert so den Mitbewerb.

Von Ulrich Hutter

Delphi war damals eine reine Windows Programmiersprache und für das Web nicht geeignet. Somit wurden die ersten Web-Produkte von GMS in PHP geschrieben – heute noch eine der am meisten verbreitetsten Sprachen der Welt. 

Codename IDUN 

Die GMS Teams wurden größer und immer besser. Unser Unternehmen steht für flache Hierarchien, jeder kann und darf sich einbringen. So kamen einige von unseren Mitarbeitern die Idee, ob wir uns nicht mal Ruby on Rails ansehen sollten. Mit RoR waren damals bereits AirBNB, Groupon, GitHub und viele andere führende Programme geschrieben worden. 

So starteten wir im Jahre 2010 ein großes Projekt mit Codenamen IDUN. Wir nutzten alles, was die modernste Softwareentwicklung im Silicon Valley zu bieten hatte. Wir besuchten viele Kurse und lernten so auch komplett neue Konzepte der Software Entwicklung wie die „Agile Entwicklung“. 

Agile Entwicklung ist seit Jahre DAS Konzept in ALLEN IT und Softwarefirmen der Welt. Einige beherrschen es perfekt wie beispielsweise Netflix oder Spotify. Bei vielen anderen Firmen, behaupte ich mal, schreibt das Management „Agile“ in ihre Marketing Unterlagen und in Wirklichkeit arbeiten sie nach uralten Methoden. 

Was bedeutet „Agile“? 

Hier gibt es viele theoretische Modelle wie Extreme Programming, Scrum, Kanban und viele mehr. Die Basis war das Agile Manifest der Softwareentwicklung https://agilemanifesto.org/iso/de/manifesto.html 

Wir haben schlichtweg einfach mal viele ausprobiert, um das für uns passende Modell zu finden. Wichtig war uns: das Modell darf nicht starr sein und MUSS sich immer weiter optimieren und verbessern – das ist ein Grundprinzip der agilen Softwareentwicklung. 

Versuch Nr.1 mit Extreme Programming  

Der wichtigste Ansatz ist hier, dass zwei Programmierer an EINEM Computer sitzen mit nur EINER Tastatur. Alle Manager schreien jetzt natürlich auf und sagen, „dann hat man nur noch die halbe Arbeitskraft und das sei Wahnsinn!“. In Wirklichkeit hat man jedoch den Vorteil, dass es mindestens zwei Personen gibt, die sich mit dem Source Code auskennen und sollte mal einer auf Urlaub sein oder ausfallen, so kennst sich der andere genauso gut aus. Der nächste große Vorteil ist, dass man sich als Programmierer nicht „verrennen“ kann. Manchmal ist die Lösung nämlich super einfach oder ein Bug wäre nur ein „;“ an einer anderen Stelle. Als Einzelperson sucht man Stunden oder Tage nach dem Fehler oder entwickelt in die vollkommen falsche Richtung. Beim PairProgramming passt das nicht. 

2012 haben wir dieses Konzept mit drei Teams ausprobiert. Die Vorteile waren genauso, wie sie von Beck, Cunningham und Jeffries behauptet wurden. 

ABER: Wir Programmierer sind jetzt keine „Dauerkuschler“. Dennoch ist in der modernen Softwareentwicklung Teamplay natürlich extrem wichtig. Der „einsame Wolf“, dem man in der Früh die Aufgabe unter der Türe durchschob und nach zehn Packungen Zigaretten kam das perfekte Ergebnis zurück, ist heute nicht mehr gefragt, dafür ist alles viel zu komplex geworden. Dennoch will man als Entwickler ein paar Stunden in Ruhe „coden“ und in seinen „Programmiertunnel“ abtauchen. Das geht mit PairProgramming selbstverständlich nicht. 

„Lasst uns Scrum probieren!“ 

Also nahmen wir uns als nächstes Scrum an. Sicher auch noch bis heute eines der besten Modelle in der aktuellen IT Welt. Scrum ist vor allem dann perfekt, wenn man ein großes Projekt mit klassischem Anfang und einem absehbaren Ende hat. Es gibt definierte Rollen für das Team. So sollten die Teams aus maximal zehn Personen bestehen, besser wären sogar sechs Teammitglieder, deren Rollen getauscht werden können. Über SCRUM gibt es viel Literatur, aber auf die im Detail einzugehen, würde hier den Rahmen sprengen. 

Nächster Versuch: Kanban 

Dann kam Kanban. Ein Modell, welches im Jahr 1950 von Kiichiro Toyoda für die Autoindustrie entwickelt wurde und Toyota zum größten Automobilkonzern der Welt machte. Hier geht es nun darum, dass nicht immer ein Chef von oben alles nach unten bestimmt, sondern dass jedes Team nur so stark ist, wie sein schwächstes Glied. Alle Mitglieder im Team dürfen und müssen mitbestimmen. Insbesondere müssen sie auch regelmäßig kommunizieren, was sie alles benötigen, um ihre Arbeit gut machen zu können. Detailliertere Informationen zum Kanban-Modell findet ihr klarerweise im Web.  

Wie haben wir das Modell nun bei GMS umgesetzt? 

Unser oberstes Prinzip ist eine offene Kommunikation mit flachen Hierarchien. Jedes Teammitglied ist wertvoll und hat eigene gute Ideen und darf diese auch umsetzen. 

Wir haben unsere Mitarbeiter in folgende Teams aufgeteilt: 

• Felix Windows Entwicklung 
• Felix Web Entwicklung 
• Kasse Zen Entwicklung 
• Topas Entwicklung
• Felix Support & Consulting 
• Kasse Support & Consulting 
• Topas Support & Consulting 
• Verkauf & Marketing 
• Management 

Hier erkennt man sofort, dass ein agiles Modell NICHT nur für die Programmierung sein darf. „Lasst mal die Entwickler agil werden…“ ist einer der größten Fehler von Software-Firmen. Sofern nicht die ganze Firma agil arbeitet, ist es mehr Schein als Sein. 

Ein elementares Element in der Agilität: die DAILYS 

Täglich gibt es ein Team Meeting. Klingt recht einfach, ist es aber nicht. Das Meeting darf NIE länger als 15 Minuten dauern und dient zur gemeinsamen Abstimmung. Inhalt: „Gibt‘s Fragen für heute? Braucht jemand Unterstützung? Klemmt es irgendwo?“
Das Daily darf NICHT dafür genutzt werden, dass sich zwei Teammitglieder ewig über ein technisches Problem unterhalten und die anderen sich inzwischen langweilen. Da es nur 15 Minuten dauern darf, erfordert es auch viel Disziplin, vor allem wenn Mitglieder einige Minuten zu spät kommen. Das ist natürlich sehr übel für ein Meeting. 

Am Anfang haben wir es bewusst als „Stand Up Meeting“ durchgeführt, d.h. alle physisch anwesenden Mitarbeiter treffen sich stehend in einem Raum. Für Remote-Mitglieder benötigt man selbstverständlich dann eine sehr gute Technik, damit diese sich dazuschalten können und nichts an Information verloren geht. In Summe, denke ich, hat es über ein Jahr gedauert, bis wir es perfektioniert haben. Heute sind bei dem Meeting alle Mitarbeiter aus der ganzen GMS Welt super pünktlich, halten sich an das Konzept und jeder stellt offen seine Fragen oder äußert seine Wünsche.  

Weiterer Teil unseres agilen Modelles: Teamplanungsmeeting (TP) 

Hier trifft sich das ganze Team alle ein bis vier Wochen. Das Intervall variiert je nach Team, Aufgaben und Schnelligkeit und von jedem Team selbst entschieden werden. Alle Erfolge und Misserfolge seit dem letzten Teamplanungsmeeting werden offen besprochen. Jeder sieht somit das „Große Ganze“ aus seinem Team und kann mitverfolgen, was und woran jeder gearbeitet hat. Auch Misserfolge werden offen angesprochen, denn aus Misserfolgen lernen wir am meisten! Fehler werden immer gemacht und diese dürfen nicht als nur negativ gesehen werden. Eine Fehlerkultur ist ganz wichtig. Gemeinsam werden sie besprochen und so versucht, Lösungen zu finden. Jeder darf und soll auch sagen, was ihm beim letzten TP gefallen bzw. nicht gefallen hat, was wir besser machen sollten und womit wir beispielsweise aufhören sollten. Durch diese regelmäßigen Verbesserungen entwickelt sich GMS im Team von Meeting zu Meeting immer weiter. 

Reviews = „Nicht schon wieder!“ 

In der Software Entwicklung ist einer der elementaren Bereiche das „Review“. Bevor ein Feature oder Bug zum Testen geschickt wird, MUSS ein zweiter Programmierer den Source reviewen. Er geht es gemeinsam mit dem Entwickler durch, versucht den Source zu verstehen und hinterfragt, was genau gemacht worden ist. Durch Reviews erhöht sich die Qualität in der Softwareentwicklung immens. Außerdem – ein großer Pluspunkt – wird das Wissen sofort weiterverbreitet. Natürlich gibts noch viele andere Details in unserer agilen Softwareentwicklung, dennoch möchte ich nun mehr zur Technik übergehen. 

Wie schon erwähnt: Bei GMS war und ist uns immer wichtig, moderne und passende Technologien zu verwenden. Jede Programmiersprache hat ihre Stärken. Man kann mit Delphi keine gute Webapplikation schreiben, man kann mit RubyOnRails kein Windows Programm entwickeln. 

Wichtiger aber, als die Vorliebe des Programmierers, ist die passende Technik zur gewünschten Aufgabe. Hierdurch wurde eine große Anzahl an Software-Sprachen und Frameworks bei GMS zur Anwendung gebracht. Aktuelle Anwendungen sind etwa Delphi 11.1, Ruby on Rails 6, PHP 7, Javascript, Angular, React und React Native. Mit dieser Vielzahl an Entwicklungssprachen ist aktuell JEDES Problem im IT-Bereich lösbar! Ebenso aktualisieren wir unsere Versionen regelmäßig, um unseren Kunden immer die neuesten und besten Technologien zu bieten. 

Ein elementarer Ansatz von GMS: „Microservices“.  

Dies ist eine Technik, in der man nicht „ein großes Programmmonster“ schafft, welches alles in sich vereint, sondern die Aufgaben in kleine Teile „schneidet“ und für jeden Teil ein eigenes Programm/Service entwickelt. Diese Programme kommunizieren über offene Schnittstellen miteinander. Nach diesem Prinzip arbeiten wir schon seit mehr als 20 Jahren. Heute machen das übrigens fast alle großen Softwarefirmen und ich glaube, diese Vorgehensweise haben sie sich alle von GMS geklaut. *Augenzwinker!*

2014 hat die sogenannte „Container Technik“ das Licht der Welt erblickt. Die Entwickler von GMS waren sofort begeistert und starteten mit Docker&Co. Wir waren sicher eine der ersten Firmen für Hotelsoftware und Kassensysteme in der Gastronomie, welche die Docker-Technologie produktiv in ihre Systeme übernahm. Es gab Anfangsschwierigkeiten, da diese Technologie eine komplett neue Welt darstellte, aber inzwischen kann man es sich nicht mehr vorstellen, wie es ohne wäre. Es vereinfacht unsere Micro-Service-Architektur gewaltig.  

Ab geht’s in die Cloud! 

Ab 2011 entwickelten sich die Cloud-Technologien extrem weiter und wir nutzten das für unsere Produkte immer intensiver. Folglich bauten wir unsere Rechenzentren in der Cloud maßgebend aus, lagerten viele Services ins Web aus. GMS Smart Order, die digitale Speisekarte, war das erste Cloud Native Produkt und das im Jahr 2011. Darauf sind wir sehr stolz. Natürlich waren wir der Zeit wieder weit voraus, obwohl alles komplizierter war im Gegensatz zu heute.  

Amazon Web Services & Serverless Technologie 

Heutzutage entwickeln wir mit Amazon Web Services viele unserer neuesten Techniken und sind dadurch auch mit den ersten „Serverless-Produkten“ an den Start gegangen. „Serverless Technologie“ ist aktuell das Modernste, was man in der Software Entwicklung machen kann. Eine super spannende Technologie! Man entkoppelt die komplette Grundlagentechnik (Server, Netzwerk, Betriebssystem, Webserver, …) und die GMS DevOps Teams können sich auf die Programmierung konzentrieren mit unendlicher Server Power im Hintergrund. Ganz gleich, ob fünf User oder 50.000 gleichzeitig arbeiten, das System ist immer gleich schnell. Insbesondere im Bereich der GreenIT ist dies ein elementarer Schritt, denn weltweit laufen viele Millionen Server die meiste Zeit im Leerlauf und verbrauchen nur unnötig Energie. Durch Cloud Services wie AWS und ServerLess-Programmierung wird wirklich nur Energie verbraucht, wenn auch Funktionen benötigt werden. Das ist großer Beitrag der IT zur Nachhaltigkeit auf unserem Planeten! 

Amazon Web Services bietet Unmengen an herausragenden und umfassenden Funktionen, die reibungslos und stets funktionieren. Plus: sie werden akribisch getestet. GMS verwendet bereits unzählige Funktionen wie Route53, Lambdas, S3, Infrastructure as a Code, Cloudformation, Cognito, AppSync, DynamoDB, CloudWatch, CloudTrail, cross mobile platform development, um nur einige zu nennen. 

Aktuell werden die Daten gerade zu den BigData Modulen transferiert, um Künstliche Intelligenz (KI) erweitert und Automatisierungen entwickelt. Deshalb, weil wir den Qualitätsanspruch haben, auch in Zukunft mit den modernsten Technologien zu arbeiten, damit unsere Produkte weiterhin die modernsten und effizientesten Softwarelösungen am Markt darstellen.  

Mit DevOps zu noch mehr Erfolg 

Ein weiteres elementares Konzept bei GMS nennt sich „DevOps“. Früher programmierten die Programmierer (Devs = Developer) etwas und gaben es den Technikern (Ops = Operator) weiter. Die kümmerten (oder ärgerten) sich in weiterer Folge. Wenn etwas nicht funktionierte, was natürlich vorkam, ging das ganze Prozedere von vorne los: zurück zu den Programmierern, die versuchten das Problem zu lösen und wieder weiter an die Techniker. Das ging viele Male so hin und her. 

Seit langem arbeiten wir nun in „DevOps“ Teams, d.h. Entwickler und Techniker arbeiten gemeinsam im Team und lösen die Themen zusammen. Das funktioniert weit besser. Beide „Welten“ haben den besseren Einblick und durch das Zusammenspiel ein sehr gutes Verständnis für den anderen Part. 

GMS praktiziert diese Teamarbeit nun beinahe zehn Jahre und meiner Meinung nach, sollte das heutzutage eigentlich jede moderne Softwarefirma so umsetzen. 

Testen, Testen und nochmals Testen 

Sehr wichtig in der Softwareentwicklung ist natürlich das Testen. Testen findet Fehler in Ablauf oder Funktionalität der Software. Der Vorgang des Testens ist aber nicht so einfach wie gedacht, sondern extrem schwierig. Der Programmierer selbst kann nur wenig selbst testen – wenn man eine Funktion tagelang schreibt, dann ist man so IN dieser Funktion drin, dass man sie immer SO testen wird, wie man sie geschrieben hat. Man wird kaum eine andere Bedienung ausprobieren. 

D.h. der Entwickler testet mal so weit, wie er es für sich kann. Dann wird es „greviewed“ von einem weiteren Programmierer und dann erst kommt es ins Q&A-(Quality and Assurance)-Center und wird dort intensiv auf Stein und Nieren geprüft. 

Sofern möglich, das hängt vom Feature ab, macht der Entwickler sogenannte „Source Code Tests“ – d.h. er schreibt Testfunktionen, welche automatisch die Funktion des Programms überprüft. Beispielsweise in dem einmal Standartwerte eingegeben werden und dann extreme Werte (z.B. unterste Grenze mit 0, Obergrenzen mit z.B. 9999999999999). Durch diese Source Code Tests wird gewährleistet, dass diese Funktion auch dann funktioniert, wenn später etwas geändert wird. 

Jeder kennt die Aussage „Seit dem Update ist der alte Fehler wieder drin“. Oft sind Kunden der Meinung, dass durch ein Update ein alter Fehler wieder ins Programm gekommen ist. Vor mehr als 15 Jahren ist dies wirklich immer wieder mal passiert, da ein Programmierer etwas falsch kopiert oder fehlerhaft in damalige „Versionskontrollsysteme“ eingespielt hat. GMS arbeitet mit einer vollautomatisierten CI/CD (Continuous Integration, Continuour Delivery) mit GitLab. Durch unsere Techniken sind diese Probleme heutzutage so gut wie ausgeschlossen. Allerdings kann sich durch eine Funktion eine Abhängigkeit in einer anderen Funktion ändern, wodurch der Kunde glaubt, ein alter Fehler sei zurück. 

Bei GMS sind die Testszenarien sehr komplex und deshalb hat das Q&A Team mindestens vier Mitarbeiter. Ein großer Bereich ist hier natürlich die Testautomatisierung. Ein Restroboter arbeitet alle Standardfunktionen der Hauptprodukte einmal durch, bevor es ausgeliefert werden kann. Hierdurch können genau solche „alten Bugs“ großteils vollautomatisiert verhindert werden. 

Wir lieben unsere DevWeeks! 

Bei GMS sind wir sehr stolz auch auf unsere „Developer Weeks“. Mindestens einmal pro Jahr kommen ALLE Entwickler aus ALLEN Teams an einem Ort physisch zusammen. Sie arbeiten gemeinsam an Projekten, hören sich Vorträge an, halten selbst Vorträge, tauschen sich über neue Technologien aus und haben – ganz wichtig – gemeinsam Spaß! 

Durch Corona sind diese Meetings leider zwei Jahre ausgefallen und alles blieb nur remote (was GMS natürlich schon seit mehr als zehn Jahren macht). 

Im Juni 2022 war es wieder soweit! Am schönen Katschberg im GMS eigenem Hotel trafen wir uns alle und haben wieder wegweisende Technologien definiert. Diese sind natürlich noch topsecret und davon werde ich dann in einem Jahr in einem weiteren Blog erzählen. Dann kann es der Mitbewerb ruhig lesen, da wir schon wieder viel weiter sind 😀 

Euer Ulrich 

Copyright Foto: gmfotografie