Haben Sie das Ihr Softwaresystem schon einmal gefragt? Haben Sie sich schon einmal ernsthaft mit dem Befinden der Applikation beschäftigt, die Sie oder Ihre Entwickler tagtäglich erweitern? Hat sie vielleicht keine Lust mehr und will kündigen, oder geht es ihr blendend und sie verlangt nach MEHR?
In diesem Vortrag sehen wir uns an wie wir das Befinden unserer Software ermitteln können. Dazu zählen Prozess- und Codemetriken, aber auch direkte Betrachtungen im Alltag. Ziel ist es, eine Art Frühwarnsystem zu etablieren, das uns sagt wann wir evtl. zu viel oder sogar zu wenig verlangen in dem wir Symptome aufdecken und diesen mögliche Krankheitsbilder zuordnen.
4. Quelle: Ron Jeffries http://xprogramming.com/articles/refactoring-not-on-the-backlog
5.
6. Innere Qualität /
Anpassbarkeit
Business Value
Start der
Entwicklung
Featureentwicklung mit
geringem Qualitätsanspruch
Featureentwicklung
unter hohem Zeitdruck
Entfernen fehlerhafter
Bestandteile
Umfassende
Restrukturierung inkl.
neuer Features
Einsatz der
Pfadfinderregel
32. Problem Auswirkungen Betroffene Stakeholder
Keine Zielarchitektur
vorhanden
Änderungen werden unstrukturiert vorgenommen. Unterschiedliche
Muster werden eingesetzt. Es besteht eine beschleunigt
Architekturerrosion.
Entwicklungsteams werden in ihrer direkten Arbeit
behindert.
Fachabteilungen merken, dass ähnliche Vorgänge sehr
unterschiedliche Arbeitsabläufe aufweisen.
Geringe
Testabdeckung
Sehr hoher Testaufwand. IT Abteilung bindet Ressourcen die in der Entwicklung
gebraucht werden.
Fachabteilungen müssen Personal für den Test
abstellen.
Viele Fehler schlagen bis in die Produktivumgebungen durch. Entwicklungsteams brauchen lange um Fehler zu
beheben und verlieren Leistungsfähigkeit.
Fachabteilungen werden in ihrer Arbeit behindert.
Entwickler verbringen
viel Zeit mit Bugfixing.
Es besteht kaum strukturierte Weiterentwicklung weshalb
Anforderungen als Service Requests formuliert werden.
Fachabteilungen verlieren Zeit, da sie für
Kernaufgaben die IT konsultieren müssen.
Entwicklungsteams werden mit zusätzlichen SRs
blockiert.
Features bieten dem Kunden sichtbare Mehrwerte, daher müssen sie nicht verteidigt werden.
Wartungs- und Reparaturarbeiten sind unsichtbar und daher schwer für Außenstehende zu bewerten.
Das Problem ist, man sieht die Anpassbarkeit nicht von außen.
Klare fachliche Trennung einzelner Module.
Fachliche wie technische Bestandteile können leicht ausgetauscht oder verändert werden.
Gerichtete und damit nachvollziehbare Abhängigkeiten.
Änderungen wirken sich nur auf einen definierten Teilbereich aus und sind frei von Nebeneffekten.
Kommunikation nur über abstrakte Schnittstellen.
Es ist leicht automatisierte Tests zu verfassen und Bestandteile unabhängig voneinander zu betrachten.
Zusammensetzung der Anwendung durch entsprechende Modulaggregatoren und eine Rahmenapplikation.
Definierte Schlüsselpunkte weisen hohe Komplexität auf, alle anderen eher geringe.
Einheitliches Vorgehen bei der Umsetzung neuer Funktionalität.
Geringer Einarbeitungsaufwand.
Beides sind Dinge die in der Softwareentwicklung oft vernachlässigt werden. Dies führt dazu, dass die damit verbundenen Unzulänglichkeiten auf andere Weise kompensiert werden müssen.
Features entsprechen wertsteigernden Maßnahmen
Mit den Fachbereichen ausspezifizierte neue Funktionalität.
Service Requests sind Hilfen für den Fachbereich die er mit der Applikation (noch) nicht selbst umsetzen kann.
Möglicherweise Funktionalität die vom Fachbereich tatsächlich gebraucht wird.
Fragen zum System von Endanwendern die auf schlechte Nutzerführung deuten.
Incidents stellen Probleme mit der Software dar, die in kürzester Zeit gelöst werden müssen.
Kritische Fehler die den Fachbereich stark behindern und ohne IT nicht gelöst werden können.
Bugs stellen ein Fehlverhalten gegenüber ursprünglich spezifiziertem Verhalten dar.
Fehler die den Fachbereich behindern.
Restrukturierungen sind werterhaltende Maßnahmen die sich nicht in zusätzlicher Funktionalität wiederspiegeln.
Investitionen in die Anpassbarkeit und Funktionstüchtigkeit des bestehenden Systems.
Immer Zeit und Menge erfassen, damit man ein Überblick dafür bekommt wie lange sich womit beschäftigt wurde.
Features brauchen im Schnitt immer länger, da sie umfangreicher sind. Service Requests lassen sich meist mit einem Anruf erledigen. Incidents teilweise auch. Bugs sind komplexer. Ein Umfeld wie dieses treibt die Entwickler aus der Firma.
Kreise sind ein ungünstiges Mittel um Größenverhältnisse darzustellen… codescene ist sehr nett, kostet aber recht viel Geld.
Teamregeln – generelle Regeln.
DoR – Wann können wir mit der Arbeit beginnen.
DoD – Wann sind wir mit der Arbeit fertig.
Wer ist eigentlich an der Kommunikation beteiligt.