Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue Features
0 gefällt mir1,944 aufrufe
Das Dokument behandelt die Herausforderungen und Strategien bei der parallelen Entwicklung neuer Features und der Wartung bestehender Systeme in der Softwareentwicklung. Es wird auf die Notwendigkeit hingewiesen, Wartungskontexte zu berücksichtigen und die Teamdynamik zu optimieren, um Wissenssilos zu vermeiden. Verschiedene Strategien wie die Schaffung von Wartungsteams oder das Einführen fester Wartungstage werden diskutiert, um die Balance zwischen Wartung und Featureentwicklung zu halten.
Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue Features
- 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?
- 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
- 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
- 26. Was gilt es bei einer Parallelisierung zu beachten?
- 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
- 39. Es gibt ein Team, bestimmteTage sind für Maintenance reserviert Strategien: Maintenance-Tage
- 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
- 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.