SlideShare ist ein Scribd-Unternehmen logo
Confessions of a Codehausmeister
Confessions of a Codehausmeister
Confessions of a Codehausmeister
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
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
t
Servicing
Wertsteigernde
Investitionen
Werterhaltende
Investitionen
100%
0
Initial Entwicklung Evolution
Confessions of a Codehausmeister
Confessions of a Codehausmeister
Confessions of a Codehausmeister
Alt
Neu
Funktionsumfang
t
Kick-Off Geplante Ablösung
Alt
Neu
Kick-Off Geplante Ablösung
Funktionsumfang
t
Vertrauen
AufwandFeedback
Confessions of a Codehausmeister
Produkt 1 Produkt 2 Produkt 3
Rahmenapplikation
Kunde
Produkt 1 Produkt 2 Produkt 3
Rahmenapplikation
•
•
•
•
•
•
Entwicklung
Team
3
Infrastrukturteam
Team
1
Team
2
Sales Service
Confessions of a Codehausmeister
Softwaresystem
Softwaresystem
Fehlerkosten
Prozessfortschritt
Automatisierte Tests
Manuelle Tests
Abnahme durch Fachbereich
Produktiveinsatz Fachbereich
Auswirkungen auf Endkunden
Entwicklungsintern
Extern
Systemtests
Integrationstests
Komponententests
Micro Tests
Bestehender Code
Neuer Code
User Interface
Business Logic
Datenhaltung
User Interface
Business Logic
Datenhaltung
Confessions of a Codehausmeister
Confessions of a Codehausmeister
ToDo In Progress Done
ToDo In Progress Done
•
•
•
•
•
0%
1%
5%
74%
20%
Bug
Incident
ServiceRequest
Feature
Restrukturierung
Bug
28%
Incident
18%
ServiceRequest
22%
Feature
32%
Zeitliche Verteilung
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
Productbacklog Maintenance
Backlog
Feature
Backlog
Product Owner Team
Incidents
Features
Service Requests
Restrukturierung
Confessions of a Codehausmeister
Confessions of a Codehausmeister
Confessions of a Codehausmeister
Rahmenapplikation
Produkt 1 Produkt 2 Produkt 3
Kunde Saxonia
Kunde Saxonia
Quelle: https://de.wikipedia.org/wiki/Konflikteskalation_nach_Friedrich_Glasl
Kunde Saxonia
Confessions of a Codehausmeister
•
•
•
•
•
•
Quelle: https://www.steuerklassen.com/stellenbeschreibung/hausmeister/
•
•
•
•
Confessions of a Codehausmeister

Weitere ähnliche Inhalte

Ähnlich wie Confessions of a Codehausmeister

Migrationsstrategien
MigrationsstrategienMigrationsstrategien
Migrationsstrategien
Hendrik Lösch
 
Sps whitepaper auvesy datenmanagement in der automatisierungstechnik
Sps whitepaper   auvesy   datenmanagement in der automatisierungstechnikSps whitepaper   auvesy   datenmanagement in der automatisierungstechnik
Sps whitepaper auvesy datenmanagement in der automatisierungstechnik
AUVESY
 
Windows as a Service - Herausforderungen ohne Windows Desktop Analytics
Windows as a Service - Herausforderungen ohne Windows Desktop AnalyticsWindows as a Service - Herausforderungen ohne Windows Desktop Analytics
Windows as a Service - Herausforderungen ohne Windows Desktop Analytics
Fabian Niesen
 
"Design & Generate": Standard ERP Systeme nach Mass
"Design & Generate": Standard ERP Systeme nach Mass"Design & Generate": Standard ERP Systeme nach Mass
"Design & Generate": Standard ERP Systeme nach Mass
topsoft - inspiring digital business
 
DevOps Prinzipien im Zusammenspiel mit Kubernetes
DevOps Prinzipien im Zusammenspiel mit Kubernetes DevOps Prinzipien im Zusammenspiel mit Kubernetes
DevOps Prinzipien im Zusammenspiel mit Kubernetes
QAware GmbH
 
Scrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für ProgrammiererScrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für Programmierer
Tobias Schlüter
 
Testmanagement mit Visual Studio 2013
Testmanagement mit Visual Studio 2013Testmanagement mit Visual Studio 2013
Testmanagement mit Visual Studio 2013
Nico Orschel
 
Aktuarielle Beratung: Test im aktuariellen Umfeld
Aktuarielle Beratung: Test im aktuariellen Umfeld Aktuarielle Beratung: Test im aktuariellen Umfeld
Aktuarielle Beratung: Test im aktuariellen Umfeld
PPI AG
 
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
René Spengler
 
Google Analytics Konferenz 2012: Siegfried Stepke, e-dialog: Analytics for En...
Google Analytics Konferenz 2012: Siegfried Stepke, e-dialog: Analytics for En...Google Analytics Konferenz 2012: Siegfried Stepke, e-dialog: Analytics for En...
Google Analytics Konferenz 2012: Siegfried Stepke, e-dialog: Analytics for En...
e-dialog GmbH
 
Verhärtete nullnummer version 2.0 - german testing day
Verhärtete nullnummer   version 2.0 - german testing dayVerhärtete nullnummer   version 2.0 - german testing day
Verhärtete nullnummer version 2.0 - german testing day
Michael Fischlein
 
MediaInfo: Git DVCS & Requirements Management InfoDay@Intland Software
MediaInfo: Git DVCS & Requirements Management InfoDay@Intland Software MediaInfo: Git DVCS & Requirements Management InfoDay@Intland Software
MediaInfo: Git DVCS & Requirements Management InfoDay@Intland Software
Intland Software GmbH
 
Mit agilen Prinzipien große Integrationstests einfach managen
Mit agilen Prinzipien große Integrationstests einfach managenMit agilen Prinzipien große Integrationstests einfach managen
Mit agilen Prinzipien große Integrationstests einfach managen
Christoph Schmiedinger
 
Quantitativer und qualitativer Nutzen von PLM Projekten
Quantitativer und qualitativer Nutzen von PLM ProjektenQuantitativer und qualitativer Nutzen von PLM Projekten
Quantitativer und qualitativer Nutzen von PLM Projekten
Intelliact AG
 
Referat: Change Management 2.0
Referat: Change Management 2.0Referat: Change Management 2.0
Referat: Change Management 2.0
Digicomp Academy AG
 
[DE] Itris Automation - Unternehmenspräsentation
[DE] Itris Automation - Unternehmenspräsentation[DE] Itris Automation - Unternehmenspräsentation
[DE] Itris Automation - Unternehmenspräsentation
Itris Automation Square
 
eControl - Identity Management als SaaS - German
eControl - Identity Management als SaaS - GermaneControl - Identity Management als SaaS - German
eControl - Identity Management als SaaS - German
Omni - www.omni-ts.com
 
Enterprise Git Adoption Webinar - German
Enterprise Git Adoption Webinar - GermanEnterprise Git Adoption Webinar - German
Enterprise Git Adoption Webinar - German
CollabNet
 
Testmanagement mit Visual Studio 2013 / CodedUI / Neues aus der Produktgruppe...
Testmanagement mit Visual Studio 2013 / CodedUI / Neues aus der Produktgruppe...Testmanagement mit Visual Studio 2013 / CodedUI / Neues aus der Produktgruppe...
Testmanagement mit Visual Studio 2013 / CodedUI / Neues aus der Produktgruppe...
Nico Orschel
 
Webinar- Lösungsorientierte Integration vorhandener Werkzeuge in ein Applicat...
Webinar- Lösungsorientierte Integration vorhandener Werkzeuge in ein Applicat...Webinar- Lösungsorientierte Integration vorhandener Werkzeuge in ein Applicat...
Webinar- Lösungsorientierte Integration vorhandener Werkzeuge in ein Applicat...
Minerva SoftCare GmbH
 

Ähnlich wie Confessions of a Codehausmeister (20)

Migrationsstrategien
MigrationsstrategienMigrationsstrategien
Migrationsstrategien
 
Sps whitepaper auvesy datenmanagement in der automatisierungstechnik
Sps whitepaper   auvesy   datenmanagement in der automatisierungstechnikSps whitepaper   auvesy   datenmanagement in der automatisierungstechnik
Sps whitepaper auvesy datenmanagement in der automatisierungstechnik
 
Windows as a Service - Herausforderungen ohne Windows Desktop Analytics
Windows as a Service - Herausforderungen ohne Windows Desktop AnalyticsWindows as a Service - Herausforderungen ohne Windows Desktop Analytics
Windows as a Service - Herausforderungen ohne Windows Desktop Analytics
 
"Design & Generate": Standard ERP Systeme nach Mass
"Design & Generate": Standard ERP Systeme nach Mass"Design & Generate": Standard ERP Systeme nach Mass
"Design & Generate": Standard ERP Systeme nach Mass
 
DevOps Prinzipien im Zusammenspiel mit Kubernetes
DevOps Prinzipien im Zusammenspiel mit Kubernetes DevOps Prinzipien im Zusammenspiel mit Kubernetes
DevOps Prinzipien im Zusammenspiel mit Kubernetes
 
Scrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für ProgrammiererScrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für Programmierer
 
Testmanagement mit Visual Studio 2013
Testmanagement mit Visual Studio 2013Testmanagement mit Visual Studio 2013
Testmanagement mit Visual Studio 2013
 
Aktuarielle Beratung: Test im aktuariellen Umfeld
Aktuarielle Beratung: Test im aktuariellen Umfeld Aktuarielle Beratung: Test im aktuariellen Umfeld
Aktuarielle Beratung: Test im aktuariellen Umfeld
 
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
 
Google Analytics Konferenz 2012: Siegfried Stepke, e-dialog: Analytics for En...
Google Analytics Konferenz 2012: Siegfried Stepke, e-dialog: Analytics for En...Google Analytics Konferenz 2012: Siegfried Stepke, e-dialog: Analytics for En...
Google Analytics Konferenz 2012: Siegfried Stepke, e-dialog: Analytics for En...
 
Verhärtete nullnummer version 2.0 - german testing day
Verhärtete nullnummer   version 2.0 - german testing dayVerhärtete nullnummer   version 2.0 - german testing day
Verhärtete nullnummer version 2.0 - german testing day
 
MediaInfo: Git DVCS & Requirements Management InfoDay@Intland Software
MediaInfo: Git DVCS & Requirements Management InfoDay@Intland Software MediaInfo: Git DVCS & Requirements Management InfoDay@Intland Software
MediaInfo: Git DVCS & Requirements Management InfoDay@Intland Software
 
Mit agilen Prinzipien große Integrationstests einfach managen
Mit agilen Prinzipien große Integrationstests einfach managenMit agilen Prinzipien große Integrationstests einfach managen
Mit agilen Prinzipien große Integrationstests einfach managen
 
Quantitativer und qualitativer Nutzen von PLM Projekten
Quantitativer und qualitativer Nutzen von PLM ProjektenQuantitativer und qualitativer Nutzen von PLM Projekten
Quantitativer und qualitativer Nutzen von PLM Projekten
 
Referat: Change Management 2.0
Referat: Change Management 2.0Referat: Change Management 2.0
Referat: Change Management 2.0
 
[DE] Itris Automation - Unternehmenspräsentation
[DE] Itris Automation - Unternehmenspräsentation[DE] Itris Automation - Unternehmenspräsentation
[DE] Itris Automation - Unternehmenspräsentation
 
eControl - Identity Management als SaaS - German
eControl - Identity Management als SaaS - GermaneControl - Identity Management als SaaS - German
eControl - Identity Management als SaaS - German
 
Enterprise Git Adoption Webinar - German
Enterprise Git Adoption Webinar - GermanEnterprise Git Adoption Webinar - German
Enterprise Git Adoption Webinar - German
 
Testmanagement mit Visual Studio 2013 / CodedUI / Neues aus der Produktgruppe...
Testmanagement mit Visual Studio 2013 / CodedUI / Neues aus der Produktgruppe...Testmanagement mit Visual Studio 2013 / CodedUI / Neues aus der Produktgruppe...
Testmanagement mit Visual Studio 2013 / CodedUI / Neues aus der Produktgruppe...
 
Webinar- Lösungsorientierte Integration vorhandener Werkzeuge in ein Applicat...
Webinar- Lösungsorientierte Integration vorhandener Werkzeuge in ein Applicat...Webinar- Lösungsorientierte Integration vorhandener Werkzeuge in ein Applicat...
Webinar- Lösungsorientierte Integration vorhandener Werkzeuge in ein Applicat...
 

Mehr von Hendrik Lösch

Why (most) softwareprojects fail silently
Why (most) softwareprojects fail silentlyWhy (most) softwareprojects fail silently
Why (most) softwareprojects fail silently
Hendrik Lösch
 
We (don't) need a software architect!?!
We (don't) need a software architect!?!We (don't) need a software architect!?!
We (don't) need a software architect!?!
Hendrik Lösch
 
Restrukturierung einer industriellen Großapplikation
Restrukturierung einer industriellen GroßapplikationRestrukturierung einer industriellen Großapplikation
Restrukturierung einer industriellen Großapplikation
Hendrik Lösch
 
Vom Monolith zum Modulith
Vom Monolith zum ModulithVom Monolith zum Modulith
Vom Monolith zum Modulith
Hendrik Lösch
 
Der Software auf den Zahn gefühlt - Einstieg in die Architekturbewertung
Der Software auf den Zahn gefühlt - Einstieg in die ArchitekturbewertungDer Software auf den Zahn gefühlt - Einstieg in die Architekturbewertung
Der Software auf den Zahn gefühlt - Einstieg in die Architekturbewertung
Hendrik Lösch
 
„Wie reden Sie denn mit mir?!?“ – Stakeholder überzeugen als Softwarearchitekt
„Wie reden Sie denn mit mir?!?“ – Stakeholder überzeugen als Softwarearchitekt„Wie reden Sie denn mit mir?!?“ – Stakeholder überzeugen als Softwarearchitekt
„Wie reden Sie denn mit mir?!?“ – Stakeholder überzeugen als Softwarearchitekt
Hendrik Lösch
 
Software ist was du draus machst!
Software ist was du draus machst!Software ist was du draus machst!
Software ist was du draus machst!
Hendrik Lösch
 
Modular mit .NET
Modular mit .NETModular mit .NET
Modular mit .NET
Hendrik Lösch
 
.NET zu .NET Core
.NET zu .NET Core.NET zu .NET Core
.NET zu .NET Core
Hendrik Lösch
 
Workshop Vue js
Workshop Vue jsWorkshop Vue js
Workshop Vue js
Hendrik Lösch
 
Einstieg in das Vueniverse
Einstieg in das VueniverseEinstieg in das Vueniverse
Einstieg in das Vueniverse
Hendrik Lösch
 
WPF Dos n Don'ts - der WPF Rundumschlag
WPF Dos n Don'ts - der WPF RundumschlagWPF Dos n Don'ts - der WPF Rundumschlag
WPF Dos n Don'ts - der WPF Rundumschlag
Hendrik Lösch
 
Clean mit visual studio
Clean mit visual studioClean mit visual studio
Clean mit visual studio
Hendrik Lösch
 
Advanced Refactoring Patterns
Advanced Refactoring PatternsAdvanced Refactoring Patterns
Advanced Refactoring Patterns
Hendrik Lösch
 
Codesmells
CodesmellsCodesmells
Codesmells
Hendrik Lösch
 
Advanced Refactoring Patterns - Dev Day 2018
Advanced Refactoring Patterns - Dev Day 2018Advanced Refactoring Patterns - Dev Day 2018
Advanced Refactoring Patterns - Dev Day 2018
Hendrik Lösch
 
Der Healthcheck für Softwareprojekte
Der Healthcheck für SoftwareprojekteDer Healthcheck für Softwareprojekte
Der Healthcheck für Softwareprojekte
Hendrik Lösch
 
MVVM mit WPF
MVVM mit WPFMVVM mit WPF
MVVM mit WPF
Hendrik Lösch
 
Ionic 3
Ionic 3Ionic 3
Legacy Code refaktorisieren
Legacy Code refaktorisierenLegacy Code refaktorisieren
Legacy Code refaktorisieren
Hendrik Lösch
 

Mehr von Hendrik Lösch (20)

Why (most) softwareprojects fail silently
Why (most) softwareprojects fail silentlyWhy (most) softwareprojects fail silently
Why (most) softwareprojects fail silently
 
We (don't) need a software architect!?!
We (don't) need a software architect!?!We (don't) need a software architect!?!
We (don't) need a software architect!?!
 
Restrukturierung einer industriellen Großapplikation
Restrukturierung einer industriellen GroßapplikationRestrukturierung einer industriellen Großapplikation
Restrukturierung einer industriellen Großapplikation
 
Vom Monolith zum Modulith
Vom Monolith zum ModulithVom Monolith zum Modulith
Vom Monolith zum Modulith
 
Der Software auf den Zahn gefühlt - Einstieg in die Architekturbewertung
Der Software auf den Zahn gefühlt - Einstieg in die ArchitekturbewertungDer Software auf den Zahn gefühlt - Einstieg in die Architekturbewertung
Der Software auf den Zahn gefühlt - Einstieg in die Architekturbewertung
 
„Wie reden Sie denn mit mir?!?“ – Stakeholder überzeugen als Softwarearchitekt
„Wie reden Sie denn mit mir?!?“ – Stakeholder überzeugen als Softwarearchitekt„Wie reden Sie denn mit mir?!?“ – Stakeholder überzeugen als Softwarearchitekt
„Wie reden Sie denn mit mir?!?“ – Stakeholder überzeugen als Softwarearchitekt
 
Software ist was du draus machst!
Software ist was du draus machst!Software ist was du draus machst!
Software ist was du draus machst!
 
Modular mit .NET
Modular mit .NETModular mit .NET
Modular mit .NET
 
.NET zu .NET Core
.NET zu .NET Core.NET zu .NET Core
.NET zu .NET Core
 
Workshop Vue js
Workshop Vue jsWorkshop Vue js
Workshop Vue js
 
Einstieg in das Vueniverse
Einstieg in das VueniverseEinstieg in das Vueniverse
Einstieg in das Vueniverse
 
WPF Dos n Don'ts - der WPF Rundumschlag
WPF Dos n Don'ts - der WPF RundumschlagWPF Dos n Don'ts - der WPF Rundumschlag
WPF Dos n Don'ts - der WPF Rundumschlag
 
Clean mit visual studio
Clean mit visual studioClean mit visual studio
Clean mit visual studio
 
Advanced Refactoring Patterns
Advanced Refactoring PatternsAdvanced Refactoring Patterns
Advanced Refactoring Patterns
 
Codesmells
CodesmellsCodesmells
Codesmells
 
Advanced Refactoring Patterns - Dev Day 2018
Advanced Refactoring Patterns - Dev Day 2018Advanced Refactoring Patterns - Dev Day 2018
Advanced Refactoring Patterns - Dev Day 2018
 
Der Healthcheck für Softwareprojekte
Der Healthcheck für SoftwareprojekteDer Healthcheck für Softwareprojekte
Der Healthcheck für Softwareprojekte
 
MVVM mit WPF
MVVM mit WPFMVVM mit WPF
MVVM mit WPF
 
Ionic 3
Ionic 3Ionic 3
Ionic 3
 
Legacy Code refaktorisieren
Legacy Code refaktorisierenLegacy Code refaktorisieren
Legacy Code refaktorisieren
 

Confessions of a Codehausmeister

Hinweis der Redaktion

  1. Ersetzen sensibler und instabiler Codebestandteile. Monolithische Anwendung. Ausgiebiges Code Review im Vorfeld.
  2. 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.
  3. Der Kunde ist so vorsichtig geworden, dass er
  4. Bereitstellung eines Applikationsrahmens für unterschiedliche Produkte Umsetzung verschiedener Infrastrukturkomponenten. Konzentration der Produktteams auf Fachspezifika.
  5. 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.
  6. Wer ist eigentlich an der Kommunikation beteiligt.
  7. Verringerung des Ressourcenbedarfs. Optimierung des Quellcodes durch vereinheitlichte Konzepte. Ablösen alter Frameworks durch neue.
  8. 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.
  9. Es gibt keine Bugs oder Fehler, es gilt nur die Frage ob ein Verhalten akzeptabel ist oder nicht.
  10. 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.
  11. 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.
  12. 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.
  13. Am besten hat man nur eines und spricht mit allen darüber.
  14. 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.
  15. Bugs sind entweder so schwerwiegend, dass sie
  16. Bugs sind entweder so schwerwiegend, dass sie zu incidents werden oder sie können wie Features eingeplant werden.
  17. Entkoppeln von Infrastrukturkomponenten. Pflege der Infrastruktur in einem externen Team. Zusammenarbeit auf der gleichen Codebasis.
  18. 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.
  19. 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.
  20. Die Sicherungsmechanismen des Unternehmens für solche Fälle haben gegriffen und schlimmere Eskalationen wurden verhindert.
  21. 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.