PROJEKT-LOG - Klassisch agiles Projektmanagement und mehr
  • Startseite
  • Autoren
  • Lob & Kritik
  • Kontakt
  • Impressum

Kategorien

  • Agile Softwareentwicklung (82)
  • Allgemein (97)
  • Internet (22)
  • Interview (5)
  • Literatur (7)
  • Management (23)
  • Präsentation (44)
  • Projektmanagement (31)
  • Scrum (53)
  • Software (17)
  • Studien & Umfragen (2)
  • Termine (8)
  • Tools (31)
  • Umfrage (3)
  • Zertifizierung (8)
  • Zitate (18)
  • Zusammenarbeit (6)

Partner







Autoren

  • Robert Wiechmann 227
  • Sven Röpstorff 10

Empfehlung

Letzte Artikel

  • 7 interessante Antworten von Felix Rüssel
  • Leseempfehlungen der Woche [2010-07-25]
  • Es gibt keine Deadline…
  • Agile Jobbörse
  • Präsentation über die Macht von Social Media

Weitere Artikel

  • Zitatreife Sprüche & Spruchreife Zitate
  • Mindmaps als Informationsquelle nutzen
  • 6 Monate Scrum - ein Kurzfilm
  • Auf dem Weg vom Projektmanager zum Agile Coach
  • Schätzungen und Oxymora
  • Video - Agile skaliert, Wasserfall nicht
  • Aus 12 mach 13
  • Die magische Schätzmethode
  • Programme für die agile Entwicklung
  • Zitatreife Sprüche & Spruchreife Zitate

Archiv

  • Juli 2010
  • Juni 2010
  • Mai 2010
  • April 2010
  • März 2010
  • Februar 2010
  • Januar 2010
  • Dezember 2009
  • November 2009
  • Oktober 2009
  • September 2009
  • August 2009
  • Juli 2009
  • Juni 2009
  • Mai 2009

Twitter

  • Detailverliebte Inspiration für die nächsten Powerpoint-Slides http://bit.ly/ceZpWj #ppt #präsentieren 11 hrs ago
  • Manager 2.0: The Role of the Manager in Scrum: http://bit.ly/c8YlIi #scrum #management #pmde 2 days ago
  • Ten Principles for Agile Testers | Agile Zone: http://bit.ly/cLSXlw via 4 days ago
  • 10 Tips for Re-energizing Your Day, Every Day: http://bit.ly/a7Rs0G 4 days ago
  • More updates...

Informationen


 RSS Feed abonnieren


Projekt-log.de auf Twitter





Creative Commons License

Anzeige

Schlagwörter

Agil Agile Agile Softwareentwicklung Artikel Backlog Blogbeiträge Buch Empfehlung Entwicklung Estimation Framework Informationen Interessantes Internet Kanban Kommunikation Konferenz Lean Management Meeting Methode News Online Organisation PMI PPT Produktivität Projekt Projektmanagement Präsentation präsentieren Scrum Software Team Tipps Tool Tools User Stories User Story Video Vortrag Weiterbildung XP Zitat Zusammenarbeit

Anzeige

Letzte Kommentare

  • ScrumMaster zu Scrum iPhone Applikationen
  • Susanne zu Ich bin...
  • Andree zu Was Projektmanager tatsächlich den ganzen Tag tun
  • Sven Röpstorff zu Bye bye, Planning Poker?
  • Dirk zu Bye bye, Planning Poker?
  • Sven Röpstorff zu Die vierte Frage im Daily Scrum

Weitere Artikel

  • Projektmanager Typen - Was sind Sie für einer?
  • Wie bei IBM die Transformation zu Agilität und Lean Management vollzogen wurde
  • Auf dem Tablet(t) präsentiert
  • Zitatreife Sprüche & Spruchreife Zitate
  • Die Struktur des Heiligen Grals
  • Zitatreife Sprüche & Spruchreife Zitate
  • Kurze Auszeit auf www.projekt-log.de

Schulden vermeiden

01.01.2010


Innerhalb meines laufenden Projekts musste ich leider in meiner Rolle als Scrum Master die schmerzliche Erfahrung machen, was es bedeutet, eine nicht klar definierte und allgemein gültige Definition of Done (DoD) zu haben. Dies führte uns im Projekt soweit, dass die Entwickler sich den zunehmend auftretenden Fehlern nicht mehr stellen konnten. Dieses Szenario endete in einem Stabilisierungssprint, in dem die angehäuften „technischen Schulden“ beglichen werden mussten. Wie kam es dazu?

Mit Stabilisierungssprint meine ich, dass in diesem Sprint keine Features umgesetzt, sondern lediglich die Überarbeitung des bestehenden Codes und die Eliminierung von Fehlern vorgenommen wurde. Es häufen sich also durch alle vorherigen Sprints so viele Fehler an, dass die aktuelle Arbeit an neuen Features nicht mehr fortgeführt werden kann, da in Scrum gilt: Fehlerbehebung vor Neuentwicklung. Es musste die Notbremse gezogen werden. Ich habe dann kurzfristig eine Sitzung mit dem Team einberufen und ihnen die aktuelle Situation anhand der unten angefügten Präsentation erläutert. Das Meeting sollte dazu dienen die Teammitglieder für die aktuelle Situation zu sensibilisieren, die neue Defintion of Done festzulegen und ein Commitment aller Beteiligten zu erhalten.

Technische Schulden

Folie 1: Das Titelbild habe ich als Anspielung auf etwas Unfertiges, etwas schnell Beendetes oder auch etwas an dem mit Qualität gespart wurde gewählt.

Folie 2: Die Eingangsfrage lautete „Wie können wir zukünftig sicherstellen fertigen und funktionsfähigen Code zu entwickeln?“. Bedeutet „fertig“ auch wirklich der Code muss nicht mehr angefasst werden, die Architektur ist vorbereitet für zukünftige Entwicklungen – spricht der Kunde erhält was ihm versprochen wurde – oder ist der Code eigentlich noch „unfertig“?

Folie 3 & 4: Wird Unfertiges mitgeschleppt, beginnt man Schulden aufzubauen. Die Frage die man dabei stellen muss: „Warum macht man Schulden?“. Natürlich damit man sich aktuell etwas leisten kann, auf das man ansonsten verzichten müsste. In der Softwareentwicklung könnten dies Work arounds oder Nachlässigkeiten bei der Qualität (um Termine zu halten) sein. Im Review Meeting sind diese Fehler nicht sichtbar bzw. es können auch Umwege gefunden werden, diese nicht sichtbar zu machen. Die Fehler summieren sich somit über einzelne Sprints und führen zu dem oben beschriebenen Szenario.

Folie 5 & 6: Blickt man nun auf die Planung, wird eines deutlich. Der anhand der Velocity ermittelte Fertigstellungstermin ist nur ein Scheintermin, da mehr und mehr Arbeit bzw. Schulden angehäuft werden. Der eigentliche Termin verschiebt sich somit um Faktor „x“.

Folie 8: Die Folie zeigt Beispiele für „Done“-Kriterien, die in einer DoD enthalten sein können. Diese galten als Hilfestellung für das Team. Für diesen Teil des Workshops hatte ich am meisten Zeit eingeplant, um mit dem Team eine allgemeingültige und anerkannte Definition of Done zu entwickeln.

Zum Abschluss habe ich noch einmal auf den Vortrag von Robert C. Martin hingewiesen (siehe Artikel). Sein Beispiel bringt es im Grunde auf den Punkt – das Herz guter Software ist der Code. Und guter Code ist ein Versprechen an den Kunden.

  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  • Kategorie: Agile Softwareentwicklung|Präsentation|Scrum
  • Schlagworte: Definition of Done, DoD, Done, Technical Debt
  • Autor: Robert Wiechmann

Weitere Artikel zu diesem Thema

  • Messzahl für die Qualität des Codes
  • Wie stellt man sicher, keinen schlechten Code zu produzieren?
  • Ein Manifest für Softwareentwickler


2 Kommentare zu Schulden vermeiden

Avatar

Frederik

07.01.2010 um 20:50

Hallo Robert,

klasse Artikel! Bei dem Thema Schulden fehlt mir eigentlich nur noch wie man mit “alten Schulden” am Besten umgeht. Zum Beispiel wenn das Team eine Legacy Software übernimmt, muss man sich einarbeiten, man weiss (noch) nicht welche Probleme auftreten werden und wo man vielleicht grössere Baustellen aufräumen muss…

-Frederik

Avatar

Robert Wiechmann

08.01.2010 um 08:17

Hallo Frederik,
vielen Dank für deine Anmerkung, guter Punkt.

Baut man neue Features auf ein Fundament, welches zukünftigen Anforderungen nicht gerecht werden kann, ist ein Schuldenberg wahrscheinlich vorprogrammiert. Irgendwann skaliert die Software nicht mehr, man setzt Workarounds zur Stabilisierung ein oder muss ggf. Abstriche bei besseren Lösungsansätzen leisten…

Daher müssen im Grunde die alten Schulden von denen du sprichst, in die neuen Features und auch Schätzungen einfließen. Es reicht hier nicht, nur die neuen Funktionalitäten zu sehen, sondern ggf. gehört die Evaluation der bestehenden Architektur und des Codes dazu. Auch Refactorings des bestehenden Codes sind u.U. zu berücksichtigen.

Beste Grüße,
Robert

Kommentare

top

Copyright ® 2010 - PROJEKT-LOG  RSS Feed abonnieren

Blogverzeichnis - Blog Verzeichnis bloggerei.deblogoscoop