Autor: JIT

Micro Services – die Insider-Perspektive. Teil 1:

„WIR HABEN DIE LÖSUNG. FEHLT NUR NOCH DAS PROBLEM.“

Vierzehn Jahre als IT-Dienstleister – das macht etwas mit dir. Die Erfahrung wächst. Die naive Begeisterung für Hypes und Moden schrumpft. Gut so, denn IT ist ein Werkzeug. Nicht mehr und nicht weniger. Und der Wert neuer Werkzeugdesigns misst sich an den Problemen, die sie lösen.

Micro Services zum Beispiel: Seit Jahren in aller Munde, gelegentlich als Allheilmittel für wirklich, wirklich alle IT-Probleme angepriesen, sind sie auch für JIT von stetig wachsender Bedeutung, und wo wir sie einsetzen, sind Kunden in der Tat begeistert. Das liegt allerdings daran, dass wir nur dann zur Migration raten, wenn die Problemstellung den Aufwand rechtfertigt und alle organisatorisch-technischen Rahmenbedingungen stimmen.

Wirklich empfehlenswert sind Micro Services zur Revitalisierung von IT-Landschaften, die über Jahre und Jahrzehnte hinweg organisch gewachsen sind, bis sie zu groß, kompliziert und unbeweglich wurden, um sich an veränderte Umweltbedingungen anzupassen. Jurassic Systems sozusagen.

Das wichtigste Symptom akuter Systemwachstumskrisen ist die explodierende Fehlerquote: An einer in die Unüberschaubarkeit gewucherten Applikation doktern unterschiedliche Teams herum und implementieren neue Features, die meist wenig miteinander zu tun haben. Was nicht weiter stört, denn ehrlich gesagt überblickt längst niemand mehr im Unternehmen die Business-Logik der Applikation in ihrer Gesamtheit. Die ausufernde Komplexität macht Code-Eingriffe zu Weiterentwicklung und Wartung immer schwieriger, teurer und riskanter: Selbst kleinste Änderungen provozieren unterwartete Reaktionen in scheinbar unbeteiligten, weit entfernten Regionen des Systems. Das wachsende Fehlerrisiko hemmt dringend nötige Entwicklungsschritte, das Unternehmen verliert seine Agilität, der Markt läuft ihm davon.

In solchen Settings sind Micro Services eine ideale Lösung: kompakte, autonome Services, die miteinander kollaborieren, wobei die Kopplung zwischen den Services möglichst lose und die Kohäsion innerhalb des einzelnen Services möglichst stark ausgelegt wird. Die gesamte IT-Architektur folgt dem Single Responsibility Prinzip „Do one thing and do it well“. Die Vorteile liegen auf der Hand:

Kompakte, überschaubare Services können einfach, schnell und risikoarm überarbeitet werden, und das über den gesamten Lebenszyklus hinweg vom immer gleichen Team – so wird die Devops-Vision greifbar. Auch Service-Neuimplementierungen und Modernisierungen einzelner Services durch spezialisierte Technologien sind mit wenig Aufwand möglich. Performance-kritische Services können einzeln skaliert werden. Laufende, rasche, risikoarme Deployments reduzieren die Time-to-market. Services können vielfältig verknüpft werden, um neue Funktionalitäten zu schaffen.
Zusammenfassend könnte man sagen, Micro Services ersetzen System-Dinosaurier durch hoch agile Bienenschwärme.

Das sagen wir unseren Kunden. Aber wir sagen ihnen auch, dass die neue Agilität einen Preis hat, und nein, die Rede ist hier nicht von der Einstiegsinvestition, sondern vielmehr von der veränderten Risikolandschaft: Migration zur Micro Service-Architektur bringt die charakteristischen Herausforderungen komplex verteilter Systeme mit sich – Stichwort Distributed Transactions, AKID und Konsistenzen. Und siehe Bill Joy und seine „Acht Irrtümer bezüglich verteilter Systeme“.

Auch über die organisatorisch-technischen Voraussetzungen für Micro Services gibt es eine Menge zu sagen. In Teil 2 dieser Blog-Serie tun wir genau das.

Micro Services – die Insider-Perspektive. Teil 2:

„WAS MICRO SERVICES BRAUCHEN, UM ZU FUNKTIONIEREN?“

Willkommen bei Teil 2 unserer Blog-Reihe über Micro-Services – einen jungen Ansatz der IT-Architektur, der monolithische System-Dinosaurier durch hoch agile Bienenschwärme von kompakten, autonomen, kollaborierenden Services ersetzt, wobei die Kopplung zwischen den Services idealer Weise möglichst lose und die Kohäsion innerhalb des einzelnen Services möglichst stark sein soll.

Eine solche Architektur bietet den Ausweg aus der Unbeweglichkeit und Unsteuerbarkeit komplexer, organisch gewachsener Systeme. JIT hat viele einschlägige Projekte begleitet und empfiehlt Micro-Services gerne und aus Überzeugung – allerdings nur dann, wenn die technischen und organisatorischen Rahmenbedingungen tatsächlich gegeben sind.

Das Nachdenken über organisatorische Rahmenbedingungen beginnt mit „Conway´s Law“: Wenn eine Organisation ein System entwirft, erkannte Melvin Conway schon vor einem runden halben Jahrhundert, entsteht völlig zwangsläufig eine Abbildung ihrer eigenen Team- und Kommunikationsstrukturen.

Deshalb wird ein Unternehmen, das die Migration zu einer Micro Service-Architektur vorbereitet, eingehend über Businessprozess-Anatomie, Zuständigkeitsgrenzen und Aufgabenverteilungen nachdenken müssen.

Denn um eine möglichst lose Kopplung zwischen Micro Services bei möglichst starker Kohäsion innerhalb jedes Services erzielen, müssen die Services und die zugrundeliegenden Datenmodelle sorgsam entlang klarer Domänengrenzen und Zuständigkeiten modelliert werden, die sich dann in einer klaren, effizienten Micro Service-Architektur spiegelt.

Domain-driven Design (DDD) ist das Werkzeug der Wahl für solche Modellierungen, speziell wegen der dazu verwendeten „bounded contexts“: Sie teilen die Business-Domäne sauber in klar abgegrenzte Zonen auf, zum Beispiel in Billing, Payment, Shipping usw. Jeder so definierte „bounded context“ bietet eine explizite Schnittstelle, die von kollaborierenden Services anderer Zonen verwendet wird.

Zu den organisatorischen Voraussetzungen gesellen sich auch technische Vorbedingungen. Die eine ist ein hoher Automatisierungsgrad: Continous Integration/Delivery ist in einem Micro Service-System unabdingbar.

Ebenso wesentlich ist das Monitoring: Der Zustand der einzelnen Services und des Gesamtsystems muss kontinuierlich überwacht werden. Dies gestaltet sich etwas komplexer als bei traditionellen Applikationen, da mehrere Server, Logfiles und Metriken wie CPU-Auslastung oder Response-Zeiten an einer zentralen Stelle aggregiert werden müssen. Tools wie Graylog, Graphite und Nagios sind dazu hilfreich.

Sind alle diese Rahmenbedingungen geschaffen, bleibt nur noch eine Frage: Soll das System in Zukunft spielen wie die Philharmoniker? Oder soll es tanzen wie Nijinsky? Was das bedeutet, impliziert und erfordert, verraten wie Ihnen in Teil 3 unserer Blog-Serie.

Micro Services – die Insider-Perspektive. Teil 3:

„TANZEN ODER SPIELEN – DAS IST HIER DIE FRAGE?“

Willkommen bei Teil 3 unserer Blog-Reihe über Micro-Services – einen jungen Ansatz der IT-Architektur, der statt auf monolithische System-Dinosaurier auf hoch agile Bienenschwärme von kompakten, autonomen Services setzt. Die Kunst besteht dabei darin, die einzelnen Services als sinnvolles, effizientes, agiles Ganzes zu organisieren.

Denn kein Auto kann auf einem einzigen Rad fahren und kein Geschäftsprozess besteht aus einem einzigen Service: Microservices wie Billing, Payment und Shipping müssen kollaborieren, damit ein Prozess, und daraus ein Mehrwert für das Unternehmen, entsteht.

Gehen wir daran, solche Kollaborationen zu organisieren, dann steht eine Grundsatzentscheidung an: Orchestrieren – oder choreographieren?

Choreographierte Micro Services verhalten sich wie Tanzpaare in einem Ballsaal, die, ihren eigenen Routinen folgend, aufeinander reagieren und umeinander herum navigieren, ohne dass eine zentrale Steuerungsinstanz eingreift. Denn statt andere Services direkt aufzurufen, schreiben choreographierte Micro Services relevante Events in einen Message-Bus, z. B. Apache Kafka, den andere Services auf bestimmte, für sie relevante Events abhören. Publiziert z.B. ein Customer-Service bei der Neuanlage eines Kundenprofils den Event ‚Customer created‘, reagiert das Loyalty-Service mit den entsprechenden nächsten Prozessschritten. Wir nennen das asynchrone, event-basierte Kommunikation.

Die dabei Schritt für Schritt entstehende Eventkette bildet den gesamten Geschäftsprozess ab. Ein zentraler Steuerungsapparat ist überflüssig und die Kopplung zwischen den einzelnen Services ist so lose wie überhaupt nur möglich – ein Idealzustand in der Micro Service-Architektur.

Warum also nicht alle Micro Services orchestrieren? Weil jeder Idealzustand seinen Preis hat. Verwender orchestrierter Services entrichten ihn erstens in Form erhöhter Komplexität infolge asynchroner Kommunikation, zweitens durch totale Abstraktion, die Geschäftsprozesse nur mehr implizit in Form von Events abbildet bzw. im Code verbirgt, und drittens durch erhöhten Aufwand beim Monitoring des Gesamtprozesses: Choreografierte Systeme geben nicht von sich aus Auskunft, wie viele Prozesse derzeit laufen, wie viele Prozesse Fehlermeldungen produzierten usw.: Ein solches Monitoring müsste über kostspielige Custom-Lösungen eingerichtet werden.

Darüber hinaus lösen orchestrierte Systeme das Versprechen der totalen Autonomie des einzelnen Services nur bedingt ein: Durch den Nachrichteninput und -output der Services entsteht eine indirekte Kopplung, die bei Implementation neuer Anforderungen die Anpassung mehrerer Services erfordert – im eklatanten Widerspruch zur reinen Microservice-Lehre.

Lösen lässt sich dieses Manko durch eine Event-Command-Transformation, aber diese läge nicht im Verantwortungsbereich der beteiligten Services. Vielmehr müsste ein separates Service für diese Aufgabe erstellt werden, etwa durch Einsatz einer BPM-Engine, was aber wiederum den ersten Schritt zur zentralen Orchestrierung bedeuten würde.

Angesichts solcher Komplikationen wird verständlich, warum orchestrierte Micro Service-Systeme immer populär werden: Im Gegensatz zu choreographierten Architekturen sind sie mit einer zentralen Steuerstelle ausgerüstet. Diese lenkt den Gesamtflow, nicht unähnlich einem Dirigenten, der die Musiker eines Orchesters synchronisiert. Als Kommunikationsschiene zwischen Steuerstelle und Services wird häufig REST eingesetzt. Als zentraler Orchestrator eignen sich speziell leichtgewichtige BPM-Engines wie Camunda, Zeebe oder Conductor.

Warum solche Konstruktionen anfänglich mit Vorurteilen zu kämpfen hatten, mittlerweile aber immer öfter die beliebten Choreografie-Lösungen überholen, erfahren Sie in Teil 4 unserer Blog-Serie.

Micro Services – die Insider-Perspektive. Teil 4:

„LIEBER LEICHT SEIN ALS SCHWER HABEN.“

Das Grundprinzip aller Micro Service-Architektur lautet: „Leicht und agil ist gut und effizient“. Es stand hinter allen Bemühungen um die Optimierung der in Teil 3 dieser Serie beschriebenen schlanken Choreografie-Lösungen. Und es erklärt, warum viele Micro Service-Pioniere fremdelten, als erstmals BPM-Engines zur Orchstrierung von Micro Service-Systemen herangezogen wurden: Zu schwergewichtig. Zu viel Initialaufwand. Zu mühsame Inbetriebnahme. Passt gar nicht zu Micro Services. Sagten sie damals. Mittlerweile haben sie ihre Meinung geändert. Mit guten Gründen.

Denn rasch erwiesen sich orchestrierte Systeme mit zentraler Steuerung als um nichts problematischer, komplexer und schwerfälliger als choreografierte Lösungen – im Gegenteil, Orchestratoren räumen buchstäblich mit den inhärenten Problemen von choreografierten Systemen auf:

Geschäftsprozesse verschwinden nicht mehr in abstrakten Codes, sondern können Parameter für Parameter in Echtzeit zentral überwacht und im BPMN-Kontext visuell dargestellt und modelliert werden. Logische Fehler werden auf einen Blick erkennbar. Timeouts und ähnliche Fehler können automatisiert verarbeitet werden. Visualisierung macht die Prozesse für alle Stakeholder verständlich. Kurz gesagt: Alles klar.

Der aktuelle State of the Art lautet deshalb: Choreographierte Systeme werden nur noch für einfache Standard-Prozesse eingesetzt, und selbst dabei ist zu bedenken, dass jeder neu hinzukommende, komplexere Prozess dem System und seinen Betreibern exponentiell wachsende Probleme bescheren würde.

Ausschließlich auf Choreografie zu setzen macht deshalb selten Sinn, umso weniger als es durchaus möglich ist, Choreographie und Orchestrierung in ein und demselben System zu mischen. Auch BPM-Engines müssen nicht zwingend als schwergewichtige, monolithische Zentralinstanzen eingesetzt werden. Im Gegenteil – es ist möglich und oft sinnvoll, abgeschlankte Engines direkt in einzelne Microservices zu integrieren. Beispielsweise könnte ein Payment-Service im Kontext eines Order-Services intern eine BPM-Engine verwenden, um den Payment-Prozess zu steuern.

Prominente Microservice-Vorreiter wie Netflix haben den Mehrwert solcher Orchestratoren für die Microservice-Architektur früh erkannt und dazu eigene, schlanke BPM-Engines entwickelt. Conductor ist ein gutes Beispiel. Auch auf dem freien Markt sind mittlerweile gleich mehrere leichtgewichtige BPM-Engines wie Camunda oder Zeebe erhältlich. Sie können als Teil eines Microservices embedded laufen und auch in der Cloud verwendet werden.

Die wachsenden Popularität solchen Lösungen spiegelt sich auch in veränderten Lizenzmodellen: Immer öfter wird nicht mehr nach Anzahl der Server oder CPUs, sondern nach Transaktionszahlen verrechnet.

Die Anatomie und Vorzüge einer solchen schlanken BPM-Engine werden wir im nächsten und letzten Teil unserer Blog-Serie betrachten.

Micro Services – die Insider-Perspektive. Teil 5:

„ZEEBE – DIRIGENT MIT LEICHTER HAND.“ 

Leichtgewichtige, auf die Orchestrierung von Micro Services ausgelegte BPM-Engines sind die jüngsten Kinder der Micro Service-Revolution. Wie sie beschaffen sind und was sie leisten, lässt sich zum Beispiel an Zeebe studieren, dem neuesten Produkt aus der Softwareschmiede der deutschen BPM-Pioniere Camunda.

Diese BPM-Engine wurde mit konsequentem Fokus auf Microservice-Orchestrierung entwickelt und deshalb auf horizontale Skalierbarkeit, niedrige Latenz und hohen Durchsatz getrimmt. Sie operiert mit Event-Sourcing: Sämtliche Prozessänderungen werden als Events geschrieben. Zeebe-Instanzen können in einem Cluster zusammenarbeiten. Ein Replikations-Mechanismus sorgt für Fehlertoleranz bei Ausfall von Nodes.

Zeebe kann zum Process-Mining in vorhandenen, event-basierten Microservice-Architekturen integriert werden. In einer solchen reinen Beobachterrolle registriert die Engine sämtliche Events und korreliert sie mit den per Business Process Modelling & Notation definierten Geschäftsprozessen.

Dies ermöglicht eingehendes und zugleich zeitnahes Monitoring der Geschäftsprozesse und macht visuell nachvollziehbar, auch – und das ist neu – in rein choreographierten Architekturen.

Zeebe kann aber auch aktiv als als Orchestrierungs- und/oder Kommunikations-Layer integriert werden und Kommandos in Event-Form schreiben – entweder in einen vorhandenen Message-Bus oder der Zeebe-eigenen Messaging-Plattform.

Zeebe finden wir gut – aus allen hier dargestellten Gründen. Und weil diese Engine einmal mehr beweist, dass BPMs und Microservices einander nicht ausschließen, sondern in Wahrheit ideal ergänzen.

Transparentes Festpreis-Angebot

„Transparentes Festpreis-Angebot“

Geht es um Individualsoftware-Entwicklung so geben sich viele IT-Dienstleister Mühe Festpreis Angebote zu vermeiden. Auch ist es der Fall, dass sich die Zusammenstellung der Aufwände nicht immer in jener Klarheit erschließen wie es vom Kunden erwartet wird.

Bezüglich Verrechnungsart wird oftmals die Abwicklung nach tatsächlichem Aufwand – also Time & Material – fokussiert. Dies bedeutet im Klartext die vollständige Übernahme des Risikos durch den Kunden.

Aus Sicht des IT Dienstleisters ist dies die perfekte Lösung – ausgenommen bis auf einen wesentlichen Aspekt: dem Kundenwunsch entsprechend Planungs- und Budgetsicherheit zu entsprechen.

Betrachtet man das Thema Abwicklung auf Festpreisbasis etwas näher so ergeben sich einfache Regeln für den IT Dienstleister, welche sich positiv auf eine Risikominimierung auswirken:

  • Unabhängig der Gesamt-Projektgröße ist darauf zu achten, dass einzelne atomare Aufgaben (z.B.: funktionale Anforderungen) eine maximale Größe an Aufwand nicht überschreiten dürfen. Ist dies der Fall so muss die entsprechende Aufgabe abermals aufgeteilt werden.
  • Dem IT-Dienstleister muss die Möglichkeit gegeben werden sich mit der Infrastruktur, den Technologien und den handelnden Personen des Kunden vertraut zu machen.
  • Klare Kommunikation bezüglich der Qualität der zugrunde liegenden Dokumente (Spezifikationen, etc.). Im Bedarfsfall hat eine Überarbeitung zu erfolgen. Gibt es diesbezüglich keine Einigung zwischen den beiden Parteien so ist dies der korrekte Zeitpunkt sich einem anderen Projekt zu widmen.

Man muss die Angelegenheiten nicht komplizierter machen als sie ohnedies sind.

Neben dem verbindlichen Preis ist für den Kunden die Nachvollziehbarkeit der zugrundeliegenden Aufwände von höchster Priorität.

Hand auf‘s Herz, wie oft haben Sie als Entscheidungsträger zu ein und derselben Anforderung mehrere Angebote erhalten und konnten diese nicht miteinander vergleichen? Ergänzend hierzu macht es oftmals die angeführte Aufteilung der Kosten unmöglich für einzelne Positionen den ROI zu errechnen.

Auch hierzu gibt es eine einfache Lösung: Das Auflisten nach fachlichen Anforderungen mit dem jeweiligen Kosten. Im Idealfall nachvollziehbar durch eine offizielle Metrik, beispielsweise dem Function-Point-Verfahren.

Fazit:

Beachtet man neben dem erforderlichen technischen Skillset einige Verhaltensweisen sowie Regeln und stellt man darüber hinaus Überlegungen an wie ein Angebot aus Kundensicht gestaltet sein soll, so hat man gute Chancen den Auftrag zu gewinnen.

Passierschein A38 – BPM ist schon längst kein gallisches Dorf mehr

„Passierschein A38 – BPM ist schon längst kein gallisches Dorf mehr.“

Was Asterix und Obelix, der Passierschein A38 und BPM miteinander gemeinsam haben? Lest selbst:

Im Kultzeichentrick „Asterix erobert Rom“ stehen Asterix und Obelix vor der Aufgabe den Passierschein A38 aus einer römischen Präfektur (Anm.: Amt) zu besorgen. Diese Prüfung gestaltet sich alles andere als einfach: Die beiden Gallier erfahren eine ständige Weiterreichung von Department zu Department, das benötigte Dokument bleibt ihnen jedoch verwehrt. Erst als Asterix sich einer List bedient und den fiktiven Passierschein A39 verlangt, gelingt es ihm, die gestiftete Verwirrung zu seinen Gunsten zu nutzen und somit dennoch den erforderlichen Passierschein A38 zu erlangen.

Diese Geschichte zeigt – wenn auch überspitzt – dass sobald eine Institution eine bestimmte Größe erreicht, eine Prozessautomatisierung unumgänglich ist, um die Effizienz der Abwicklung von diversen Abläufen zu gewährleisten. Der Schritt in Richtung Automatisierung bringt im Vergleich zur manuellen Prozessbearbeitung folgende Vorteile mit sich:

  • geringere Prozesskosten
  • schnellere Prozessdurchführung
  • weniger Prozessfehler
  • bessere Nachvollziehbarkeit

Wer nun jedoch glaubt, dass die automatische Durchführung von Abläufen nur für große Unternehmen mit entsprechenden finanziellen Mitteln Relevanz hat, der irrt. Auch kleine und mittlere Unternehmen (KMU’s) können ohne sich in finanzielle Unkosten stürzen zu müssen ihren Benefit aus der Prozessautomatisierung ziehen. Durch sogenannte „Human Tasks“ können automatische Prozessabläufe punktuell um manuelle Tasks angereichert werden. So bleiben z.B. im Prozess „Anmeldung eines neuen Mitarbeiters“ die einzelnen Schritte wie Anmeldung bei der Sozialversicherung, Anlage eines Benutzerkontos und Übergabe von Schlüssel und Zutrittskarte manuell. Durch Prozessautomatisierung wird hingegen sichergestellt, dass keiner der zuvor genannten Schritte vergessen wird.

Die Einführung von BPM ins Unternehmen gestaltet sich so einfach wie noch nie. Leichtgewichtige Open-Source Lösungen wie Camunda ermöglichen mittlerweile eine sehr geringe Einstiegshürde. Die Aufsetzung einer Prozessengine für ein Pilotprojekt kann innerhalb kürzester Zeit ohne Lizenzkosten durch einen erfahrenen Java Developer vorgenommen werden. Anschließend erfolgt in Abstimmung mit dem Fachbereich die Festlegung auf die zu automatisierenden Prozesse. Erst nach Abschluss einer erfolgreichen Pilotphase gewinnt der Einsatz von kostenpflichtigen Features an Bedeutung.

Hätte sich bezogen auf die Geschichte von Asterix und Obelix die Präfektur damals bereits an BPM bedient, wäre das Erlangen von Passierschein A38 ein leichtes gewesen. Somit zeigt sich auch schon in der Antike: BPM macht das Leben einfacher!

Best Buddy

„Best Buddy“

Was erwartet einen frisch gebackenen IT Hero, wenn er seinen ersten JIT-Arbeitstag bestreitet? Die Antwort findet ihr hier:

Vorfreude gepaart mit etwas Lampenfieber begleiten oft den ersten Arbeitstag in einer neuen Firma. Damit einem erfolgreichen Einstieg nichts im Weg steht, erwartet neue JIT Mitarbeiter neben bereits vorbereitetem Laptop, Systemzugängen und Arbeitsplatz ein persönlicher Buddy, der ihnen die ersten Wochen nicht von der Seite weicht.

Aufgabe des Buddies ist die Einschulung des Heroes in das jeweilige Projekt. Dies umfasst neben den projektspezifischen Arbeitsprozessen und Organisationsstrukturen vor allem die Vermittlung des technischen und domänspezifischen Wissens. Ziel ist es, den neuen Mitarbeiter möglichst rasch auf ein hohes Produktivitätsniveau zu heben und eine selbständige Arbeitsweise zu ermöglichen.

Die Einschulung gliedert sich grob in folgende Phasen:

1. High-Level Überblick

Der Buddy skizziert ein Bild der Domäne. Es werden die Systemarchitektur, die Aufgaben der unterschiedlichen Komponenten sowie deren Zusammenspiel erläutert. Hier hat es sich bewährt, die tatsächliche Verwendung des Systems aus Sicht des Endnutzers zu präsentieren.

2. Low-Level Details einer Komponente

Um einen Informationsüberfluss zu vermeiden, wird der Schwerpunkt auf eine Komponente gelegt, deren Funktionalität anhand des Quellcodes im Detail durchgegangen wird. Nachfolgende Tasks werden auf diesen Codeteil eingegrenzt.

3. Kooperatives Arbeiten

Zusammen mit dem Buddy werden die ersten Tasks als Pair-Programming-Aufgabe durchgeführt, d.h. zwei Entwickler arbeiten auf einem Rechner. Während ein Entwickler die aktive Rolle einnimmt und den Quellcode schreibt, verharrt der zweite Entwickler in einer observierenden Rolle. Er skizziert den Lösungsweg und identifiziert potentielle Probleme. Die Rollen werden regelmäßig getauscht. Durch diese agile Arbeitsweise wird nicht nur die Wissensvermittlung und Teambildung forciert und beschleunigt, sondern auch die Codequalität erhöht.

4. Autonomes Arbeiten

Nach den ersten Wochen werden Aufgaben eigenverantwortlich gelöst. Die Stützräder werden aber nicht entfernt, der Buddy ist im Hintergrund unterstützend wirkend. Die Behebung von Bugs eignet sich besonders für diese Aufgaben. Nach dem Abschluss eines Tasks wird ein Code Review durchgeführt, in dem die Lösung vorgestellt, Verbesserungsvorschläge unterbreitet und etwaige Probleme durch den Buddy aufgezeigt werden.

5. Expansion auf weitere Systemteile

Kontinuierlich werden weitere Komponenten eingeführt und darauf abzielende Tasks sowohl mittels Pair-Programming als auch selbständig gelöst. Die benötigte Hilfestellung des Buddies reduziert sich fortlaufend.

Das Gelernte wird stets in Form von Glossars, Anleitungen und Systembeschreibungen zu Papier gebracht. Dadurch wird einerseits das neue Wissen gefestigt, andererseits dienen diese Ressourcen als Trainingsmaterial für zukünftige Heroes, deren potentieller Buddy der dann erfolgreich eingeschulte Mitarbeiter ist.

Wie man die Stärken von Scrum und Function Points im Festpreismodell vereint

„Wie man die Stärken von Scrum und Function Points im Festpreismodell vereint.“

Wichtiger als die richtige Metrik ist die gemeinsame Schätzung der Komplexität

Scrum ist mittlerweile in der IT weitverbreitet und bekannt. Jeder kennt das beliebte agile Framework, jeder weiß welche Rollen es gibt und vom Daily Stand-up hat man zumindest auch schon gehört.

Scrum ist aber nicht nur ein Framework zur Projektentwicklung. Scrum unterstützt einen dabei die Werte agiler Vorgehensmethoden umzusetzen. Diese Werte wurden im Agilen Manifest definiert:

Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge
Funktionierende Software ist wichtiger als umfassende Dokumentation
Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlung
Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans

Scrum konzentriert sich auf die beteiligten Personen und darauf, dass am Ende ein erfolgreiches Ergebnis erzielt wird. Es verhindert bürokratische Prozesse, die auf Kosten der Motivation der Mitarbeiter gehen. Hürden sollen durch intensive Zusammenarbeit – sowohl innerhalb des Teams, als auch nach außen – frühestmöglich überwunden werden.

Bei JIT verwenden wir einen Scrum-Prozess für Festpreisprojekte deren Anforderungen mit Function Points geschätzt wurden. Das bedeutet, dass wir das Scrum-Framework so adaptieren müssen, dass es unseren Anforderungen entspricht. In zwei Punkten weicht unsere Methode etwas vom gängigen Fall ab:

1) Festpreisprojekte mit Scrum

Festpreisprojekte mit der agilen Methode Scrum zu realisieren ist auf den ersten Blick ein Widerspruch. Da Kunden aber häufig den Festpreis bevorzugen, haben wir eine Methode gefunden, beides zu vereinen.

Der Einsatz von Scrum bei Festpreisprojekten kann die Zusammenarbeit zwischen Kunden und Lieferanten erleichtern. Dafür ist es notwendig, dass der Kunde den Scrum-Prozess mitlebt. Das ist aber bei jedem agilen Projekt so, unabhängig von den Verträgen oder Zahlungsmodalitäten. Die obigen agilen Werte müssen im gesamten Projekt gelebt werden.

Wir sind mit unseren Scrum-Projekten in den Entwicklungsprozess der KundInnen mit eingebunden; Hier können wir von JIT unsere größten Stärken einsetzen – kooperative Zusammenarbeit und direkte Kommunikation nach außen. Außerdem ist es so nicht erforderlich sämtliche Anforderungen für eine Applikation auf einmal schätzen, denn mit Scrum schätzt man die einzelnen User Stories nacheinander. Das ist entschieden einfacher.

2) Function-Point mit Scrum

Die gängigste Schätzmetrik für Scrum sind zwar nicht Function Points, sondern Story Points, diese sind für Scrum jedoch nicht obligatorisch. Weit wichtiger als die Metrik ist das vergleichende Schätzen der Komplexität. Wenn man daher die Einschätzung der Komplexität eines Elementarprozesses bzw. Datenbestands gemeinsam macht, können Story Points wegfallen.

Ein Scrum Team muss gemeinsam schätzen, sich gemeinsam das Sprintziel setzen und dieses dann auch gemeinsam erreichen. Darauf kommt es an.

Fazit: Die Function-Point-Schätzung und der Festpreis lassen sich gewinnbringend mit Scrum vereinbaren, wenn gewisse zulässige Adaptionen gemacht werden. Das wichtigste für den Erfolg eines Scrum-Projekts ist, dass das Team kollektiv die agilen Werte lebt. Diese Prämisse erfüllt JIT voll und ganz. Wir haben die agilen Werte schon gelebt, bevor Scrum überhaupt eingeführt wurde. Scrum hat lediglich mehr Ordnung in unseren agilen Alltag gebracht.

WAS HAUSBAU UND SOFTWARE-ENTWICKLUNG GEMEINSAM HABEN

„Was Hausbau und Software-Entwicklung gemeinsam haben.“

Ein Haus zu bauen ist keine leichte Aufgabe. Man muss dabei gegensätzliche Anforderungen unter einen Hut bringen und gleichzeitig Fertigstellungstermine und vorhandene Kostengrenzen einhalten. Entscheidungen, die man in der Planung trifft, wirken sich über Jahrzehnte auf Komfort und Werterhaltung aus.

Ganz ähnlich sieht die Situation bei größeren Softwareprojekten aus. Man muss Anforderungen präzisieren und eingrenzen, weil das Budget knapp und die Zeit bis zur Inbetriebnahme tendenziell zu kurz ist.

Ein eklatanter Unterschied wird beim Vergleich von Hausbau und Software-Entwicklung aber auch deutlich:

Während die Verantwortlichen beim Hausbau vielen gesetzlichen Normen, der lokalen Bauordnung und satten Haftungen bei Fehlern unterworfen sind, werden Softwareprojekte im Blindflug auf ihre Codequalität getestet. Bei der Abnahme solcher Systeme testet der Empfänger oft nur oberflächlich Performance, Lastverhalten und Funktionalität gemäß den fachlichen Anforderungen. Dabei vergisst er, dass die interne Codequalität ein wesentlicher Faktor für die Werterhaltung von Software ist. Nur wenn der Quellcode schon vom Start weg gut strukturiert und qualitativ hochwertig ist, können im Nachhinein hinzukommende Anforderungen einfach und gefahrlos integriert werden. Hohe interne Qualität verlängert also den Lebenszyklus einer Software. Software von schlechter Codequalität ist dagegen kurzlebig, da sie rasch den Punkt der Unwartbarkeit erreicht. Zudem ist minderwertige Software ein Kostentreiber, da jede fachliche Änderung zu immensem Aufwand bei Implementierung und Test führt.

Wenngleich niemand ein Haus ohne Normen, Bauordnung und tiefgreifende Kontrolle der Arbeiten bauen lassen würde, werden Softwareprojekte jedoch meist ohne oder mit nur sehr schwachen Vorgaben an die interne Codequalität abgewickelt. Haftungen betreffen, wenn überhaupt welche vereinbart sind, lediglich die fachlich-funktionalen Anforderungen. Da es für die meisten Bereiche der Softwareentwicklung noch keine Normen oder gesetzliche Standards gibt, ist dieses Vorgehen aus rechtlicher Sicht vollkommen legal, aus Kundensicht jedoch überaus fatal.

Kann der Auftraggeber selbst die interne Codequalität messen? Er kann. Hierzu gibt es glücklicherweise sehr gute Unterstützung aus der Open-Source-Gemeinde:

Mit Sonar (sonarqube.org) steht ein überaus mächtiges Werkzeug zur Qualitätssicherung in Softwareprojekten zur Verfügung. In den Continuous-Integration-Prozess aufgenommen, kann Sonar Leaks, also fehlerhafte Codestellen, frühzeitig erkennen. Neben statischer Codeanalyse bietet es über PlugIns die Möglichkeit, die Testabdeckung zu messen, den Aufwand zur Behebung von Qualitätsmängeln zu schätzen usw. Aus der Analyse lassen sich objektive Qualitätsmetriken ableiten, die zwingend einzuhalten sind. Diese Kriterien sollten folglich auch eine notwendige Bedingung für die Abnahme durch den Kunden darstellen.

Der volle Nutzen von Sonar ergibt sich in Kombination mit einem Continuous-Integration-Server wie z.B. Jenkins (jenkins-ci.org). Damit lassen sich Build, Tests sowie Sonaranalyse automatisiert durchführen und Qualitätsreports erstellen sowie gleich per Mail verschicken.

Analog zum Hausbau bedeutet dies, dass man mit besagtem Setup bei jedem Bauschritt prüfen kann, ob die gültigen Normen eingehalten werden.

Fazit: Vertrauen Sie nicht nur auf funktionale Tests bei der Abnahme von Softwareprojekten! Achten Sie auf Transparenz und lassen Sie sich nicht von bunten Icons und animieren User-Interfaces blenden, sondern gehen Sie mit Sonar unter die Oberfläche. Prüfen Sie die Qualität der abgelieferten Arbeit, bevor es zu spät ist. Ein qualitätsorientierter Lieferant wird Sie dabei stets unterstützen.