Wie schon in “Qualitätsinvestition statt technischer Schulden” angedeutet ist die reine Ermittlung der technischen Schulden (z.B. in Manntagen) nur eine Seite der Medaille. Insgesamt ist Technical Debt nicht per se schlecht und manchmal sogar unvermeidlich. So wie es sinnvoll ist einen Kredit für einen Hauskauf aufzunehmen kann es bei der Entwicklung neuer Features sinnvoll sein bewusst Qualitätskompromisse einzugehen um dieses Mal schneller am Markt zu sein (weil es sonst vielleicht kein nächstes Mal gibt). Wichtig ist in beiden Fällen sich die gemachten Schulden bewusst zu machen, zu wissen wie man die gemachten Schulden zurückzahlt und das natürlich auch explizit zu tun (im Rahmen eines Rückzahlungs- oder Finanzierungsplans). Finanzielle Schulden sind leicht messbar (da reicht ein Blick auf den Kontoauszug), technische Schulden nicht. Das führt in Unternehmen leider oft dazu dass für die gemachten Schulden kein Bewusstsein entsteht weil diese nicht explizit sichtbar sind.
Es ist darum wichtig die gemachten technischen Schulden sichtbar zu machen und möglichst objektiv zu beziffern, da dies die Grundlage zum "Technical Debt Management", d.h. zur Schuldenrückzahlung bildet. Allgemein finden sich im Netz unter dem Suchbegriff "Managing Technical Debt" viele gute Informationen. Ein paar sehr hilfreiche habe ich hier zusammengetragen:
- Managing Technical Debt (InfoQ Article, 06/2013)
- The Solution to Technical Debt (Henrik Kniberg, Crips's Blog, 07/2012)
- Identifying and managing Technical Debt (Nico Zazworka, SlideShare, 06/2012)
- Managing Technical Debt (Eric Allman, ACM Queue, 03/2012)
- Be thoughtful when measuring technical debt with Sonar (Sven Johann, Trifork Blog, 09/2012)
- Managing Technical Debt (Srinath Ramakrishnan, ScrumAlliance, 06/2013)
- Technical Debt (Steve McConnell, Construx article, 2007)
- Paying Down Your Technical Debt (Jeff Atwood, Coding Horror, 2009)
- ComputerWoche:
- Schuldenfallen im Sourcecode (02/2013)
- Softwarereparaturen fehlen in der Budgetplanung (01/2012)
- Kein Budget für Softwarereparaturen? (01/2012)
- Die Codeanalyse allein reicht nicht (08/2011)
- Keine Angst vor versteckten Kosten (03/2011)
No comments:
Post a Comment