54
© 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?

Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue Features

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?

Martin Ruprecht

[email protected]@mrupilo

„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

13 %

6 %

63 %

19 %

Maintenance Entwicklung Spikes Architektur Meeting

8 %

10 %

4 %

18 % 61 %

Maintenance Entwicklung Spikes Architektur Meeting Weiterbildung

Maintenance

neue

FeaturesLicence: Public Domain

Das Dilemma

Was macht Maintenance parallel

zur Featureentwicklung so schwierig?

Für Fehleranalyse und Verbesserung von freiem Code

braucht das Kurzzeitgedächtnis den Kontext von dazu.

Maintenance

Kontext: Welchen Code dazu gibt

es?

Maintenance

Kontext: Wie hängt der Code

zusammen?

Maintenance

Ich muss mich in den Bereich wo es passiert

erst einarbeiten!

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.

Das Team wird langsamer!

Maintenance und Featureentwicklung parallel

Licence: Public Domain

Entweder langsamer in der Maintenance

Maintenance und Featureentwicklung parallel

Licence: Public Domain

oder langsamer in der Featureentwicklung

Maintenance und Featureentwicklung parallel

Licence: Public Domain

Planen ist nicht mehr möglich!

Maintenance und Featureentwicklung parallel

Licence: Public Domain

Der Marktdruck steigtMaintenance und Featureentwicklung parallel

Licence: Public Domain

Technical Debt wird akzeptiert

Maintenance und Featureentwicklung parallel

Licence: Public Domain

Ein Teufelskreis entsteht!

Maintenance und Featureentwicklung parallel

Licence: Public Domain

Kunden werden unzufrieden!

Maintenance und Featureentwicklung parallel

Licence: Public Domain

Kollegen werden unzufrieden!

Maintenance und Featureentwicklung parallel

Licence: Public Domain

Maintenance

neue

FeaturesLicence: Public Domain

Das Dilemma

Was gilt es bei einer Parallelisierung zu

beachten?

Produkt - Weiterentwicklung

Maintenance- Geschwindigkeit

Wissens- Silos

Fokus/Kontext

Zuverlässigkeit

Ausgeglichenheit

Mit welchen Strategien kann ich das

Dilemma umgehen?

Ein Team

Strategien

Licence: Public Domain

Der Product Owner priorisiert die Arbeit aus beiden Töpfen:

Maintenance und Featureentwicklung

Strategien: Ein Team

Strategien

Zwei TeamsLicence: Public Domain Licence: Public Domain

Jedes Team kümmert sich jeweils ausschliesslich um

seine Aufgabe - Maintenance oder Featureentwicklung

Strategien: Zwei Teams

Maintenance-Tage

Strategien

Licence: Public Domain

Es gibt ein Team, bestimmte Tage sind für Maintenance reserviert

Strategien: Maintenance-Tage

Strategien

Maintenance-Guys

Licence: Public Domain

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

Welche Strategie soll ich wählen?

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 ++ — — — +

Parallelbetrieb bedeutet immer ein abwägen an Scope:

was mache ich- was nicht

Unsere Learnings:

Kontext-Wechsel und

„Wieder lernen von Themen“ kostet Zeit

Wir kennen nun die Auswirkungen der vorgestellten

Strategien und können damit besser umgehen!

© 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“

© 2016 Mayflower GmbH

[email protected]

@mrupilo

Feedback please!

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

© 2016 Mayflower GmbH

Bildnachweis: Alle gewählten Bilder unterliegen der Public Domain und sind frei verfügbar.