Confessions of a Codehausmeister
•Als PPTX, PDF herunterladen•
0 gefällt mir•265 views
Dieser Vortrag beschreibt typische Fehler bei der Pflege von Software, anhand von Realbeispielen und welche Schlüsse man aus diesen Fehlern ziehen kann.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Confessions of a Codehausmeister
Ähnlich wie Confessions of a Codehausmeister (20)
Mehr von Hendrik Lösch
Mehr von Hendrik Lösch (20)
Confessions of a Codehausmeister
- 4. Anpassbarkeit Business Value Start der Entwicklung Features mit geringem Qualitätsanspruch Featureentwicklung unter hohem Zeitdruck Entfernen fehlerhafter Bestandteile Umfassende Restrukturierung inkl. neuer Features Einsatz der Pfadfinderregel Basierend auf Managed Evolution : A Strategy for Very Large Information Systems. 2010
- 5. Entwicklung Weiter- entwicklung Weiter- entwicklung Weiter- entwicklung Stabilisierung Optimierung Sanierung Stabilisierung Stabilisierung Optimierung t in Jahren Basierend auf Tom Gilb, Evolutionary Delivery vs Waterfall Model, ACM Software Engineering Notes, Juli 1985
- 14. Produkt 1 Produkt 2 Produkt 3 Rahmenapplikation
- 15. Kunde
- 16. Produkt 1 Produkt 2 Produkt 3 Rahmenapplikation
- 17. • • • • • •
- 20. Softwaresystem
- 21. Softwaresystem
- 22. Fehlerkosten Prozessfortschritt Automatisierte Tests Manuelle Tests Abnahme durch Fachbereich Produktiveinsatz Fachbereich Auswirkungen auf Endkunden Entwicklungsintern Extern
- 28. ToDo In Progress Done
- 29. ToDo In Progress Done
- 32. 21 30 26 106 120 48 127 150 74 0 20 40 60 80 100 120 140 160 Sprint 7 Sprint 8 Sprint 9 Velocity Wert steigernd Wert erhaltend kumulierte Velocity
- 38. Rahmenapplikation Produkt 1 Produkt 2 Produkt 3
- 39. Kunde Saxonia
- 40. Kunde Saxonia
- 42. Kunde Saxonia
Hinweis der Redaktion
- Ersetzen sensibler und instabiler Codebestandteile. Monolithische Anwendung. Ausgiebiges Code Review im Vorfeld.
- Bei Bestandscode verbringt man 90% und mehr der Zeit um die Zusammenhänge zu verstehen und die Aufwände für die letztendlichen Änderungen sind vergleichsweise gering.
- Der Kunde ist so vorsichtig geworden, dass er
- Bereitstellung eines Applikationsrahmens für unterschiedliche Produkte Umsetzung verschiedener Infrastrukturkomponenten. Konzentration der Produktteams auf Fachspezifika.
- Die Akzeptanz des Frameworks bei den Teams war gering, da sie nur geringen Einfluss darauf hatten. Produkt 1 hatte Angst, dass es sich um eine Eintagsfliege handelt, also haben Sie eine Kapsel drumer herum gebaut um es wieder loswerden zu können. Produkt 2 hat nur Teile davon verwendet. Produkt 3 hat das alles zu lange gedauert, deshalb haben sie ihre Infrastrukturkomponenten selbst gebaut. Es wurden Dinge umgesetzt die nicht gebraucht wurden. Dafür wurden Dinge nicht umgesetzt die gebraucht wurden.
- Wer ist eigentlich an der Kommunikation beteiligt.
- Verringerung des Ressourcenbedarfs. Optimierung des Quellcodes durch vereinheitlichte Konzepte. Ablösen alter Frameworks durch neue.
- Das Softwaresystem war ein Monolith. Wir haben Teile des Monolithen verändert. Damit wurden unsere Änderungen Teil des Monoliths und wir übernahmen die Verantwortung für alle Fehler die darin enthalten sind.
- Es gibt keine Bugs oder Fehler, es gilt nur die Frage ob ein Verhalten akzeptabel ist oder nicht.
- 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.
- Am besten hat man nur eines und spricht mit allen darüber.
- 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.
- Entkoppeln von Infrastrukturkomponenten. Pflege der Infrastruktur in einem externen Team. Zusammenarbeit auf der gleichen Codebasis.
- Ziel war die Entwicklung über dedizierte Schnittstellen zu treiben. Ein Proxy PO vom Kunden sollte die Anforderungen mit den Teams abstimmen und dabei Unterstützung von einem Analysten und Architekten bekommen. Er sollte aber keinen Zugriff auf die Entwickler und Tester erhalten.
- Tester und Analyst waren nicht ausgelastet, weil es zu wenig zu tun gab. Es gab zu wenig zu tun, weil die Aufgaben sehr technisch waren und sich nicht prüfen ließen. Ständiges Kompetenzgerangel zwischen den Architekten. Statt auf Ebene der Anforderungen wurde auf Ebene der technischen Umsetzung diskutiert. Eskalation bis zur persönlichen Ebene.
- Die Sicherungsmechanismen des Unternehmens für solche Fälle haben gegriffen und schlimmere Eskalationen wurden verhindert.
- Analyst und Architekt hätten die ganze Zeit bei den Teams sein müssen. Der Analyst hätte mit den POs sprechen müssen, der Architekt mit den technischen Verantwortlichen.