Das Dasein eines Codehausmeisters ist schon nicht einfach. Da müht man sich tagein, tagaus damit ab die Software am Laufen zu halten und niemand dankt es einem. Schlimmer noch, ständig kommt jemand und beschwert sich das etwas nicht funktioniert oder macht die ganze Sache sogar noch schlimmer. Bloß wenn man mal etwas ändern will, dann ist kein Weg drin. Erkennen Sie sich hier wieder? Wenn ja hilft Ihnen unser Survival Kit weiter. Es unterstützt Sie mit Werkzeugen sowie Argumenten beim steten Kampf um Softwarequalität, Wartbarkeit und Restrukturierungsbudgets; mit dem Ziel Ihnen die Arbeit zu erleichtern und Ihrer Software endlich die Pflege zu Teil werden zu lassen, die sie so bitter nötig hat.
4. 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
36. 0 - 50
50 - 100
100 - 150
150 - 200
200 - 250
> 250
Sonstiges
Anzahl der Änderungen
von Januar bis März 2018
https://gist.github.com/HerrLoesch/632e7882773deb6add55a86f78f4eaef
37.
38. Team 3Team 2
Team 1
C – Core Domain
S – Support Domain
G – Generic Domain
G
SG
S
G
G
S
G
C
S
C
G
39. Team 3Team 2
Team 1
G
SG
S
G
G
S
G
C
S
C
G
C – Core Domain
S – Support Domain
G – Generic Domain
40.
41. 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.
Das Problem ist, man sieht die Anpassbarkeit nicht von außen.
Farben – Fachlichkeit
Vierecke – Teams
Schwarze Pfeile – Upstream Beziehung
Rote Pfeile – Schlecht gewählte Upstream Beziehungen
Orangene Pfeile – Partnerschaftliche Beziehungen
Legt man die Verantwortlichkeiten der Teams darüber, merkt man, wo Abhängigkeiten zwischen den Teams bestehen. Hier ist es insbesondere schwierig, weil Partnerschaftliche Beziehungen zwischen Modulen bestehen die bei unterschiedlichen Teams liegen. Außerdem liegen Module der gleichen Fachlichkeit bei unterschiedlichen Teams.
Grüne Pfeile -> bewusste Abhängigkeitsumkehr.
Die Quellcodemenge die zu betreuen ist, ist fast noch die gleiche. Team 1 hat etwas mehr zu tun.
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.
Alles eine Frage der Akzeptanz.
Was lohnt sich wie zu testen?
Farben – Fachlichkeit
Vierecke – Teams
Schwarze Pfeile – Upstream Beziehung
Rote Pfeile – Schlecht gewählte Upstream Beziehungen
Orangene Pfeile – Partnerschaftliche Beziehungen
Legt man die Verantwortlichkeiten der Teams darüber, merkt man, wo Abhängigkeiten zwischen den Teams bestehen. Hier ist es insbesondere schwierig, weil Partnerschaftliche Beziehungen zwischen Modulen bestehen die bei unterschiedlichen Teams liegen. Außerdem liegen Module der gleichen Fachlichkeit bei unterschiedlichen Teams.
Grüne Pfeile -> bewusste Abhängigkeitsumkehr.
Die Quellcodemenge die zu betreuen ist, ist fast noch die gleiche. Team 1 hat etwas mehr zu tun.
Wer ist eigentlich an der Kommunikation beteiligt.
Am besten hat man nur eines und spricht mit allen darüber.
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.
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. Wir nehmen bewusst, erst einen späteren Sprint, da die ersten Sprints meist durch Besonderheiten gekennzeichnet sind.
Incidents haben die höchste Kritikalität und müssen daher gleich behandelt werden.
Features sollte man einplanen.
Service Requests kann man zu bestimmten Zeiten bearbeiten um sich darauf zu konzentrieren.
Restrukturierungen können ggf. auch mal einen Sprint ausgelassen werden, sie sollten nur nicht vergessen werden. Ggf. kann man dann auch einen Restrukturierungssprint raus handeln, wenn die Sachen ewig liegen blieben. Man sieht auf die Weise auch recht schnell ob Incidents oder Service Requests entstehen die aufgrund von Restrukturierungsaufgaben entstehen, die nicht angegangen wurden.
Bugs sind entweder so schwerwiegend, dass sie
Bugs sind entweder so schwerwiegend, dass sie zu incidents werden oder sie können wie Features eingeplant werden.