Geekstammtisch

Synopsis: Wir hatten dieses Mal Stefan Schiffer (@scrat0105) zu Gast. Er berichtet von dem doch sehr radikalen Wandel seines Arbeitgebers: Von On-Premise zu SaaS und Cloud, von Wasserfall-Prozessen hin zu Agiler Softwareentwicklung und von .NET & Windows zu Ruby & Linux. Stefan erzählt, woher der Wandel kommt und wie er den Wandel von Anfang an miterlebt hat.

• Kurz in eigener Sache
  • opus-Feed: http://geekstammtisch.de/episodes.opus.rss
  • Rheinklick: Die digitale Offensive des Kölner Stadt-Anzeiger rund um die Kölner Tech-Szene
  • der Geekstammtisch beim Rheinklick-Blog: http://www.ksta.de/rheinklick/podcast-des-geekstammtischs-gruende--in-koeln-zu-gruenden,22789250,23728778.html
  • Wir sind auf dem Railscamp

• Stefan Schiffer: @scrat0105, https://www.xing.com/profiles/Stefan_Schiffer8
• hört gern denn Geekstammtisch <3
• hat mit Dirk und Basti Medieninformatik an der FH Köln studiert
• wollte immer in Richtung UX
• macht seit ~2 Jahren Rails
• explizite Stellen für Interaction Design sind eher unüblich

• Stefan arbeitet bei InVision AG: http://www.invision.de
• InVision ein solides mittelstänidges Unternehmen aus der klassichen B2B On Premise Welt
• Jetzt allerdings radikaler Wandel: Weg von On Premise hin zur Cloud und zu SaaS
• InVision stellt Software für die Personaleinsatzplanung wie etwa Personal-Forecasting her
• Vor 3-4 Jahren kam die Erkenntnis, dass man sich technologisch modernisieren muss
• War mit der damaligen Software schwierig bis unmöglich
• Daher war eine Schnitt unvermeidbar
• InVision ist kein Startup
• Mittlerweile hat sich eine "Startup-Mentalität" eingestellt
  • Von Individualsoftware hin zu webbasierten Diensten
  • Das UX-Team kommt hier viel besser zum Einsatz
• Vorher gab es eine C#/.NET-basierte Lösung mit viel lizensierter Drittanbietersoftware
• Das neue, Rails-basierte Produkt ist noch nicht in Gänze live
• Das Ziel ist, dass das neue Produkt das alte irgendwann ablöst
• Die alte Software lebt nun auch in der Cloud und wird weiterhin betrieben
• Diese Lösung ist auch schon als Saas verfügbar
• Neue Kompotenten greifen auch noch teilweise auf die alte Software zu
• Bestandskunden wechseln nach und nach auf die Cloud-basierte Variante
• Vor allem sehr große Kunden sind noch auf der On Premise Version
• Die Cloud der Wahl ist AWS (inkl. Windowsserver für die alte Umgebung)
• Kunden, die die On Premise Lösung einsetzen können bereits auf neue Clouddienste zugreifen
  • Beispiel dafür ist das Cloud-basierte Forecasting, was bereits jetzt einen Mehrwert bietet
  • Bedingt dadurch hat man nicht nur einmalige Migrationen von Altdaten, sondern auch eine konstante Verbindung zwischen den Systemen
• 80% der Entwickler arbeiten auf dem neuen System, 20% arbeiten an der Pflege des Altsystems
• Entwicklung findet an drei Standorten statt (Derry/Londonderry, Ratingen, Leipzig)
• Jeder Standort hat mehrere Teams für unterschiedliche Komponenten der Software
• Neben den Entwicklungsteams, gibt es noch Service-Teams für UX und Technical Writing, die allen Teams zur Verfügung stehen
• Es gibt ein Operations-Team in Derry/Londonderry und es wird ein DevOps-Team in Ratingen aufgebaut
• 50-60 Menschen in der Produktentwicklung

• Was war der Auslöser für den radikalen Wandel?
  • Technologische Erweiterbarkeit war nicht mehr gegeben
  • Zwei Möglichkeiten: Entweder radikal aufräumen, oder von Vorne anfangen
  • Man war von der Cloud und ihren Möglichkeiten für den Anwendungsfall überzeugt
• Erst kam der Switch zur Cloud und erst danach der Wechsel der Technologie
• Gleichzeitig mit der Technologie wurde der Entwicklungsprozess und die Unternehmensstruktur radikal geändert
• Wichtig war, dass die Unternehmensführung zu 100% dahinter steht
• Ja, es sind Leute auf der Strecke geblieben: Es sind mehr Leute gegangen als die normale Fluktuation
• Die Änderung der Unternehmensstruktur war im Nachgang eine Bedingung für den neuen Prozess
• Mitarbeiter müssen Verantwortung übernehmen
• Vorteil: Fachwissen gefestigt, Probleme bekannt und weitestgehend gelöst, Kundenstamm vorhanden
• Nachteil: Niemand kannte Rails, niemand war firm in agiler Softwareentwicklung
• Zu Beginn Scrum nach Lehrbuch inkl. externen Trainings
• Heute wird Scrum nicht in Reinform gemacht, was die typische Entwicklung ist

• Schwerfällige Entwicklung
• Automatisiertes Testing nur sehr schwer möglich
• In der C#-Welt ist Open-Source nicht sehr populär
• Entscheidung für Rails ist eher spontan gefallen
  • Prototypen wurden mit Rails erstellt und das Vorgehen hat überzeugt
  • Danach hat man sich entschieden, dass man einfach weiter darin arbeitet und die Prototypen noch mal neumacht
• Lizensierung und deren Kosten ein tatsächliches Problem
• Kosten für die Server in der Cloud waren auch ein Problem
• Herausforderungen beim Umstieg auf Rails war vor allem zu lernen was es bedeutet Web-Anwendungen zu schreiben
• Ansonsten die üblichen Probleme: Neue Sprache, neues Framework, neues Paradigma
• QA musste lernen Tests zu schreiben
• Keine IDE mehr, sondern arbeiten mit Texteditor und CLI, vor allem durch den "Wegfall" des Debuggers
• "Ich kann gar nicht mehr debuggen"
• Zudem kam auch noch ein Wechsel des Betriebssystems ^^
• Man musste auch lernen wie man deployed und Server provisioniert
• Jenkins zur Realisierung der Deployment-Pipeline
• Provisionierung der Server mit Chef
• Genutzte Dienste von AWS: Vor allem EC2, ELB und S3
• DB wird selber auf EC2 gehostet
• Basti weist mal wieder darauf hin, dass AWS sich nur lohnt, wenn man es richtig nutzt und automatisch provisioniert
• Stefan erzählt, dass sie am Anfang EC2 "nur" als Server in der Cloud gesehen haben und erst den richtigen Umgang lernen mussten
• Stefan meint, sie sind fast fertig, aber fertig wird man ja eh nicht
• Initiale Wissenslücke durch Trainings, Workshops und Self-Training geschlossen
• Man musste lernen, dass man seinen eigenen Code auch mal wegwerfen muss

• Während der Umstellung auf neue Technologien hat man sich die Frage gestellt, warum schreiben wir eigentlich Spezifikationen? Am Ende kommt eh nicht das raus, was der Kunde wollte?
• Die häufigste Antwort auf diese Fragen war: Im besten Fall war es überflüssig, aber in der Regel hat es Nachteile gebracht.
• Und was ist eigentlich dieses Scrum?
• SaaS eignet sich perse nicht für Wasserfall, man muss viel schneller reagieren können
• Man hört ganz anders auf die Kunden: Nicht mehr der einzelne zählt, sondern der Bedarf des Marktes
• Dadurch musste auch der Produktbereich umlernen bzw. überhaupt aufgebaut werden
• Entscheidungen über Produktänderungen werden vor allem in den einzelnen Teams getroffen
• Am Anfang war es schwierig ein Produkt ohne echte Kunden zu entwickeln
• Die Lücke musste durch internes Know-How geschlossen werden
• Das machte auch Reviews schwierig
• Mittlerweile haben alle Teams den selben Sprint-Rythmus und machen ihr Review gemeinsam in einem Conference-Call
• Stefan ist zufrieden mit dem Transformationsprozess
• besondere positive Aspekte, der Mehrwert der Umstellung
  • direktes und schnelles Feedback
  • worst-case werden nur 1-2 Sprints an Zeit "weggeworfen"
• Retrospektiven werden noch etwas stiefmütterlich behandelt
• Teams arbeiten sehr eigenverantwortlich
  • jedes Team betreibt ihre eigenen Komponenten/Module
  • organisieren selbst Urlaub im Team
• Standortübergreifende Kommunikation ist eine Herausforderung
  • Module, die enger zusammenarbeiten und direkte Abhängigkeiten haben, sind nach Möglichkeit am selben Standort angesiedelt
  • Ausnahme, das UX Team: Das Team ist verteilt und unterstüzt die anderen Teams
• Technologie/Architekturentscheidungen werden in einer Art Architekturboard getroffen, nachdem es Vorschläge und Bewertungen aus dem jeweiligen Team gab.

• "Technische Schulden" hat jeder, egal wie jung oder alt ein Projekt ist
• Es gibt ein paar Regeln, wie mit Technical Depts umzugehen ist:
  • erst kommen Bugs, dann Technical Depts und dann User Features
• interne gems, werden von den Teams wie externe Dependencies verwendet (mit Pull Requests, Forks usw.)
• dadurch, dass alle Teams quasi eigene Rails Apps entwickeln, sind die Teams relativ unabhängig von Entscheidungen, wie erb vs HAML oder CSS/SCSS/…
• mitlerweile wird nur noch HAML benutzt: http://haml.info/

• Andauernder Learnprozess, viele Fehler, viel gelernt
• Zusammen mit dem technischen Wandel gab es auch einen starken "kulturellen" Wandel
  • neuer Entwicklungsansatz, neue Motiviation gute Qualität abzuliefern
  • Collective (code) Ownership: http://www.extremeprogramming.org/rules/collective.html
  • ständier Lern- und Verbesserungsprozess

• Die bisherige On-Premise-Lösung war nicht Service-orientiert
• Jetzt geht es schon mehr in diese Richtung
• z.B. gibt es ein zentrales User-Management (Service)
  • API spricht JSON via HTTP
  • wird bereitgestellt durch gems
• Services/Module haben ihre eigenen Datenbanken

• Wir sind beeindruckt von dem doch radikalen und positiven Wandel, den Stefan beschrieben hat
• Wir sind uns einig, dass ein ganzheitlicher Ansatz am erfolgversprechendsten ist
• InVision sucht noch Entwickler und vor allem Leute, die DevOps machen wollen
• Basti hat eine Mail mit Jobangebot bekommen, worin mit einem Foto von Clubmate im Kühlschrank geworben wurde :)
• Mate gibt es bei InVision noch nicht, aber es wird gegrillt (reicht nicht ganz ^^)