Autor: JIT

Adresse: Vorgartenstraße 206B, A-1020 Wien

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.

JIT im Videoportrait

„JIT im Videoportrait“

Hier sehen Sie das Vorstellungsvideo von JIT für den WKO-Preis Crescendo’14, in dem Thorsten in einem knappen Q & A das Unternehmensprofil vorstellt. Sie erfahren unter anderem was das Ei des Columbus mit unserer Philosophie zu tun hat.

JIT im ON-Magazin

„JIT im ON-Magazin“

JIT wurde im September 2014 in der Kategorie „Aufstieg“ für den UnternehmerInnenpreis Crescendo’14 nominiert. Aus diesem Anlass ist im Magazin ON der WK Wien ein kurzer Artikel über JIT erschienen, den Sie hier finden.

Er portraitiert unseren CEO, Thorsten Guggenberger, und lobt die mittelfristige Entwicklung besonders in puncto Wandelfähigkeit und der Bereitschaft zum kalkulierten Risiko. Außerdem erklärt er dessen beherzten Schritt, mit dem Festpreis-Kalkulator ein transparentes Service zu lancieren, das in der IT-Branche bisher nicht angefasst wurde

Vom Troubleshooter zum Vorreiter (S.9)

Die Krux mit der IT-Aufwandsschätzung

„Die Krux mit der IT-Aufwandsschätzung.“

Im IT-Sektor stehen CEOs und CTOs oft schon vor Beginn eines Projekts vor einem großen Problem: Die Aufwandsschätzung ist unklar. Sie wissen oft schon relativ genau, welche Software sie wollen, bekommen aber von IT-Firmen keine exakten Preisberechnungen.

Warum gibt es keine verlässlichen Angebote?

Bei der Aufwands- und Kostenschätzung gilt es für IT-Unternehmen, komplexe Vorhersagen zu machen und die Faktoren Zeit, Arbeit und Geld zu berücksichtigen. Gleiches gilt natürlich für die Auftraggeber, also CEOs und CTOs, deren Entscheidung, ein Angebot anzunehmen, beträchtlich von der Höhe der Kosten und der Transparenz der Kostenauflistung abhängt.

Die Kostenstruktur für ein beliebiges Projekt setzt sich im Normalfall neben Lizenzkosten zum größten Teil aus Personalkosten zusammen. Das Realisierungsrisiko darf nicht zu groß sein und auch Vorfinanzierungskosten und etwaige Personalsteigerungskosten müssen klein gehalten werden. Die Genauigkeit von Seiten der IT-Firmen lässt hierbei nicht selten zu wünschen übrig: Entweder der Preis kann nicht genau eingegrenzt werden, oder ein Pauschalpreis wird angegeben, aber die konkreten Leistungen, die ein Softwarepaket abdeckt, sind undurchsichtig. Manchmal entscheiden sich Auftraggeber dann für eine Kompromisslösung, die selten ideal ist. Außerdem fressen komplexe Machbarkeitsstudien oft schon vor dem Projektstart eine Menge Zeit und Geld. Kein Wunder, wenn man als Geschäftsführer mit diesen Komplikationen überfordert ist.

Wie komme ich zu einer klaren Aufwandsschätzung?

Abhilfe für diese Probleme schaffen transparent dargelegte Fixkosten, die vom ersten Tag an feststehen. J-IT benutzt als Schätzungsverfahren das von Allen J. Albrecht bei IMB entwickelte Function-Point-Verfahren, das von funktionalen Anforderungen ausgeht und daher unabhängig von der Programmiersprache eingesetzt werden kann. Mit diesem Verfahren können wir von Beginn an nahezu exakt angeben, wie viel ein Projekt kostet und welche Einzelleistungen enthalten sind. Um Unternehmen eine transparente Preisberechnung zu bieten, haben wir auf unserer Webpage den Festpreis-Kalkulator eingerichtet. Er ermöglicht es Interessenten, innerhalb von Minuten ein glasklares Angebot zu bekommen, an dem im Nachhinein nicht mehr gerüttelt wird. Obwohl dieses Verrechnungsmodell Risiken für uns birgt, haben wir uns entschlossen, diesen Schritt zu wagen. Damit machen wir es Unternehmen einfacher, den IT-Preisnebel zu durchblicken und die Anschaffung von individuellen Software-Lösungen effektiv zu planen. Hier können Sie die Kosten für Ihr IT-Projekt mit unserem Festpreis-Kalkulator berechnen.