Downloaden Sie, um offline zu lesen
Hochgeladen vonHendrik Lösch
Confessions of a Codehausmeister
Das Dokument befasst sich mit der Anpassbarkeit und dem Geschäftswert von Softwareentwicklungsprozessen, einschließlich der Entwicklung neuer Funktionen unter Zeitdruck und der Notwendigkeit einer umfassenden Restrukturierung. Es werden verschiedene Entwicklungsstrategien und Testmethoden beschrieben sowie die Bedeutung von Fehlerkosten und Prozessfortschritt hervorgehoben. Zudem werden die Auswirkungen auf Kunden und der Zusammenhang zwischen Vergangenheit und zukünftiger Entwicklung thematisiert.
Confessions of a Codehausmeister
- 4. Anpassbarkeit Business Value Start der Entwicklung Featuresmit 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 Basierendauf Tom Gilb, Evolutionary Delivery vs Waterfall Model, ACM Software Engineering Notes, Juli 1985
- 6.
- 10.
- 11.
- 12.
- 14. Produkt 1 Produkt2 Produkt 3 Rahmenapplikation
- 15.
- 16. Produkt 1 Produkt2 Produkt 3 Rahmenapplikation
- 17.
- 18.
- 20.
- 21.
- 22. Fehlerkosten Prozessfortschritt Automatisierte Tests Manuelle Tests Abnahmedurch Fachbereich Produktiveinsatz Fachbereich Auswirkungen auf Endkunden Entwicklungsintern Extern
- 23.
- 24.
- 25.
- 28. ToDo In ProgressDone
- 29. ToDo In ProgressDone
- 30.
- 31.
- 32. 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
- 33.
- 34.
- 38. Rahmenapplikation Produkt 1 Produkt2 Produkt 3
- 39.
- 40.
- 41.
- 42.
- 44.
Hinweis der Redaktion
- #11 Ersetzen sensibler und instabiler Codebestandteile. Monolithische Anwendung. Ausgiebiges Code Review im Vorfeld.
- #13 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.
- #14 Der Kunde ist so vorsichtig geworden, dass er
- #16 Bereitstellung eines Applikationsrahmens für unterschiedliche Produkte Umsetzung verschiedener Infrastrukturkomponenten. Konzentration der Produktteams auf Fachspezifika.
- #18 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.
- #21 Wer ist eigentlich an der Kommunikation beteiligt.
- #23 Verringerung des Ressourcenbedarfs. Optimierung des Quellcodes durch vereinheitlichte Konzepte. Ablösen alter Frameworks durch neue.
- #24 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.
- #29 Es gibt keine Bugs oder Fehler, es gilt nur die Frage ob ein Verhalten akzeptabel ist oder nicht.
- #33 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.
- #34 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.
- #35 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.
- #37 Am besten hat man nur eines und spricht mit allen darüber.
- #38 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.
- #39 Bugs sind entweder so schwerwiegend, dass sie
- #40 Bugs sind entweder so schwerwiegend, dass sie zu incidents werden oder sie können wie Features eingeplant werden.
- #42 Entkoppeln von Infrastrukturkomponenten. Pflege der Infrastruktur in einem externen Team. Zusammenarbeit auf der gleichen Codebasis.
- #43 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.
- #44 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.
- #45 Die Sicherungsmechanismen des Unternehmens für solche Fälle haben gegriffen und schlimmere Eskalationen wurden verhindert.
- #46 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.