Downloaden Sie, um offline zu lesen
Hochgeladen vonHendrik Lösch
Survivalkit für Codehausmeister
Das Dokument behandelt die Herausforderungen in der Softwareentwicklung, insbesondere bei der Featureentwicklung unter Zeitdruck und mit geringem Qualitätsanspruch. Es wird auf die Notwendigkeit einer strukturierten Weiterentwicklung und die Verbesserung der Testabdeckung hingewiesen, um Fehler und Ineffizienzen zu reduzieren. Zudem werden die Auswirkungen unstrukturierter Änderungen auf die Entwicklungsabläufe und die Zusammenarbeit zwischen Fachabteilungen und IT hervorgehoben.
Survivalkit für Codehausmeister
- 2.
- 4. Innere Qualität / Anpassbarkeit BusinessValue Start der Entwicklung Featureentwicklung mit geringem Qualitätsanspruch Featureentwicklung unter hohem Zeitdruck Entfernen fehlerhafter Bestandteile Umfassende Restrukturierung inkl. neuer Features Einsatz der Pfadfinderregel
- 5. Entwicklung Weiter- entwicklung Weiter- entwicklung Weiter- entwicklung Stabilisierung Optimierung Sanierung Stabilisierung Stabilisierung Optimierung t in Jahren Basierendauf Tom Gilb, Evolutionary Delivery vs Waterfall Model, ACM Software Engineering Notes, Juli 1985
- 6.
- 7.
- 10.
- 11.
- 12.
- 16.
- 17.
- 18. Ohne Schichten Datenhaltung Mit Schichten Datenhaltung Userinterface Controller Geschäftslogik FachlicheSchichtung Technische Schichtung
- 19.
- 20. Sales S Invoiceing G C – CoreDomain S – Support Domain G – Generic Domain Consulting C ACL
- 21. C – CoreDomain S – Support Domain G – Generic Domain G SG S G G S G C S C G
- 22. G SG S G G S G C S C G C – CoreDomain S – Support Domain G – Generic Domain
- 23. Sales Module UI Logic Data Interfaces Invoicing ModuleUI LogicData Interfaces Rahmen- applikation Invoicingbenötigt Daten von Sales Initialisiert Invoicing Initialisiert Sales Invoicing Sales
- 24.
- 25.
- 29. Fehlerkosten Prozessfortschritt Automatisierte Tests Manuelle Tests Abnahmedurch Fachbereich Produktiveinsatz Fachbereich Auswirkungen auf Endkunden Entwicklungsintern Extern
- 31. % Covered CountDelta LoC LoC Covered Delta LoC Delta LoC Covered Sprint 1 1,01 244 0 453254 4578 0 0 Sprint 2 1,02 268 24 455198 4643 1944 65 Sprint 3 1,06 301 33 456988 4844 1790 201 Sprint 4 1,2 345 44 455827 5470 -1161 626 Sprint 5 1,24 402 57 457112 5668 1285 198 244 268 301 345 402 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Count 1.01 1.02 1.06 1.2 1.24 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 % Covered 4578 4643 4844 5470 5668 SPRINT 1 SPRINT 2 SPRINT 3 SPRINT 4 SPRINT 5 LoC Covered -1500 -1000 -500 0 500 1000 1500 2000 2500 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Added LoC vs. newly covered LoC Delta LoC Covered Delta LoC
- 32. Quelle: https://www.artima.com/weblogs/viewpost.jsp?thread=215899 C.R.A.P.(m) =CC(m)^2 * (1 – Coverage(m)/100)^3 + CC(m) π •👍 30
- 33.
- 34.
- 35.
- 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
- 38. Team 3Team 2 Team1 C – Core Domain S – Support Domain G – Generic Domain G SG S G G S G C S C G
- 39. Team 3Team 2 Team1 G SG S G G S G C S C G C – Core Domain S – Support Domain G – Generic Domain
- 41. Problem Auswirkungen BetroffeneStakeholder 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.
- 43.
- 45. ToDo In ProgressDone
- 46. ToDo In ProgressDone
- 47.
- 48.
- 49. 8 19 4 11 3 9 26 19 7 2 6 2 0 5 10 15 20 25 30 35 40 45 50 Sprint 7Sprint 8 Sprint 9 Burnup Chart Bug Incident ServiceRequest Feature
- 50. 21 30 26 106 120 48 127 150 74 0 20 40 60 80 100 120 140 160 Sprint 7 Sprint8 Sprint 9 Velocity Wert steigernd Wert erhaltend kumulierte Velocity
- 51.
- 55.
- 56.
- 57.
- 58.
- 59.
- 66.
Hinweis der Redaktion
- #5 Das Problem ist, man sieht die Anpassbarkeit nicht von außen.
- #23 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.
- #24 Grüne Pfeile -> bewusste Abhängigkeitsumkehr. Die Quellcodemenge die zu betreuen ist, ist fast noch die gleiche. Team 1 hat etwas mehr zu tun.
- #25 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.
- #30 Alles eine Frage der Akzeptanz.
- #31 Was lohnt sich wie zu testen?
- #40 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.
- #41 Grüne Pfeile -> bewusste Abhängigkeitsumkehr. Die Quellcodemenge die zu betreuen ist, ist fast noch die gleiche. Team 1 hat etwas mehr zu tun.
- #42 Wer ist eigentlich an der Kommunikation beteiligt.
- #46 Am besten hat man nur eines und spricht mit allen darüber.
- #50 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.
- #51 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.
- #52 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.
- #54 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.
- #55 Bugs sind entweder so schwerwiegend, dass sie
- #56 Bugs sind entweder so schwerwiegend, dass sie zu incidents werden oder sie können wie Features eingeplant werden.