von TDD, Continuous Integration bis Continuous Delivery

Arbeitsbereich für den Abstract

 

Roter Faden durch das 5-seitige Kapitel:

  1. Einleitung
    • Ein wichtiger Aspekt der Qualitätssicherung ist, Fehler und Fehlentwicklungen möglichst nahe zu ihrem Entstehen zu entdecken. Je später ein Fehler gefunden wird, desto höher sind die Fehlerbehebungskosten ("10er-Regel"). (1 Seite)
  2. TDD (Test Driven Development) lässt frühzeitig Softwareentwickler vor der Entwicklung überlegen, wie das Stück Software Integriert und dann dessen "Qualität" hinsichtlich definierter Qualitätsmerkmale (Performance, Usability, funktionale Korrektheit, ...) überprüft wird. (1 Seite)
  3. Continuos Integration und Continuous Delivery sind wichtige Schritte zur frühzeitigen Qualitätsüberprüfung und zum schrittweisen Aufbau des Produktes. (1 Seite)
    • Vorteile:
      • Fehlentwicklungen und Fehler in Basisfunktionen können sehr früh entdeckt und behoben werden
      • Wenn die Planung die kritischen und schwierigen Teile für die Umsetzung hoch priorisiert, dann werden diese bei jeder (Teil-)Integration implizit mitgetestet
      • die künftigen Benutzer bzw. deren Vertreter können früh das Look-and-feel beurteilen und Feedback geben.
  4. Herausforderungen für Continous Integration (2 Seiten)
    • Technisch müssen die Systeme dafür ausgelegt sein (Testsystem, Daily build, ...)
    • Organisatorisch muss die Sprintplanung zur Continous Integration passen 
  5. Abschluss mit Timeboxing und Continous Delivery
    • Frage ob der Konnex mit Timeboxing hier soviel Mehrwert gibt?

 

Eventuell Verweis auf Agiles Projektmanagement mit Critical Chain und Reliable/Ultimate Scrum zum Kapitel über Reliable Scrum. 

 

 

 

Twittern
  • Keine Stichwörter

Kommentar

  1. Hallo Johann, wir haben dieses Kapitel ursprünglich mal aufgenommen. Heute bin ich mir nicht mehr so sicher, ob dies eine gute Idee war. Es geht in der bisherigen Denke sehr stark in Richtung IT. Wenn wir das Thema so ausgestalten können, dass mittels CI das agile Mindset auf der Verhaltensebene für alle Anwendungsfälle ausgestaltet wird und IT nur ein Beispiel ist, fände ich dies sehr gut. Das Kapeitel sollte einen Mehrwert für alle Agilisten liefern. Gruß Alfred

Dieser Inhalt von openPM steht unter einer Creative Commons Lizenz (CC BY 3.0) und kann frei verwendet werden unter Namensnennung durch Link auf http://openpm.info. Unpassende Inhalte, insbesondere Verstöße gegen Urheberrechte, bitte via info@openpm.info melden. Weitere Informationen unter Nutzungsbedingungen