© 2016 Mayflower GmbH
International PHP Conference, München 26. Oktober 2016

Martin Ruprecht
Mit Maintenance umgehen könne...
Martin Ruprecht
martin.ruprecht@mayflower.de
@mrupilo
„Wir sind hier an zwei Fronten tätig, 

neben den neuen Features sind wir
auch für die Maintenance des
Systems zuständig“
...
13 %
6 %
63 %
19 %
Maintenance Entwicklung Spikes Architektur Meeting
8 %
10 %
4 %
18 % 61 %
Maintenance Entwicklung Spikes Architektur Meeting Weiterbildung
Maintenance
neue
F
e
a
t
u
r
e
sLicence: 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
C...
Maintenance und Featureentwicklung parallel
Ich muss mich in den
Bereich wo es passiert erst
einarbeiten und verliere
dami...
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 steigt
Maintenance und Featureentwicklung parallel
Licence: Public Domain
Technical Debt wird akzeptiert
Maintenance und Featureentwicklung parallel
Licence: Public Domain
EinTeufelskreis 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
F
e
a
t
u
r
e
sLicence: 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 ...
Maintenance-Tage
Strategien
Licence: Public Domain
Es gibt ein Team,
bestimmteTage 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 Mainte...
Welche Strategie soll
ich wählen?
Ein Team Zwei Teams
Maintenance
Tage
Maintenance
Guys
1 Team, FE &
M. Budget
Produkt-
Weiterentwicklung + ++ ++ ++ +
Maint...
Parallelbetrieb bedeutet
immer ein abwägen an Scope:
was mache ich- was nicht
Unsere Learnings:
Kontext-Wechsel 

und
„Wieder lernen vonThemen“
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 S...
Frage von Martin Ruprecht: „Welche Strategien kennt/verfolgt ihr?“
- „Wir haben ein Team das sich nur um Maintenance kümme...
© 2016 Mayflower GmbH
martin.ruprecht@mayflower.de
@mrupilo
Feedback please!
Vielen Dank für Ihre Aufmerksamkeit!
© 2013 Mayflower GmbH
Kontakt Martin Ruprecht
martin.ruprecht@mayflower.de
+49 89 24 20...
© 2016 Mayflower GmbH
Bildnachweis:
Alle gewählten Bilder unterliegen der Public Domain und sind
frei verfügbar.
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
Nächste SlideShare
Wird geladen in …5
×

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

294 Aufrufe

Veröffentlicht am

Nach dem erfolgreichen Launch einer Software gibt es immer das gleiche Dilemma: Neue Features konkurrieren mit Bugs und Anpassungen an der bestehenden Software, die aus dem operativen Betrieb kommen. Und die Gretchenfrage nach dem dringenden und dem wichtigsten stellt sich kontinuierlich und es braucht einen Mechanismus um diese zu Balancieren. Ich möchte die Auswirkungen von Maintenance parallel zur Produktentwicklung aufzeigen, die Folgeprobleme benennen und Strategien vorstellen um dieses Dilemma zu umgehen.

Veröffentlicht in: Software
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
294
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
1
Aktionen
Geteilt
0
Downloads
1
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

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

  1. 1. © 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?
  2. 2. Martin Ruprecht martin.ruprecht@mayflower.de @mrupilo
  3. 3. „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
  4. 4. 13 % 6 % 63 % 19 % Maintenance Entwicklung Spikes Architektur Meeting
  5. 5. 8 % 10 % 4 % 18 % 61 % Maintenance Entwicklung Spikes Architektur Meeting Weiterbildung
  6. 6. Maintenance neue F e a t u r e sLicence: Public Domain Das Dilemma
  7. 7. Was macht Maintenance parallel 
 zur Featureentwicklung so schwierig?
  8. 8. Für Fehleranalyse und Verbesserung von freiem Code braucht das Kurzzeitgedächtnis den Kontext von dazu. Maintenance
  9. 9. Kontext: 
 Welchen Code dazu gibt es? Maintenance
  10. 10. Kontext: 
 Wie hängt der Code zusammen? Maintenance
  11. 11. Ich muss mich in den Bereich wo es passiert erst einarbeiten! Maintenance
  12. 12. Kontinuierlicher Aufbau von Wissen Featureentwicklung Sprint Planning Meeting Sprint Refinement Meetings Pair Programming Code Reviews Architektur Planning Meeting Lightning Talks Brownbag Sessions Slacktime
  13. 13. Maintenance und Featureentwicklung parallel Ich muss mich in den Bereich wo es passiert erst einarbeiten und verliere damit das Kurzzeitgedächtnis für die eigentlichenTasks, an denen ich sitze.
  14. 14. Das Team wird langsamer! Maintenance und Featureentwicklung parallel Licence: Public Domain
  15. 15. Entweder langsamer in der Maintenance Maintenance und Featureentwicklung parallel Licence: Public Domain
  16. 16. oder langsamer in der Featureentwicklung Maintenance und Featureentwicklung parallel Licence: Public Domain
  17. 17. Planen ist nicht mehr möglich! Maintenance und Featureentwicklung parallel Licence: Public Domain
  18. 18. Der Marktdruck steigt Maintenance und Featureentwicklung parallel Licence: Public Domain
  19. 19. Technical Debt wird akzeptiert Maintenance und Featureentwicklung parallel Licence: Public Domain
  20. 20. EinTeufelskreis entsteht! Maintenance und Featureentwicklung parallel Licence: Public Domain
  21. 21. Kunden werden unzufrieden! Maintenance und Featureentwicklung parallel Licence: Public Domain
  22. 22. Kollegen werden unzufrieden! Maintenance und Featureentwicklung parallel Licence: Public Domain
  23. 23. Maintenance neue F e a t u r e sLicence: Public Domain Das Dilemma
  24. 24. Was gilt es bei einer Parallelisierung zu beachten?
  25. 25. Produkt -
 Weiterentwicklung
  26. 26. Maintenance- Geschwindigkeit
  27. 27. Wissens-
 Silos
  28. 28. Fokus/
 Kontext
  29. 29. Zuverlässigkeit
  30. 30. Ausgeglichenheit
  31. 31. Mit welchen Strategien kann ich das 
 Dilemma umgehen?
  32. 32. Ein Team Strategien Licence: Public Domain
  33. 33. Der Product Owner priorisiert die Arbeit aus beiden Töpfen: Maintenance und Featureentwicklung Strategien: Ein Team
  34. 34. Strategien Zwei TeamsLicence: Public Domain Licence: Public Domain
  35. 35. Jedes Team kümmert sich jeweils ausschliesslich um 
 seine Aufgabe - Maintenance oder Featureentwicklung Strategien: Zwei Teams
  36. 36. Maintenance-Tage Strategien Licence: Public Domain
  37. 37. Es gibt ein Team, bestimmteTage sind für Maintenance reserviert Strategien: Maintenance-Tage
  38. 38. Strategien Maintenance- Guys Licence: Public Domain
  39. 39. Es gibt 1-5 Maintenance-Guys pro Sprint, die sich um Maintenance-Themen kümmern. Strategien: Maintenance-Guy
  40. 40. Strategien Ein Team, 
 fixes Gesamtbudget für Features & Maintenance über das ProjektLicence: Public Domain
  41. 41. Der Product Owner bestimmt das Feature - und Maintenance-Budget pro Sprint. Strategien: Ein Team, Budget für FE und Maintenance
  42. 42. Welche Strategie soll ich wählen?
  43. 43. 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 ++ — — — +
  44. 44. Parallelbetrieb bedeutet immer ein abwägen an Scope: was mache ich- was nicht
  45. 45. Unsere Learnings:
  46. 46. Kontext-Wechsel 
 und „Wieder lernen vonThemen“ kostet Zeit
  47. 47. Wir kennen nun die Auswirkungen der vorgestellten Strategien und können damit besser umgehen!
  48. 48. © 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)
  49. 49. 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“
  50. 50. © 2016 Mayflower GmbH martin.ruprecht@mayflower.de @mrupilo Feedback please!
  51. 51. Vielen Dank für Ihre Aufmerksamkeit! © 2013 Mayflower GmbH Kontakt Martin Ruprecht martin.ruprecht@mayflower.de +49 89 24 20 54 1116 Mayflower GmbH Mannhardtstr. 6 80538 München
  52. 52. © 2016 Mayflower GmbH Bildnachweis: Alle gewählten Bilder unterliegen der Public Domain und sind frei verfügbar.

×