Zu viele Softwareprojekte leiden unter Technischen Schulden. Sogar wenn sich die Betroffenen beschweren über schlechten Code, Änderungen sehr aufwändig sind, die Gefahr Fehler einzubauen steigt, der Fortschritt immer langsamer wird - nicht immer fühlt sich jemand verantwortlich, die Lage zu ändern. Es muss jemanden geben, der die Verantwortung übernimmt und langfristig für eine hohe Codequalität sorgt, damit fortlaufend Wertsteigerndes ausgeliefert werden kann: der Technical Debt Manager. Im Vortrag werden seine Aufgaben und benötigten Fähigkeiten herausgearbeitet sowie der Bezug zu anderen Rollen - insbesondere den Architekten - dargestellt.

1. Der Technical Debt Manager
JUG Saxony Day 2017
Jens Nerche
@jensnerche
http://techblog.kontext-e.de

2. Worum geht‘s?
Warum?
Aufgaben
Diskussion
… und der Architekt?

3. Definition Technische Schluden
Zengyang Li, Paris Avgeriou, Peng Liang:
„Technical debt (TD) is a metaphor reflecting technical
compromises that can yield short-term benefit
but may hurt the long-term health of a software
system.“
(Paper A systematic mapping study on technical debt and its management)

4. Aber wer behält den Überblick?
Jeder ein bisschen?
„Verantwortung ist nicht teilbar.“
Verantwortungsdiffusion
Dedizierte Rolle:
„Technical Debt Manager“

5. Aufgaben
sammeln dokumentieren
bewerten priorisieren
Rückzahlung planen (Rückzahlung überwachen)

6. Stakeholder
Aufgaben

7. Sprint 1 Sprint 5 Sprint 10 Sprint 20
0
1
2
3
4
5
6
7
8
9
10
Velocity
Deliver Value Constantly
Traurige Wahrheit
Erwartung
Sprint
StoryPoints

8. Wurzel-Ursachen angehen
(„Root-Cause-Analysis“)
Team
Management
Kundenerwartungen
Ops
...

9. Menschen
„The code got that way for a reason, & if you can't
change people's habits,
it'll just re-messify again after the refactoring.“
Sarah Mei (@sarahmei) on Twitter
https://twitter.com/sarahmei/status/715639963274969088

10. Skills, die dabei hilfreich sind
Geduld und ein langer AtemGeduldGeduld
Soziale Kompetenz
Mit Management reden können: Investitionen in
Clean Code begründen können, ROI abschätzen,
Risiken des vorhandenen TD
einschätzen und kommunizieren
Schlitzohrigkeit im positiven Sinne, Chuzpe, Listigkeit

11. Ist das alles nicht
eigentlich eine Aufgabe
für den
Softwarearchitekt?

12. Dietrich, 62 Jahre, verheiratet
Hamburg
Modelleisenbahn
Softwarearchitekt
„Haben wir schon immer so gemacht“
Programmiert nicht mit
Erstellt Dokumentation mit Bildern
in eigener Notation, meist ohne
Legende
Denkt lange über optimale (überladene)
Architektur nach
Hat Anschluss an technologische
Entwicklung verloren

13. Großes Projekt, großes, agiles Team
Muss an vielen Sitzungen teilnehmen
Oft beim Kunden
Noch andere Aufgaben,
z.B. Bewerbungsgespräche
hat nicht so viel Zeit fürs Programmieren
wie sie gerne hätte
sieht die Probleme, hat aber zu wenig
Zeit sich selbst darum zu kümmern
Susann, 45 Jahre, ledig
Leipzig
Ehrenamt bei DKMS
Diplommathematikerin

14. Marco, 34 Jahre
Berlin
Fußball
Software Craftsman
Elternzeit, dann Teilzeit
Muss aus vertraglichen Gründen
Architekten-Rolle weiterhin übernehmen
Erfahrenes, eingespieltes Team
Projekt läuft schon einige Zeit, wichtige
Entscheidungen sind getroffen, viele
ähnliche Masken, Use Cases, ... müssen
"nur noch" hinzugefügt werden
Kein Problem wenn Architekt für gewisse
Zeit kürzer arbeitet

15. Hannah, 28 Jahre, verliebt
Köln
Schlagzeug, JUG Orga Team
Team Lead
"Pizzateam" (gemeinsames Pizzabacken)
Besucht mit ihrem Team die
Sachbearbeiter, beobachtet Abläufe,
„Interviews“ in Kaffeeküche
Achtet auf Clean Code
Pair Programming, Code Reviews
Organisiert Coding Dojos und Code
Retreats
Continuous Delivery

16. Robert, 37 Jahre, geschieden
München
Kaninchenzucht
Architekt
Architekt, weil er der einzige
Festangestellte im Projekt ist
Wurde vom Management eingesetzt, evtl.
leicht überfordert
Mangel an Qualifikation und/oder
Interesse
Andere Sachen wie Deadlines, Features
usw. sind wichtiger als Codequalität
Codequalität, Infrastruktur, ... leidet

17. Technischer Projektleiter,
Systemarchitekt,
Berater und Autor
Mitglied des C++-DIN-Arbeitskreises

18. "Es geht um die Frage, ob es nicht an der Zeit ist, die
Tatsache zu akzeptieren, dass Code immer in einem
mehr oder weniger miesen Zustand ist."
Nicolai Josuttis, Blogpost auf heise Developer

19. „We must finally accept that code will be crap and so
we must ???“
ACCU 2009

20. ??? = introduce the role of a Technical Debt Manager
JUG Saxony 2017

21. Ich kümmere mich ab jetzt um die
Technischen Schulden:
Ich fühle mich verantwortlich
Ich forme mein T: Weiterbildung
Mache mir die betreffenden Tickets im Backlog zu eigen
Betrachte Legacy Code, mangelnde Infrastruktur etc. nicht
als Last, sondern als interessante Herausforderung

22. Ich forme durch mein Verhalten und meine Kompetenz
eine Kultur des Clean Code und Bewusstseins für
Technische Schulden.
Ich kümmere mich ab jetzt um die
Technischen Schulden:

23. Quellen
Nicolai Josuttis
https://www.heise.de/developer/artikel/Handwerkskunst-versus-miese-Realit
aet-353161.html
Uncle Bob citing Nicolai Jossutis
https://sites.google.com/site/unclebobconsultingllc/crap-code-inevitable--rum
blings-from-accu
http://avatarmaker.com/
Jusottis Bild: https://programutvikling.no/en/instructor/nicolai-josuttisis

24. Jens Nerche
Kontext E GmbH
Softwarearchitektur, Technischen Schulden, Brownfield-
Projekte, Agile Softwareentwicklung, Domänenspezifische
Sprachen
Email j.nerche@kontext-e.de
Twitter @jensnerche
Blog http://techblog.kontext-e.de
Homepage www.kontext-e.de
Folien Slideshare