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.

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. Martin Ruprecht
martin.ruprecht@mayflower.de
@mrupilo

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

5. 13 %
6 %
63 %
19 %
Maintenance Entwicklung Spikes Architektur Meeting

7. 8 %
10 %
4 %
18 % 61 %
Maintenance Entwicklung Spikes Architektur Meeting Weiterbildung

8. Maintenance
neue
F
e
a
t
u
r
e
sLicence: Public Domain
Das Dilemma

9. Was macht
Maintenance parallel
zur Featureentwicklung
so schwierig?

10. Für Fehleranalyse und
Verbesserung von freiem Code
braucht das Kurzzeitgedächtnis
den Kontext von dazu.
Maintenance

11. Kontext:
Welchen Code dazu gibt
es?
Maintenance

12. Kontext:
Wie hängt der Code
zusammen?
Maintenance

13. Ich muss mich in den
Bereich wo es passiert
erst einarbeiten!
Maintenance

14. Kontinuierlicher Aufbau
von Wissen
Featureentwicklung
Sprint Planning
Meeting
Sprint Refinement
Meetings
Pair Programming
Code Reviews
Architektur
Planning Meeting
Lightning Talks
Brownbag Sessions
Slacktime

15. 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.

16. Das Team wird langsamer!
Maintenance und Featureentwicklung parallel
Licence: Public Domain

17. Entweder langsamer in der Maintenance
Maintenance und Featureentwicklung parallel
Licence: Public Domain

18. oder langsamer in der Featureentwicklung
Maintenance und Featureentwicklung parallel
Licence: Public Domain

19. Planen ist nicht mehr möglich!
Maintenance und Featureentwicklung parallel
Licence: Public Domain

20. Der Marktdruck steigt
Maintenance und Featureentwicklung parallel
Licence: Public Domain

21. Technical Debt wird akzeptiert
Maintenance und Featureentwicklung parallel
Licence: Public Domain

22. EinTeufelskreis entsteht!
Maintenance und Featureentwicklung parallel
Licence: Public Domain

23. Kunden werden
unzufrieden!
Maintenance und Featureentwicklung parallel
Licence: Public Domain

24. Kollegen werden
unzufrieden!
Maintenance und Featureentwicklung parallel
Licence: Public Domain

25. Maintenance
neue
F
e
a
t
u
r
e
sLicence: Public Domain
Das Dilemma

26. Was gilt es bei einer
Parallelisierung zu
beachten?

27. Produkt -
Weiterentwicklung

28. Maintenance-
Geschwindigkeit

29. Wissens-
Silos

30. Fokus/
Kontext

31. Zuverlässigkeit

32. Ausgeglichenheit

33. Mit welchen Strategien
kann ich das
Dilemma umgehen?

34. Ein Team
Strategien
Licence: Public Domain

35. Der Product Owner priorisiert die
Arbeit aus beiden Töpfen:
Maintenance und
Featureentwicklung
Strategien: Ein Team

36. Strategien
Zwei TeamsLicence: Public Domain Licence: Public Domain

37. Jedes Team kümmert sich
jeweils ausschliesslich um
seine Aufgabe - Maintenance
oder Featureentwicklung
Strategien: Zwei Teams

38. Maintenance-Tage
Strategien
Licence: Public Domain

39. Es gibt ein Team,
bestimmteTage sind für
Maintenance reserviert
Strategien: Maintenance-Tage

40. Strategien
Maintenance-
Guys
Licence: Public Domain

41. Es gibt 1-5 Maintenance-Guys
pro Sprint, die sich um
Maintenance-Themen
kümmern.
Strategien: Maintenance-Guy

42. Strategien
Ein Team,
fixes Gesamtbudget für Features & Maintenance über das
ProjektLicence: Public Domain

43. Der Product Owner
bestimmt das Feature - und
Maintenance-Budget pro Sprint.
Strategien: Ein Team, Budget für FE und Maintenance

44. Welche Strategie soll
ich wählen?

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

46. Parallelbetrieb bedeutet
immer ein abwägen an Scope:
was mache ich- was nicht

47. Unsere Learnings:

48. Kontext-Wechsel
und
„Wieder lernen vonThemen“
kostet Zeit

49. Wir kennen nun die
Auswirkungen der vorgestellten
Strategien und können damit
besser umgehen!

50. © 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)

51. 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“

52. © 2016 Mayflower GmbH
martin.ruprecht@mayflower.de
@mrupilo
Feedback please!

53. 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

54. © 2016 Mayflower GmbH
Bildnachweis:
Alle gewählten Bilder unterliegen der Public Domain und sind
frei verfügbar.