Upload
mayflower-gmbh
View
160
Download
1
Embed Size (px)
Citation preview
© 2016 Mayflower GmbH
International PHP Conference, München 26. Oktober 2016 Martin Ruprecht
Mit Maintenance umgehen können- fixt du noch Bugs oder lieferst du schon neue Features?
„Wir sind hier an zwei Fronten tätig, neben den neuen Features sind wir
auch für die Maintenance des Systems zuständig“
Zitat des Product Owners
Für Fehleranalyse und Verbesserung von freiem Code
braucht das Kurzzeitgedächtnis den Kontext von dazu.
Maintenance
Kontinuierlicher Aufbau von Wissen
Featureentwicklung
Sprint Planning Meeting
Sprint Refinement Meetings
Pair Programming
Code Reviews
Architektur Planning Meeting
Lightning Talks
Brownbag Sessions
Slacktime
Maintenance und Featureentwicklung parallel
Ich muss mich in den Bereich wo es passiert erst
einarbeiten und verliere damit das Kurzzeitgedächtnis für die eigentlichen Tasks, an
denen ich sitze.
Entweder langsamer in der Maintenance
Maintenance und Featureentwicklung parallel
Licence: Public Domain
oder langsamer in der Featureentwicklung
Maintenance und Featureentwicklung parallel
Licence: Public Domain
Der Product Owner priorisiert die Arbeit aus beiden Töpfen:
Maintenance und Featureentwicklung
Strategien: Ein Team
Jedes Team kümmert sich jeweils ausschliesslich um
seine Aufgabe - Maintenance oder Featureentwicklung
Strategien: Zwei Teams
Es gibt 1-5 Maintenance-Guys pro Sprint, die sich um Maintenance-Themen
kümmern.
Strategien: Maintenance-Guy
Strategien
Ein Team, fixes Gesamtbudget für Features & Maintenance über das
ProjektLicence: Public Domain
Der Product Owner bestimmt das Feature - und
Maintenance-Budget pro Sprint.
Strategien: Ein Team, Budget für FE und Maintenance
Ein Team Zwei Teams Maintenance Tage
Maintenance Guys
1 Team, FE & M. Budget
Produkt-Weiterentwicklung + ++ ++ ++ +
Maintenance-Geschwindigkeit + + 0 0/+ +
Wissen-Silos ++ — + 0 0
Fokus/Kontext - + - + 0
Zuverlässigkeit - + + 0 0
Ausgeglichenheit ++ — — — +
© 2016 Mayflower GmbH
Diskussion: Welche Strategien kennt? Welche habt ihr schon probiert? Welche Auswirkungen hatten die Strategien? (International PHP Conference, München 26.10.2016: Mitschrift der Diskussion auf der folgenden Folie)
Frage von Martin Ruprecht: „Welche Strategien kennt/verfolgt ihr?“- „Wir haben ein Team das sich nur um Maintenance kümmert, allerdings nur bis zu einem gewissen Grad. Wir kategorisieren die Bugs in Klassen, wird z.B. ein critical Bug nicht in 4Std. gefixt, wird ein „Experte“ aus dem Entwickler-Team hinzugezogen.“
- „Wir haben für Maintenance ein fixes Zeitbudget, je nach Dringlichkeit werden damit Bugs gefixt.“
Frage aus dem Publikum: „Ist es nicht falsch zwei Teams zu haben mit fix getrennten Themenbereichen- werden da nicht automatisch Wissens-Silos aufgebaut?“- Antwort Martin: „Du hast völlig recht! In einer optimalen Welt sollte ein Feedback Kanal etabliert werden um zum einen das Wissen zu einem Bugfix wieder in das Team zurück zutragen. Und zum anderen sollten alle Projektbeteiligten über die Entwicklung neuer Features Bescheid wissen.“
Frage aus dem Publikum: „Wie habt ihr Bugs kategorisiert?“- Antwort Martin: „Wir hatten vier Klassen von Bugs. Eins: Businesskritischer Bug- alle Kraft sollte darauf verwendet werden diesen Bug zu fixen (weil z.B. keine Buchung erfolgen kann), Zeitraum zum fixen: sofort. Zwei: High Prio Bug- es ist zwar eine gewisse Funktionalität gegeben aber nicht im gewünschten Format, Zeitraum zum fixen: in max. 2 Tagen. Drei: Medium Bug: Der Fehler hat nahezu keine Auswirkung auf die Funktionalität, Zeitraum zum fixen: einen Sprint (2Wochen). Vier: Low Prio Bug, die Funktionalität ist vollständig gegeben, andere Fixes sind erwünscht (z.B. kosmetische Änderungen), Zeitraum zum fixen: 2 Sprints“
Vielen Dank für Ihre Aufmerksamkeit!
© 2013 Mayflower GmbH
Kontakt Martin Ruprecht [email protected] +49 89 24 20 54 1116
Mayflower GmbH Mannhardtstr. 6 80538 München